Contents (6 sections)
Phase 3 of India's Digital Personal Data Protection Act binds on 13 May 2027. Most published DPDPA compliance checklists treat AI as a footnote — and the section that covers model training on personal data, cross-border inference, and the genuinely unsettled question of whether you can erase someone's data from a fine-tuned model simply does not exist in any template I have seen.
This matters right now because the compliance calendar is shorter than it looks. Phase 1 activated on 13 November 2025. Phase 2 activates Consent Manager registration on 13 November 2026. Phase 3 — the one with the substantive obligations, the penalty schedule, and the cross-border transfer rules under Rule 15 — lands on 13 May 2027. That is eighteen months from the date of this post. Eighteen months sounds comfortable until you account for the fact that most enterprises are only now getting to grips with Phase 1 definitions, and "getting a contract signed with legal" at any large Indian pharma or NBFC takes four to six months by itself. If your AI rollout is already in production and your DPDPA compliance plan does not specifically address what the AI system does with personal data, you are behind.
The definitions that your AI vendor contract almost certainly gets wrong
DPDPA §2(i) defines a Data Fiduciary as anyone who "alone or in conjunction with other persons determines the purpose and means of processing." §2(k) defines a Data Processor as "any person who processes personal data on behalf of a Data Fiduciary." The distinction matters enormously because it determines who faces the §33 penalty schedule — up to ₹250 cr per breach event for failure of reasonable security safeguards under §8(5).
In the standard cloud LLM arrangement — your organisation sends employee queries or customer data to ChatGPT Enterprise, Claude Team, or Copilot — the classification question is not settled. Your organisation is the Fiduciary. But OpenAI, Anthropic, and Microsoft are not pure Processors in the DPDPA sense if they use that data to improve their models, tune their systems, or feed it into any cross-customer artefact. The moment any of those things happen, §2(i)'s "in conjunction with other persons determines the purpose and means" language becomes live. You may be sharing Fiduciary status with a company headquartered outside India that has never heard of the DPDP Rules 2025.
Standard enterprise agreements from US cloud vendors are written around GDPR and CCPA templates. They classify the vendor as a "data processor" or "service provider" under those frameworks, which maps approximately onto DPDPA §2(k) — but not perfectly. GDPR's processor definition, like DPDPA's, hinges on whether the vendor determines purpose and means. If your ChatGPT Enterprise agreement permits Microsoft to use your data for model improvement (even with an opt-out that you have to actively exercise), you have a Fiduciary characterisation problem that your current compliance plan probably ignores entirely.
For on-premises deployments, this problem largely disappears: if the model runs on your hardware, inside your network, and the vendor never sees your inference data, the vendor is at most a one-time Processor at the point of fine-tuning, and a well-drafted §8(2) contract can lock the processing scope to that single, defined task. This is the architecture we use at OwnAI (architecture overview) — not primarily for commercial reasons, but because it produces the cleanest DPDPA answer.
Model training on personal data: the gap nobody has written a template for
Here is the scenario that every compliance template I have reviewed fails to address. Your organisation wants to fine-tune an LLM on internal data: clinical trial reports, GMP deviation logs, customer complaint records, credit underwriting notes. Some of that data contains personal information — patient identifiers, employee names, borrower PAN numbers, adverse event narratives linked to identifiable individuals.
Under DPDPA §6(1), consent for processing personal data must be "free, specific, informed, unconditional and unambiguous, with a clear affirmative action," and it must be limited to "such personal data as is necessary for such specified purpose." The purpose on which most existing consent was obtained — "providing you with healthcare services" or "processing your loan application" — does not cover "training an AI model." The Act contains no GDPR-style legitimate-interests balancing test. The §7 "legitimate uses" list is closed, and none of the items in it map comfortably onto retrospective LLM fine-tuning of production records.
This means, in practice, that most Indian enterprises that want to fine-tune on their own historical data will need to obtain fresh, AI-training-specific consent from the affected data principals, or de-identify the training corpus to a standard that genuinely removes personal data before a model ever touches it. The latter is harder than it sounds: research published in 2024–2025 shows that fine-tuning on repeatedly-presented sensitive data raises privacy leakage rates to 60–75% across multiple model families, compared to a 0–5% baseline. A dataset that you consider "pseudonymised" may not survive a model-memorisation test.
The practical implication for your AI compliance plan: add a training-data classification step before any fine-tuning project begins. Classify every dataset against DPDPA §2(t) (personal data) and any applicable sectoral overlay — ICMR guidelines for clinical data, RBI data localisation direction for payment data. The consent or legitimate-use basis must cover the specific purpose of AI training, not just the original collection purpose. This step does not exist in any standard DPDPA compliance template I have reviewed as of May 2026.
Cross-border training runs are a Section 16 transfer — plan accordingly
DPDPA §16(1) gives the Central Government power to restrict the transfer of personal data outside India by notification. §16(2) preserves stricter sectoral law. The final DPDP Rules 2025 implement a "negative list" mechanism: transfers are permitted except where the Central Government restricts by notification. As of the date of this post, no negative list has been gazetted, and transfers to the United States are currently permitted under this framework.
But "currently permitted under DPDPA" is not the full analysis for the customers we work with. The RBI's Storage of Payment System Data directive mandates that payment system data be stored only in India. NBFCs operating as payment system operators are in scope. The ICMR National Ethical Guidelines and the New Drugs and Clinical Trials Rules, 2019, place independent obligations on clinical trial data. The CERT-In Direction of 28 April 2022 requires 180-day India-soil log retention. All of these run in parallel with DPDPA §16.
Why does this matter for AI specifically? Because cloud GPU rentals for fine-tuning — RunPod, Vast.ai, Lambda Labs, Together AI — are all US-based. When you upload training data to any of those platforms to run a LoRA fine-tune, you are transferring personal data outside India. For NBFC data involving payment records, the analysis ends before it reaches DPDPA: the RBI directive prohibits the transfer outright.
The defensible architecture is to classify every training dataset against DPDPA §16 plus applicable sectoral overlay before any GPU rental begins. For regulated pharma and NBFC data, the working default should be India-only training unless you can affirmatively demonstrate that no sector overlay applies. For OwnAI engagements, we train on A100 instances rented from Indian regional providers (Jarvis Labs, E2E Networks, Yotta Shakti) for any engagement where the sectoral overlay is live, and document the transfer assessment before the first training token is processed. Our deployment architecture page covers the full data-flow design.
Personal data in the prompt: the risk nobody is discussing
There is a second cross-border transfer risk that is almost entirely absent from published DPDPA commentary, and it is more immediately operationally live than the training-data question. Every time a user sends a prompt to a cloud LLM, that prompt may contain personal data. An NBFC credit analyst asking "summarise the risk profile of this borrower, PAN ABCDE1234F, based on the following bureau report" has just transferred personal data outside India to a US inference endpoint. A pharmacovigilance officer pasting an adverse event narrative that contains an identifiable patient's name and medical history has done the same thing.
This is not a theoretical concern. The standard enterprise agreements for all major cloud LLM providers route inference through US or EU data centres. Some offer regional inference endpoints — Microsoft Azure OpenAI in South India / Central India, for instance — but the configuration step to constrain inference to that region is not automatic, is often not enabled by default, and does not cover all model versions. More importantly, even when the inference occurs in India, the prompt data may be retained by the provider's systems for abuse monitoring, safety review, or model improvement purposes.
The practical fix is not to prohibit cloud LLMs entirely — that horse has likely left the stable. It is to add a prompt-data classification step to your LLM governance policy: identify which use cases involve personal or sensitive personal data in prompts, and route those use cases exclusively to inference endpoints that are either on-premises or demonstrably India-located under a contract that prohibits further data egress. Cloud LLMs are appropriate for use cases where prompts can be confirmed to contain no personal data. The two-tier architecture — on-prem for regulated data, cloud for generic work — is not an OwnAI sales pitch; it is what a defensible DPDPA compliance posture actually requires.
The erasure question that genuinely has no answer yet
DPDPA §12(3) requires a Data Fiduciary to erase personal data on a data principal's request, unless retention is necessary for the specified purpose or legal compliance. §8(7)(b) requires the Fiduciary to "cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing." Final Rule 14 sets a 90-day SLA for compliance with rights requests.
Here is the problem: nobody knows whether "erase" reaches fine-tuned model weights. This is genuinely unsettled. The statutory text is silent on derivative ML artefacts. The Data Protection Board has not yet issued any decision on the question. No Indian court has addressed LLM weight erasure. Machine unlearning research as of 2026 has not produced a certified solution short of full model retraining.
The defensible posture today: first, de-identify training data where technically feasible, so the erasure question never arises. Second, layer source-row deletion, embedding index regeneration, and where economically practical, LoRA adapter retraining without the data subject's records. Third, document the technical infeasibility argument proportionately — this is the only real shield until the Board rules. Fourth, and most importantly, disclose to data subjects at the §5 notice stage that full removal of their personal data from a trained model may not be technically possible without complete retraining. Transparency at the notice stage is the only position that survives a DPB inquiry in a world where the technology cannot guarantee perfect unlearning.
This disclosure does not currently appear in any DPDPA notice template I have reviewed. It needs to. And it needs to appear before 13 May 2027.
A proposed contract clause for AI Processor relationships
DPDPA §8(2) requires a "valid contract" as a precondition for a Fiduciary engaging a Processor. Standard IT services contracts do not address AI-specific processing. Here is a starting-point clause that addresses the gaps discussed above. This is a drafting starting point for your legal counsel, not legal advice.
| Clause element | Recommended drafting intent | DPDPA anchor |
|---|---|---|
| Purpose limitation for training | Processor may process Customer Data solely for the specified fine-tuning task described in the SOW. Processor must not use Customer Data to improve any base model, generic prompt library, or cross-customer artefact without express written consent. | §2(k), §8(2), §6(1) |
| Training data classification | Customer represents that it has conducted a training-data classification exercise and that each dataset provided to Processor either (a) contains no personal data, or (b) is accompanied by written confirmation that a §6(1)-compliant consent or closed §7 legitimate-use basis specific to AI fine-tuning exists. | §4, §6, §7 |
| Cross-border transfer control | Processor must not transfer Customer Data outside India except as expressly authorised in writing by Customer. Any authorised cross-border transfer must comply with §16 and applicable sectoral law. For data subject to RBI payment-system localisation direction, no cross-border transfer is permitted. | §16, SPDI Rule 7 |
| Erasure on request | On receipt of a §12 erasure request, Processor will (a) delete all source training records, (b) regenerate any embedding or retrieval indices, and (c) where technically feasible, retrain the fine-tuned adapter without the affected records. Where retraining is infeasible, Processor will provide written documentation within 30 days. | §12(3), §8(7)(b), Rule 14 |
| Inference-time data residency | If Processor operates any inference endpoint, such endpoint must be located within India. Customer Data processed at inference must not be retained beyond the session duration without separate written authorisation. | §16, §8(5) |
| Breach notification | Processor will notify Customer within 1 hour of detecting any personal data breach, in sufficient detail to enable Customer to meet its CERT-In 6-hour reporting obligation. | §8(6), Rule 7; CERT-In 2022 |
| Non-recharacterisation undertaking | Processor undertakes not to take any action that would cause Processor to be characterised as a Data Fiduciary under §2(i), including making independent determinations on training-data curation purpose, retaining gradients or any derivative dataset for Processor's own use, or entering into sub-processing arrangements without prior written consent. | §2(i), §2(k), §33 |
The penalty exposure that sits behind this table is real: §33 imposes up to ₹250 cr for failure of reasonable security safeguards (§8(5)), up to ₹200 cr for breach notification failure (§8(6)), and up to ₹50 cr for any other non-compliance — and these are fixed monetary caps, not GDPR-style turnover percentages. A mid-size Indian NBFC or pharma company faces the same ceiling as a multinational on a single breach event.
Bottom line.
The DPDPA 2023 is not an AI regulation. But every significant AI deployment in an Indian regulated enterprise will intersect with it on at least four vectors: training-data consent, cross-border transfer, Processor characterisation, and the right to erasure from trained models. None of these is addressed in standard DPDPA compliance templates. All of them carry material penalty exposure from 13 May 2027.
We are not disinterested observers — OwnAI's entire commercial proposition rests on the argument that on-premises deployment produces a cleaner DPDPA answer than cloud inference. You should weigh that context. But the regulatory gaps described above are real regardless. The compliance resources page has a working summary. You have until 13 May 2027, which is less time than it looks.
Book a discovery call to walk through what your AI chapter should look like.