DPDP and Agentic AI: Why India's Privacy Law Changes How Enterprise AI Agents Must Be Designed

Consider an HR agent asked to identify employees suitable for a new project. Technically, it may be able to access resumes, performance reviews, compensation, location, project history and manager comments. But technical access is not the same as permission to process every field for every purpose.

The DPDP framework makes the purpose and lawful basis of processing important. In an agentic environment, this means access needs to take into account not just who is asking, but which agent is acting, for what purpose and what information is actually necessary.

This points to a shift from simple role-based access towards purpose-aware access.

Once an agent has access to enterprise data, another question arises: how much of that data should actually reach the model?

A finance agent investigating an increase in operating expenses may need general-ledger transactions, vendor invoices and budget information. It does not need employee bank details or unrelated personal information simply because those fields exist in the same source system. This makes data minimisation an AI architecture issue.

Data should ideally pass through permission checks, filtering, masking or tokenisation before it enters the model's context. This has an additional benefit: a cleaner context is often a better AI context. Minimising unnecessary information can reduce noise while reducing the exposure of sensitive data.

The principle is not to give the model everything it can technically access and expect it to ignore what is irrelevant.

Persistent memory is one of the features that makes agents useful. An agent can remember previous interactions, customer complaints, employee project history or recurring preferences and use that information in future tasks. But memory also creates a new governance challenge.

Once those memories contain information relating to identifiable individuals, they become part of the organisation's data environment. Enterprises need to know what an agent is permitted to remember, why it is remembering it, how long that information should remain available and how it can be corrected or erased where applicable.

This is particularly important because the DPDP framework places obligations around retention and erasure. Data cannot simply remain indefinitely in an Agent's memory because it happens to be useful. The future enterprise agent will therefore need something that today's applications rarely required at this level: a governed memory lifecycle.

Without such controls, agent memory can quietly become an ungoverned shadow database.

Agentic systems also generate far more information about an interaction than conventional applications. A single request may generate a user prompt, retrieved records, model context, tool calls, intermediate outputs, a final response and execution traces. Personal data can potentially appear anywhere along this chain. Consequently, protecting the original database is no longer sufficient.

DPDP readiness therefore requires enterprises to create visibility across the agent's complete data journey — including prompt logs, vector stores, conversation histories, caches, tracing systems and model-provider environments.

The question is no longer simply: "Where is the personal data stored?" It becomes: "Where does the agent see, transform, transmit, remember and leave traces of personal data?"

Most enterprises will not build every component of their AI stack themselves. Agents may use external foundation models, managed AI services, vector databases and other third-party tools. That creates another important consideration.

Where is the data processed? Are prompts retained? Is enterprise data used for model training? What sub processors are involved? How are deletion requirements handled?

The DPDP framework places responsibility on the Data Fiduciary even when processing is undertaken on its behalf by a Data Processor. For enterprise architecture, this means model selection cannot be based solely on performance, cost or latency. Organisations also need to consider what data a model or service can see, under what conditions, and what controls surround that access.

This is likely to drive greater adoption of enterprise AI gateways, private model endpoints, redaction layers, controlled connectivity and stronger contractual controls.

The biggest change comes when an AI agent moves from recommendation to execution. A copilot might identify customers at risk of churn and recommend an offer. An autonomous agent could identify those customers, decide on the offer, send the communication and update the CRM. The moment AI can act, rather than merely advise, the risk profile changes.

Enterprises therefore need clear boundaries around what an agent can execute autonomously. An agent might draft an email but require approval before sending it. It might recommend a refund but be prevented from issuing a high-value refund. It might read CRM data but not export an unrestricted customer list. The principle is not to eliminate autonomy. It is to make autonomy proportionate to risk.

Agent autonomy should never mean unrestricted authority.