Short answer: GDPR-compliant AI is achievable, because GDPR does not ban AI. It sets rules for personal data, and an LLM application is another system that touches it. Seven controls cover most of your exposure: a stated purpose, a lawful basis, minimal data in the prompt, limits on what vendors keep, retention on every store, human review of significant decisions, and control over what agents and tools receive.
An analyst pastes a customer email into a chat assistant to draft a reply. The email holds a name, a home address, and an order history. That text now sits in a prompt, in a vendor log, and possibly in a chat history nobody gave a retention period. Nobody did anything reckless. But ask where that customer’s data went, how long it stays, and whether the vendor trains on it, and most teams cannot answer. That gap is where GDPR-compliant AI work starts.
Most teams get this wrong in one of two ways. They ban LLM use outright, or they ship an agent on top of customer records and hope nobody asks. There is a middle path: a small set of controls covers most of your exposure, and the rest is edge cases you handle one at a time.
Does GDPR apply to you? Scope does not depend on where your servers sit. You are in scope if you have an EU establishment, or if you offer goods or services to people in the EU or monitor their behavior there, whether you are in Frankfurt or San Jose. This guide describes EU GDPR. UK GDPR follows the same shape, but UK rules on automated decisions changed in 2025, so review UK requirements separately.
What does GDPR require for AI applications?
GDPR rests on seven principles in Article 5, and every AI application maps back to them. The table shows what each one means when an LLM is in the loop.
| GDPR principle | What it means for an AI application |
|---|---|
| Lawfulness, fairness, transparency (Art. 5, 6, 13, 14) | You need a legal reason to feed personal data to a model, and people must know. Pick a lawful basis per use case and update your privacy notice to name AI processing |
| Purpose limitation | Data collected for support tickets cannot quietly become model training data. Block secondary use, including vendor training |
| Data minimization | Send the model only what the task needs. Strip or mask identifiers before the prompt |
| Accuracy | Output about a person must not be wrong in ways that affect them. Keep a human in the loop for significant decisions, and let people correct outputs about them |
| Storage limitation | Prompts, logs, embeddings, and fine-tune data are all retention problems. Set retention on every store, including vector stores |
| Integrity and confidentiality | Prompts leak, logs leak, models memorize, and agents hand data to tools. The model reads clear text at runtime, so tokenize before the prompt and control who can unmask |
| Accountability | You must prove all of the above: records of processing, a DPIA for high-risk use, and an audit trail of what was masked and who unmasked it |
Three practical questions decide most of your risk. What goes into the model: raw personal data, masked data, or nothing personal at all? What does the vendor keep: prompts, completions, chat history, logs, fine-tune sets, and whether any of it trains future models? And where is the data processed and stored: US, EU, China, or “worldwide” each means a different set of engineers and governments who can read your clear text. Answer those three well and the Article 5 table mostly takes care of itself.
Which seven controls make an LLM application GDPR-compliant?
Seven fixes handle the bulk of GDPR trouble with AI: purpose, lawful basis, minimization, vendor terms, retention, human review, and agent data flows. Most are engineering and product decisions. A lawyer should check them, but does not build them.
1. Decide what the application is for, and write it down
Before you pick a model, state in one sentence what the application does with personal data, such as “summarize support tickets so agents respond faster.” That sentence guides the choice of lawful basis, tells you which data fields the task needs, and becomes the line in your records of processing and your privacy notice. If you cannot write the sentence, you are not ready to build.
2. Pick a lawful basis per use case, not per company
Article 6 gives you six bases. Three come up most often for AI applications, though legal obligation and public task can be central too.
| Basis | When it fits | Trap |
|---|---|---|
| Contract | Processing is objectively necessary to deliver what the person contracted for, like a support bot answering their own ticket | Does not stretch to convenience, internal efficiency, or training a model on their data |
| Legitimate interest | Internal efficiency, fraud detection, analytics on your own customers | Needs a written balancing test. Weak when data is sensitive or the person would not expect it |
| Consent | Marketing personalization, anything optional | Must be specific and revocable. Withdrawal means you must be able to stop, and erase where no other ground lets you keep the data |
Each use case gets its own basis. The ticket summarizer and the churn predictor are different processing activities.
3. Send the model only what the task needs
Data minimization is the most useful GDPR principle for AI builders, because it is also the cheapest control. A summarizer does not need the customer’s email address. The practical move is to mask or tokenize identifiers before the prompt leaves your boundary. The model sees a consistent placeholder, does its work, and the real value is restored only where an authorized user needs it.
4. Know what your vendor keeps, and turn training off
Every hosted LLM API has three policies you must read: prompt retention, training on your data, and sub-processor location. No training and zero retention are two different commitments. Enterprise tiers often turn off training by default. Zero retention is usually a separate setting, often needs vendor approval, and may not cover every feature or stored application state. Consumer and free tiers often offer neither. Verify the exact service and configuration you are on, get it in the data processing agreement, and check whether abuse-monitoring logs are still kept for a window of days. If the vendor cannot put “we do not train on your data and we delete prompts within N days” in writing, treat every prompt as a disclosure to a third party.
5. Set retention on every store the AI creates
An AI application creates new copies of personal data in places your retention policy never covered: prompt and completion logs, conversation history, vector embeddings in a RAG index, fine-tuning and evaluation sets, and cache layers and observability tools. Each one needs a retention period and a delete path.
RAG is where this gets hard. A pipeline makes several representations of every source document, and when the source record is deleted, all copies have to go. Do not assume an embedding is anonymous. Carry a source ID through the pipeline from day one. The full walk-through is in are embeddings personal data.
6. Keep a human in the loop for decisions that affect people
Under EU GDPR, Article 22 restricts decisions made solely by automated means that have legal or similarly significant effects. Loan approvals, hiring screens, insurance pricing, and benefit eligibility all qualify. The fix is not to avoid AI. Make the AI draft and a person decide, and be able to show that the person reviewed it rather than clicked through. A model that hallucinates a fact about a customer has also created inaccurate personal data, and a review step catches it.
Watch out. Article 22 has its own exceptions and safeguards, for example where the decision is needed for a contract or the person gave explicit consent. Real human review keeps you out of “solely automated” territory. It does not make the rest of the processing compliant on its own.
7. Control where data goes once agents and tools are in the loop
A chat application has one data path: user to model to user. An agent has many. It reads a CRM record, passes part of it to a search tool, sends another part to an email tool, and writes a summary back to a ticket. With MCP, every tool is a new receiver, often built by someone else, often with its own logs.
GDPR cares about every receiver. Each tool call that carries personal data is a disclosure, and the question becomes “did this tool need this field.” A payments tool needs the account number. The calendar tool does not. If the agent forwards the whole record to both, you have over-disclosed, and no attacker was needed. That is a design flaw and can still be a reportable breach. Decide per destination which fields stay masked, and log each decision.
Encryption does not solve this. Encryption protects storage and the wire. At the moment of use the model and every tool read clear text, because a model cannot reason over ciphertext. So when someone says “the data is encrypted,” ask where. Tokenization holds at runtime, because the token is what the model and the tools actually see.
Do these seven and you have most of GDPR for AI covered.
What personal data does an LLM store?
Personal data can live in four places when you use an LLM, and they have very different GDPR profiles.
| Where data lives | Can you delete it? |
|---|---|
| Model weights, from training or fine-tuning on data that contained personal information | Not easily. Unlearning and output filters are immature, so plan on retraining as the fallback. The hardest case |
| Prompt, completion, and session logs kept by the vendor for days to months | Yes, if the vendor contract allows it and you know the retention window. Standard processor data |
| Context at inference time: prompt, system prompt, retrieved documents | Yes. It exists only for the call unless logged. Lowest risk if the vendor does not retain it |
| Your own stores: RAG indexes, embeddings, chat history, caches | Yes, but only if you built the delete path. Fully your responsibility as controller |
Weights are the one you cannot easily undo. Large models memorize, and researchers have pulled names, email addresses, and phone numbers out of production models. Never fine-tune on raw personal data. Use masked or synthetic data instead.
The model is often not the biggest problem. Your own stores are. Each is a processing activity you own, with a lawful basis, a retention period, access control, and separate search and delete paths for access and erasure requests. One right must never trigger the other.
How does tokenization help?
Tokenization replaces each personal value in a prompt or document with an opaque token that keeps the type and stays consistent. The model works on tokens, and real values return only to authorized users. GDPR names pseudonymization as a safeguard in Article 25 and Article 32, and Recital 28 says it reduces risk for data subjects. For AI applications it is the control that makes the rest of the list easier.
Redaction deletes. Tokenization translates. A redacted prompt that reads “[REDACTED] called about [REDACTED]” breaks the model’s ability to reason. A tokenized prompt keeps the grammar, the type, and the consistency, so the model can track who did what. Unmasking is a logged policy decision made at the moment of use, and that log is the audit trail Article 5(2) asks for.
Watch out. Tokenized data is still personal data in your hands, because you hold the key. In 2025 the CJEU held that pseudonymized data may not be personal data for a recipient who has no realistic means to re-identify people (EDPS v SRB, Case C-413/23 P). That takes a case-by-case look at what the recipient holds and what the surrounding text gives away. Treat tokenization as a safeguard, not as a way out of your obligations.
The token-to-value mapping should sit inside your own infrastructure, in the region the data belongs to. Protecto Vault runs in your private cloud or on-premises, with an air-gapped option. The full breakdown is in does AI redaction meet GDPR.
Does GDPR require personal data to stay in the EU?
No. GDPR allows personal data to leave the EU with a valid transfer mechanism, such as an adequacy decision or standard contractual clauses. Many European enterprises still keep data in region, because Schrems II struck down Privacy Shield and the EU-US Data Privacy Framework is still being tested in court. For GDPR-compliant AI, you have three ways to handle it:
- Use the EU region of a hosted API. You still deal with a US-headquartered processor, and support access and abuse logs may cross borders.
- Tokenize before the API. Identifiers never leave and it works with any model. It does not by itself take the transfer out of Chapter V, so keep a transfer mechanism and write down why the residual risk is low. Only self-hosting answers “no data in the US” literally.
- Run the model yourself in your own EU VPC, private cloud, or air-gapped environment. You get full control over where data is processed, and you own the ops and the GPU bill.
Self-hosting is not a GDPR exit. It settles one question: where the data is processed. Purpose, lawful basis, minimization, retention, who may detokenize, and what each agent and tool receives do not change because the GPU is yours. The comparison and the watch-outs for each option are in data residency for LLMs.
Which GDPR edge cases should you plan for?
The seven controls handle most applications. Special category data and the DPIA can decide whether your first use case ships at all, so check those before launch.
- Special category data. Health, biometrics, religion, politics, sexual orientation, trade union membership, and ethnic origin fall under Article 9 and need an explicit exception on top of the lawful basis. Tokenizing does not take the data out of Article 9, since you can still link it back. It shrinks who sees it. It does not change what it is.
- Data subject rights. Access, correction, and erasure are hard against ten thousand chat transcripts, a vector store, and a fine-tune set. You need an index of where each person’s data went.
- Indirect identification. A record with no name but with a postcode, a birth year, an employer, and a job title can still point at one person.
- Prompt injection and leaks. These are security incidents under Article 32 and may be breaches under Article 33. Tokenization limits the damage, because what leaks is tokens.
- DPIA triggers. Article 35 requires an assessment for high-risk processing. One trigger can be enough, and each regulator publishes its own list.
- Controller or processor. If the model provider decides what to do with your data, for example by training on it, they act as a controller for that use. Roles follow what actually happens, not the label in the contract.
- The EU AI Act. The EU AI Act adds obligations for high-risk AI systems on top of GDPR, with phased application dates running from 2025 into 2028. GDPR still governs the personal data. The AI Act governs the system.
GDPR-compliant AI checklist
Hand this to an engineer before they build. Tokenization and an in-region vault are the architecture we recommend, not something the law names.
- ☐ One sentence that says what the application does with personal data, and a lawful basis chosen for it
- ☐ DPIA screening done, and a full assessment before launch where the processing is likely high risk
- ☐ Only the personal data the task needs goes into the prompt, with identifiers tokenized before they leave your boundary
- ☐ Token vault runs in your infrastructure, in region, under your keys, and detokenization is a logged policy decision per user and per destination
- ☐ Each tool or MCP server an agent calls gets only the fields it needs
- ☐ Documents tokenized before embedding, with a source ID carried through the index
- ☐ Vendor training is off, the retention window is known, and inference region, log location, and sub-processors are listed
- ☐ Retention set and a delete path built for logs, chat history, vector stores, and caches
- ☐ A human with authority to change the outcome reviews decisions with significant personal impact (our recommended baseline, not the only lawful route)
- ☐ Organization-wide: privacy notice updated, use case added to records of processing, rights and breach processes extended to AI stores and vendors, and your DPO consulted. The business stays accountable
FAQs
Which AI platforms are GDPR compliant?
Compliance depends on your purpose, lawful basis, the data you send, and the vendor’s terms. Check three things in writing: training is off, the retention window is known, and sub-processors and region are listed.
Is tokenized data still personal data under GDPR?
Yes, in your hands, because you hold the key. In 2025 the CJEU held that pseudonymized data may not be personal data for a recipient with no realistic means to re-identify people. That is a case-by-case question. Treat tokenization as a safeguard that reduces risk, not as an exemption.
Where to start
GDPR and AI are not in conflict. GDPR asks you to know what data you use, use only what you need, protect it, and prove it. Tokenization does most of the work on the first three at the prompt layer, and the audit log backs up the fourth.
See how Protecto approaches GDPR compliance for AI.
