DPDP 2023: the six things every enterprise must fix before deploying AI

Before an AI system touches personal data in production, the Digital Personal Data Protection Act 2023 requires the deploying enterprise to fix six things: a lawful consent or legitimate-use basis for the specific AI purpose, purpose limitation that the model actually respects, a breach-notification path that includes the AI stack, data-retention and erasure that reach into vector stores and logs, a defensible answer on training data, and processor contracts that pin down every vendor in the chain. The enterprise is the Data Fiduciary. None of these obligations transfer to the AI vendor, and the AI system inherits all of them the moment it goes live.

That framing matters because most enterprises scope an AI project as an engineering problem and discover the DPDP problem at the compliance review, weeks before a planned go-live. The Act is now backed by notified rules. The Digital Personal Data Protection Rules 2025 were notified on 14 November 2025, with substantive obligations phasing in and full compliance required by mid-2027 (Source: MeitY, DPDP Rules 2025, notified 14 November 2025, as reported by EY India). The penalties are not nominal. Failure to implement reasonable security safeguards that leads to a breach carries a fine up to 250 crore, and failure to notify a breach carries up to 200 crore (Source: DPDP Act 2023, Schedule). Here is the checklist a CIO or DPO should run before signing off, in the order the review will actually test it.

1. Establish a lawful basis for the specific AI purpose

Consent under DPDP is purpose-bound. Data collected for appointment booking was not collected to train or condition an AI model, and a consent notice that predates the AI project almost never covers the new use. Before deployment, confirm which basis you are relying on: fresh consent for the AI purpose, or one of the legitimate uses the Act permits. If it is consent, the notice has to name the AI purpose in clear language, and the Data Principal has to be able to withdraw it as easily as they gave it.

The trap here is treating a broad, historical consent as blanket cover. It is not. If your AI feature processes personal data for a purpose the original notice did not describe, you are processing without a basis, and that is the failure class the Data Protection Board of India is set up to adjudicate. Fix the notice and the consent capture before the model sees the data, not after.

2. Enforce purpose limitation inside the system, not just on paper

Purpose limitation is easy to write into a policy and hard to enforce in an AI pipeline. A retrieval system that can reach any record in the store will, under the wrong prompt, pull data collected for a different purpose into a new context. A model given broad database access does not respect the boundary your consent notice drew.

The fix is architectural. Scope what the AI can retrieve to the purpose it was consented for, log every retrieval, and make the boundary a property of the system rather than a line in a document. A compliance reviewer who asks "what stops this agent from using booking data to do something we never consented" needs an answer that lives in the code, not in the contract. This is where compliance-aware design earns its place: the constraint is built in, and you can show it.

3. Extend breach notification to the AI stack

DPDP imposes a duty to notify the Data Protection Board and affected individuals of a personal data breach. Most enterprises have an incident-response plan. Very few have extended it to the AI components: the vector database, the prompt and output logs, the model provider's retention, the caching layer. Each of these can hold personal data, and each is a place a breach can happen or be discovered.

Before deployment, map where personal data sits across the AI stack and write those locations into the incident-response runbook. Decide who declares a breach when it is the embedding store that leaks rather than the primary database. Given a notification-failure penalty of up to 200 crore, the cost of an unmapped AI component is not theoretical (Source: DPDP Act 2023, Schedule). The system that logs every input and output for good governance reasons is also the system most likely to hold personal data in a place your existing plan never covered.

4. Make retention and erasure reach the places AI hides data

The Act gives the Data Principal a right to erasure and requires that personal data not be kept past its purpose. AI systems quietly break both. Embeddings derived from personal data sit in a vector store. Prompts and completions sit in logs. Fine-tuning or conditioning data sits in artifacts that outlive the request. An erasure request that deletes the row in the primary database and leaves the embedding behind has not been honoured.

Before go-live, confirm that your deletion path reaches every derived copy, and that retention windows apply to logs and vector stores, not only to the source of record. This is one of the most common gaps we see when an AI pilot moves toward production: the engineering team built for capability and never asked where personal data comes to rest. The right of erasure is only real if the plumbing can execute it everywhere.

5. Have a defensible answer on training and conditioning data

What data trained or conditions this model, and on what basis? This is the question that stalls AI reviews, and it deserves a clear answer before deployment rather than an improvised one during audit. If you fine-tuned or built retrieval on personal data, you need the same lawful basis you would need for any other processing of it. If you rely on a third-party foundation model, you need to know what its provider claims about its training data and what your contract says about the data you send at inference time.

DPDP does not carve out AI training. Personal data processed to train or condition a system is processing, and the Data Fiduciary obligations attach. [POSITION NEEDED: Does Nextdot use client personal data to fine-tune or condition models, and if so on what documented lawful basis?] The safe posture before deployment is to be able to state, in writing, where the model's behaviour comes from and why every use of personal data in that lineage is lawful.

6. Pin down every processor in the chain by contract

An AI deployment usually involves more than one outside party: a model provider, possibly a hosting layer, sometimes a specialist vendor. Under DPDP each is a Data Processor acting for you, the Data Fiduciary, and the Act requires that processing by a processor happen under a valid contract. The obligations to the Data Principal remain yours regardless of how many vendors sit in the chain.

Before deployment, confirm that a contract exists with every party that touches personal data, that it constrains them to your instructions and purposes, that it addresses retention, deletion, breach reporting back to you, and location of the data. The reason this is a hard rule and not a nicety: when the Board comes asking, "the vendor handled it" is not a defence. You are answerable for the whole chain, so the whole chain has to be papered.

There is a reason all six of these are the enterprise's to fix rather than the vendor's. Under DPDP the enterprise deploying AI is the Data Fiduciary. It owns the consent, the purpose, the breach duty, the erasure right, and the relationship with the Data Principal. A vendor can build the system well, constrain it, log it, and make erasure executable, and a good one will. It cannot become the Data Fiduciary in your place. India has no standalone AI statute to change this: the MeitY India AI Governance Guidelines, published November 2025, take the position that existing law, DPDP 2023 included, already binds AI systems today (Source: MeitY, India AI Governance Guidelines, November 2025). The obligations are live now. The checklist above is how you meet them before a deployment, not after a notice from the Board.

Frequently asked questions