You've shipped a support chatbot. A customer pastes their phone number and a bank reference into it, your server logs the prompt, a vendor's API processes it, and a vector database stores an embedding of it. Under India's data protection law, that is four places personal data now lives. The short answer for developers: if you decide why and how that data is processed, the Digital Personal Data Protection Act, 2023 probably makes you a Data Fiduciary, you're responsible for what your vendors do with it, and most of the heavy duties start in 2027.
This post is a DPDP Act checklist for AI app developers. I read the parts of the Act and the DPDP Rules, 2025 that matter here, from the Gazette copies, then mapped the duties to engineering tasks. It is not legal advice. I'm not a lawyer, and where a point needs interpretation I say so and say "ask counsel".
What did I read, and what couldn't I read?
I downloaded these on 2026-10-09 and read the extracted text.
| Source | What it is | Status |
|---|---|---|
| The Digital Personal Data Protection Act, 2023 (No. 22 of 2023) | Gazette of India Extraordinary, assent 11 August 2023, hosted by MeitY | Read sections 1 to 17, section 33 and the Schedule of penalties; did not read the rest |
| Digital Personal Data Protection Rules, 2025 | Gazette notification G.S.R. 846(E), headed 13 November 2025, hosted by MeitY | Read rules 1 to 17 and the start of the Third Schedule; did not read the rest |
| PIB release "DPDP Rules, 2025 Notified" | Press Information Bureau, 17 November 2025 | Read the opening and penalty summary |
| MeitY notices dated 6 May 2026 | Invitation to apply for the Chairperson and four Members of the Data Protection Board | Read |
Things I could not read or confirm:
- The notification that brings Act sections into force (reported as G.S.R. 843(E)). I couldn't open the Gazette copy. Secondary summaries (a Taxmann post and a third-party DPDP wiki, both unverified against the Gazette) say it is dated 13 November 2025, brings the Board and definition sections into force at once, and puts the main duties (sections 3 to 17) eighteen months out. That matches the Rules' timing, but read the notification itself before relying on it.
- India Code's page for the Act. It timed out or returned 403 from my environment. I used the MeitY-hosted Gazette copy instead.
- MeitY's own listing page, which renders with JavaScript and gave me no usable text.
- Anything after May 2026: Board decisions, FAQs, guidance, amendments, or sector rules. Check MeitY for those.
- The Schedules to the Rules beyond the opening of the Third Schedule, including the Seventh Schedule that rule 8(3) points to, and Act sections 18 onward other than section 33.
- Sector laws (banking, health, telecom, insurance). The Rules repeatedly say "unless any law requires otherwise", and section 16(2) of the Act preserves stricter transfer rules in other laws, so they may add duties.
One more fact worth knowing: I searched the Act's text for "artificial", "algorithm", "machine" and "train". The only hit is "artificial juristic person" in the definition of person. The Act does not mention AI, models or training. The Rules mention "algorithmic software" once, in a duty on Significant Data Fiduciaries (rule 13(3)). Applying a general law to LLM pipelines is therefore interpretation, which is another reason for counsel.
When do the duties actually start?
Rule 1 of the Rules sets the timing, and I read it on the Gazette copy:
| Rules | Subject | In force |
|---|---|---|
| 1, 2, 17 to 21 | Short title, definitions, Board administration | On publication in the Gazette |
| 4 | Consent Manager registration | One year after publication |
| 3, 5 to 16, 22, 23 | Notice, security safeguards, breach intimation, erasure, children, rights, cross-border, appeals | Eighteen months after publication |
The Gazette I read is headed 13 November 2025. PIB's release says the Rules were notified on 14 November 2025. Because both counts run "from publication", the eighteen-month date lands in mid-May 2027, but I won't give you a day. Ask counsel for it.
That's a long runway, and it's the reason to start now with the cheap parts: inventory, retention, logging hygiene and a redaction layer. The expensive parts, such as consent records and erasure that actually reaches every store, are much easier to build into a young system than to retrofit.
Am I a Data Fiduciary, and is my LLM vendor a Data Processor?
Section 2(i): a Data Fiduciary is "any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data". Section 2(k): a Data Processor "processes personal data on behalf of a Data Fiduciary". "Processing" in section 2(x) lists collection, storage, use, indexing, sharing, retrieval, erasure and more, so sending a prompt to an API and storing it in a vector index both count.
Section 8(1) is the line to remember: the Fiduciary is responsible "irrespective of any agreement to the contrary" for processing done on its behalf by a Processor. Section 8(2) adds that you may use a processor for activity related to offering goods or services only "under a valid contract".
What this means in practice: your vendor's terms are not a shield. If your app sends customer data to a model API, you need to know which plan you're on, what that vendor retains, and whether it trains on your data. I put those answers for the main vendors in a dated retention and training table.
Which duties map to which engineering tasks?
This is the table I'd put in a ticket tracker. The right column is my suggested engineering response, not something the Act prescribes. Rows cite the section or rule I read.
| Duty (paraphrased) | Source | Engineering task |
|---|---|---|
| Ask for consent with a notice that itemises the personal data and the purpose, in plain language, with a link to withdraw consent, exercise rights and complain to the Board | Act s5, s6(1); Rule 3 | Notice screen before first use that lists data types (prompts, uploads, voice) and purposes; version it |
| Consent must be limited to data necessary for the stated purpose | Act s6(1), with an illustration about a contact list not needed for telemedicine | Strip fields the feature doesn't need before the model call. See PII redaction before LLM calls |
| You must be able to prove the notice was given and consent obtained | Act s6(10) | Consent ledger: user id, timestamp, notice version, purposes, withdrawn-at |
| Withdrawal must be as easy as giving consent; after withdrawal, stop processing and make processors stop | Act s6(4), s6(6) | A withdraw button, plus a job that propagates to the vector store, caches, analytics and vendor-side stores |
| Use processors only under a valid contract; you stay responsible | Act s8(1), s8(2) | Vendor register with contract, plan, region and retention for every AI vendor |
| If data is likely used to make a decision affecting the person, ensure completeness, accuracy and consistency | Act s8(3) | For any model output feeding a decision about a person, add review steps and accuracy tests. Whether your use triggers s8(3) is a question for counsel |
| Reasonable security safeguards, at minimum encryption, obfuscation, masking or tokens; access control; logs and monitoring; backups; processor contract terms | Act s8(5); Rule 6(1) | Encrypt stores, mask before logging, role-based access, audit logs, tested restores |
| Retain logs and personal data for one year for detecting and investigating unauthorised access | Rule 6(1)(e) | Decide which logs this means (see the tension below) |
| On a breach, tell each affected person without delay, and tell the Board without delay plus a detailed report within 72 hours | Act s8(6); Rule 7 | Incident runbook with a notification template. See an incident postmortem template |
| Erase personal data when consent is withdrawn or the purpose is no longer served, and make processors erase | Act s8(7) | Deletion pipeline covering every store in the next section |
| Publish contact details of a person who can answer questions about processing | Act s8(9); Rule 9 | Contact line in app and site |
| Publish a grievance redressal route and respond within a period the Rules cap at ninety days | Act s8(10); Rule 14(3) | Grievance form and a ticket queue with an SLA |
| Rights to a summary of data processed, the identities of other Fiduciaries and Processors it was shared with, and to correction and erasure | Act s11, s12 | Export and delete endpoints; the processor register feeds the "shared with" list |
| Children (under 18): verifiable parental consent, no tracking or behavioural monitoring, no targeted advertising | Act s2(f), s9; Rule 10 | Age gate, or a decision that the product is adults-only with a real control |
Two rows deserve a longer comment.
The logging tension. Rule 6(1)(e) says to retain "such logs and personal data" for one year for detecting unauthorised access, unless a law requires otherwise. Rule 8(3) says a Fiduciary must retain personal data, associated traffic data and other logs of processing for at least one year for purposes in the Seventh Schedule, then erase them. Meanwhile data minimisation pushes you to not store raw prompts at all. I can't tell you how those fit together for a chat product, and I haven't read the Seventh Schedule closely. A defensible engineering approach is to keep access and security logs for a year while masking personal data in prompt text before it hits any log. Confirm that with counsel.
Time limits for erasure. Rule 8(1) sets a "no longer served" time limit only for the classes in the Third Schedule. The rows I read are e-commerce entities with at least two crore registered users, online gaming intermediaries with at least fifty lakh, and social media intermediaries with at least two crore, each with a three-year limit from the user's last interaction. If you're not in a listed class, that rule doesn't give you a number, but section 8(7) still requires erasure when it's reasonable to assume the purpose is no longer served. Rule 8(2) also requires a warning to the person at least forty-eight hours before a scheduled erasure under rule 8.
Where does personal data hide in an AI app?
Developers tend to protect the database and forget everything the LLM stack creates. Use this as an inventory sheet.
| Store | What personal data it holds | Erasure question |
|---|---|---|
| Application DB | Accounts, chat history, uploaded files | Can you delete one user's rows and files by id? |
| Vector database | Embeddings and the source chunks of documents | Do chunks carry a user or document id so you can delete them? |
| Prompt and response logs, traces | Raw prompts, tool outputs, sometimes keys | Is personal data masked before logging? What is the log TTL? |
| Evaluation datasets and golden sets | Real user messages copied for testing | Did you copy production data into a repo? Can you find and remove it? |
| Fine-tuning data and trained weights | User text baked into a model | You can't un-train one record cheaply. Don't fine-tune on personal data you can't justify keeping |
| Vendor-side storage | Abuse-monitoring logs, stored responses, uploaded files | Which retention applies on your plan? Is there a zero-retention option? |
| Caches | Prompt caches, semantic caches, CDN | What is the TTL, and does deletion reach the cache? |
| Analytics and error tracking | Events with text, user ids, IPs | Is message text excluded from events? |
The vendor-side row is the one teams skip. The vendor table shows that several APIs keep inputs for up to 30 days by default, and that some features, such as stored files, are retained until you delete them.
What should you build first?
If I had one sprint before any legal review, in this order:
- Inventory. Fill in the table above for your product, one row per store and per vendor. Copy this skeleton (untested template, adapt it):
- store: vector-db
purpose: answer questions from customer documents
personal_data: [names, emails, ids inside documents]
processor: self-hosted
region: ap-south-1
retention: until document deleted
delete_path: DELETE /documents/{id} removes chunks by doc_id
owner: backend-team
- store: llm-api
purpose: generate answers
personal_data: [prompt text after redaction]
processor: <vendor name>
retention: <from vendor docs, dated>
delete_path: vendor setting or contract
owner: platform-team
- Redact before you send. Mask direct identifiers in prompts and logs. It supports the "necessary data only" principle in section 6(1) and the masking example in rule 6(1)(a).
- Set retention TTLs on logs, caches and evaluation data.
- Build delete and export by user id, and test that it reaches the vector store.
- Write the notice and keep a consent record, versioned.
- Write the breach runbook before you need it, including who calls counsel.
The first three are cheap and useful even if your lawyers later change the plan.
What should you ask counsel?
Take these to a lawyer who works on Indian data protection:
- Are we a Data Fiduciary for this product, and is each LLM vendor our Data Processor on the plan we use?
- Does section 8(3) apply to our model outputs, and what accuracy duty follows?
- How do the one-year log retention rules (rule 6(1)(e), rule 8(3)) apply to prompt text?
- Does any sector law add duties on top of the Act (finance, health, education)?
- Is the product likely to be used by under-18s, and what does "verifiable consent" need to look like for us?
- Does sending personal data to a vendor outside India need anything extra today, given section 16 and rule 15?
- Could we be notified as a Significant Data Fiduciary (section 10, rule 13)?
- What is the exact commencement date for each rule that applies to us?
What are the penalties?
I read these in the Schedule to the Act itself, so they are not from a summary. Each is a ceiling the Board "may" impose after an inquiry, using the factors in section 33(2).
| Breach | Penalty may extend to |
|---|---|
| Failing to take reasonable security safeguards (s8(5)) | 250 crore rupees |
| Failing to notify the Board or affected people of a breach (s8(6)) | 200 crore rupees |
| Breaching the children's duties (s9) | 200 crore rupees |
| Breaching a Significant Data Fiduciary's duties (s10) | 150 crore rupees |
| Any other provision | 50 crore rupees |
The May 2026 MeitY notices I read were still inviting applications for the Board's Chairperson and Members. I haven't checked what has happened since. If your product records or transcribes calls, see call recording consent and AI disclosure basics. For background on what not to hand to a chatbot in the first place, see what not to paste into ChatGPT.
