DPIAs for generative AI and AI agents become a living risk map

You must now treat the Data Protection Impact Assessment for any generative AI or agentic system handling personal data as a design tool and verification checkpoint, not a compliance document filed and forgotten. The DPIA obligation is no longer optional for high-risk deployments, and regulators expect it to cover the entire AI chain from training through inference, logging and autonomous action.

The prompt is an analysis of 19 August 2026 of how data protection authorities across multiple jurisdictions are reframing the DPIA for generative AI and AI agents, which argues that the DPIA must function as a living risk map tied to concrete operational controls rather than a static document. The analysis draws on guidance from the French CNIL, the European Data Protection Supervisor, the European Data Protection Board and the Kenyan regulator, each setting out the same expectation: that a DPIA for AI systems must address the entire lifecycle and the specific risks posed by scale, profiling and autonomous decision-making. In our assessment, this shift means you cannot treat the DPIA as a box-ticking exercise completed before deployment. It becomes a mechanism by which you demonstrate that the risks you identified have been mitigated in practice, and that those mitigations remain in place and verifiable.

When does a DPIA become mandatory for your AI system?

Three characteristics trigger the DPIA obligation. The first is the use of innovative technology — generative models and agentic systems fall squarely into this category because their behaviour is not fully predictable and their outputs depend on training data you may not fully control. The second is large-scale processing: these systems typically handle data across many individuals and many data points per individual. The third is automated decision-making, particularly where the system acts without human review between each decision. If your deployment exhibits all three, a DPIA is not discretionary. The obligation applies whether you are a public authority, a private organisation or a service provider acting on behalf of a controller.

What must your DPIA actually cover?

The DPIA for an AI system is not a data-only assessment. It must map the entire chain: the training data and its provenance, the inference process and the model's behaviour under different inputs, the logging and retention of outputs, the way the system makes or influences decisions, and the effects on the people whose data it processes. For agentic systems, this extends to the agent's tool permissions, its memory functions and the decision paths that lead to autonomous action. Each of these points becomes a potential risk vector. You must document which data flows through which models, which tools the agent can invoke, where decisions are logged and who can access those logs. A fragmentary assessment of outputs alone is insufficient; regulators now expect you to show that you have thought through the entire lifecycle.

Which failure modes and risk categories must you address?

• Discrimination and bias — the system making decisions that disadvantage individuals on grounds of protected characteristics or that amplify historical inequalities in training data.
• Unexplainable decisions — the system producing outputs or triggering actions that cannot be traced to a specific input or rule, leaving data subjects unable to understand why they were affected.
• Data leakage and memorisation — personal data reproduced or inferred from model outputs, or retained in model weights or logs beyond the retention period.
• Unauthorised profiling — the system inferring sensitive attributes about individuals beyond what was necessary for its stated purpose.
• Autonomous action without oversight — the agent executing decisions or tool calls without a human review step, creating a gap between intent and effect.
• Dependency and lock-in — reliance on a third-party model or service whose behaviour you cannot fully audit or whose terms may change.

Which concrete controls must you be able to demonstrate?

1. Document the model, its purpose and its data — record which model each workflow uses, the lawful basis for processing, the training data sources and the retention period for outputs.
2. Implement least-privilege access — ensure that the agent or system can only invoke the tools, access the data and trigger the actions strictly necessary for its stated purpose.
3. Log all decisions and tool calls — maintain an audit trail that shows what input the system received, what decision or action it took and when, so that you can later trace any harm or error.
4. Build in human review checkpoints — require a human to approve or review decisions before they take effect, particularly where the decision affects a data subject's rights or interests.
5. Establish unlearning and correction procedures — document how you will remove or correct personal data from the system if a data subject requests it, and how you will verify that the correction has taken effect.
6. Conduct periodic verification — test the system's behaviour against the mitigations you documented in the DPIA, and update the DPIA if the system's behaviour or the risks change.

How does the DPIA become a living document rather than a filing?

The shift from static assessment to living risk map requires you to link your DPIA findings to the controls you actually operate. When you identify a risk in the DPIA — say, the risk that the system will memorise personal data — you must then specify which control mitigates it: perhaps a data masking layer that removes sensitive values before the model sees them, or a logging system that tracks what data the model outputs so you can detect leakage. You then verify that the control is in place and working. If the system's behaviour changes, or if you discover a new risk, you update the DPIA and the controls together. This is not a one-time exercise; it is a cycle of assessment, implementation, verification and revision.

Tooling can help you link the DPIA to the controls — a verification console can expose which models are being used in each workflow, which data flows through them, which logs are being kept and which review steps are in place. But the tooling cannot replace your professional judgement about whether a control is adequate, whether a risk has been fully mitigated or whether a new risk has emerged. The DPIA remains your responsibility, and the controls remain your choice. What changes is that you can now make those choices visible and verifiable to regulators, auditors and the people whose data you process.