What the guidance is, and what it is not
The Turkish data protection authority has published a guide on generative AI and the protection of personal data. It sits on the authority's own Rehberler index at kvkk.gov.tr, and a shorter fifteen-question version is published on the same site at kvkk.gov.tr under the generative AI heading. It is guidance rather than binding regulation, and some teams take that as permission to file it and move on. That is a misreading of how supervision actually works. Guidance is the regulator telling you in advance what it considers reasonable, and reasonable is precisely the standard you will be measured against when an inspection or a complaint arrives on your desk.
Türkiye has no dedicated artificial intelligence law in force. What binds you is Law No. 6698 on the Protection of Personal Data, alongside the Turkish Penal Code, Law No. 5651 on internet publications and the Turkish Commercial Code. Five articles of Law 6698 do most of the day-to-day work in an AI project: Article 5 on lawful basis, Article 6 on special categories such as health and biometric data, Article 10 on the duty to inform, Article 11(g) on the right not to be subject to a result produced solely by automated analysis, and Article 12 on data security. The wider legal picture sits in where Turkey's AI regulation actually stands.
This article does something the law-firm summaries do not. It takes each theme in the guidance and states the architectural change it implies, because a data protection principle that has not been expressed as a schema, a retention job or an access filter is not implemented. Every section below ends somewhere concrete: a field you add, a store you purge, a filter you push down into the query, a signal you monitor. If you take one thing from it, take this: in a generative system the compliance surface is not the model, it is the data path around the model, and almost all of it is ordinary engineering.
One further note before the detail. The authority also published a document on agentic systems, using its own Turkish term Etken Yapay Zekâ, on 12 March 2026. It is guidance rather than binding regulation, and everything in this article gets harder once a system can act rather than merely answer. An agent that sends mail, writes to a record or triggers a payment converts a wrong output into a wrong action, and the questions shift from what the model said to what the system did and who could have stopped it. If you are building agents, design the permission model with that document open.
RAG moves the lawful-basis question to the corpus
The most common analytical error we see is treating the prompt as the processing. A team writes a careful notice about what users type into a chat box, and says nothing about the two hundred thousand documents that were indexed to answer them. Retrieval-augmented generation processes that corpus continuously: it is read, chunked, embedded, stored as vectors, searched and surfaced. Every one of those steps is processing under Law 6698 if the documents contain personal data, and in a Turkish enterprise corpus they nearly always do. The prompt is the smallest part of the exposure.
So the lawful basis analysis has to be run per corpus, not per feature, and recorded that way. For each indexed source, write down what the original collection purpose was, what the retrieval purpose is now, and whether the second is compatible with the first. That last question is where projects fail. Support tickets collected to resolve support tickets can usually justify a support assistant. The same tickets fed into a sales propensity model are a different purpose and need their own analysis. Article 6 makes this sharper for special categories: health, biometric and similar data should not drift into a general-purpose index because it happened to sit in the same folder.
Practically this means the index needs provenance carried at chunk level, not just a document id. Store the source system, the original collection purpose, the sensitivity classification, the retention clock and the record owner alongside every vector. It costs a few extra columns and it is what makes every later obligation answerable: which chunks came from a source you no longer have a basis for, which must be purged on a schedule, which can never be exposed to a general audience. The retrieval architecture behind this is covered in vector databases and semantic search.
What to log, and what never to log
You need logs. Article 12 security obligations, incident response, quality evaluation and any future demonstration of oversight all depend on them, and a system with no record of what it produced cannot be defended. But the naive implementation, dumping full prompts and full responses into the same observability platform that holds application logs, creates a second copy of your most sensitive data in a system with weaker access controls, longer retention and a much wider audience. We have reviewed projects where the strictest data in the company was in the vector store, and a full plaintext duplicate was in a log index that thirty engineers could query.
Split the logging into two planes. The telemetry plane holds what operations needs and no content: request id, tenant, user id in tokenised form, model and version, prompt token count, response token count, latency, retrieval document ids, tool calls, error codes, cost. This is what runs your dashboards and alerts, it is safe to retain for months, and it is where nearly all operational value lives. The content plane holds the actual prompt text, the retrieved passages and the generated response. It is stored separately, encrypted, access-controlled to a named group, retained briefly and always linked to the telemetry record by request id.
Some things never go into either plane. Never log credentials, tokens or API keys that a user pasted into a prompt, and detect and drop them rather than trusting users not to. Never log raw special-category data in the clear if you can hash, mask or reference it instead. Never log the full contents of a retrieved document when a document id plus a chunk offset reconstructs it from the source of truth. And never let a debugging flag that promotes content into the telemetry plane survive past a single incident: those flags are the single most common cause of accidental long-term retention we encounter.
Retention windows for prompts and responses
Keep everything for debugging is not a retention policy, it is the absence of one, and it will be read as such. The workable pattern is tiered. Telemetry without content can typically be retained for six to twelve months because it supports capacity planning and trend analysis and carries little personal data once identifiers are tokenised. Prompt and response content is a different class: in the systems we build, seven to thirty days is usually enough to investigate an incident, and anything longer needs a stated reason. Evaluation and review records, where a human judged an output, are retained on their own clock because they are the evidence of oversight.
The important word is enforced. A retention policy that exists in a document and not in a scheduled job is a liability rather than a control, because it creates an expectation you are demonstrably failing. Write the deletion as code, run it daily, log what it deleted in aggregate, and alert when it fails or when it deletes nothing at all, which is the usual sign that a query stopped matching after a schema change. Then test it: put a marker record in, wait out the window, and assert that it is gone from every store including backups within the documented recovery period.
Consent-based or preference-based retention needs a separate lane. If a user has opted out of their conversations being retained for improvement, that decision has to travel with the request as a field, not as a downstream filter someone remembers to apply. We make it part of the request envelope, so the storage layer refuses to write content when the flag is set, rather than writing it and cleaning up later. The difference sounds academic until the cleanup job is late by a week, at which point one design has stored nothing and the other has an incident to report and explain.
Redaction before the model ever sees the text
If a hosted model is involved, the cheapest privacy control available is not sending the personal data at all. A redaction layer sits between your application and the model, detects identifiers in the prompt and in retrieved passages, replaces them with stable placeholders, calls the model, and restores the placeholders in the response before it reaches the user. The model gets a coherent document about PERSON_1 and CONTRACT_2 rather than a named individual and a contract number, and the answer is usually just as good because the reasoning does not depend on the literal identifier.
Turkish deployments need Turkish detection. A generic detector trained on English will miss the identifiers that matter here: the eleven-digit national identity number, tax and trade registry numbers, IBANs in the Turkish format, plate numbers, Turkish address and street conventions, and personal names that inflect through Turkish suffixes so that the same name appears in five surface forms across one document. A regex-only approach catches the structured items and misses the names. A model-only approach catches the names and drifts. What works is a layered detector, structured patterns with checksum validation first, then a named-entity model, then a deny list for the specific terms your organisation cares about.
Set a false-negative budget and measure against it, because a redaction layer nobody has measured is a comfort blanket. Build a labelled sample of a few hundred real documents from your own corpus, score recall per entity type, and treat a drop below your threshold as a release blocker. Expect to trade precision for recall deliberately: over-redaction annoys users, under-redaction is a notification event. Budget roughly twenty to eighty milliseconds per request for the detection pass on typical prompt sizes, and note that the cost scales with retrieved context, which is the part teams forget when they enlarge the top-k and watch latency move.
Decide consciously whether masking is reversible. A placeholder map held in your own memory for the life of a request is reversible and lets you restore names in the answer, which users expect. A one-way hash is safer but breaks the reading experience and cannot support follow-up questions about the same entity. We default to reversible within the request and irreversible in storage: the mapping lives in process memory and is never written to the log or the trace. That single rule prevents the most common leak in this design, which is a placeholder dictionary quietly persisted in a debug artefact that outlives the request that produced it.
Where inference runs, and what it means for transfer
The physical location of inference is a data protection decision before it is an infrastructure one, and it should be recorded as such. Broadly there are three postures. Fully self-hosted inference on your own or a Turkish provider's infrastructure keeps the data inside your control boundary and removes the transfer question altogether. A hosted model with a regional deployment and contractual guarantees moves the analysis into transfer terms and sub-processor management. A general public API endpoint with default terms is the option that requires the most work to defend and the one most teams start with by accident.
Whatever you choose, you have to be able to answer four questions in writing. Where does the request physically go. Which entities process it along the way, including the ones behind your provider. What are they contractually permitted to do with prompts and outputs, and specifically whether either is used for model training. How long do they retain it, and can you configure that down. Providers publish this and it changes, so record the answers with a date and re-check them at a set cadence rather than relying on a screenshot someone took during procurement eighteen months ago.
The architectural conclusion we reach most often with regulated Turkish clients is a split. Run the sensitive path, meaning anything that touches identified customer records, health data or special categories, on self-hosted open-weight models inside the boundary. Run the general path, meaning summarisation of public material, code assistance and drafting, on a hosted frontier model. Routing between them is a policy decision made per request from the data classification, not a per-team preference. It costs more to operate two paths, typically in the range of a few extra engineer-weeks up front and ongoing capacity for the self-hosted side, and it is the design that survives a supervisory conversation intact.
Access control has to be carried through retrieval
This is the failure we see most often in enterprise RAG, and it is the one with the worst consequences. A team indexes a shared drive, builds a beautiful assistant, and then discovers that a junior employee can ask about a salary band, a disciplinary file or an unannounced acquisition and get a fluent answer assembled from documents they could never have opened in the source system. Nothing was hacked. The index simply flattened a permission model that the source system had been enforcing for years, and the assistant did exactly what it was built to do with the data it was given.
The rule is absolute and worth stating as a test: a user must never receive a passage they could not open in the system of record. Implement it as a pre-filter, not a post-filter. Pre-filtering pushes the identity and group memberships into the vector query so the search only ever considers permitted chunks. Post-filtering retrieves the top matches and then removes the ones the user cannot see, which is wrong in two ways. It leaks through result counts and latency, and it silently degrades quality, because a user with narrow permissions may end up with three results when the system was tuned for twenty.
That means every chunk carries an access control list at write time, resolved from the source system rather than assumed. Group expansion has to be cached and invalidated when permissions change. Permission propagation is the part that gets neglected: someone leaves a project on Monday and can still retrieve its documents on Friday because the index has not been refreshed. Set a maximum staleness you can defend, minutes for sensitive corpora and hours for general ones, and monitor it as a service level rather than hoping. Domain-specific patterns for this are discussed in RAG on Turkish legal data.
Test it adversarially and keep the tests. Build a permission matrix of representative users and documents, generate queries designed to pull the forbidden content out sideways, and run the whole thing in CI on every index change. Ask for the salary of a named colleague. Ask for a summary of last quarter's board pack. Ask indirectly, for the highest figure mentioned in any compensation document, which is the phrasing that defeats naive filters. A retrieval access control suite of eighty to two hundred cases is cheap to maintain and it is the single most valuable safety test in an enterprise RAG deployment.
Shadow AI: finding what people are already using
Shadow AI is the use of unapproved AI tools with company data, and in every organisation we have looked at it is already happening at a scale that surprises the people who run the organisation. It is not malicious. Someone has a deadline, a public chatbot is one tab away, and the contract, the customer list or the incident report gets pasted into it. From a Law 6698 perspective the company is still the controller: you are responsible for a transfer you never authorised, cannot describe and did not log, which is the worst possible position to be in when someone asks you what happened.
Detection is unglamorous and mostly uses telemetry you already have. Web proxy and DNS logs show which AI domains are being reached and how often. Egress volume to those domains distinguishes casual reading from bulk pasting, since a few kilobytes is a question and several megabytes is a document set. Browser extension inventories on managed devices catch AI assistants installed with broad page access. Expense reports show individual subscriptions billed to personal cards. Cloud application discovery tools in your identity provider show which third-party apps users have granted access to corporate accounts, which is the quietest and most consequential category.
The response that works is not a ban. Provide a sanctioned tool that is genuinely good, make it the path of least resistance, and be explicit in plain language about what may and may not be pasted anywhere. Then keep measuring: sanctioned usage should climb while unsanctioned egress falls, and if it does not, your tool is not good enough or people do not know it exists. We treat that ratio as a product metric for the internal platform, reviewed monthly, and it is a far better indicator than any policy attestation.
Data subject rights, and when a full assessment is triggered
Erasure is where generative architectures break, because the data has been copied into places a delete statement never reaches. Deleting a row from the source database does not remove it from the vector index built last month, the embedding cache, the reranker cache, the prompt and response log, the evaluation dataset assembled from real traffic, or the analytics warehouse. Every one of those is a copy of personal data under Law 6698. The first time a team maps this honestly is usually uncomfortable: a single customer record has often propagated into six systems, only two of which have a knowing owner.
Build erasure as a fan-out job with a documented target list and a completion receipt. Source record deleted, vector chunks deleted by document id, caches invalidated by key prefix, log entries purged by subject reference, evaluation cases removed or re-anonymised, warehouse rows tombstoned. Vector stores vary in how well they support deletion: some remove immediately, some tombstone and reclaim on compaction, and a few effectively require a rebuild of the affected partition. Know which one you have before you commit to a deletion window in a customer contract, because the honest answer for some architectures is a scheduled weekly rebuild rather than an instant delete.
The other rights need plumbing too and are usually forgotten. Access means you can produce what you hold about a person across all of those stores, not just the source system. Rectification means a corrected record has to be re-embedded rather than left stale in the index, which is why the pipeline needs a per-document reindex path and not only a full rebuild. Article 11(g) means a person facing a result produced solely by automated analysis that works against them can object, which is a real workflow with a queue, a service level, an override and a record of who used it, not an inbox in a footer.
A formal impact assessment is not required for every project, and pretending otherwise burns credibility. The triggers we treat as automatic are: special-category data under Article 6 entering the pipeline; a decision that materially affects a person's rights, such as employment, credit or access to a service; large-scale processing of customer data for a new purpose; systematic monitoring of employees or the public; a new cross-border transfer path; or an agent that can take an irreversible action without human confirmation. Run the assessment before the build, not after the pilot, and keep it with the system's inventory entry as described in the governance artefacts engineers actually run.
How we build this at HatsonTech
We are an engineering company, not a law firm. We do not opine on whether a particular processing is lawful; we build the systems that let a client's own counsel answer that question and keep answering it after the next release. In a RAG deployment that means chunk-level provenance and sensitivity metadata, a layered Turkish redaction pass in front of hosted inference, split telemetry and content logging with different retention clocks, pre-filtered retrieval that enforces source-system permissions, an erasure fan-out with a receipt, and an adversarial permission test suite that runs on every index change.
The pattern we meet most often is a good pilot with no data path. The retrieval quality is fine, the demo is convincing, and nobody can say which documents were indexed, who can see what, how long prompts are kept or what happens when a customer asks to be deleted. Retrofitting those controls after launch typically costs more than building them in, mostly because the index has to be rebuilt to add fields that should have been there from the first ingestion run. Our advice is unpopular and consistent: spend the extra week on ingestion metadata before you tune the reranker.
European obligations often arrive on the same system through a customer, so we build both at once rather than twice, which is the subject of the EU AI Act after the omnibus. The broader privacy architecture, including on-premise and hybrid options, is set out in our data privacy article. If you have a RAG system in production and cannot currently answer the erasure question end to end, that is the place to start, and it is what our RAG and semantic search practice does first on almost every engagement we take.