Most of these duties apply in full from 13 May 2027, eighteen months after the Digital Personal Data Protection Rules were published on 13 November 2025. The penalties are large: up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing to report a breach. Generic DPDP checklists cover consent forms and privacy notices well. They rarely follow personal data into the places an AI system copies it, which is where most of the new risk sits.
This checklist maps the Act and the Rules to those places. It is a practical guide written from building and running AI inside regulated environments, not legal advice; confirm your specific position with counsel.
The DPDP timeline: what applies when
The Digital Personal Data Protection Act, 2023 became law on 11 August 2023, but it needed Rules to operate. Rule 1 of the DPDP Rules sets a phased commencement: the provisions on the Data Protection Board took effect on publication, Consent Managers follow after one year, and almost everything an operating business must do follows after eighteen months.
Table: DPDP commencement dates
| Date | What applies |
|---|---|
| 11 August 2023 | The DPDP Act is enacted |
| 13 November 2025 | Rules published; Rules 1, 2 and 17 to 21 (the Data Protection Board) in force |
| 13 November 2026 | Rule 4 (registration and obligations of Consent Managers) in force |
| 13 May 2027 | Rules 3, 5 to 16, 22 and 23 in force: notices, security safeguards, breach intimation, retention, rights and the duties of Significant Data Fiduciaries |
The Schedule to the Act sets the maximum penalty for each kind of breach. The Data Protection Board decides the amount after an inquiry, up to these limits, and the two highest apply to security safeguards and breach reporting, which is why those duties deserve the most engineering attention.
Maximum penalties under the Schedule to the DPDP Act
| Breach | Maximum penalty |
|---|---|
| Failure to take reasonable security safeguards (section 8(5)) | ₹250 crore |
| Failure to notify the Board or affected people of a breach (section 8(6)) | ₹200 crore |
| Breach of the additional obligations for children’s data (section 9) | ₹200 crore |
| Breach of the additional obligations of a Significant Data Fiduciary (section 10) | ₹150 crore |
| Breach of any other provision of the Act or Rules | ₹50 crore |
Why AI systems need their own DPDP checklist
A conventional application keeps a customer record in one database. An AI system copies it. The same record can sit in the source system, in an ingestion pipeline, as chunks in a vector index used for retrieval, inside the prompts sent to a model, in the model’s answers, in debugging logs and, if a model was fine-tuned on it, inside the model’s weights. Under the Act, each of those copies is processing, and each needs the same care as the original.
Three provisions bite harder on AI than on ordinary software. First, section 8(2) allows a Data Fiduciary to use a Data Processor only under a valid contract, and an external AI API that receives your prompts is a processor. Second, section 8(3) requires completeness, accuracy and consistency where personal data is used to make a decision that affects the person, which reaches AI outputs used in credit, claims or hiring. Third, section 8(7) requires erasure once consent is withdrawn or the purpose is no longer served; deleting a row is easy, removing a person’s data from a trained model is not.
None of this makes AI harder to run lawfully than any other system. It means the compliance map has to follow the data through the AI pipeline, not stop at the consent form.
Where personal data hides in an AI system
| Place | Example | Duty that lands there |
|---|---|---|
| Source systems | CRM, core banking, HRMS, claims system | Lawful basis, notice, accuracy |
| Ingestion and document indexes | KYC files split into chunks in a vector database | Minimisation, access control, erasure |
| Training data and model weights | A model fine-tuned on support tickets | Purpose limitation, erasure you can actually perform |
| Prompts and outputs | An agent’s question and answer about a borrower | Security safeguards, accuracy where decisions follow |
| Logs and monitoring | Prompt and response logs kept for debugging | Access control, one-year retention, review |
| Recordings and images | Call recordings, CCTV frames | Notice or legitimate use, retention, security |
Start every assessment by filling in this table for each AI use case, and repeat it whenever the use case changes, because a new data source or a new output destination adds a row. Pay particular attention to the logs and the document indexes: engineers create them for debugging and retrieval rather than as part of a business process, so they are the easiest places to leave out of a company’s records of processing.
1. Map, minimise and choose a lawful basis
- Inventory each AI use case: The personal data it touches, the purpose, the systems it reads from and every place it writes to.
- Minimise before you index: Strip or mask identifiers the task does not need before documents enter an index or a training set. Rule 6 itself names encryption, obfuscation, masking and virtual tokens as security measures.
- Pick the lawful basis for each purpose: Either consent with a clear, itemised notice, or one of the legitimate uses in section 7, such as data a person has voluntarily provided for a specified purpose (section 7(a)) or processing for the purposes of employment (section 7(i)).
- Check new purposes: Data collected to service a loan is not automatically available to train a marketing model. A new AI purpose needs its own basis.
- Make withdrawal as easy as consent: And plan for Consent Managers, whose registration regime starts on 13 November 2026.
- Treat “public” data carefully: The Act does not apply to personal data the person made public, or data published under a legal obligation (section 3(c)(ii)). Data that is merely findable online is not automatically covered by that exemption.
2. Control processors, model providers and transfers
Every external service that touches personal data on your behalf is a processor: the AI model API, the speech-to-text service behind a voice agent, the vector database in someone else’s cloud, the monitoring tool that stores prompts. Each needs a contract, and Rule 6(1)(f) requires that contract to include appropriate provisions for reasonable security safeguards.
- List every processor in the AI pipeline: Including the ones engineers added for evaluation or logging.
- Know where each one processes data: Section 16 lets the government restrict transfers to countries it notifies; Significant Data Fiduciaries can also be told to keep specified data in India.
- Read the model provider’s data terms: Whether prompts are retained, for how long, and whether they are used for training.
- Prefer processing inside your own environment: For the most sensitive data. A model deployed on your servers or in your own cloud account removes a processor and a transfer from the map entirely; this is the core reason enterprises choose private LLM deployment.
Processors do not carry your accountability. Under the Act the Data Fiduciary remains responsible for what its processors do, so the contract and your own monitoring both matter.
3. Apply the Rule 6 security safeguards to the AI stack
Rule 6 sets the minimum safeguards every Data Fiduciary must take, including for processing done by its processors. Here is what each requirement means once an AI system is involved:
| Rule 6 requirement | What it means in an AI system |
|---|---|
| Encryption, obfuscation, masking or virtual tokens | Encrypt indexes, training sets and logs; mask identifiers in prompts where the task allows |
| Access control to computer resources | Retrieval returns only documents the asking user is allowed to open; agents get the narrowest permissions that work |
| Logs, monitoring and review to detect unauthorised access | Record who asked what, which documents were retrieved and which actions an agent took, and review them |
| Continued processing if data is compromised, such as backups | Back up indexes and configurations; know how to rebuild an index from source |
| Retain logs and personal data for one year unless another law says otherwise | Keep AI access logs for at least a year, and plan storage and access for them |
| Contract provisions with Data Processors | Security clauses in every AI vendor contract |
The access-control row is the one most AI pilots fail. A knowledge assistant that indexes a shared drive and answers anyone’s question will eventually quote a salary file to the wrong person. Permissions must travel with documents into the index and be checked at answer time.
4. Keep outputs accurate and people in the loop
Section 8(3) requires a Data Fiduciary to ensure the completeness, accuracy and consistency of personal data when it is likely to be used to make a decision that affects the person, or disclosed to another Data Fiduciary. When an AI system reads a KYC pack, scores a claim or summarises a borrower’s history, its output is exactly that kind of data.
- Evaluate before go-live on a fixed, human-verified test set, and record the results.
- Show sources for every factual answer, so a person can check it.
- Keep a person on consequential decisions. Let the system read, check and flag exceptions, and let a person decide on credit, claims, hiring and similar outcomes.
- Close the loop. When a person corrects an output, record the correction and use it to fix the source data and improve the system.
This is how our document and compliance agent is designed: it checks KYC packs, claims and contracts against your rules and flags exceptions for a person to decide. The person’s decision, not the model’s, is what reaches the customer, and the record shows both.
5. Plan retention and erasure before you train
Section 8(7) requires erasure once consent is withdrawn or it is reasonable to assume the purpose is no longer being served, unless another law requires retention. In an AI system, an erasure request has to reach every copy, which is easy to promise and hard to do unless it was designed in.
- Keep a register: Of which indexes, datasets and models contain which sources.
- Make deletion cascade: From the source system to the index, caches and stored outputs, keeping only what Rule 6’s one-year log retention requires.
- Prefer retrieval over fine-tuning on personal data: Removing a document from an index is immediate. Removing a person’s data from a model’s weights generally means retraining it.
- Set retention periods per purpose: For recordings and images, and delete on schedule.
- Test erasure end to end: Before go-live: delete a test person from the source and confirm they disappear from every index, cache and output store.
Teams that decide this before the first model is trained can honour an erasure request quickly. Teams that decide it afterwards may find they cannot honour it without rebuilding an index or retraining a model.
6. Prepare for breaches, children’s data and rights requests
Rule 7 sets two clocks once a personal data breach is discovered. Affected people must be told without delay, in plain language: what happened, the likely consequences for them, what is being done and what they can do to protect themselves. The Board must receive a fuller report within 72 hours, covering the facts, mitigation, any findings about who caused the breach and the remedial measures taken.
- Add AI-specific scenarios to your incident plan: A prompt injection that makes an agent reveal data, an index that ignored permissions, an exposed log store.
- Children’s data: Needs verifiable parental consent, and section 9(3) bars tracking or behavioural monitoring of children and targeted advertising directed at them. Check whether any AI use case could touch minors.
- Rights requests: For access, correction and erasure (sections 11 to 13) must cover the AI copies too, so route them through the register in step 5.
- Rehearse the 72-hour report: Once a year with the people who would write it: security, legal, the AI team and the business owner. The first breach is the wrong time to find out who holds which facts.
7. If you are a Significant Data Fiduciary
The government can notify a Data Fiduciary, or a class of them, as significant based on the volume and sensitivity of the data they process and the risk to people. Large banks, insurers and platforms should plan on the assumption that they will be. Section 10 requires a Data Protection Officer based in India, an independent data auditor and periodic Data Protection Impact Assessments.
Rule 13 adds three duties that land squarely on AI. A Significant Data Fiduciary must carry out a Data Protection Impact Assessment and an audit every twelve months and report significant observations to the Board. It must observe due diligence to verify that technical measures, including algorithmic software, are not likely to pose a risk to the rights of Data Principals. And it must keep personal data the government specifies, with its traffic data, inside India.
The practical response is documentation that already exists in a well-run AI programme: a record of each model’s purpose and data, evaluation results, bias and error testing, change logs and the human approvals around consequential decisions. Keep it current as models change, because the annual audit will ask for the version that was running, not the one in the original design document.
How this looks in four common AI deployments
DPDP focus points by AI deployment
| Deployment | Personal data involved | Controls that matter most |
|---|---|---|
| Voice agent for reminders and collections | Names, numbers, amounts due, call recordings | Notice at the start of the call, a retention schedule for recordings, masking in logs, calling-hour and consent rules |
| KYC or claims document agent | Identity documents, addresses, signatures, medical or financial records | Encryption at rest, permission-aware access, a person deciding on exceptions, erasure that reaches the index |
| Internal knowledge assistant | Employee records, policies, contracts | Retrieval that enforces document permissions, logs of who asked what, no training on HR files |
| CCTV-based vision AI | Images of identifiable workers and visitors | Processing on site, blurred faces in alerts, short retention, notice to visitors |
Collections calls carry additional sector rules on calling hours and conduct; our compliance checklist for AI collection calls covers them alongside DPDP. The lawful basis for each deployment depends on how the data was collected and for what purpose, so settle it use case by use case with your compliance team.
Design DPDP into your AI from the start
Data residency, consent, access control and audit trails, designed with your compliance team before go-live, for lenders under RBI rules, insurers under IRDAI and providers under health-data rules.
See AI governance and compliance →
Where private deployment helps, and where it does not
Running AI inside your own environment changes the map in useful ways. The model, the indexes and the logs sit on your servers or in your cloud account, so the AI layer adds no new processor and no cross-border transfer. Access control uses the permissions your security team already manages. Logs are yours to keep, review and delete on your schedule.
It does not remove the duties that come from the Act itself. You still need a lawful basis and notice for every purpose, accurate outputs where decisions follow, working erasure, rights handling and breach readiness. Private deployment makes those duties easier to meet and to evidence; it does not make them optional.
That is the line we draw in our own engagements, where data residency and consent are designed in with the client’s compliance team before anything goes live, and nothing is sent to a third-party AI service to be useful.
Frequently asked questions
Does the DPDP Act apply to AI training data?
Yes, when the training data includes digital personal data. Using personal data to train or fine-tune a model is processing, so it needs a lawful basis for that purpose, security safeguards and a way to honour erasure. Data collected for one purpose does not automatically cover training a model for another.
Is publicly available personal data exempt from the DPDP Act?
Only in specific cases. The Act does not apply to personal data that the person made publicly available, or that someone else published under a legal obligation. Data that is simply findable online, such as scraped profiles, is not automatically covered by that exemption.
Do we need consent to use call recordings or CCTV footage in AI?
It depends on the purpose and how the data was collected. Some processing can rely on a legitimate use under section 7, such as purposes of employment for workplace footage of staff; other uses need consent with a clear notice. Either way, security safeguards, retention limits and breach duties still apply.
When do DPDP obligations apply in full?
Most operational obligations, including notices, security safeguards, breach intimation, retention, rights and the duties of Significant Data Fiduciaries, apply from 13 May 2027. The Data Protection Board provisions applied from 13 November 2025, and the Consent Manager rules from 13 November 2026.
What are the penalties under the DPDP Act?
Up to ₹250 crore for failing to take reasonable security safeguards, up to ₹200 crore each for failing to report a breach or breaching the obligations on children’s data, up to ₹150 crore for breaches of a Significant Data Fiduciary’s additional obligations, and up to ₹50 crore for other breaches.
Are AI model providers data processors under the DPDP Act?
Usually, yes. A provider that processes personal data in your prompts or documents on your behalf acts as a Data Processor, which the Act allows only under a valid contract. You remain responsible for its processing, so check its retention and training terms.
Does personal data have to stay in India under the DPDP Act?
Not in general. Transfers abroad are allowed except to countries the government restricts by notification. Significant Data Fiduciaries can be required to keep specified personal data in India, and sector regulators may impose their own localisation rules.
Map your AI use case against DPDP
Tell us the use case and the systems it touches. An engineer replies within one business day with where personal data will sit and how we would protect it.