Two things are happening in Indian enterprises at the same time, and most teams are treating them as separate projects. They are not. Where DPDP agentic AI programmes are concerned, the two belong together.
The first is regulatory. The Digital Personal Data Protection Rules were notified on 13 November 2025, which started a phased compliance clock. The consent manager framework lands around November 2026, and the substantive obligations, the ones with real enforcement behind them, take effect on 13 May 2027. There has even been talk in government of shortening the 18 month window to 12. Whatever the final dates, the direction is fixed and the runway is shorter than it looks.
The second is architectural. Enterprises are handing genuine decisions to AI agents that chain tasks together, call APIs, read from systems of record and act. Not draft-and-review copilots. Agents that do things.
Put those two trends in the same room and a hard question falls out: how do you honour consent, purpose limitation and accountability when a machine is making decisions at machine speed?
Consent becomes a live control, not a stored record
Under DPDP, consent has to be free, specific, informed and unambiguous, backed by a plain-language notice. Most systems today treat consent as something you capture once and file away. That model breaks the moment an agent is acting continuously on a person’s data.
The withdrawal problem is the sharp edge. When someone withdraws consent, that decision has to propagate everywhere the data went: into vector stores, into fine-tuned checkpoints, into cached outputs, into whatever an agent has already retrieved and is mid-way through using. Very few enterprise AI stacks are wired to do that. Consent has to become a control the system checks at the point of action, not a row in a database that nobody reads again.
Purpose becomes an access boundary
Purpose limitation sounds like a policy statement. In an agentic system it has to become an access boundary. If data was collected to service a loan application, an agent should not be able to reach for it to power a marketing recommendation, however useful that might be in the moment. The purpose a person consented to has to be enforced in the permissions the agent runs under, not written in a document that the agent never sees.
This is where a lot of well-meaning DPDP agentic AI projects will fail an audit. Broad consent for improving services does not cover model training. Consent obtained for one product cannot be reused to train a model that ships in another. These are not edge cases. They are the default way most data flows inside a company today.
Accountability has to be built into the architecture
When an agent makes a decision, someone will eventually ask why. The regulator might ask. A data principal exercising their rights might ask. Your own risk team will certainly ask after the first incident.
Answering that question means being able to reconstruct what the agent did after the fact: what data it touched, under which purpose, on what basis, and where the human threshold sat. That is an architecture decision, much like deciding where inference physically runs, and it has to be made before deployment, not bolted on after the first regulatory notice arrives. Logging every tool call and every model invocation is not optional overhead. It is the evidence you will need to produce, sometimes within a day, when someone asks you to prove compliance.
DPDP agentic AI: what we would tell a CIO planning for 2027
Treat the DPDP timeline and your agentic AI roadmap as one programme, not two. Done well, DPDP agentic AI governance is simply one discipline, not a legal track bolted onto an engineering track. The controls that make an agent auditable, consent checked at the point of action, purpose enforced in permissions, and a reconstructable trail of decisions, are the same controls that make the agent safe to run in production at all. Good governance and good engineering point in the same direction here.
The organisations that treat consent as a live control and accountability as an architecture, rather than a compliance document written after the build, are the ones that will still be shipping agents in May 2027 without scrambling. The rest will be retrofitting governance into systems that were never designed to give it. That retrofit is expensive, and it usually arrives at the worst possible time, right after something has already gone wrong.
Comments 1