Does the DPDP Act cover data used to train or prompt AI models?

Yes, wherever that data is personal data of people in India. The Act does not mention AI, but it governs processing of digital personal data, and feeding customer records into a prompt, a fine-tuning set, or a retrieval store is processing. The obligations that bite are the ordinary ones: a lawful basis for the use, a purpose the individual was told about, and deletion when the purpose ends. Reusing data collected for one purpose to train a model is a new purpose, and it needs its own justification.

Does the DPDP Act allow sending personal data to AI vendors outside India?

By default, yes. The Act follows a blocklist model: cross-border transfers are generally permitted except to countries the government specifically restricts by notification. But sector regulators can and do impose stricter rules — the RBI's localisation of payment data is the best-known example — so an AI workload in banking or payments may face hard residency limits even though the DPDP Act itself imposes none. Check both the current notified list and your sector regulator's position before routing data abroad.

Who is accountable when an AI vendor processes our customers' data — us or the vendor?

You are. Under the DPDP Act the data fiduciary — the organisation that decides why and how personal data is processed — carries the legal duty, and using a model vendor or cloud API does not transfer it. The vendor is your processor, working under your contract, and you remain answerable for what happens to the data in its hands and its subprocessors' hands. That is why vendor contracts, deletion rights, and knowing the full processing chain sit on the compliance checklist rather than in a procurement afterthought.

DPDP Compliance Checklist for AI Teams

A DPDP compliance checklist for an AI team has eight sections: map the personal data entering your AI stack, fix consent and notice, enforce purpose limitation, bind your vendors, check the cross-border position, prepare for breach response, honour data principal rights, and put governance around the whole thing. India's Digital Personal Data Protection Act 2023 never mentions AI, but every prompt, training set, retrieval store, and output log containing personal data of people in India is processing under the Act, and the organisation deciding why that processing happens — the data fiduciary — carries the duty.

The checklist below reframes the Act's obligations as work items an AI team can actually close, with the reason each one matters. It deliberately stops short of procedural specifics — timelines, thresholds, and designations that live in the implementing rules — because those should be verified in their current form, not quoted from a blog. The wider two-market picture sits in AI compliance in Saudi Arabia and India; this piece is the India half turned into a to-do list.

1. Map the personal data touching your AI stack

List every AI system in use, including unofficial ones. Shadow usage — a team pasting customer emails into a public chatbot — is processing you are accountable for and have not mapped.
For each system, trace the four data paths: prompts, training or fine-tuning data, retrieval stores, and outputs. Personal data hides in all four. An output can contain personal data even when the prompt did not.
Find the logs. Most AI stacks record prompts and outputs by default, often in a vendor's infrastructure. Those logs are personal data if the prompts were, and they are the most commonly forgotten store in any inventory.

Why it matters: every later checklist item operates on this map. Teams that skip it end up compliant about the systems they know of and exposed on the ones they do not.

2. Consent, notice, and legal basis

Name the lawful basis for each use. The Act's default is specific, informed consent for a stated purpose, with a narrow set of legitimate uses as alternatives. "We collected it, so we can use it" is not a basis.
Check the notice actually describes the AI use. If your privacy notice says data is used to provide the service, and you are also using it to fine-tune a model, the notice and the reality have diverged.
Treat children's data as a special case. The Act imposes stricter conditions on processing children's data, including verifiable parental consent; if your AI product can touch minors' data, this needs specific design, and the current rules should be checked rather than assumed.

Why it matters: consent gaps are the most visible kind of non-compliance, because the individual who was never told is also the individual who can complain.

3. Purpose limitation and retention

Match each AI use to the purpose the data was collected for. Support transcripts collected to resolve tickets, reused to train a sales model, is a new purpose. Either get a basis for it or do not do it.
Give every prompt and output log an owner and an expiry. The Act expects personal data to go when its purpose is served. Default-indefinite logging is where most quiet exposure accumulates.
Include derived data. Embeddings, extracted fields, and model outputs built from personal data are part of the same obligation, not a loophole out of it.

Why it matters: purpose and retention are where regulators in every modern regime look first, because they are where organisations drift furthest from what individuals were told.

4. Vendor and processor obligations

Identify the full chain for each AI vendor: the model provider, the cloud it runs on, and any subprocessors, and where each is located.
Put processing terms in the contract: what the vendor may do with your data, whether it may train on it, how deletion works, and how its subprocessors are bound.
Confirm you can actually get data back or destroyed. A deletion right you cannot exercise against a vendor is a right you do not have.

Why it matters: accountability under the Act stays with you as fiduciary. The vendor chain is your processing, done at arm's length.

5. Cross-border transfers

Know the model: general permission with a blocklist. Transfers are allowed except to countries the government restricts by notification. Check the current notified position; do not rely on what it was.
Layer in sector rules. Sector regulators can be stricter than the Act — the RBI's payment data localisation is the standing example — so a BFSI workload may be locked in-country regardless of the general rule.
Treat model APIs as transfers. If inference happens abroad, the personal data in the prompt went abroad. Where the analysis is uncomfortable, in-country deployment is often the simpler answer than a clever transfer argument.

Why it matters: this is the checklist item where "where does the model actually run" stops being an infrastructure detail and becomes a legal fact.

6. Breach response

Have a defined path from "something looks wrong" to notification. The Act requires personal data breaches to be reported to the Data Protection Board and affected individuals; the operational specifics belong to the current rules, so build the process around verified requirements, not remembered ones.
Extend incident scope to AI-specific failures. A prompt-injection exfiltration or a model output leaking one customer's data to another is a personal data breach with an unusual mechanism, not a curiosity.

Why it matters: breach handling is judged on preparation. A team that has to work out its obligations during the incident has already lost the timeline.

7. Data principal rights

Be able to answer access and correction requests across the AI stack. If a customer's data sits in a retrieval store and a log archive, "we checked the CRM" is an incomplete answer.
Make erasure real. Deletion must reach prompts, logs, and derived stores, and flow to processors. Whether and how it reaches trained models is genuinely hard — design so that personal data stays out of training sets unless you have specifically decided otherwise.
Stand up grievance handling. The Act gives individuals a route to complain to you and escalate beyond you; someone in the operation must own the response.

Why it matters: rights requests are compliance made visible. They are also the mechanism by which an unmapped system gets discovered at the worst possible moment.

8. Governance that holds it together

Check whether heavier duties could apply to you. The Act allows the government to designate Significant Data Fiduciaries, which attracts added obligations such as audits and impact assessments; whether you are in scope is a question for counsel against the current designations.
Put the controls in one place. Routing rules, retention enforcement, vendor allowlists, and audit logs work far better as a single AI governance control plane than as eight policies in a shared drive.
Re-run the checklist on change. New model, new vendor, new use case, new notified country — each reopens items above.

Why it matters: the difference between a checklist completed once and a control that holds is enforcement, and enforcement needs machinery, not memos.

The checklist at a glance

Item	The question it answers
Data mapping	What personal data does our AI actually touch?
Consent and notice	Were people told, and is there a basis?
Purpose and retention	Is each use the stated one, and does data expire?
Vendors	Who else processes it, and what binds them?
Cross-border	Where does it go, and may it?
Breach response	What happens when it goes wrong?
Rights	Can we answer the individual?
Governance	Who enforces all of the above?

Where to start

Do sections one and three first: the map, and retention. Nearly every DPDP problem an AI team has is either a system nobody inventoried or a log nobody expires, and both are fixable in weeks without a lawyer in the room. Then close the vendor contracts and the cross-border position, which do need the lawyer. The Act's implementing rules and the Data Protection Board's practice are still settling, so treat the checklist as durable structure and verify the specifics as you close each item — that discipline travels well beyond India, as the broader AI adoption picture across India and the GCC makes clear.