lexsas TR
SECURITY AND DATA

Security and data handling

Two different things are usually mixed together under this heading: what a website does, and what a workflow does. They are separated below. The second half is honest about what is decided with each client rather than promised to everybody in advance. A promise made to everybody in advance is usually the one that turns out to be conditional.

Last reviewed 18 October 2026.

This site

  1. 1.1This site sets no cookies. It runs no analytics, no tag manager and no tracking pixel.
  2. 1.2It loads nothing from a third party, its fonts included, which are served from this domain. A content security policy restricts what the pages may load, and there is no third party in it to restrict.
  3. 1.3Who is responsible. For personal data that reaches me through this site, the data controller is Asım Serdar Yılmaz. LEXSAS is the name of the venture I run personally in Istanbul; it is not a separate company. Contact: serdar@lexsas.com.
  4. 1.4What is processed, and why. There is no form on this site, so nothing is submitted anywhere; personal data reaches me only through an email you choose to send. If you write to me, I process your name, your email address, the content of your message and anything in it, to read and answer it and, if we decide to work together, to scope that work. The legal basis is KVKK Article 5(2)(c) where the message concerns setting up a contract, and otherwise my legitimate interest in answering correspondence (Article 5(2)(f)); where the GDPR applies, Articles 6(1)(b) and 6(1)(f). Your address is not added to a list, because there is no list, and it is not used for marketing.
  5. 1.5Who handles it, and where. Email to lexsas.com is delivered and stored by Google (Google Workspace). The site is hosted on GitHub Pages; GitHub records visitors’ IP addresses in its server logs under its own privacy statement, I have no access to those logs, and I build no profile from them. Both providers may process data on servers outside Türkiye; that transfer is made in accordance with KVKK Article 9. If you ask, I will tell you by email which Article 9 route it relies on. I share your message with no one else.
  6. 1.6How long. Correspondence that does not lead to an engagement is deleted within twelve months of the last message. Correspondence that does is kept with the engagement record for the period agreed in that engagement.
  7. 1.7Your rights. Under KVKK Article 11 you may ask whether your data is processed and for information about it, learn the purpose and whether it is used for that purpose, know who it is transferred to, ask for correction or, where the conditions are met, deletion, and for recipients to be told, object to an adverse result produced solely by automated analysis, and claim compensation for unlawful processing. Where the GDPR applies you have the rights in its Articles 15 to 21 and may complain to your supervisory authority. To exercise them, write to serdar@lexsas.com from the address you wrote to me from. If you would rather apply in writing, or no longer have that address, write to me and I will send you a postal address for a written application. I answer within thirty days, free of charge. In Türkiye the complaint route is the Personal Data Protection Board.
  8. 1.8The limit. What this section says about cookies, analytics and third-party loads can be checked in the page source; the providers’ server logs and mail storage cannot. The policy is delivered inside the page, so it cannot stop another site from framing these pages; nothing here takes input, so a framed page can show the site but cannot act for you.

Where a workflow runs

  1. 2.1Workflows are designed to run inside your own environment, or in a region you choose. That is a design constraint written into the brief before anything is built.
  2. 2.2It is one of the first questions on the scoping call, because it changes what is possible afterwards. Where data staying in Türkiye is a requirement, that requirement is written into the scope and the chosen provider is checked against it with you; what is promised is set by your own provider contract. That is a decision per engagement, not a global promise.
  3. 2.3Where a model is called, which provider and which region are named in the design brief, together with the account settings that apply.

Sources

  1. 3.1The sources an agent may read are fixed in advance, by name, and enforced in configuration rather than in an instruction. The list is a document, not a setting: it carries a version and a named approver.
  2. 3.2Every run logs what it actually read.
  3. 3.3An agent that reaches outside its list is a failed run, not a feature.

Logs and retention

  1. 4.1What is logged, who may read it, how long it is kept and how it is deleted are decided with you and written into the design brief.
  2. 4.2The default I argue for is metadata and the review trail rather than full prompts, with a stated retention period and a deletion rule. Run logs, intermediate outputs and prompt history carry separate retention periods; binding all three to one period is easy and usually wrong.
  3. 4.3The line “every record kept” on this site means kept for the period agreed with you, in your systems. It is not a promise to keep anything for ever, and a retention rule is part of good handling rather than a contradiction of it.

Model training

  1. 5.1The design brief names the provider terms and the account settings that keep your content out of model training. The pilot does not start until they are in place and someone on your side has read them.
  2. 5.2I write the requirement and check the setting. The contractual promise is the provider’s to make to you, and it should be read as such.

Subprocessors

  1. 6.1Named per engagement, in writing, before any data moves, and you are told when one of them changes.
  2. 6.2There is no global subprocessor list on this page, because the stack differs by client. A list that is not true of your engagement would be worse than no list.
  3. 6.3The foundation model provider is treated as a subprocessor and named like any other.

Data protection responsibilities

  1. 7.1Your organisation is the data controller and makes the compliance call. LEXSAS designs to that decision, records it, and says plainly where a design would make it harder to defend.
  2. 7.2Lawful basis, minimisation, retention, logging and any cross-border transfer are settled in the design brief before a pilot starts. The transfer mechanism is named, and the notification duty and its period are allocated.
  3. 7.3The information notice is provided before personal data is processed, regardless of the lawful basis. Where processing relies on explicit consent, the notice and consent text have separate headings and declarations; they may share a page. The notice asks only for acknowledgement that it has been read, not approval or consent. No consent text is presented where another lawful basis applies. These distinctions follow KVKK Board principle decision 2026/347 of 18 February 2026. Under KVKK and under GDPR the questions are different in detail and the discipline is the same: decide it in writing, before the run.

Material that needs the terms read first

  1. 8.1Special-category personal data. Evidence and enforcement file content. Negotiation strategy. Anything covered by professional secrecy. None of it enters a system whose terms have not been read for that purpose.
  2. 8.2This is the line the Union of Turkish Bar Associations drew for lawyers in its advisory guide of 28 August 2026. It is a sensible line for an in-house team as well.

Incidents

  1. 9.1The incident plan exists before the incident does. It says preserve first, meaning capture the prompt, the output, the model version and the logs before any rollback, session clearing or key rotation that can wait, because each of those moves can erase the evidence. Then contain. Where the harm is still running, as with a misused credential or data still leaving, containment does not wait: the workflow is stopped at once and the evidence is captured alongside.
  2. 9.2It names who may switch a workflow off and who tells the business.
  3. 9.3Notification duties sit with you as controller. The record is what makes a notification possible inside the period the law allows.

What I do not claim

  1. 10.1LEXSAS holds no security certification and does not imply one: today there is no SOC 2 Type II report, no ISO 27001 certificate and no independent penetration test report, and you will not find a line on this site that suggests otherwise. It is a venture founded in 2026 and led by one founder.
  2. 10.2I make this a separate heading because it is the first thing a security team asks, and an answer hidden inside a page erodes trust. If it is asked, and it should be, today’s answer is no. What I can show instead: the operating standard itself, the mandate template, the list of record fields, a sample run record, the pilot’s exit terms and this page. If your organisation has its own vendor review checklist, I can send it back completed before the scoping call. Where your procurement requires a certification, the honest answer is that I do not have it, and the design should place the certified components with the providers who do.
  3. 10.3To report a vulnerability in this site, see security.txt.
  4. 10.4This site carries no client names, logos, testimonials or success data. The professional reason: TBB rules prohibit client information under references or another label on lawyers’ websites and restrict advertising that promotes cases or legal work (Articles 7(c), 7(d), 11). As my own policy, I do not request public endorsements from law firms. The principled reason: the product of this work is the record, and a record-keeping business turning its own client’s name into marketing material would be odd. In their place: method notes with no names, and a sample record.

The clauses behind this page are sections 9 and 10 of the operating standard. The terms used here are defined in the glossary. If your procurement has a question this page does not answer, write and ask. Get in touch