Short answer: Do not assume an embedding is anonymous. An embedding can be matched back to the text it came from, and the text is usually stored right next to it. Treat each representation in a RAG pipeline as personal data when it can still be tied to a person, which is most of the time for chunk text. When the source record is deleted, every copy has to go.
Your team builds a RAG assistant over HR policy and customer contracts. Documents go in, get chunked, get embedded, and land in a vector store. Then a customer asks you to erase their data, or an employee asks what you hold about them. Someone has to answer whether the vector store is in scope, and which rows came from which document.
Most vector stores have no idea which rows came from which source. That is the practical problem behind the legal question, and it is why this guide spends more time on pipeline design than on the label. It is part of our wider guide to GDPR-compliant AI.
Are embeddings personal data under GDPR?
Treat them as personal data when they can still be tied to a person. Do not assume an embedding is anonymous.
The reasoning is practical. An embedding can be matched back to the text it came from, and the text is usually stored right next to it. So the question is not whether a vector looks like numbers. It is whether anyone can connect the stored material to a person.
GDPR counts data as personal if a person can be singled out from it, directly or by combining fields. A record with no name but with a postcode, a birth year, an employer, and a job title points at one person in most datasets. A RAG index over a million records holds enough of these quasi-identifiers that a determined query can rebuild a profile nobody ever typed in.
GDPR scope does not depend on where your servers sit. This guide describes EU GDPR; review UK requirements separately.
What copies does a RAG pipeline create?
A RAG pipeline makes several representations of every source document: the chunk text in the index, the embedding vector, the metadata, and often more. Treat each as personal data when it can still be tied to a person, which is most of the time for chunk text.
An AI application creates new copies of personal data in places your existing retention policy never covered:
- Prompt and completion logs
- Conversation history for multi-turn chat
- Vector embeddings of documents in a RAG index
- Fine-tuning datasets and evaluation sets
- Cache layers and observability tools
Each one needs a retention period and a delete path. These are your stores, so they are fully your responsibility as controller. Each is a processing activity you own. It needs a lawful basis, a retention period, access control, a search path that answers an access request, and a delete path that fires on an erasure request.
| Store | What it holds | Can you delete it? |
|---|---|---|
| RAG index and embeddings | Chunk text, vectors, metadata, derived from your documents | Yes, but only if you built the delete path |
| Chat history | Every question a user asked, including ones where they pasted a customer’s details | Yes, but only if you built the delete path |
| Observability tools and gateways | Often the full prompt and completion, with every retrieved chunk inside | Yes, if you own the logs and set retention |
When you embed a customer contract, the vector store now holds a derived copy of that contract. That derived copy is a processing activity with its own lawful basis and retention period.
How do you delete personal data from a vector store?
Carry a source ID through the pipeline from day one. When the source record is deleted, all copies have to go: the chunk text, the embedding vector, and the metadata.
Without that ID, you are searching an index that cannot tell you which rows came from which document. With it, an erasure request becomes a lookup and a delete instead of an investigation.
Access and erasure are different rights, and one must never trigger the other. Your stores need a search path that answers an access request, and a delete path that fires on an erasure request, and they should not be the same button.
Access, correction, and erasure requests are easy against a database. They are hard against ten thousand chat transcripts, a vector store, and a fine-tune set. The honest answer is that you need an index of where each person’s data went. A token vault gives you a starting index. Without one, plan for manual search and expect it to eat most of the one-month deadline, which you can extend only in limited cases. Erasure also has exceptions, so check before you delete.
Downstream copies still need their own handling. The vault tells you where a person’s token went. It does not delete the downstream copies for you, so build integrations and check that the delete landed.
How do you stop RAG from disclosing data to the wrong user?
Retrieval adds a second problem. The index serves many users. A chunk from an HR file retrieved for the wrong user is a disclosure, even if nothing was logged.
Your application has to decide which documents a user can retrieve. And the sensitive values inside a retrieved chunk should stay masked unless that user is cleared for them.
Two controls do this work:
- A per-user limit on which documents can be retrieved.
- Masked values inside retrieved chunks, restored only for users who are cleared for them.
The first is an access control on the index. The second is where tokenization comes in. The same rule applies to agents that sit on top of RAG: a tool result with personal data in it lands in the context, and from there it flows into whatever tool the agent calls next. Each tool call that carries personal data is a disclosure, so decide per destination which fields stay masked.
Consider the HR policy assistant. A RAG assistant over HR policy does not need the employee’s salary in the retrieved chunk. Data minimization is the single most useful GDPR principle for AI builders, because it is also the cheapest control. Ask what the model actually needs to do the job, and send it only that.
Why does tokenizing before embedding help?
Tokenizing documents before you embed them handles the second part of the retrieval problem. The index holds <PER>...</PER>, and the real name appears only on the way out, for users who may see it.
Tokenization replaces each personal value with an opaque token that carries the type, keeps the shape, and stays consistent for the same value across the document. Here is what a support ticket looks like before it is chunked and embedded:
| Before | After |
|---|---|
| Hi, this is Sarah Whitfield, account 4471-8820. My card ending 3310 was charged twice on March 3. Call me at +44 7700 900123. | Hi, this is <PER>rk4m2</PER>, account <ACCT>k93f1</ACCT>. My card ending <CARD>p42</CARD> was charged twice on <DATE>d8m1</DATE>. Call me at <PHONE>q27x8</PHONE>. |
The model can still summarize, classify, and draft a reply from the tokenized text. It knows there is a person, an account, and a duplicate charge. It does not know who. Unmasking is a policy decision made at the moment of use, and each decision is logged, which is the audit trail Article 5(2) asks for.
The pattern also supports EU data residency. Tokenize the corpus before you embed it or train on it. The index and the fine-tune set hold pseudonymous data, and the mapping stays in the vault, in region, under your keys. The trade-offs are in data residency for LLMs.
Watch out. Tokenized data is still personal data in your hands, because you hold the key. The CJEU held in 2025 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), but that takes a case-by-case look at what the recipient holds and what the surrounding text gives away. A tokenized index is lower risk than a raw one. It still needs a lawful basis, a retention period, and a delete path. For the redaction side of the story, see does AI redaction meet GDPR.
The vault 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. For retrieval-heavy products, see also Protecto’s approach to secure RAG.
What about logs, rights requests, and indirect identification?
Prompt logs are the easier case, but only if you own them. Observability tools and AI gateways often keep the full prompt and the full completion, with every retrieved chunk inside. Set retention there too, and make sure what they store is the tokenized version.
Indirect identification needs its own care at RAG scale. Masking the name is not always enough, so tokenize beyond the obvious types. Dates, locations, employers, and job titles are identifiers in combination, so treat them as such when the dataset is large or the population is small.
Fine-tuning adds a harder version of the same problem. Large models memorize. Once personal data is in the weights, there is no simple delete, because unlearning techniques exist but are young, and regulators such as CNIL accept output filtering for rights requests only when it is shown to be effective and robust. If you need domain adaptation, fine-tune on masked or synthetic data. Never fine-tune on raw personal data.
Special category data raises the stakes for any index that holds medical notes or HR files. 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.
RAG and GDPR checklist
- ☐ Documents tokenized before embedding, with a source ID carried through the index
- ☐ Your application limits which documents each user can retrieve, and sensitive values inside stay tokenized unless that user is cleared
- ☐ Retention set and a delete path built for logs, chat history, vector stores, and caches
- ☐ A search path for access requests and a separate delete path for erasure requests
- ☐ Observability tools and gateways store the tokenized version of prompts and retrieved chunks
- ☐ Token vault runs in your infrastructure, in region, under your keys
- ☐ Fine-tuning and evaluation sets limited to what is needed, tokenized or synthetic where possible
- ☐ Special category data in scope: Article 9 condition identified
- ☐ Subject requests: existing access, correction, and erasure process pointed at the new stores, using token mappings and data lineage to find records and downstream copies
FAQs
Are vector embeddings personal data?
Do not assume they are anonymous. An embedding can be matched back to the text it came from, and the text is usually stored right next to it. Treat each representation as personal data when it can still be tied to a person, which is most of the time for chunk text.
How do I delete a person’s data from a RAG index?
Carry a source ID through the pipeline from day one. When the source record is deleted, the chunk text, the embedding vector, and the metadata all have to go. Most vector stores have no idea which rows came from which source, so without the ID the delete is hard to target.
Can RAG disclose one user’s data to another user?
Yes. The index serves many users, and a chunk from an HR file retrieved for the wrong user is a disclosure, even if nothing was logged. Limit which documents each user can retrieve, and keep sensitive values inside retrieved chunks masked unless that user is cleared for them.
Where to start
Pick one RAG pipeline and trace a single document through it. List every copy it creates, give each a retention period, and add a source ID if it is missing. Then tokenize the documents before they are embedded, so the index holds tokens and the real values appear only for users who are cleared to see them.
See also Protecto Secure RAG.