Governance & regulation
Is a RAG system GDPR compliant?
Short answer
RAG can be GDPR compliant, and is often easier to make compliant than fine-tuning, because personal data stays in a retrievable store you control rather than being absorbed into model weights. That structure means you can honour erasure requests by deleting from the index, enforce access controls at retrieval time, and show exactly which records informed an answer. The obligations that still apply are a documented lawful basis, a data processing agreement with your model provider, a transfer mechanism if inference happens outside the EEA, and a DPIA where the processing is likely to be high risk.
Last reviewed
This is engineering guidance, not legal advice. Your data protection officer or counsel should own the legal position.
Why RAG is structurally easier than fine-tuning
Under GDPR, personal data must be deletable, correctable and access-controlled. Once personal data is fine-tuned into model weights, none of those are cleanly achievable. You cannot surgically remove one person’s data from a trained model, and you cannot stop it surfacing to an unauthorised user.
In a RAG system the personal data stays in an index:
- Erasure is a delete from the index and the source, and it takes effect immediately.
- Rectification is an update and re-index.
- Access control is enforced at retrieval, before the model sees anything, so so a user only ever gets answers grounded in documents they were entitled to read.
- Traceability falls out of the citations: you can show which records contributed to a given output.
That is a far better starting position.
What you still have to get right
Lawful basis. Usually legitimate interests for internal knowledge tools, with a documented balancing test. Consent is rarely the right basis for a workplace system, and it is fragile because it can be withdrawn.
Processor agreements. Your model provider is a processor. You need an Article 28 data processing agreement, and you need to check what the provider does with inputs: whether prompts are retained, for how long, and whether they may be used for training. Enterprise tiers of the major providers generally offer zero-retention and no-training options; the default consumer tiers often do not.
International transfers. If inference happens outside the EEA you need a valid transfer mechanism, typically Standard Contractual Clauses or the EU-US Data Privacy Framework where the provider is certified. The simplest path is often to avoid the question by using EU-region inference endpoints, which every major provider now offers.
DPIA. Required where processing is likely to result in high risk to individuals. For systems touching employee data, health data, or automated decisions affecting people, assume you need one.
Purpose limitation. Data collected for one purpose cannot be silently repurposed as AI training or retrieval material. This catches a lot of internal projects that index a CRM or a support archive without revisiting the original notice.
Design choices that make this tractable
- Filter at retrieval, not in the prompt. Apply the user’s permissions to the search query itself so unauthorised passages are never retrieved.
- Keep the index authoritative and derived. Treat it as a projection of the source system so deletions propagate on a known schedule, and document that schedule.
- Redact before egress. Strip identifiers that the model does not need to answer the question.
- Choose EU-region inference for EU personal data. It removes the hardest part of the transfer analysis.
- Log what was retrieved, not just what was answered. That log is what lets you respond to a subject access request truthfully.
- Set a retention period on prompt logs and enforce it. Conversation history is personal data too, and it is the part teams most often forget.
People also ask this as
- Can we put personal data in a RAG system?
- Does GDPR allow sending data to an LLM provider?
- How do we handle a deletion request in a RAG system?