Loopholes in the law

The copies your deletion script never reaches

RAG pipelines, vector stores and what the DPDP Act actually asks of an AI feature

18 September 2026 · about 8 minutes

The shortcut: "Our model runs in India, and when a customer asks us to delete their data we delete the row. We are covered."
Does it work?: Residency is not what the Act asks for in the first place, and deleting the row is the easy half. The copies sit in the vector index, the prompt logs, the cache and the backup, and the Act does not care which system a copy lives in.
What to do instead: Know where every copy goes before you ship the feature, key each one back to the person, and test an erasure request end to end rather than assuming it cascades.

Every few months a new piece of infrastructure gets described as the thing that unblocks AI for regulated Indian businesses. The latest is in country inference: the model call stays on servers in India.

It is genuinely useful. It is also not what India's data protection law asks for, and it does nothing about the part that will actually be difficult.

1. Residency is not the test

The DPDP Act does not require personal data to be processed in India. Section 16 works as a negative list: the Central Government may, by notification, restrict transfers to a particular country or territory, and until it notifies one, transfers are permitted. Section 16(2) then preserves any other Indian law that demands more.¹

So the rules that genuinely require Indian storage are sectoral. The Reserve Bank's payment data direction is the obvious one. If you are inside that perimeter, in country inference helps you a great deal. If you are a clinic, a school, a retailer or a SaaS company, it helps your latency and your procurement conversation, and it moves you no closer to what the Act requires.

This matters because "the data never leaves India" has become the sentence that ends the compliance discussion in a lot of rooms. It should be the sentence that starts it.

2. Where the copies actually go

Take an ordinary support assistant. A customer's ticket history is pulled from the main database, turned into embeddings, and stored in a vector index so the assistant can find it later. The question and the retrieved context go to the model as a prompt. The answer comes back. Somewhere along the way your monitoring captures the request for debugging.

One customer record has now been copied into, at minimum:

the vector index, as embeddings plus whatever text you stored alongside them;
the prompt and response logs, which usually hold the retrieved context in plain text;
a cache, if you added one to keep costs down;
the nightly backups of all of the above;
and, if you fine tuned on historical tickets, the model weights.

Now a customer exercises the right to erasure. Your script deletes them from the main database, because that is the system the script was written for. Everything else in that list survives.

3. The Act does not care which system the copy is in

Two provisions do the work here, and neither mentions databases.

Section 8(7) puts the duty on the organisation: unless retention is necessary for compliance with a law, erase personal data when the person withdraws consent, or as soon as it is reasonable to assume the specified purpose is no longer being served, whichever is earlier, and cause your Data Processor to erase it too.¹

Section 12(3) gives the person the right to ask for it.¹

Neither is limited to a particular storage technology. "We deleted them from the primary database" is not an answer to either. It is a description of one of the places you deleted them from.

There is one comfort worth stating plainly, because it is the opposite of the scare story doing the rounds: a vector store can be deleted from. It is a database. Rows come out of it. The reason they usually do not is that nobody wrote the code to map a person's identifier to their vectors, not that the mathematics forbids it. Model weights are the genuinely hard case, and that is the next section.

4. Embeddings are not anonymisation, because the Act has no such concept

The common defence is that a vector is just a list of numbers, so it is no longer personal data.

Check the statute before relying on that. The words anonymis, anonymiz, de-identif and pseudonym appear zero times in the DPDP Act and zero times in the DPDP Rules. There is no anonymisation standard to meet, and no safe harbour for having converted data into a different representation.

What the Act has instead is a definition. Section 2(t) defines personal data as data about an individual "who is identifiable by or in relation to such data".¹ That phrase does all the work. An embedding sitting in a row that carries a customer id, a ticket number or a document name is data in relation to which the person is plainly identifiable. Embeddings are also routinely reversible enough to recover a recognisable version of the source text.

So the honest position is this: if you can find that record in order to serve it into a prompt, you can find it in order to delete it, and a regulator will ask why you did the first and not the second.

5. Fine tuning on old tickets is a new purpose

Feeding five years of support conversations into a training run feels like using your own data. Legally it is a different activity from the one the customer took part in.

If you rely on section 7(a), that legitimate use covers "the specified purpose for which the Data Principal has voluntarily provided her personal data".¹ A person who wrote in about a delayed refund in 2022 provided that data to get the refund sorted out. Training a model is not that purpose.

If you rely on consent, section 6(1) requires it to be free, specific, informed, unconditional and unambiguous, with a clear affirmative action, and "limited to such personal data as is necessary for such specified purpose".¹ A consent form from 2022 that says nothing about model training will not stretch over it.

This is where the technical asymmetry bites. A vector store can be cleaned. Weights cannot be reversed without training the model again. So the decision that is expensive to reverse is the one about what you train on, and it is usually taken by whoever is fastest rather than by whoever is accountable.

6. The breach question nobody has answered

Assume the worst case: the vector store is exposed. What do the Rules require?

Rule 7(1): intimate each affected Data Principal, without delay, in concise and plain language, with a description of the breach, the consequences relevant to that person, the measures you are taking, what they can do to protect themselves, and the business contact information of somebody who can answer their questions.²

Rule 7(2): intimate the Board without delay, and within seventy two hours provide updated and detailed information, the broad facts and reasons, the mitigation, any findings about who caused it, the remedial measures, and a report on the intimations given to affected people.²

Read Rule 7(1) again with a vector index in mind. You cannot tell people what happened to them unless you can say which people. If the index holds no reliable mapping back to the individual, that duty stops being difficult and becomes impossible to discharge. The mapping skipped in order to ship faster is the same mapping the erasure right needed.

7. The vendor is not the answer either

Whether the model is hosted abroad, hosted in India, or running on your own hardware, section 8(1) keeps the responsibility with the Data Fiduciary for processing done on its behalf, and section 8(2) requires a valid contract with the Data Processor.¹ Section 8(5) and Rule 6 then require reasonable security safeguards, and Rule 6 names the kind of thing that counts: encryption, obfuscation, masking, access control, logs and monitoring, and appropriate terms in the contract with your processor.¹ ²

A zero retention promise from a model provider is worth having. It says nothing about the copies in your own index, your own logs and your own backups, which is where this problem actually lives.

8. What a defensible AI pipeline looks like

Write down every place a record lands on its way through the feature: index, logs, cache, backups, evaluation sets, and the notebook on somebody's laptop.
Key every derived copy back to the person. If a vector cannot be traced to a Data Principal identifier, neither erasure nor breach notification is possible.
Make deletion a cascade rather than a script against one database, and decide what happens when a backup is restored. A restore that resurrects deleted people is a quiet failure nobody notices.
Put a retention period on prompt and response logs, and keep retrieved context out of them where you can.
Do not fine tune on historical personal data collected for a different purpose. Retrieval gives you most of the benefit and stays reversible.
Get the contract right with every processor in the chain, including the vector database and the monitoring vendor, not only the model provider.
Test it. Take one real erasure request, run it end to end, then check the index, the logs, the cache and a restored backup. That test is the artefact worth having, because it is evidence rather than an assertion.

The point

None of this commences before 13 May 2027, so nobody is in breach of anything today. But an AI feature built this quarter will still be running then, and the mapping between a person and their vectors is enormously cheaper to build now than to retrofit across a live index, a year of logs and a pile of backups.

Where the model runs is a procurement decision. What you copied, where it went, and whether you can find it again is the compliance question, and it is answered in your own code rather than in anybody's data centre.

References

#DPDP #DataProtection #RAG #AI #VectorDatabase #Privacy #DataMinimisation

General information about the DPDP Act 2023 and the DPDP Rules 2025, not legal advice.

DPDP Roles, explained simply