Imagine — and this is a hypothetical, though every element of it exists in your estate today — that a single customer withdraws consent tomorrow morning. Their data sits in the row it arrived in. It also sits in a vector index, in a retrieval cache, in an agent's memory, and possibly in a fine-tuned model. The law says erase. Most of those places have no erase button. Whoever wired the ingestion pipeline decided, without knowing it, whether that request can ever be honored.
That image is India's Digital Personal Data Protection Act read the way an engineer has to read it — and it is exactly what gets lost when the Act is read by lawyers and summarized for engineers, which is how it usually travels. What survives that translation is a list of things the organization must be able to say. What does not survive is that several of the Act's core requirements can only be satisfied 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: processing bounded by a purpose at run time rather than at schema time; consent as a grant with a named principal and a lifetime rather than a flag; erasure propagating into every derived artifact; and all three evidenced. Those are architecture, not compliance, and the distinction determines whether the work takes a quarter or takes two years.
What 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 — a trusted system tricked or drifted into using its legitimate powers for something nobody authorized — 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. 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. 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 in that phase-in have architectural consequences. Data fiduciaries must be prepared to interoperate with registered consent managers, which means consent has to be represented in a form an external system can present, honor 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, which quietly implies a per-principal retention clock modeled as 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, restricted only where the government notifies otherwise, with a separate power to specify categories significant data fiduciaries must keep in India. That is not a localization 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 — a different and considerably harder capability.
Purpose limitation is a scoping constraint, not a data-labeling 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 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 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 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 sentence is the highest-value architectural change available in this 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 its cleanest illustration in any statute I work with. A permission is a statement about reach, attached to a long-lived identity. An entitlement is a statement about authority — this principal granted this actor this class of action, within these limits, for this period, for this purpose — attached 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, so the grant has a lifetime and a termination event. And from November 2026 it must be honourable by a registered consent manager, which means representable outside the system that captured it. Every one of those is an entitlement property; none is a boolean property. A permission answers can it. An entitlement answers may it.
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 the questions that actually arise: 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: consent records take the same four fields as any other entitlement, so if an entitlement register already exists for your agentic identities, consent is another row type in it rather than a second system.
Erasure propagates into artifacts 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. 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 — the searchable mathematical form documents take so an AI can find them — cached in a retrieval layer, summarized into agent memory, copied into a training set and from there into fine-tuned weights: each of them a place the data now exists in a form with no delete operation matching the obligation.
Once personal data has been embedded into a vector index, “delete” has no obvious meaning. Drop the vector and you handle the retrieval path, leaving the index statistics quietly informed by a record that was supposed to be gone. Rebuild the index and you have 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.
So the requirement is architectural: every derived artifact must know its sources. An embedding traceable to the record it was computed from, a cache entry carrying lineage, an agent memory recording provenance per element, a fine-tuning dataset with a manifest — because discovering that a withdrawn consent is baked into a model you are serving has no clean remedy short of retraining. A fine trade to make deliberately; a very bad one to make accidentally.
The Rules already ask you to verify your own algorithms
One sentence in the additional obligations on significant data fiduciaries — the large-scale processors the Rules single out for heavier duties — deserves reading twice. Alongside an annual 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 written at execution or it does not exist. An audit assembled from application logs and a vendor questionnaire is a document about a system, not evidence from one.
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 — the natural entropy of a long-lived identity in a growing system. 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. Handed a customer-service purpose and a credential scoped to “customer systems,” it 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. DPDP does not need to mention artificial intelligence anywhere to bite on that — which is precisely why AI-specific regulatory timelines are the wrong clock to plan against.
Three legal theories, three clocks, one artifact
Run the same exercise across the three markets I work in and the question arrives dressed differently each time, then lands in 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, governance across the model lifecycle, independent validation, periodic audit, and an inventory of models and use cases. It 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 — accountability, fairness, transparency, effective human oversight, data management. Non-binding in form; entirely clear in expectation. In Saudi Arabia the controlled event is transfer out of the Kingdom. 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 of 17 April 2026 supersedes SR 11-7, 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 where it was. What has gone is the document that would have told you what adequate looks like.
Three legal theories, three clocks, one artifact. 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. The convergence is the most useful fact here, because it means the work is not three programs.
The two failures differ in a way that determines what you fix first. An Indian program typically arrives with a strong policy position and a weak enforcement boundary: a well-drafted purpose taxonomy, a consent notice reviewed by counsel, and nowhere in the runtime that an action is actually refused. The American failure is the mirror image — a mature control estate sitting underneath an agent whose authority nobody ever stated, so the controls have nothing to evaluate against. One has to build the enforcement point; the other 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 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 Board has no enforcement record, and the timeline could slip. Those are arguments about when the deadline binds, not about whether the architecture is right. The harder objection is that building for the strictest reading has a real cost: 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. A governance model so precise it is abandoned within two quarters leaves you with less than a coarse one would have.
Four artifacts, 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. If two 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. One system rather than two is what makes the exercise affordable.
- Lineage on derived artifacts. Source attribution on every embedding, cache entry and memory element; a manifest on every fine-tuning dataset. Highest-consequence workflow first — doing it everywhere at once is how this becomes a two-year program that delivers nothing.
- Act-time attestation. What was known, from where, under which entitlement, evaluated by which policy version. The artifact that serves all three regimes 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. The first attempt always finds artifacts nobody knew were in scope.
All of it is buildable now, with ordinary engineering. The unpleasant part 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 program currently consists of a well-drafted policy and nowhere in the runtime that an action can be refused, that gap is the conversation I have most weeks — compare notes with me.