The DPDP Act and AI Systems: Consent Managers, Notices and Data Principal Rights
How India's DPDP Act lands on autonomous agents: consent scope, notice at indirect collection, and erasing personal data from prompts, traces and vector stores.
The DPDP Act and AI Systems: Consent Managers, Notices and Data Principal Rights
The DPDP Act applies to AI agents exactly as it applies to any other processing: the organisation deploying the agent is the Data Fiduciary. The difficulty is operational. Consent must be specific, notice must be given at collection, and erasure must reach personal data sitting in prompts, logs, traces, vector stores and evaluation sets.
This is for CIOs and heads of automation with agents in production or pilot. The DPDP Act says nothing about artificial intelligence. It was drafted for systems where a person fills a form, a database stores the answer, and someone deletes the row. Agents break that model in a few fixable ways: scoping consent at tool granularity, answering an erasure request that reaches a vector store, and defending a breach timeline.
Who the Data Fiduciary is when an agent does the work
An agent is not a legal person and cannot be a Data Fiduciary. The organisation that decides what it is for and how it runs is, on the wording of section 2: whoever "alone or in conjunction with other persons determines the purpose and means of processing of personal data". Everything the agent calls is then either your processing or a Data Processor's. Model API vendors, vector database hosts, observability platforms and transcription services are processors. Section 8(2) permits processing by a processor only under a valid contract, and Rule 6(1) requires the Fiduciary to secure equivalent measures contractually. The DPA with your model provider is the load-bearing document in the stack, and needs four things stated: retention of prompts and completions, training use, handling of abuse-monitoring logs, and the sub-processors behind the endpoint.
MeitY's India AI Governance Guidelines of November 2025 concede the point, asking openly whether "principles of collection and purpose limitation are compatible with how modern AI systems operate". They are recommendations, and relieve a Fiduciary of nothing.
Consent that survives an agent acting across systems
Section 6(1) requires consent to be free, specific, informed, unconditional and unambiguous, by clear affirmative action, limited to the data necessary for the specified purpose. Rule 3 requires the notice to itemise both data and purposes.
An agent that reads a mailbox, queries the CRM, calls a payments API and drafts a reply performs four processing operations over four data classes for arguably four purposes. A tick reading "I consent to AI-assisted service" is specific to none of them. Enumerate purposes at tool granularity: one declared purpose per tool or tool group, mapped to the data classes that tool sees, with a consent record storing the set of purposes granted rather than a boolean.
Withdrawal is where implementations fail. Section 6(4) to (6) requires withdrawal to be as easy as giving consent, and processing to stop within a reasonable time. If the agent checks consent at session start and then runs for six hours, or runs as a scheduled job over a queue built yesterday, you keep processing after withdrawal. Consent state must be readable mid-run and checked at each tool call, with defined behaviour on failure: halt, drop the step, write the reason into the run record.
Section 7 legitimate uses cover much internal agent work, including employment purposes, and fit an internal helpdesk agent better than manufactured consent. And if the agent does not need a direct identifier, tokenise before the prompt.
Notice when the agent collects indirectly
Section 5 requires notice at or before the request for consent. The Act sets out no separate regime for data obtained from someone other than the individual, which is what an agent creates when it enriches a lead from a third-party source, transcribes a call with a third party present, or extracts a name from an email someone else wrote.
Where you rely on consent, the notice duty attaches to you whatever the collection channel. Rule 3 fixes the contents: itemised description of the data, the specified purposes, and a link to withdraw consent, exercise rights and complain to the Board. Put it at whatever human interface exists (the IVR opening, the chat preamble, the portal consent page) rather than inside the agent's reasoning, and version it, treating a tool-set change as a notice change.
[NEEDS SOURCE: whether MeitY or the Data Protection Board has issued guidance on notice obligations where personal data is obtained from a source other than the Data Principal.]
Purpose limitation against a general-purpose agent
Section 5(1) requires an itemised description of the data and the purpose it will be processed for. Section 8(7) requires erasure once that purpose is no longer served. A general-purpose agent is, by construction, one without a fixed purpose.
Two honest ways out. Narrow the agent, so each deployment has a declared purpose and a tool set that cannot exceed it. Or attach a purpose token to each run: a stable identifier propagated into every tool call, written into every record created, and stamped on every trace and vector chunk. The second is the only approach that answers, eighteen months later, why a particular row exists. It also fixes retention, because retention clocks belong to purposes rather than tables: close a purpose and everything carrying its token becomes a deletion candidate in every store at once.
Where personal data ends up in an agent stack
Ordinary application records are easy. Everything below is where erasure requests fail.
| Where it lands | Why deletion is hard | Control that works |
|---|---|---|
| Prompt and completion payloads at the model provider | Retention is outside your control and varies by endpoint | Contract zero or short retention and no training use; record the period |
| Provider abuse-monitoring logs | Usually excluded from the deletion commitment | Ask explicitly in the DPA; send no direct identifiers |
| Agent traces and spans in observability tooling | Copies fan out to several vendors | Redact at the SDK boundary; short TTL; tag spans with the subject ID |
| Long-term memory and rolling summaries | Identifiers survive paraphrase | Key memory to the subject, delete the object, regenerate |
| Vector embeddings and chunk metadata | No back-index from subject to chunk | Put source document ID and subject ID in chunk metadata; delete by filter; verify by query |
| Queues, dead-letter queues, caches, webhook logs | The DLQ is the copy nobody owns | TTL per queue, redaction before enqueue, a named DLQ owner |
| Evaluation and regression datasets | Version-pinned; deletion breaks reproducibility | Synthetic or pseudonymised data only; never promote raw transcripts |
| Fine-tuning corpora and model weights | No reliable removal from trained weights | Do not train on personal data; else keep a provenance manifest and retrain plan |
| Backups and snapshots | Deletion reappears on restore | Re-deletion at restore, on a stated rotation |
| Downstream systems the agent wrote to | You cannot know what it wrote unless you recorded it | An action ledger with target system and record ID per write |
Handling an erasure or correction request across an agent stack
Rule 14 requires you to publish the means by which rights are exercised and to respond within a period not exceeding ninety days, which the PIB summary of the Rules gives as the maximum for responding to such requests. Ninety days sounds generous until step six.
- Intake and identity. Accept through the published channel, record the timestamp, verify identity using the identifiers you said you would require. The clock starts on receipt, not triage.
- Decide whether erasure is owed. Section 12 gives correction and erasure; retention required by law overrides it. Record the decision and its basis. A human decision, not a rule in code.
- Resolve the subject to every internal key: user, account, session, thread, trace, tool-call, document and embedding IDs. If that mapping is not a query you can run, you have an intention rather than a capability.
- Freeze the agent for that subject. Disable memory recall and revoke the relevant tool scopes first, or an in-flight run repopulates what you removed.
- Delete in the primary stores in dependency order, capturing row counts.
- Delete in the vector store by metadata filter, then verify with a retrieval query on the subject's distinctive terms. Re-embed any document you modified rather than removed.
- Instruct the processors (model provider, observability vendor, transcription service) to the deadline your contract sets, and keep the acknowledgements.
- Handle the one-year floor. Rule 6(1) requires logs to be kept at least a year, and Rule 8(3) requires personal data, traffic data and processing logs to be kept at least a year for the Seventh Schedule purposes. These cannot be deleted on request: segregate them, restrict access, say plainly that they are held under a statutory retention requirement, and diarise the erasure.
- Deal with evaluation data and any training corpus. Remove the subject from eval sets and regenerate the fixtures. If the data entered a fine-tune, record it and escalate, and do not describe the record as erased when it is not.
- Replay the action ledger and respond. Propagate to every downstream system the agent wrote to, assemble the evidence (per-store confirmations, processor acknowledgements, the retained-by-law list), respond within the published timeline, and diarise deferred items for the next backup rotation.
Correction is worse in one respect: fixing a name in the source system does not fix the summaries, embeddings or cached answers derived from it. Step six becomes re-index rather than delete.
Breach intimation when an agent misroutes data
An agent that sends customer A's statement to customer B, or passes the wrong account ID into a tool that returns another person's record, has caused a personal data breach.
Rule 7(1): tell each affected Data Principal without delay, through their user account or a registered channel, in concise plain language, giving the nature, extent and timing, the likely consequences, the mitigation applied, the safety measures they can take, and a contact.
Rule 7(2): tell the Board without delay, then give detailed particulars within seventy-two hours of becoming aware, or a longer period the Board allows: the facts, circumstances and reasons, mitigation, findings in respect of the person who caused the breach, remedial measures, and a report on the intimations given to Data Principals.
Two of these are hard for agents specifically. Scoping needs you to know which record went where, and teams that redacted traces aggressively often destroyed the only evidence that would answer it: keep a redacted content trace and, separately, an access-controlled action ledger of identifiers, targets and timestamps. Attribution is awkward when the actor is a model, so record the model and prompt versions, the tool version, the run ID and the human who approved the run.
A breach at an Indian entity may also trigger separate incident reporting to CERT-In on a shorter clock. [NEEDS SOURCE: CERT-In directions of 2022, the exact reporting window and the categories of incident covered.]
Consent Managers and Significant Data Fiduciary status
A Consent Manager is a company registered with the Board giving an individual one interoperable place to give, review and withdraw consent across many Data Fiduciaries. Rule 4 and the First Schedule set the bar: incorporated in India, net worth of at least two crore rupees, and independent certification that the platform conforms to the data protection standards and assurance framework published by the Board. Part B requires records of consents given, denied and withdrawn with their notices, machine-readable and kept at least seven years, no sub-contracting, no conflicts of interest with Data Fiduciaries, and no change of control without Board approval.
Rule 4 commences one year after publication, so the mechanism arrives around November 2026 and the substantive duties six months later. Two practical points. A Consent Manager records consent; it does not enforce it inside your stack, and it hands your agent no machine-readable purpose scope. And nothing can be registered until there is a Board to register it, which as of mid-2026 there was not. Build your own consent state service, with an interface that can accept an external signal later.
[NEEDS SOURCE: whether the Board has published the data protection standards and assurance framework referred to in the First Schedule, and whether any Consent Manager has been registered.]
If you are notified as a Significant Data Fiduciary under section 10 you appoint a Data Protection Officer based in India and an independent data auditor. Rule 13(1) requires a DPIA and audit once in every twelve-month period from the date of notification, with significant findings going to the Board under Rule 13(2). Rule 13(3) requires you to verify that the algorithmic software used for storage, transmission, publication, modification or sharing of personal data does not pose a risk to Data Principals' rights: an obligation to test orchestration and model behaviour for rights risk, not only accuracy, and to keep the evidence. Rule 13(4) allows the Central Government to confine specified categories of data to India.
MeitY circulated a proposal in early 2026 to compress the SDF window to twelve months and advance Rules 13(4) and 15. [NEEDS SOURCE: whether that proposal has been notified, and the resulting dates for SDFs.]
A design checklist
- One declared purpose per agent or tool group, with a purpose token propagated into every tool call, record, trace and vector chunk, and consent state checked at each tool call with defined halt behaviour.
- Notice versioned, the version ID stored against each consent record, and a tool-set change forcing a new version.
- Subject identifier indexed on every row, span, chunk and memory object, and chunk metadata carrying source document ID and subject ID, with deletion by filter proven in a test.
- Redaction at the SDK boundary before traces leave your network, retention set per store.
- An access-controlled action ledger: target system, record ID, timestamp, run ID, model and prompt version, plus DPAs stating retention, training use, abuse-log handling and sub-processors for every vendor in the path.
- Eval and regression datasets built from synthetic or pseudonymised data, with a documented rule against promoting production transcripts.
Where teams get this wrong
Treating embeddings as derived data outside the Act. If the chunk you retrieve identifies a person, the embedding and its metadata are personal data, and a store with no back-index from subject to chunk cannot honour a request.
Consent modelled as a single boolean per account. Withdrawal becomes all-or-nothing, the business refuses to honour it because it would switch off a service the customer still wants, and the request ages past ninety days.
Evaluation data. A gold-standard eval set built from production transcripts, version-pinned and copied into three repositories, is the copy every erasure process misses and the copy an SDF audit under Rule 13(1) finds.
Waiting for enforcement. Because the Board was not constituted by mid-2026, several programmes have decided to defer. The obligations arrive in mid-May 2027, and the traces, memories and eval sets accumulated in between are what has to be remediated, at the point when the team is also trying to ship.
What to automate, and what not to
Automate discovery and fan-out: resolving a subject to every key across stores, issuing delete commands, collecting per-store confirmations and processor acknowledgements, diarising the statutory retention floor, versioning notices. These are mechanical, error-prone by hand, and what makes ninety days achievable.
Do not automate judgement. Whether erasure is owed when another law requires retention, whether an incident is reportable and how far it extends, and whether Rule 13(3) due diligence is satisfied are decisions a named person signs, as is the response to the individual, because that is the artefact the Board reads at an inquiry. A system should get a person to a decision in ten minutes with the evidence in front of them.
Where a system helps
The recurring gap is the record, not the policy. Nobody can reconstruct what an agent collected, under which purpose, and which records it created downstream, because nothing was built to record it. CohortaOS writes a purpose token and subject identifier into every run and keeps an action ledger of every downstream write, so erasure can be worked store by store and a breach timeline assembled from evidence.
Related reading: What Is the DPDP Act? Scope, Obligations and Timelines, Explained (KB-005).
FAQ
Does the DPDP Act apply to models trained on personal data? Training is processing, so consent, purpose and security obligations apply. The Act does not address training specifically, and data the individual has made public herself sits outside it. MeitY's AI Governance Guidelines treat exemptions for training on publicly available personal data as an open question. [NEEDS SOURCE: any MeitY or Board clarification on the DPDP Act's application to AI model training.]
Must we delete personal data from a model already trained? Section 12 gives a right to erasure. Neither the Act nor the Rules say what that means for trained weights, and no established technique reliably removes one individual from a model. Keep personal data out of training and prove it from a provenance manifest. [NEEDS SOURCE: any guidance on erasure obligations in relation to trained model parameters.]
Is an agent sending data to the wrong recipient a reportable breach? Yes, where it results in unauthorised disclosure or access. Rule 7 requires intimation to each affected Data Principal without delay and detailed particulars to the Board within seventy-two hours of becoming aware. Rule 14 separately sets a ninety-day maximum for responding to rights requests.
Do we need to register as a Consent Manager? No. Registration under Rule 4 applies to the entity offering the service, not to a Data Fiduciary using one. Your obligation is to receive and act on its signals, including withdrawal.