India's Digital Personal Data Protection Act is usually read by lawyers and summarised for engineers, and something specific is lost in that direction of travel. What survives the translation is a list of things the organisation must be able to say. What does not survive is that several of the Act's core requirements can only be satisfied by decisions taken at design time, in the shape of the system — and cannot be retrofitted by a policy, a consent banner or a quarterly attestation.
Read as a checklist, DPDP produces a document. Read as a specification, it produces four constraints: that processing is bounded by a purpose at run time rather than at schema time; that consent is a grant with a named principal and a lifetime rather than a flag; that erasure must propagate into every derived artefact; and that all three must be evidenced. Those are architecture, not compliance, and the distinction determines whether the work takes a quarter or takes two years.
The part that makes this urgent rather than merely interesting is that the exposure DPDP describes is neither new nor about AI. It is the confused-deputy problem, which is decades old, with a statute attached and an actor patient enough to find every instance of it.
The timeline is an engineering timeline
The Rules were notified on 13 November 2025 with a deliberately staggered commencement, and the three phases are worth holding separately because they impose different kinds of work. The definitions and the machinery constituting the Data Protection Board took effect immediately, which means the regulator exists now. The consent-manager provisions commence twelve months on, in November 2026. And the bulk of the operative obligations on data fiduciaries — notice, security safeguards, data-principal rights, erasure, cross-border transfer — commence eighteen months on, in May 2027.
Three requirements inside that phase-in have architectural consequences worth naming early. Data fiduciaries must be technically prepared to interoperate with registered consent managers, which means consent has to be represented in a form an external system can present, honour and revoke — not merely recorded. Personal data must be erased once the purpose it was collected for is no longer served, and for the largest e-commerce, social media and online gaming platforms the Rules put a hard three-year ceiling on retention measured from the individual's last contact. And the data principal must be told at least forty-eight hours before that erasure completes, so they have an opportunity to preserve the data — which quietly implies that you can compute, per individual, when their retention clock expires.
That last implication is the one teams underestimate. A per-principal clock is data, not a batch job somebody wrote in 2019 and nobody has read since.
On cross-border movement the Rules operate as a negative list: transfer is permitted by default and restricted only where the government notifies otherwise, with a separate power to specify categories that significant data fiduciaries must keep within India. This is not a localisation mandate, and reading it as one has caused a good deal of wasted architecture. It is a mandate to know, per data category, where processing actually occurred — which is a different and considerably harder capability.
Purpose limitation is a scoping constraint, not a data-labelling exercise
This is the constraint that breaks the most existing designs, so it is worth stating slowly.
Purpose limitation says personal data is processed for the purpose for which consent was given. In a conventional application that is satisfiable at schema time: this table serves this function, this service reads this table, and the mapping between purpose and data is fixed when the system is built. Access control expresses it, review confirms it, and the boundary holds because the code cannot decide to do something else.
An agentic system inverts that. Its reach is determined at run time by a plan the model composes, over a set of tools and retrievals that were provisioned generously because nobody could enumerate in advance which ones a given task would need. The purpose is stated at design time; the scope is chosen at execution time; and nothing in the architecture connects them.
So the requirement translates into something quite specific: the boundary has to be enforced between the agent's intent and the system of record, at the moment of action, where refusal is still possible. Not at login, because an actor that operates continuously is only bounded at the start. Not at the storage tier, because the data was legitimately stored for some purpose and the question is whether this processing serves that purpose. Not in a review, because reviews are periodic and the agent is not.
That single sentence is the highest-value architectural change available in this entire domain, and it is available now, with ordinary policy-enforcement machinery, without waiting for anything to be notified.
Consent is an entitlement, and a boolean has kept the receipt and thrown away the grant
The distinction I keep returning to is between a permission and an entitlement, and consent is the cleanest illustration of it in any statute I work with.
A permission is a statement about reach. This identity can read this table. It attaches to an identity, and identities are long-lived by design — they accumulate the union of everything any workflow ever needed, and nothing in the model records what was intended.
An entitlement is a statement about authority. This principal granted this actor the ability to take this class of action, within these limits, for this period, for this purpose. It attaches to a grant, and grants expire.
Consent under DPDP is unmistakably the second thing. It has a granting principal, who is the individual. It has a purpose. It is revocable, which means the grant has a lifetime and a termination event. And from November 2026 it must be honourable by a registered consent manager, which means it must be representable outside the system that captured it. Every one of those is an entitlement property, and none of them is a boolean property.
Most enterprise implementations store consent as a flag on a customer record, with a timestamp if you are fortunate. That structure answers “did they consent?” and cannot answer any of the questions that actually arise: consented to what purpose, at what scope, expiring when, revoked through which channel, and — the one that matters for agents — does this particular processing fall inside the grant. A flag is the receipt. The Act asks for the grant.
The remedy is unglamorous and small. Consent records take the same four fields as any other entitlement: permitted purpose in business terms, limits, granting principal, expiry. If an entitlement register already exists for your agentic identities, consent is another row type in it rather than a second system — which is one of the few genuinely elegant simplifications available here.
Erasure propagates into artefacts that have no delete operation
Now the constraint that will hurt, and the one I see least prepared for.
Erasure in a relational world is a solved problem with known edge cases. Erasure in an AI system is a lineage problem, because personal data does not stay in the row it arrived in. It gets embedded into a vector index. It gets cached in a retrieval layer. It gets summarised into an agent's working memory and then into a durable memory store. It gets copied into a training set and, from there, into fine-tuned weights. Each of those derived artefacts is a place the data now exists in a form that has no delete operation matching the obligation.
Once personal data has been embedded into a vector index, “delete” has no obvious meaning. You can drop the vector, which handles the retrieval path and leaves the index statistics quietly informed by a record that was supposed to be gone. You can rebuild the index, which is a scheduled operation, not a response to a request. Which of those satisfies the obligation is a question about the shape of your system, and it was answered — by default, by whoever wrote the ingestion job — long before anyone asked it.
So the requirement is hard and architectural: every derived artefact must know its sources. An embedding traceable to the record it was computed from. A cache entry carrying the lineage of what produced it. An agent memory recording provenance per element. And a fine-tuning dataset as a governed artefact with a manifest, because the alternative — discovering after the fact that a withdrawn consent is baked into a model you are serving — has no clean remedy short of retraining.
This is why I argue that open-weight programmes carry more DPDP exposure than API-only ones rather than less. Fine-tuning converts your data into an artefact you cannot selectively edit. That is a fine trade to make deliberately, with a dataset manifest and a retraining plan. It is a very bad trade to make accidentally.
The Rules already ask you to verify your own algorithms
One sentence in the additional obligations on significant data fiduciaries deserves to be read twice by anyone building. Alongside an annual data protection impact assessment and audit, an SDF must observe due diligence to verify that the algorithmic software it deploys for processing personal data is not likely to pose a risk to data principals' rights.
Notice what that asks for. Not a statement that the software is safe — a verification. You cannot verify a system you cannot reconstruct, and reconstruction is not a property you can add to a running system later. It is written at execution or it does not exist. An annual audit assembled from application logs and a vendor questionnaire is a document about a system; it is not evidence from one.
This is the same artefact the rest of the argument keeps arriving at, reached from a fourth direction.
This is the confused deputy with a statute attached
Here is why I insist the exposure predates AI regulation entirely.
Service accounts accumulate the union of every permission any workflow ever needed. That is not a failure; it is the natural entropy of a long-lived identity in a growing system, and it has been true of enterprise IT for as long as enterprise IT has existed. What contained it was never the access-control model. It was that the humans operating those accounts were bounded by knowledge, habit and time — they used the three permissions their job required and never discovered the other forty.
An agent has none of those bounds. It does not tire, it has no habits, and it will exercise any permission it holds the moment a plan suggests doing so. An agent handed a customer-service purpose and a credential scoped to “customer systems” will, given a sufficiently ambitious task, traverse into systems holding data collected for entirely different purposes — and every one of those reads is processing outside the consented purpose.
Notice what did not happen there. No model failed. No prompt was injected. No control was bypassed. The system worked exactly as built and produced a statutory violation, because scope was determined by a credential rather than by a purpose. That is a design defect with a legal consequence, and DPDP does not need to mention artificial intelligence anywhere to bite on it — which is precisely why AI-specific regulatory timelines are the wrong clock to plan against.
Three legal theories, three clocks, one artefact
Run the same exercise across the three markets I work in and the question arrives dressed differently each time, then lands on the same place.
India routes it through data protection. Purpose limitation, consent as a grant, erasure with lineage — and, in financial services, the Reserve Bank's FREE-AI framework of August 2025, which asks regulated entities for a board-approved AI policy, structured governance across the model lifecycle from approval and testing through deployment and change control, independent validation, periodic audit, and an inventory of models and use cases. Between the privacy statute and the supervisor, the Indian question reaches the enterprise as a policy question first.
The Gulf routes it through supervisory scale. The Central Bank of the UAE's guidance note of 23 February 2026 asks licensed financial institutions for documented governance of AI and machine learning proportionate to size and complexity, built on governance and accountability, fairness, transparency and explainability, effective human oversight, and data management. Non-binding in form; entirely clear in expectation. In Saudi Arabia the controlled event is transfer out of the Kingdom, with a documented risk assessment expected for continuous or large-scale transfers of sensitive data. Read architecturally, both are demands to know where each inference happened and on what basis.
North America routes it through model risk — or used to. The revised interagency guidance issued on 17 April 2026 supersedes SR 11-7 and its companion, keeps conceptual soundness and ongoing monitoring as the spine of validation, and places generative and agentic AI expressly outside its scope pending separate guidance. That is a deferral rather than a dispensation: every obligation attached to the underlying action is exactly where it was. What has gone is the document that would have told you what adequate looks like.
Three legal theories, three clocks, one artefact. A supervisor's question is a reconstruction question — what did the system do, on what basis, and can you show your challenge of it was effective — and it is answered by the same act-time record that answers India's purpose question and the CBUAE's governance question. That convergence is the most useful fact in this piece, because it means the work is not three programmes.
There is a shape to how these two failures differ, and it is worth naming because it determines what you fix first. An Indian programme typically arrives with a strong policy position and a weak enforcement boundary: a well-drafted purpose taxonomy, a consent notice reviewed by counsel, and no place in the runtime where an action is actually refused. The American failure is the mirror image — a mature control estate, gateways, monitoring and an audit function, sitting underneath an agent whose authority nobody ever stated, so the controls have nothing to evaluate against. Neither half is sufficient. The Indian programme has to build the enforcement point; the American one has to write down the grant.
What this reading does not prove
Reading a statute as a specification is a choice, and it is mine rather than the regulator's. MeitY has not published DPDP as an engineering requirement, and a careful lawyer would tell you that several of the readings above are stricter than the text compels. I would rather build to the stricter reading, because the cost of over-scoping an entitlement is inconvenience and the cost of under-scoping one is a notifiable event — but that is a risk preference, not a legal conclusion.
A great deal also remains to be notified. The cross-border negative list is a mechanism, not yet a list. The categories significant data fiduciaries must retain in India are for a government committee to specify. The Data Protection Board exists but has no enforcement record, so the practical severity of all of this is unmeasured, and anyone telling you how DPDP will be enforced is speculating.
The timeline could move. Phase-ins slip, and an eighteen-month clock that started in November 2025 has ample room to become a twenty-four-month one. That is an argument about when the deadline binds, not about whether the architecture is right — and the architecture is worth building at a firm that will never see an Indian regulator.
Building for the strictest reading has a genuine cost too. An over-constrained agent is a useless agent, and a purpose taxonomy fine-grained enough to be theoretically pure is one nobody in the business will maintain. That failure mode is real: a governance model so precise it is abandoned within two quarters, leaving the organisation with less than a coarse one would have.
Four artefacts, in this order
The work is smaller than it sounds, provided it is sequenced.
- The purpose register. Enumerate the purposes for which you actually collect personal data, in business language, and map each agentic workflow to the ones it may serve. This is a week of workshops and it is the input to everything else. If two purposes are indistinguishable in practice, merge them.
- Consent as entitlement records. Four fields — purpose, limits, granting principal, expiry — in the same register you use for agentic identities. Doing these as one system rather than two is what makes the whole exercise affordable.
- Lineage on derived artefacts. Source attribution on every embedding, cache entry and memory element; a manifest on every fine-tuning dataset. Do the highest-consequence workflow first. Doing it everywhere at once is how this becomes a two-year programme that delivers nothing.
- Act-time attestation. What was known, from where, under which entitlement, evaluated by which policy version. This is the artefact that serves the Indian purpose question, the Gulf governance question and the American reconstruction question at once.
Then run the deletion drill on one data principal. Pick a real individual whose data flows through an AI workflow. Trace every place it now exists — rows, indexes, caches, agent memory, training sets, served weights — and produce, on paper, what a valid erasure request would require and how long it would take. Nothing else I know of makes the abstract concrete this fast, and the first attempt always finds artefacts nobody knew were in scope.
Every organisation running agents against personal data will eventually be asked one of these three questions by one of these three regimes. The pleasant thing about the convergence is that the answer is the same in each case, and it is buildable now with ordinary engineering. The unpleasant thing is that it is only buildable in advance. There is no version of the purpose question you can answer retrospectively about a system that was never scoped to a purpose.
If your DPDP programme currently consists of a well-drafted policy and no place in the runtime where an action can be refused, that gap is the conversation I have most weeks — compare notes with me.