Can you actually delete someone from a RAG pipeline?

A data subject access request arrives. You delete the source document and close the ticket. The person is still in four other places, and one of them you cannot reach.

The month starts when the email lands

Article 12(3) gives you one month to respond to a data subject access request, extendable by two further months where the request is complex. Article 15 says you have to tell the person what you hold about them. Article 17 says that in defined circumstances you have to erase it.

None of that was written with retrieval-augmented generation in mind, and none of it cares.

The workflow most organisations have is the one they built in 2018. Search the file shares, search the mail archive, export what you find, delete what qualifies, write the letter. It was never comfortable but it was tractable, because there was one copy of the truth and the copies of the copies were at least in file systems you could enumerate.

Then someone connected a RAG pipeline to those same shares. The number of places a person exists went from one to five, and only three of them are in anyone's erasure procedure.

The five places, and which ones you can reach

1. The source documents. The CV, the email thread, the contract, the support ticket. This is what your existing process handles and it handles it adequately. Tractable.

2. The vector index. This is the one that gets forgotten, and it is not a small oversight.

When you ingest a document you chunk it and embed each chunk as a vector. That vector is not a pointer to the document — it is a lossy but semantically faithful representation of the text itself, sitting in a separate datastore with its own lifecycle. Delete the source file and the vector remains, happily retrievable, because nothing in a naive ingestion pipeline propagates deletion backwards.

People assume a vector is anonymous because it is a list of floats. It is not. Embedding inversion is a live research area and it works well enough to reconstruct substantial portions of the source text from the vector alone. Treat embeddings of personal data as personal data, because on any honest reading of Article 4(1) that is what they are.

Tractable, but only if you built for it. You need stable document IDs carried into the vector store as metadata, and a delete path that fans out from source to index. Retrofitting this into a pipeline that was stood up as a proof of concept is genuinely painful, and most RAG deployments in production today were stood up as proofs of concept.

3. Conversation logs. Every prompt and every response, retained for debugging, evaluation, and abuse detection. If an employee asked the assistant about a customer and got a synthesised answer containing that customer's details, the customer's personal data is now in a log store that your DSAR process has almost certainly never searched.

Tractable, and mostly a matter of admitting the log store exists and giving it a retention rule.

4. Caches, backups, replicas. Prompt caches, retrieval caches, the nightly snapshot of the vector database, the read replica. Deleting the primary and leaving the copies is not erasure. It is erasure from the one place you happened to be looking.

Tractable with effort, and this is where I would concentrate the effort, because it is the failure that is easiest to demonstrate to a regulator and hardest to explain away.

5. Model weights. If you fine-tuned on personal data — a LoRA adapter over ten years of support tickets, say — the person is now distributed across parameters in a way nobody can localise or excise.

Not tractable. There is no delete operation. Machine unlearning is an active research field, the published techniques are approximate, and none of them will give you an assurance you would want to put in writing to a supervisory authority.

The EDPB looked at the adjacent question in Opinion 28/2024 and did not hand anyone a blanket exemption. Whether a model can be considered anonymous is a case-by-case assessment, and it turns on whether personal data can be extracted or a data subject singled out — which, given what membership inference and extraction attacks demonstrate, is not a safe default assumption.

The practical consequence is blunt: do not fine-tune on personal data. Not because it is forbidden, but because you are creating an obligation you have no mechanism to discharge. Keep personal data in the retrieval layer, where deletion is an engineering problem rather than an unsolved research one. RAG is the compliant architecture almost by accident, provided you wired the deletion path.

What Article 15 asks that everyone forgets

The erasure half gets all the attention. The access half is quietly harder.

A data subject access request asks you to state what personal data you hold about the person and where it came from. If your pipeline ingested a set of SharePoint sites because scoping properly was going to take three weeks, you cannot answer that question. Not "it takes a while to answer" — you structurally cannot, because you never knew what went in.

That is the same failure as Article 5(2), arriving through a different door and with a named individual attached to it.

Writing a procedure that survives scrutiny

The version that holds up is shorter and more honest than the version most organisations have:

• Enumerate the stores. Source systems, vector index, conversation logs, caches, backups. Named, owned, with a retention rule each. If it is not on the list it will not be searched.

• Propagate by ID, not by name. Deletion fans out from a stable document identifier. Matching on a person's name across five systems fails on spelling, on marriage, and on the fact that people share names.

• Log the deletion, not the data. Identifier, reason, authoriser, timestamps per store. Enough to prove the act without retaining what you deleted.

• State what you did not delete, and why. Data under a statutory retention obligation, and — if you fine-tuned before you knew better — the model. Regulators respond considerably better to a documented limitation than to a discovered one.

• Re-run it. A deletion that succeeds once and is silently broken by the next pipeline change is worse than no deletion, because you have a certificate saying otherwise.

The shortcut

Every item above is easier in proportion to how little you ingested.

The organisations that will handle this well are not the ones with the most sophisticated erasure tooling. They are the ones who classified their unstructured data first, deleted what had no lawful purpose, and only then pointed a retrieval pipeline at what was left.

They are answering data subject access requests against a corpus they can describe. Everyone else is answering them against a corpus they hope they can describe.

If you want to know what is actually sitting in your unstructured data, we run a free review.

Take care out there.

/A