The DPDP erasure right will break your vector store

Here is a question worth asking your team this week: if a customer exercises their right to erasure under the Digital Personal Data Protection Act, can you delete their data from your retrieval index?

Not from the source database — that part is usually fine. From the embeddings.

For most teams that have shipped a retrieval system in the last two years, the honest answer is no. And the reason is an architectural decision made early, casually, and almost always by default.

How the problem gets built#

The standard pipeline is: take documents, split into chunks, embed each chunk, store the vectors with the chunk text. Retrieval works. Ship it.

What is missing is the link from each chunk back to the source record it came from. Once that link does not exist, "delete everything relating to this individual" becomes unanswerable, because you cannot determine which of two hundred thousand chunks contain their information without reading all of them.

Why the obvious workarounds fail#

Search the chunk text for their name. Their data is not only in chunks that mention their name — it is in the chunk about their transaction, their claim, their support conversation.

Delete and rebuild the whole index. Works, and it means every erasure request triggers a full reindex. At any real volume that is not operable.

Rely on the source deletion. The embeddings persist and remain retrievable. The data is still there, and still being returned to users.

The fix, and its cost#

Store source lineage with every chunk: the source system, the record identifier, and where in the document it came from. Then erasure is a filtered delete, and it takes milliseconds.

Designed in from the start, this costs an afternoon. Retrofitted, it means a schema change plus a full reindex of your corpus — and if your embeddings are expensive to generate, that is a real number.

The other DPDP constraints with teeth#

Purpose limitation. Data collected to deliver a service generally cannot be repurposed to train or fine-tune a model without fresh consent. This is a constraint on what your AI is allowed to learn from, not a documentation exercise.

Consent must be specific and revocable. Bundled or pre-ticked consent is not consent. That changes form design, and it means marketing consent has to be captured separately from the consent needed to answer an enquiry.

Significant Data Fiduciary duties. Above certain thresholds you owe additional obligations including a Data Protection Officer and independent audits. Worth knowing which side of that line you are on before you scale rather than after.

The general lesson#

Compliance requirements that look like paperwork are frequently architecture requirements wearing a costume. Erasure is the clearest example: it reads like a policy question and it is a schema question.

The teams that will handle this cheaply are the ones that asked before they built.