India's data protection regime is read almost universally as a privacy statute. Consent, notices, cross-border transfer, breach reporting. That reading is correct and it misses what the Act does to anyone running an AI agent.
Read Section 8 of the DPDP Act 2023 against a deployed agent and it stops being about privacy. It becomes conduct regulation. The agent processes personal data as your automated operation, so you answer for what it decides. You must keep the data it acts on accurate and complete. You must retain the record for a year. You must run a grievance channel a person can actually reach, and the agent must not be the thing on the other end of it.
There is no agent framework in Indian law and no exemption for one. The Act does not care that the processor was a language model, and that indifference is the whole point.
Do the DPDP Rules 2025 apply to AI agents?
Yes, without needing to mention them. The DPDP Act 2023 applies to processing of digital personal data, and Section 2 defines automated as any digital process capable of operating automatically in response to instructions or otherwise for the purpose of processing data. An AI agent processing personal data is automated processing by a Data Fiduciary.
That is the entire jurisdictional analysis. There is no AI-specific trigger to satisfy, no risk tier to fall into, no threshold of autonomy above which the Act engages. If your agent touches digital personal data and you determine the purpose and means, you are a Data Fiduciary in respect of that processing and every obligation in Chapter II attaches.
Compare that with the EU, where a team can spend a fortnight determining whether an agent is Annex III high-risk and often conclude that it is not. India offers no such exit. The obligations are lighter, but they are unconditional.
The corollary is worth stating for anyone building agent infrastructure. India's regime attaches to the processing, not to the technology, so an agent adds no new legal category. What it adds is difficulty in discharging obligations that were drafted for systems where a human was in the decision path.
Who is liable when an AI agent processes personal data: developer or deployer?
The deployer, in almost every configuration. Section 8(1) makes a Data Fiduciary responsible for compliance in respect of any processing undertaken by it or on its behalf by a Data Processor, irrespective of any agreement to the contrary or any failure by the Data Principal to carry out their own duties.
Those seven words, irrespective of any agreement to the contrary, are the operative ones. You cannot contract out of the obligation. You can contract for an indemnity, which is a commercial allocation of loss and does nothing to your position before the Data Protection Board. Section 8(2) permits engaging a Processor only under a valid contract, but the contract allocates work rather than liability.
The practical effect for agent deployments is direct. Your model provider is not your shield. Where you determine the purpose and means of processing, you are the Fiduciary, and if the agent produces an unlawful outcome the Board's inquiry is into your compliance, not your vendor's. The maximum penalty for failure to take reasonable security safeguards under Section 8(5) is ₹250 crore.
There is a narrower question that is genuinely open: whether a model provider operating an agent end to end, determining how it behaves and what it may access, could be a Fiduciary in its own right rather than a Processor. Nothing in the Act forecloses it. I have not seen it tested, and I would not build a compliance posture on the assumption that it will resolve favourably.
What does DPDP require when an agent makes a decision about a person?
Section 8(3) is the provision to read. Where personal data processed by a Data Fiduciary is likely to be used to make a decision that affects the Data Principal, or disclosed to another Data Fiduciary, the Fiduciary must ensure its completeness, accuracy and consistency.
This is the sentence that turns a privacy statute into conduct regulation, and it is almost never discussed in AI terms.
Note what triggers it. Not a decision that has legal effect. Not a significant decision. Not automated decision-making as a defined category, which the DPDP regime conspicuously does not create. Simply data likely to be used in a decision that affects the person. An agent that triages a support ticket, prioritises a lead, flags an account for review, or drafts a recommendation a human then acts on is inside Section 8(3).
The obligation is also prospective in an awkward way. It attaches where data is likely to be used in such a decision, which means the duty to ensure accuracy arises before the decision is made, not after it is challenged. For an agent assembling context at runtime from several sources, that is a duty about your retrieval pipeline.
And it is a duty you have to be able to evidence. Demonstrating that the data underpinning a particular decision was complete and accurate requires knowing what data that decision actually rested on, which is a logged field rather than a documented process. An agent that cannot say what it read cannot show it complied with Section 8(3). This is why the field-level requirements for an agent's audit trail matter more in India than the absence of an AI-specific rule would suggest.
One thing DPDP does not give you, and its absence is significant: there is no right to an explanation of an automated decision and no right to human review of one. India did not import GDPR Article 22. Whether that gap gets filled by the Board's practice, by sectoral regulators, or not at all is unresolved.
How long must an AI agent's records be retained under the DPDP Rules?
At least one year, under two separate rules. Rule 6(1)(e) requires retention of logs and associated personal data for a year as part of the reasonable security safeguards owed under Section 8(5). Rule 8(3) imposes a second one-year duty for Seventh Schedule purposes.
That floor is double the EU AI Act's six months under Articles 19(1) and 26(6), which surprises people who assume India is the lighter regime. On records, it is the stricter one.
Rule 6 also names the surrounding controls: encryption, access control, masking or tokenisation as appropriate, monitoring and review, backup and recovery, and contractual pass-through requiring Processors to implement equivalent safeguards. That last item means your model vendor's logging posture is your compliance problem by contract, not merely by risk.
Rule 8 is where the agent-specific complication sits, and it carries two distinct obligations that are commonly run together. For the classes of fiduciary listed in the Third Schedule, personal data must be erased after three years of user inactivity, and Rule 8(2) requires notice to the Data Principal at least 48 hours before that erasure. Rule 8(3) is a different thing altogether: it requires every Data Fiduciary to retain the personal data, associated traffic data and other logs of a processing operation for at least a year for the purposes listed in the Seventh Schedule, and then to erase them unless another law requires longer.
Read that as two events rather than one. The erasure is a state change. The notice is a separate, earlier event with its own timestamp, and it is the one that proves compliance. A retention system that purges on schedule but cannot show the notice fired has an erasure record and no evidence.
There are three clocks, not two, and they do not point the same way. Rule 6(1)(e) says keep the logs and the personal data attached to them for a year, for security investigation. Rule 8(3) says keep the processing records for a year for Seventh Schedule purposes and then erase them. Rule 8(1) says erase personal data once the specified purpose is served. So one rule sets a floor with no ceiling, one sets a floor and a ceiling, and one sets a ceiling with no floor, and an agent trail that embeds personal data in its decision records is subject to all three at once.
The resolution is to reference personal data from the trail rather than to copy it in, so that the log survives the erasure it recorded, and to stamp each entry with the rule that governs its retention rather than applying a single global period. A purge job that treats all entries alike will either destroy evidence that Rule 6 requires or hold data past the point Rule 8(3) requires it gone.
What is the grievance obligation, and what does it mean for an agent with no appeal channel?
Section 8(10) requires every Data Fiduciary to establish an effective mechanism to redress the grievances of Data Principals. Rule 14 supplies the operational layer, covering the rights mechanism and response expectations, and Rule 9 requires publication of contact details for the person who can answer questions about processing.
The word carrying the weight is effective.
An agent deployment commonly has no appeal channel at all, in the sense that matters. There is a support inbox, and the support inbox is answered by the same class of system that produced the complaint. A person who believes an agent got their case wrong is routed back to an agent. That is a mechanism. Whether it is effective is a question with an obvious answer, and it is the question the Board will ask.
The harder version of the problem is that grievance redress presupposes something to redress against. A complaint about a decision is only actionable if someone can determine what the decision was and on what basis. Where an agent's trail records tool calls rather than decisions, a grievance officer receiving a complaint has nothing to investigate. They can confirm that the system ran and cannot say what it concluded.
So the grievance obligation is not really a workflow requirement. It is a logging requirement wearing a workflow's clothes, and it is the point at which India's regime converges with Article 14's oversight requirements and DIFC's evidence-of-compliance duties despite sharing no drafting lineage with either.
Three questions test whether yours is effective. Can a person reach a human without first satisfying an agent? Can that human retrieve what the agent decided and why? Can the outcome be reversed if the complaint is upheld? A no to any of them means you have a channel rather than a remedy.
When do the DPDP Rules take effect for agent deployers?
13 May 2027 for almost everything that matters. Rule 1(4) of the gazette notification, G.S.R. 846(E) dated 13 November 2025, commences Rules 3, 5 to 16, 22 and 23 eighteen months after publication. That tranche contains notice, security safeguards, breach intimation, retention and erasure, children's data, Significant Data Fiduciary obligations, Data Principal rights and cross-border transfer.
The two earlier tranches are narrower than most summaries suggest.
Rule 1(2) commenced Rules 1, 2 and 17 to 21 on 13 November 2025. That is commencement, definitions and the machinery of the Data Protection Board. No operational obligation for an ordinary Data Fiduciary lives in it. Rule 1(3) commences Rule 4 on 13 November 2026, covering Consent Manager registration, which matters only to entities seeking to operate as Consent Managers.
A good deal of published commentary distributes the obligations across these tranches incorrectly, typically by placing breach notification, retention or Data Principal rights in the first tranche. They are all in the third.
One small precision, since it circulates in both forms. The notification is dated 13 November 2025 and the gazette records publication on 14 November, so you will see the eighteen-month date computed as both 13 and 14 May 2027. The difference is a day and it has never mattered to anyone's planning, but if you are drafting a compliance calendar for a client, pick the conservative date and say which you used.
What the phasing means in practice is that you have a build window, not a holiday. Consent architecture, retention logic wired into production, breach runbooks that produce a report inside the notification window, and a grievance path with a human at the end of it are all quarters of engineering rather than a documentation exercise. The Board has existed since November 2025 and can receive complaints now.
The mistake to avoid in both directions: do not remediate today against a regime that does not yet bind, and do not assume the staggered commencement will extend past May 2027. It will not.
Truveil scores AI agents against the DPDP Rules 2025 and five other frameworks, and produces the evidence described here.