Agents and the DPDP Act: personal data in prompts, logs and outputs

Scope and limits

This is a practitioner's map of how personal data moves through AI agents in Indian organisations, and it does not constitute legal advice. The law is new, guidance is still emerging and your obligations depend on your sector, your contracts and the specific data you handle, so check your own position with a qualified lawyer.

Where the law stands, as of October 2026

The Digital Personal Data Protection Act, 2023 is India's general law on personal data. The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025. They come into force in phases. Some provisions, such as those setting up the Data Protection Board, applied straight away. Others, including the registration of consent managers, follow after about a year. Most of the duties that matter for an AI agent, including notice, consent, security safeguards, breach intimation, retention and the rights of individuals, apply from around 13 May 2027 as currently notified, unless the government amends the timeline.

For anyone building agents now, that date is close. An agent designed today without these duties in mind will need rework before May 2027, and rework on a system that is already in daily use is slow and disruptive. It is far cheaper to design for the law from the start.

Sector rules still apply alongside the Act. An NBFC is also subject to RBI directions on outsourcing, information security and, for payments data, storage in India. A hospital deals with clinical record keeping norms and, where it participates, ABDM guidelines. The DPDP Act sits on top of these.

Who is responsible for what

The Act uses two roles that matter here.

The data fiduciary decides why and how personal data is processed. If your NBFC deploys a collections agent, your NBFC is the data fiduciary for the borrower data that agent handles. The responsibility stays with you even when the processing is done by a vendor.

A data processor processes personal data on behalf of a data fiduciary. The platform the agent runs on, the company that built it for you and the model provider whose model it calls are, in most setups, processors. The Act requires a fiduciary to engage processors only under a valid contract, and the fiduciary remains accountable for what the processor does.

In practice this means you need to know every party that touches the data in your agent's workflow, and have a contract with each of them that covers what they may do with it.

The five places personal data lives in an agent

When people think about AI and personal data, they usually think about the model. In a real agent, the model is only one of several places where personal data sits. We map five such places on every project.

1. The input

This is whatever the agent receives: a WhatsApp message from a D2C brand's customer, an email from a borrower, a scanned discharge summary, an admissions enquiry form from a parent. Inputs often contain more personal data than the task needs. A customer asking about a delayed order may also send a photo of their Aadhaar card "to prove who they are".

Design choice: decide what the agent needs, and strip or mask the rest as early as possible. If the task is order tracking, the agent needs the order number and perhaps the phone number. It does not need an identity document, and that image should not travel further into the system.

2. The prompt and the context

To do its job, the agent assembles a prompt. This often includes the input, plus information looked up from your systems: the borrower's outstanding amount and payment history, the patient's medications, the customer's past orders. That whole bundle is sent to a model.

Design choices: send the minimum needed for the step. Use identifiers or masked values where the model does not need the real ones. A model drafting a payment reminder needs the amount and due date; it does not need the borrower's PAN. Where possible, keep sensitive lookups in your own environment and pass the model only the result.

3. The model call

The prompt goes to a model, hosted by a provider or by you. The questions here are where that model runs, whether the provider retains prompts, whether they use them for training and what your contract says.

Design choices: choose providers and settings that do not retain or train on your data, and confirm this in the contract. For sensitive workloads, consider a private cloud or on premise deployment, or an open model you host, so the data does not leave your environment. The Act allows transfer of personal data outside India except to countries the government restricts by notification, but sector rules and your own risk appetite may be stricter.

4. The logs

This is the one teams forget. Every serious agent keeps logs: inputs, prompts, model responses, actions taken, who approved what. Logs are essential for debugging, quality review and oversight. They are also, very often, the largest store of personal data in the whole system, kept longer than anything else and accessed by more people.

The Rules require reasonable security safeguards, including access controls and logs that let you detect and investigate unauthorised access, and they set an expectation that such logs are retained for a period, currently one year, unless another law requires otherwise. At the same time, the Act requires you to erase personal data once its purpose is served. Those two duties pull in different directions, and agent logs sit right in the middle.

Design choices: separate operational logs (what the agent did, when, who approved) from content logs (the actual text of prompts and responses). Keep the first for the required period. Mask or minimise personal data in the second, restrict who can read it and set a retention period tied to its purpose. A quality reviewer usually only needs to see that the agent misread an invoice; the borrower's full account history can stay hidden.

5. The output

Outputs carry personal data too: a draft reply naming the customer, a summary of a discharge note, a collections call script with the outstanding amount. Outputs can also create new personal data, such as a risk flag on a borrower or a note that a patient may need follow up.

Design choices: treat outputs that make or support decisions about a person with care. Keep a person in the loop for anything that affects their money, care or access to a service. Make sure outputs are stored only where they need to be and follow the same retention rules as the rest of the record.

Notice, consent and purpose

Under the Act, personal data is processed either with consent or for certain legitimate uses the Act lists. Consent must be free, specific, informed and unambiguous, and must follow a notice that tells the person what data is collected and for what purpose. The Rules set out what the notice must contain and require it to be understandable on its own.

For agents, the practical question is whether your existing notices cover what the agent does. A school group that collected parent details for admissions may have told parents they would be contacted about admissions. Using the same data to train an internal model, or to send marketing messages through an agent, is a different purpose. If the purpose is new, the notice and consent need to cover it.

Children's data needs particular care. The Act requires verifiable consent from a parent or lawful guardian before processing a child's personal data, and a child here is anyone under 18. A school's admissions agent will almost always be handling children's data.

Rights of individuals

People have the right to access a summary of their data, to correct and erase it, to have grievances addressed and to nominate someone to exercise their rights. Your agent system has to support these. If a customer asks you to erase their data, that must include the copies sitting in agent logs, review queues and any vector store built from their documents. If you cannot find all the places their data lives, you cannot honour the request.

Breaches

If personal data is breached, the Act and Rules require you to inform the Data Protection Board and each affected person, with a fuller report to the Board within 72 hours of becoming aware, unless the Board allows longer. An agent with access to several systems is a meaningful part of your attack surface. Action boundaries, least privilege access and good logs are what let you answer, quickly, the question the Board will ask: what was exposed, and how.

Penalties under the Act are significant. The highest, up to 250 crore rupees, applies to a failure to take reasonable security safeguards to prevent a breach.

A design checklist for agents

• Map the five places personal data lives in the agent: input, prompt, model call, logs, output.
• Minimise and mask at each step; send models only what they need.
• Confirm in contract where each model runs and whether prompts are retained.
• Separate operational logs from content logs, and set retention for each.
• Check that existing notices cover the agent's purposes.
• Handle children's data with verifiable parental consent.
• Make sure access, correction and erasure requests reach every copy, including logs and knowledge stores.
• Keep a person approving actions that affect someone's money, care or access to a service.
• Write down what the agent may never do, and enforce it in the platform as well as in the prompt.

If you also need a programme for DPDP readiness across the whole organisation, beyond your agents, the group's TrustOS platform is built for that.

To see how access, data permissions, action boundaries and logging work on the platform, read about deployment and governance.