DPIA for autonomous AI: assess the whole agent chain, not just dataset and model

A data protection impact assessment for autonomous AI must go beyond dataset and model: also assess memory, context transfer, tool use, third parties, changing goals and human intervention, and repeat this at every change. The MLCommons Agent Privacy Risk Taxonomy v0.1 orders privacy risks into five domains and links each threat via a failure mechanism to affected people and impact.

On 1 October 2026 the Privacy Working Group of MLCommons published the Agent Privacy Risk Taxonomy v0.1, a draft framework for ordering the privacy risks of autonomous and multi-agent systems. It is explicitly a draft version and not a binding standard, but it fills a gap: classic privacy assessments look at purpose, dataset and model, whereas an agent acts independently, remembers information, calls external tools and passes tasks on to other agents.

Additional guidance reinforces this picture. In its publication on agentic AI, the Privacy Commissioner for Personal Data in Hong Kong addresses matters including memory retention, purpose limitation, least-privilege access and human review or oversight. In How to do a privacy impact assessment the Government of Western Australia describes a process structure with a project description, information flows, risk analysis and recommendations. The latter is an official methodology, not a Dutch or European statutory DPIA standard.

What is in the MLCommons Agent Privacy Risk Taxonomy v0.1?

The taxonomy orders the privacy risks of agents into five domains: data ingestion and processing, aggregation and sharing, inconsistent privacy practices between agents, failing static consent models, and accountability and governance. In addition it describes a six-step causal chain that links a threat via a failure mechanism and a privacy event to affected people, direct privacy impact and downstream harm. Our analysis adds a reassessment moment to this.

The strength of that chain lies in its compelling nature: you cannot record a risk without naming how it goes wrong, who is affected and what the consequential harm is. In our assessment this forces organisations to translate vague notions such as "data breach risk" into a concrete story, for example: an agent copies customer data from its memory to an external tool of a third party, causing a data subject to end up unintentionally in another system.

Which steps belong in a DPIA for an autonomous AI agent?

Our analysis uses the official PIA structure from Australia as a process skeleton and the MLCommons taxonomy as a source for agent-specific risk content. In our assessment this produces a usable framework in seven steps:

• Bound the purpose, degree of autonomy and the permitted external effects of the agent.
• Make a data and permissions map of prompts, retrieval, memory, logs, tools, agent handovers and third parties.
• Classify the risks according to the five MLCommons domains.
• Trace, per risk, the causal chain from threat and failure mechanism to privacy event, affected person, impact and downstream harm.
• Test purpose limitation, data minimisation, consent, data subjects' rights, retention periods, security, human intervention and supplier management.
• Record technical and organisational measures: least privilege, context shielding, memory management, independent controls and stop mechanisms.
• Note residual risk, the person responsible, the evidence and the triggers for reassessment.

The difference from a classic DPIA lies mainly in the second step. In our assessment a map of the actual subprocessor chain and model routes becomes necessary, because an agent can share data with parties that were not in view beforehand.

What does this mean for directors, lawyers and CISOs?

Our analysis: because an agent independently calls tools and passes data on to other systems, the privacy risk shifts from the moment of design to the moment of execution, and that affects everyone who remains a controller; therefore the data protection officer must, in our assessment, require that the DPIA also assesses runtime behaviour, memory and agent handovers, not just the dataset and the model. Because the Hong Kong regulator separately names memory and retention periods for histories, there is a risk that personal data lingers in an agent's memory longer than the processing purpose justifies; therefore the lawyer, in our assessment, records in the record of processing activities and in supplier contracts how long memory and logs are retained and how they are erased. Because the guidance names least-privilege access but in practice an agent is often granted broad permissions, there is a risk that one compromised agent can reach everything, and therefore the CISO, in our assessment, limits the permissions per agent and builds in a stop mechanism and incident playbook for unauthorised agent behaviour before the system goes live. Because the guidance names human review or oversight as a measure, there is a risk that decisions are taken without human intervention; therefore the board, in our assessment, determines in advance which decisions a human must approve and records that threshold in writing.

When should I carry out the assessment again?

A DPIA for an autonomous agent is, in our assessment, not a one-off document but a versionable control cycle. The Hong Kong guidance supports continuous risk assessment. In our analysis, we translate that principle, combined with the MLCommons causal chain, into a reassessment moment per risk. In our assessment, the following changes should trigger a reassessment of the affected risks and controls:

• a different underlying model or a model update;
• a changed system prompt or instruction;
• a change in memory or retention settings;
• a new or adjusted tool that the agent may call;
• a different supplier or model route;
• a new data source that the agent accesses;
• a changed purpose or a higher permission level.

Whoever fails to do this runs the risk, in our assessment, that the recorded assessment no longer matches the system that actually runs. That undermines not only privacy protection but also accountability: a linked decision and event record is only usable if it corresponds to the current configuration. For a broader setup of responsible privacy management around AI, our topic hub on AI privacy and the GDPR offers further background, and for the control of the agent chain itself the hub on agentic AI and AI agents.

Sources: The article draws on the Agent Privacy Risk Taxonomy v0.1 from MLCommons, the agentic AI guidance from the Privacy Commissioner for Personal Data in Hong Kong and the PIA methodology of the Government of Western Australia.