What the DPDP Act actually requires of an AI system

Section 8(1) makes the Data Fiduciary responsible for compliance in respect of any processing undertaken by it or on its behalf by a Data Processor, and section 8(2) permits engaging a processor only under a valid contract. Read that against a retrieval system and the boundary is not where teams assume. Your LLM API vendor is a processor. So is your vector database host, your observability platform and your transcription service. Each is a place a copy lands, each needs a contract, and each is your liability rather than theirs.

The first step on any AI project handling personal data is therefore a data-flow map rather than a model choice: every component that sees a prompt, a chunk, a tool response or a trace, and what it retains and for how long. Most teams can produce this for their primary database and not for their prompt logs — the store that fills with names, phone numbers and account references pasted in by users.

• Enumerate every sink: primary store, search index, vector index, cache, prompt and completion logs, trace store, evaluation fixtures, fine-tuning corpora, backups
• Record the retention period for each, and who controls deletion — you, or a vendor
• Treat free-text fields as containing personal data by default

Build the erasure path on day one, as a job that walks every sink in the data-flow map and reports what it deleted. Retrofitting is expensive because vector stores are keyed by chunk, not by person, so reconstructing which chunks derive from which individual means re-ingesting the corpus. Carry the subject identifier as chunk metadata from the start, and deletion becomes a filtered delete rather than a forensic exercise.

Fine-tuning is the sink with no delete. You cannot remove one person from a set of weights; you can only retrain without them, which means holding the training set indefinitely and re-running the job. Price that before approving the run. Our default recommendation is blunt: fine-tune on format, tone and domain vocabulary, and keep facts about people in retrieval, where deletion is a query and a correction propagates immediately.

The Rules add scheduled erasure for specified classes: under the Third Schedule, large e-commerce, gaming and social media intermediaries above stated user thresholds must treat the purpose as no longer served after three years of user inactivity, with advance notice before deletion (Baker Botts).

• Carry a subject key into chunk metadata so vector deletion is a filter, not a rebuild
• Set prompt and trace log retention deliberately, and confirm the vendor honours it
• Check the LLM vendor's abuse-monitoring retention — zero retention on inference is not zero retention everywhere
• Assume every fine-tune is permanent, and plan the retrain cost before approving it

Two of those interact awkwardly. The Rules require logs sufficient to detect unauthorised access, kept for a year. The Act requires erasure when the purpose ends. If your logs are the prompt and completion payloads — which is what most LLM observability defaults to — your security logs are a personal data store with a mandated one-year floor.

The resolution is structural. Split the trace into a durable skeleton and a short-lived payload: keep request IDs, subject keys, timestamps, retrieved document IDs and scores, tool names, token counts and outcome codes for as long as security needs them, and keep the text under a shorter retention with its own erasure path. You lose the ability to reread the exact prompt from eleven months ago; you keep the ability to prove what the system did, which is what an audit asks for.

Masking and tokenisation are named in Rule 6 for a reason: reversible tokens in place of identifiers shrink the blast radius of every downstream copy at once. Free text defeats naive pattern matching, so test the redactor against real traffic.

• Encryption, masking or virtual tokens where data leaves your control
• Access control scoped per collection, not per database
• Structural traces retained long, textual payloads retained short
• Processor contracts carrying the same obligations, because responsibility does not transfer

The commencement schedule, as read by AZB and Partners, brings Rules 1, 2 and 17 to 21 into force on notification, Rule 4 on consent managers a year later, and Rules 3 and 5 to 16 — notice, security safeguards, breach notification, retention and erasure, Significant Data Fiduciary obligations and cross-border processing — eighteen months on. The Ministry frames it as an eighteen-month phased compliance period (PIB).

The Schedule to the Act sets penalties as fixed rupee amounts rather than a turnover percentage: up to ₹250 crore for failure to take reasonable security safeguards under section 8(5), and up to ₹200 crore for failure to notify a breach under section 8(6). Note the ordering — the largest penalty attaches to the control set in Rule 6, the part an engineering team owns outright.

Significant Data Fiduciaries additionally face annual impact assessments and audits, and an obligation to verify that algorithmic software deployed for processing does not pose a risk to data principals' rights. That is the closest the framework comes to naming AI, and an argument for an evaluation harness with recorded results rather than an opinion — see how to evaluate a RAG system.

What we would build now is unglamorous: the data-flow map, the subject key in chunk metadata, the erasure fan-out job, split trace retention, tenancy at the retrieval filter. All five are cheaper to build than to retrofit, and none depend on how the remaining guidance lands.

Does the DPDP Act ban sending personal data to an overseas LLM API?

No. Section 16 takes a negative-list approach: the Central Government may notify countries or territories to which transfer is restricted, rather than requiring approval for every destination. But section 16(2) preserves any other Indian law imposing a higher restriction, which is why a regulated financial entity has to answer the RBI's rules first. That is covered in RBI data residency and calling an external LLM.

Do we need consent to use our own support tickets to build an internal assistant?

It depends on the purpose the data was collected for and what the notice said at the time. Answering the same customers' questions is a much easier argument than training a model, and training is a distinct purpose that generally needs stating as one. The safe engineering position is to separate the two corpora and tag them at ingestion, so that whichever way your counsel reads it, you can act on the answer without re-architecting.

What is the single biggest DPDP risk in a typical RAG deployment?

Prompt and trace logs. They accumulate free-text personal data nobody classified, they are usually held by a third-party vendor outside India, they are rarely covered by a retention policy, and they are almost never wired into the erasure path. They are also the store most likely to be readable by a broad set of internal accounts.

Is a model's output about a person covered by the Act?

If it is personal data about an identifiable individual, yes — generating it does not make it something else. Section 8(3) is the provision to read: where such data is likely to be used in a decision affecting the individual or disclosed to another Data Fiduciary, the obligation is to ensure completeness, accuracy and consistency. An inferred score or a generated summary in a CRM meets that description.