Building a KVKK-compliant AI system comes down to deciding, at the architecture level and in advance, where personal data goes, who can see it and how long it is kept. In RAG and agent systems these three questions are not answered in one place but at every stop the data passes through: the moment a document is chunked and embedded, the moment search results are sent to the model, the moment the answer is logged and the moment an agent acts in another system. If the data boundary is not drawn in writing at each of these stops, even a well-intentioned project ends up with a data flow that is hard to explain in an audit.
This article is for technical leads, product owners and compliance teams planning an internal RAG assistant or an AI agent that acts on company systems in Türkiye. KVKK is Türkiye's Personal Data Protection Law (Law No. 6698); similar principles apply under GDPR, although the two regimes are not identical. This is not legal advice. It explains which engineering decisions need to be made and which KVKK concepts they touch. Always confirm the obligations specific to your situation with your legal counsel.
Why is KVKK a separate design topic in AI projects?
In a classic web application, personal data usually sits in known tables and known fields. In AI systems, data changes shape and multiplies. A PDF is split into chunks, each chunk becomes a vector, the chunks selected by search are placed inside a prompt, the prompt goes to a model provider, and the answer, often together with the prompt itself, is logged. Within a few seconds, the same personal data can exist in four places and four forms.
That is why the core KVKK questions stay the same, but finding the answers gets harder:
- Which personal data is processed? Documents may contain customer names, national ID numbers, health information or employee reviews. Most organisations notice this not when uploading documents, but at the first wrong answer.
- Where is the data transferred? If the model provider's servers are abroad, the personal data inside the prompt has been transferred abroad.
- Who can access it? If an employee without permission in the document management system can reach the same content through the assistant, access control has been bypassed.
- How long is it kept? The vector database, prompt logs and the provider's own logs each have separate retention periods, and rarely does anyone consider them together.
Which stops does data pass through in a RAG system?
Enterprise RAG security starts by mapping the data's journey stop by stop. A typical RAG flow has five stops, each with its own risk.
- Source system: Where documents live (file server, document management system, CRM, email archive). Risk: out-of-scope documents ingested in bulk.
- Preparation and chunking: Where documents are converted to text and split. Risk: personal data processed without masking.
- Embedding and vector database: Where chunks are turned into vectors and stored. Risk: the embedding model being an external API, and chunks stored without permission metadata.
- Retrieval and prompt assembly: Where chunks are selected for the user's question and sent to the model. Risk: chunks the user is not entitled to see leaking into the answer.
- Model and logging: Where the answer is generated and the prompt and answer are logged. Risk: indefinite log retention and the provider using data for its own purposes.
Drawing this list as a data flow diagram and writing next to each stop "which personal data, in which country, who can access it, for how long" is the single most valuable document for both the technical and the compliance side of the project.
Is data sent to a model provider a cross-border transfer?
If a prompt containing personal data is sent to a model provider whose servers are outside Türkiye, this is generally treated as a transfer of personal data abroad. Article 9 of KVKK was rewritten by an amendment in 2024. Under the new rules, an adequacy decision is looked for first; without one, an appropriate safeguard is required, such as standard contractual clauses, binding corporate rules or a written undertaking approved by the Board. When standard contracts are used, notifying the Personal Data Protection Authority within a set period after signing is also among the obligations.
On the engineering side, this means answering these questions at the start of the project:
- What does the model provider's data processing agreement (DPA) say? Is submitted data used for model training, and if not, is that committed in writing?
- In which region does the provider process and store data? Can a region be selected?
- How long does the provider retain prompts for abuse monitoring? Can that be reduced to zero?
- Which safeguard will be used for the transfer, and who will handle the notification or approval it requires?
The legal answer to these questions depends on your own assessment as the data controller. The technical team's job is to surface the information that makes that assessment possible and to build an architecture that can change according to the decision. Do not start from the assumption that "the provider is big, so it is fine" without confirming it with your legal counsel.
How do you strip personal data before embedding?
The safest personal data is the data that never enters the system. For a RAG assistant to answer, it rarely needs a customer's name or ID number; the procedure, the contract clause or the technical explanation itself is usually enough. So three techniques are used together at the preparation step:
- Scope filter: Which folders, document types and date ranges enter the system is decided in writing. "Let's load the whole shared drive" is the most common data boundary mistake.
- Anonymisation: Personal data not needed for the answer is removed from the text before embedding. Truly irreversible anonymisation can remove the data's status as personal data, but you need to be sure it really is irreversible.
- Pseudonymisation: If a link to the person is needed but the model does not need to see it, fields such as name and ID number are replaced with a key. The mapping table is kept separately with restricted access. Pseudonymised data is still personal data, but what reaches the model and the provider is narrower.
Building masking rules with regular expressions alone falls short; names, addresses and health details inside free text do not follow patterns. In practice, rule-based detection is combined with an entity recognition model and the result is measured on sample documents. Saying "we do masking" without a test set showing how much personal data is missed is not a safeguard.
How is access control enforced at retrieval time?
The most insidious gap in enterprise RAG security is an assistant that shows everyone the same documents. If an employee with no access to the HR folder can ask "what is the salary scale" and get the answer from the assistant, the system has effectively disabled the permission model of document management.
The right approach is to enforce permissions during retrieval, not after the answer is generated:
- Each chunk carries the source document's access list (user, group or role) as metadata.
- The search query is filtered by the asking user's identity and groups; chunks they are not entitled to never enter the candidate list.
- When permissions change in the source system, the metadata in the vector database is updated too. The delay of this sync is measured and tied to a written target.
- The source document is shown with the answer; if the user cannot open the source document, the answer should not contain information based on it.
Instructing the model "do not share information the user is not authorised to see" is not access control. If the model has seen the chunk, it can leak it into the answer one way or another. Permissions must be enforced in the layer that decides what data reaches the model.
How do you draw the data boundary in agent systems?
A RAG system reads; an agent acts. If an agent can update CRM records, send emails or query a database, the KVKK risk goes beyond reading: sending data to the wrong person, unauthorised changes and unrecorded actions. We covered this in detail in our article on taking AI agents to production; from a data boundary perspective, the key rules are:
- Least privilege: The agent runs with the narrowest permissions needed for its job. If reading is enough, no write access; if one table is enough, not the whole database.
- Acting on behalf of the user: The agent works with the permissions of the user who triggered the action, not with its own broad service account. That way the agent cannot do anything the user could not do.
- Human approval gates: Actions that send data outside, delete records or make bulk changes do not run without human approval.
- Tool-level boundaries: Every tool the agent uses defines what it can do and which fields it returns. In protocols such as MCP, the real value is that these definitions and the authorisation layer on top of them can be managed centrally.
How do you set logging and retention?
Logging in AI systems sits between two opposing needs. On one side, recording which user asked what, which documents were used and which action the agent took is necessary for debugging and accountability. On the other, if full prompt texts are kept indefinitely with the personal data inside them, the log store becomes the organisation's most sensitive dataset.
A balanced approach looks like this:
- The audit trail (who, when, which document, which action) is kept separate from the content log (full prompt and answer text).
- Personal data in content logs is masked and retention is kept short; records are deleted automatically when it expires.
- Retention periods are written separately for the vector database, application logs, monitoring tools and the model provider's own logs, and checked against the organisation's data retention and destruction policy.
- For data subject requests (such as erasure), how one person's data is found and deleted from the vector database and logs is designed in advance. This is one of the hardest features to add later.
When does running open-weight models on your own servers make sense?
The clearest way to draw the data boundary is for data never to leave infrastructure the organisation controls. Recently released open-weight models have reached sufficient quality for many enterprise tasks and can run on your own servers or in a cloud environment you control. This option is especially worth considering when:
- Documents contain special categories of personal data, such as health data.
- Sector regulation or customer contracts require data to stay in a specific country.
- Usage volume is high and predictable enough that your own infrastructure costs less than API usage.
The price is clear too: operating, updating, monitoring and securing the model becomes your job, and you may give up some capabilities of the strongest closed models. A common middle path is to run the steps that handle sensitive data (embedding, classification, masking) on your own infrastructure and leave generation over masked content to an external model. A model-agnostic architecture is the precondition for being able to change this decision later.
How do you assess risk before the project starts?
For high-risk processing activities, a written impact assessment before work begins is good practice. An approach similar to the GDPR's data protection impact assessment (DPIA) can also be used under KVKK to make risks visible. For an AI project, the assessment should cover at least:
- The processing purpose and the data categories actually needed for it.
- The data flow diagram with country, provider and retention at each stop.
- The legal basis and, where needed, an updated privacy notice.
- The safeguard used for any cross-border transfer.
- The access control model and how it is enforced at retrieval time.
- Agent permissions and actions requiring human approval.
- Residual risks and who accepted them.
This document is valuable not only for compliance but for sharpening project scope. The question of which data is really needed often makes the project both safer and cheaper.
Checklist for KVKK-compliant AI
- A data flow diagram exists, with country, provider and retention written at every stop.
- The scope of documents entering the system is defined in writing.
- Personal data is masked before embedding, and the miss rate is measured with a test set.
- The model provider's DPA has been reviewed; training use and retention are clear.
- For cross-border transfer, the safeguard type and notification process are settled with legal counsel.
- Access control is enforced at retrieval time with the user's identity.
- Permission changes in source systems are synced to the vector database.
- Agents run with least privilege on behalf of the user; risky actions need human approval.
- Audit trail and content logs are separate; content log retention is short and automatic.
- A path to delete one person's data from every layer has been designed and tested.
- Where special category data exists, a self-hosted model option has been evaluated.
- A risk assessment is written and residual risks are signed off by their owner.
Frequently asked questions
Is sending personal data to ChatGPT or a similar API a KVKK violation? Not in itself, but it usually counts as a cross-border transfer and requires one of the conditions in Article 9 of KVKK to be met. How the provider processes and stores the data should also be settled by contract. Confirm your own situation with your legal counsel.
Do vectors count as personal data? Embedding vectors are numerical representations of text, and some techniques can recover information about the source text. Vector databases also often store the chunk itself. Protecting the vector store with the same care as the source documents is the right approach.
Does anonymisation take us out of KVKK's scope? Truly irreversible anonymised data can lose its status as personal data. Pseudonymisation does not; the data is still personal data. You need to be able to show which one you did and measure whether the result is irreversible.
Does using an open-source model solve everything? The cross-border transfer question largely goes away, but access control, logging, retention and agent permissions still apply. Wherever the model runs, the architecture defines the data boundary.
If you are planning a RAG assistant or agent system, we can map the data flow and permission model together. See how we work on our AI solutions service page, and the questions to ask a vendor in our guide on how to choose an AI integration company. To discuss your project, just fill in the quick quote form.
