GDPR Right to Erasure in Vector Databases: What Delete Misses

The Short Answer

An erasure request under Article 17 has to reach further than most RAG systems are built to reach. Three things go wrong, in order of how often I see them:

1. The source document is deleted and the embeddings are not. The chunk that mentions the person is still in the index, still retrievable, still liable to be quoted back at someone.
2. The embedding is “deleted” but only soft-deleted. It is filtered from query results while remaining on disk until compaction - which in some deployments is never.
3. Nobody knows where else it went. Conversation logs, cached retrievals, evaluation sets, provider-side logs, backups.

The fix is not a deletion routine. It is tagging at ingestion so that erasure becomes a fan-out across known locations rather than a search problem inside a store that has no concept of who anyone is.

Are Embeddings Personal Data?

Assume yes, whenever they were derived from text containing personal data.

The tempting argument is that an embedding is just an array of floats - a transformation, not the data. That does not survive contact with GDPR’s definition of anonymisation, which requires re-identification to be reasonably impossible. Embedding-inversion research has demonstrated that meaningful portions of source text can be reconstructed from vectors. A representation you can partially invert back to the sentence it came from is pseudonymised at best, and pseudonymised data is still personal data.

This has one immediate architectural consequence: the erasure boundary is the embedding, not the document. Any design that treats the vector index as a derived cache outside the data lifecycle has the boundary in the wrong place.

Soft Delete Is Not Erasure

This is the part that surprises teams who believed they had solved it, and it is worth being precise about because it is a difference between what an API reports and what is on disk.

Most vector databases implement deletion as a tombstone: the vector is flagged, excluded from query results, and physically removed later during compaction or a reindex. Between those two moments the data is still there. Research on HNSW-based indexes has shown that soft-deleted embeddings can remain reconstructible by anyone with access to the underlying storage - and that data controllers routinely treat the absence of an API response as evidence of erasure when it is only evidence of filtering.

Backups make this worse and are almost always out of scope in the initial design. A snapshot taken the day before an erasure request contains the data, and restoring it silently reinstates what you told a regulator you had removed. Snapshot retention needs to be part of the erasure story, not a separate operational concern.

Three questions to ask of whatever store you are on - and the answers vary enough that you should check yours specifically rather than trusting a general claim:

• Is delete a tombstone or a physical removal, and if the former, what triggers compaction?
• Can compaction or a reindex be invoked on demand, so an erasure has a defined completion?
• What is the backup and snapshot retention, and how are erasures reconciled against restores?

Store selection is a separate question, covered in vector databases for enterprise RAG. The point here is narrower: deletion semantics differ between stores, and they are rarely on the comparison table.

Tag At Ingestion, Or Search Forever

The single decision that makes erasure tractable is made long before the first request arrives.

Tag every chunk at ingestion with the data-subject identifiers it derives from, and propagate that tag to every derivative artifact. An erasure request then becomes a metadata query across known locations - fast, complete, and evidenceable.

Without it, you are reduced to semantic search for a person inside a store that has no identity index. That is slow, incomplete by construction, and impossible to evidence: you cannot tell a regulator you found everything, only that you found what a similarity search surfaced.

Retrofitting the tags means reprocessing the corpus, which is exactly the sort of expense that gets deferred until a request forces it. This is a genuinely cheap decision made once, at ingestion, and an expensive one made later - the same shape as the audit-trail decision in validating LLM systems under 21 CFR Part 11.

Everywhere Else Personal Data Ends Up

The vector store is the copy people remember. It is rarely the only one. A complete erasure has to account for:

Evaluation sets deserve the emphasis. They are built by copying real production data once, then treated as a fixed test asset and never revisited - which is precisely what makes them useful and precisely what takes them outside the erasure path. If your eval set contains personal data, it is in scope, and the tagging has to reach it.

Why This Is An Argument For RAG Over Fine-Tuning

Personal data in an embedding can be deleted and the index rebuilt. Personal data in model weights cannot be selectively removed. Machine unlearning is an active research area, not a compliance position you can defend today, and the practical remedy for a fine-tuned model trained on personal data is retraining on a cleaned corpus.

That asymmetry is a genuine architectural argument, and it belongs in the decision alongside the usual accuracy and cost trade-offs in RAG vs fine-tuning. Where personal data is involved, retrieval is not only usually better on freshness - it is the option that remains erasable.

PDPA, and Why the Engineering Is the Same

The statutory tests differ between GDPR, Singapore’s PDPA and Malaysia’s PDPA, and this is not legal advice on any of them. But the engineering problem is identical under all three: if you cannot enumerate where a person’s data ended up, you cannot satisfy a request under any regime.

That is worth knowing before you build regionally. Teams sometimes defer the tagging work on the grounds that they are not operating in the EU yet. The tagging is the same work, it is cheapest at ingestion, and it is what makes the answer to every one of these regimes a query rather than an investigation.

Frequently Asked Questions

Do embeddings count as personal data under GDPR?

Treat them as personal data whenever they were derived from text containing personal data. An embedding is not anonymised data - it is lossy but reversible enough that published research has demonstrated partial reconstruction of source text. Anonymisation requires re-identification to be reasonably impossible; a vector you can invert to recover the sentence it came from does not meet that bar. So an erasure request has to reach the vector store, not stop at the source document.

Does deleting a document from a vector database actually erase it?

Often not. Most vector databases implement deletion as a soft delete: the vector is marked removed and filtered from results, but stays on disk until compaction or reindex, and may persist in backups longer. Research on HNSW indexes has shown soft-deleted embeddings can remain reconstructible by anyone with storage access. Absence from API responses is evidence that queries are filtered, not that data is erased.

How do you handle a right-to-erasure request across a RAG pipeline?

Make it a fan-out over tagged data rather than an investigation. At ingestion, tag every chunk with the data-subject identifier it derives from, and propagate that tag to every derivative artifact - embeddings, cached retrievals, conversation logs, evaluation sets, analytics. An erasure request then becomes a query across known locations. Without ingestion-time tagging you are reduced to semantic search for a person inside a store with no identity index, which is slow, unauditable and cannot be evidenced.

Can you delete personal data from a fine-tuned model?

Not reliably. Once personal data is in training data it is distributed across model weights and there is no established method to remove one individual without retraining. Machine unlearning research exists but is not something to rest a compliance position on. This is a strong architectural argument for retrieval over fine-tuning wherever personal data is involved: an embedding can be deleted and the index rebuilt; a weight cannot be selectively forgotten.

Where does personal data hide in a RAG system besides the vector store?

Conversation and chat history, prompt and response logs kept for debugging, LLM provider-side logs subject to their retention terms, cached retrieval results, evaluation and test sets built from real production data, analytics events, and database backups and index snapshots. Evaluation sets are the most commonly missed, because they are copied once and then live outside the production data lifecycle entirely.

Does this apply to PDPA in Malaysia and Singapore too?

The mechanics are the same even though the legal tests differ. Both give individuals rights over their personal data and both require that you can actually locate and act on it. Whatever the statutory wording, the engineering problem is identical: if you cannot enumerate where a person’s data ended up across embeddings, logs, caches and evaluation sets, you cannot satisfy a request under any of these regimes. Build the tagging once and it serves all of them.

Build For The Request Before It Arrives

Every expensive version of this problem comes from the same source: the erasure path was designed after the ingestion path. Tagging at ingestion costs almost nothing and turns Article 17 into a query. Adding it later means reprocessing the corpus, and reconciling against backups you have already taken.

If you are building retrieval over data about people - customers, employees, patients, claimants - decide the erasure boundary before the first document is indexed. That is the whole recommendation, and it is one of the few compliance decisions in AI that is genuinely cheap when made on time. How I build production RAG covers the rest of the pipeline this sits inside.