When a German or French client asks whether their LLM project is GDPR compliant, the question usually arrives late, after a prototype already sends customer emails to a model API in another country and logs every prompt forever. Fixing that is possible, but it is cheaper to design for it from the first sprint.
The good news is that GDPR does not treat LLMs as a special category. The same principles apply as to any other processing of personal data: a lawful basis, a clear purpose, minimization, security, limited retention and respect for data subject rights. What changes is where personal data hides. It turns up in prompts, retrieved documents, embeddings, logs, evaluation sets and fine-tuning data. This post walks through each of those as engineers see them.
Lawful basis and purpose come first
Every processing activity needs one of the lawful bases in Article 6. For most business LLM features that is contract (you need to process the data to deliver the service the user signed up for) or legitimate interests, which requires a documented balancing test showing your interest is not overridden by the individual's rights. Consent is rarely the right choice for core product features, because it has to be freely given and as easy to withdraw as to give.
Purpose limitation is where LLM projects drift. Support tickets collected to answer customers are not automatically available for training a model, building a sales assistant, or populating a shared evaluation dataset. Each new use needs its own check against the original purpose. Write the purposes down per data source before engineering starts, because they decide what the pipeline is allowed to ingest. If special category data (health, religion, union membership and similar) may appear, the bar is higher still, and you need an Article 9 condition as well.
Model providers are processors, so get the DPA right
When you send personal data to a hosted model API, the provider is normally your processor, and Article 28 requires a data processing agreement. The major providers offer standard DPAs for their business and API products. Read them for a few specific points rather than signing blind:
- Whether inputs and outputs are used to train the provider's models. Business and API terms generally exclude this by default; consumer products often do not. Make sure staff are not pasting customer data into consumer chat apps.
- How long prompts and outputs are retained for abuse monitoring, and whether zero or reduced retention is available for your account.
- The list of sub-processors and how you are notified of changes.
- Where processing happens, and which transfer mechanism covers any transfer outside the EEA.
- Security commitments, breach notification timelines and audit rights.
For transfers to the US, the EU-US Data Privacy Framework covers providers certified under it, and Standard Contractual Clauses with a transfer impact assessment are the usual fallback. Keep a record of which mechanism applies to each provider in your Article 30 records of processing. Auditors and enterprise customers will ask for exactly that table.
EU data residency options
Data residency is not strictly required by GDPR, since lawful transfers are allowed, but many German and public-sector buyers require it contractually. The practical options fall into a few groups, each with different trade-offs.
| Option | What you get | Trade-off |
|---|---|---|
| Cloud-hosted models in EU regions | Major models served from EU data centers by hyperscalers | Not every model or feature is available in every region |
| Provider EU data residency offerings | Storage and processing commitments for EU customers | Check exactly what is covered, often stored data more than processing |
| European model providers | EU-headquartered vendor and hosting | Smaller model range, compare quality on your own evals |
| Self-hosted open-weight models | Full control over location and logs | You own GPUs, scaling, patching and security |
Read residency claims carefully. Some cover data at rest but allow processing elsewhere, and some exclude support access or abuse monitoring. Also remember that your other components count: the vector database, the observability tool storing traces, and the evaluation platform all process the same personal data. A model in Frankfurt does not help much if every prompt is copied to a logging service in Virginia.
Redact personal data before the prompt
Minimization is the most effective control you have. If the model does not need a customer's name, IBAN or phone number to do its job, remove them before the request leaves your system. A redaction layer typically combines pattern matching for structured identifiers (emails, phone numbers, IBANs, card numbers, national ID formats) with a named-entity model for names and addresses. Replace each item with a stable placeholder such as [PERSON_1], keep the mapping in your own system for the duration of the request, and restore the values in the output if the user needs to see them.
Be realistic about accuracy. Entity recognition misses things, especially in German compound words, unusual names and free text full of typos. Test the redactor on a labeled sample of your real data and measure recall per entity type. Treat redaction as risk reduction, not as anonymization. Pseudonymized data is still personal data under GDPR, and your other obligations remain.
Logging, retention and the DPIA
LLM applications generate a lot of logs, and engineers like keeping them for debugging and evaluation. Decide retention per log type: full prompts and outputs for perhaps 30 days for troubleshooting, redacted or aggregated records for longer, and metrics with no personal data indefinitely. Restrict access to raw traces, and do not let production conversations flow into evaluation sets without a review step and a documented purpose.
A Data Protection Impact Assessment under Article 35 is required when processing is likely to result in a high risk to individuals. Many supervisory authorities list innovative technology, large-scale processing and systematic evaluation of people among the criteria, so a customer-facing LLM feature frequently qualifies. Even when it is borderline, doing one is good practice. A useful DPIA for an LLM system describes the data flows end to end, names every processor, covers risks such as inaccurate output about a person, prompt injection leading to disclosure, and over-retention, and lists the controls that address them. If the system also falls under the EU AI Act, align the two assessments so you are not documenting the same pipeline twice.
Data subject requests against vector stores
Access and erasure requests are where many RAG systems turn out to be unprepared. If a customer asks for deletion under Article 17, their data has to come out of the source system and every derived copy: chunks, embeddings, caches, logs and any evaluation sets. Embeddings derived from personal data should be treated as personal data, since the text they came from is usually stored next to them.
The fix is mostly metadata. Tag every chunk with the source document ID and, where relevant, the data subject or customer ID it relates to. Then deletion becomes a filtered delete across the index, and access requests become a filtered query. Without those fields you are left searching embeddings for a name, which is unreliable. Fine-tuned models are harder, because removing one person's influence from model weights is not practical today. That is a strong reason to keep personal data out of fine-tuning sets and use retrieval for anything person-specific.
A note on the UK
Since Brexit the UK applies its own version, the UK GDPR, alongside the Data Protection Act 2018, and the Information Commissioner's Office is the regulator. The core principles are nearly identical, so an architecture built for EU GDPR usually carries over. The differences are mostly administrative. Transfers from the UK use the UK's own mechanisms, such as the International Data Transfer Agreement or the UK Addendum to the EU clauses, and the UK has its own extension to the US Data Privacy Framework. The Data (Use and Access) Act 2025 has also amended parts of the UK regime, so check current ICO guidance rather than assuming the rules match the EU in every detail. If you serve both markets, list both regimes in your records and DPAs.
Questions we get asked
- Can we use OpenAI or other US model APIs under GDPR?
- Often yes, with a data processing agreement, a valid transfer mechanism such as the EU-US Data Privacy Framework or SCCs, settings that exclude training on your data, and appropriate minimization. Many buyers still prefer EU-hosted options.
- Do we need a DPIA for an LLM application?
- Frequently, especially for customer-facing features processing personal data at scale. Even where not strictly required, a DPIA documents data flows and risks in a form customers and regulators expect.
- Are embeddings personal data?
- Treat them as personal data when they are derived from text about identifiable people. They are usually stored with the source text and can be linked back to individuals.
- Is PII redaction enough to make LLM use GDPR compliant?
- No. Redaction reduces risk but is imperfect, and pseudonymized data is still personal data. You still need a lawful basis, processor agreements, retention limits and a process for data subject requests.