GDPR-Compliant Enterprise AI: Data Boundaries in RAG and Agent Systems

Building a GDPR-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 to a supervisory authority or an auditor.

This article is for technical leads, product owners and privacy teams planning an internal RAG assistant or an AI agent that acts on company systems and processes personal data of people in the EU. It explains which engineering decisions need to be made and which GDPR concepts they touch. It is not legal advice: always confirm the obligations specific to your situation with your legal counsel or data protection officer. Companies operating in Türkiye face similar questions under KVKK, the Turkish data protection law, which follows comparable principles but is not identical.

Why is GDPR 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 GDPR principles in Article 5 stay the same, but applying them gets harder:

• Data minimisation: Documents may contain customer names, ID numbers, health information or employee reviews. Most organisations notice this not when uploading documents, but at the first wrong answer.
• Purpose limitation: Data collected to run a contract or a support case is now being used to answer questions in an assistant. Whether that new use is compatible with the original purpose has to be assessed.
• Transfers: If the model provider processes data outside the EU and EEA, the personal data inside the prompt has been transferred to a third country.
• Storage limitation: 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.

1. Source system: Where documents live (file server, document management system, CRM, email archive). Risk: out-of-scope documents ingested in bulk.
2. Preparation and chunking: Where documents are converted to text and split. Risk: personal data processed without masking.
3. 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.
4. 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.
5. 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, which processor, who can access it, for how long" gives you most of what your record of processing activities under Article 30 needs, and it is the single most valuable document for both the technical and the privacy side of the project.

Is data sent to a model provider a third-country transfer?

If a prompt containing personal data is sent to a model provider that processes it outside the EU and EEA, this is generally a transfer to a third country under Chapter V of the GDPR (Articles 44 to 49). A transfer needs a legal route. The first is an adequacy decision by the European Commission for the destination country. For the United States, the EU-US Data Privacy Framework provides an adequacy route for providers that have certified under it; it has been challenged before the courts, so check its current status with your counsel rather than treating it as permanent. Without adequacy, appropriate safeguards are needed, most commonly the Commission's standard contractual clauses (SCCs) together with a transfer impact assessment, or binding corporate rules within a group. The derogations in Article 49 are narrow exceptions and are not a basis for routine processing.

Separately from the transfer question, a model provider that processes data on your behalf is a processor, and Article 28 requires a contract with specific terms. On the engineering side, this means answering these questions at the start of the project:

• What does the 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 an EU region be selected, and does that cover support access and sub-processors?
• How long does the provider retain prompts for abuse monitoring? Can that be reduced to zero?
• Which transfer route applies, and who keeps the SCCs and the transfer impact assessment up to date?

The legal answer to these questions depends on your own assessment as the 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, which is data minimisation applied in code. 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. Data that is truly anonymous falls outside the GDPR, but the bar is high: if a person can still be identified by means reasonably likely to be used, it is not anonymous.
• 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 under the GDPR, but what reaches the model and the provider is narrower, and the GDPR itself names pseudonymisation as a security measure.

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, and the confidentiality obligation in Article 32 is no longer met.

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 GDPR risk goes beyond reading: sending data to the wrong person, unauthorised changes and unrecorded actions. If an agent makes decisions that have legal or similarly significant effects on people without meaningful human involvement, Article 22 on automated decision-making also comes into play. We covered agents 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, make bulk changes or decide something about a person 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 for accountability under Article 5(2). 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 and breaks storage limitation.

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 retention policy.
• For data subject requests (access, rectification, erasure), how one person's data is found and handled in 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 an EU cloud region you control. This option is especially worth considering when:

• Documents contain special categories of personal data under Article 9, such as health data.
• Sector regulation or customer contracts require data to stay in a specific country or in the EU.
• 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?

Under Article 35, a data protection impact assessment (DPIA) is required when processing is likely to result in a high risk to people's rights and freedoms, and new technologies, large-scale processing of special category data and systematic evaluation of people are typical triggers. Many AI projects meet at least one of them; even where a DPIA is not strictly required, writing one is good practice. For an AI project, it should cover at least:

• The processing purpose, the legal basis and the data categories actually needed for it.
• The data flow diagram with country, processor and retention at each stop.
• Whether the privacy notice needs updating for the new use.
• The transfer route and safeguards for any third-country processing.
• The access control model and how it is enforced at retrieval time.
• Agent permissions, actions requiring human approval and any automated decisions.
• 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 GDPR-compliant AI

• A data flow diagram exists, with country, processor and retention written at every stop, and it is reflected in the record of processing activities.
• 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 third-country processing, the transfer route (adequacy, SCCs, BCRs) is 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 and decisions about people need human approval.
• Audit trail and content logs are separate; content log retention is short and automatic.
• A path to find and erase one person's data in every layer has been designed and tested.
• Where special category data exists, a self-hosted model option has been evaluated.
• A DPIA or equivalent 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 GDPR violation? Not in itself. You need a legal basis, a processor agreement under Article 28 and, if the provider processes data outside the EU and EEA, a valid transfer route under Chapter V. How the provider processes and stores the data should 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. Treating the vector store as personal data and protecting it with the same care as the source documents is the right approach.

Does anonymisation take us out of the GDPR's scope? Truly anonymous data does. Pseudonymised data does not; it is still personal data. You need to be able to show which one you did and test whether people can still be identified.

Does using an open-source model solve everything? The third-country transfer question largely goes away if you host it in the EU, but legal basis, access control, logging, retention, data subject rights 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.