A series of guidelines and notes from 2025 and 2026 is changing the role of the Data Protection Impact Assessment (DPIA) for AI applications. Where the DPIA was long seen as a one-off document, regulators and lawyers now position it as an explicit design and verification tool. The core message: anyone deploying generative AI or AI agents that process personal data in high-risk ways will often need a DPIA — and that DPIA must cover the entire AI chain.
Regulators set the bar
In its recommendations AI system development: CNIL's recommendations to comply with the GDPR, the French CNIL sets out how AI systems must be designed under the GDPR. The CNIL explicitly links the DPIA obligation to the use of innovative technology, large-scale processing and automated decision-making. Those three characteristics are precisely what typifies generative models and agentic systems.
The European Data Protection Supervisor (EDPS) takes a similar approach for EU institutions. In the note Generative AI and the EUDPR: Orientations for ensuring data protection compliance, the EDPS states that a DPIA is required for high-risk processing operations involving generative AI. More importantly, according to the EDPS that DPIA must cover the entire lifecycle — from training and inference to logging, the effects on data subjects and possible risks to fundamental rights. A fragmentary assessment of the output alone is therefore not sufficient.
On the form side, a standard is being added. According to the commentary The EDPB's Standard Privacy Impact Assessment Template, a March 2026 commentary describes a harmonised DPIA template intended to standardise the application of Article 35 GDPR. That template explicitly takes account of AI-specific risk factors, such as innovative technology and large-scale profiling. The message for organisations: an ad-hoc DPIA is no longer sufficient; regulators expect a recognisable, standardised structure.
The same direction internationally
That this line is not confined to the EU is shown by the Kenyan regulator's Guidance Note on Artificial Intelligence July 2026. It prescribes a DPIA before every high-risk processing activity and works out a specific AI framework: a description of the system, a necessity and proportionality test, a risk assessment that takes discrimination and unexplainable decisions into account, and concrete mitigations. Generative and agentic AI are named as examples of systems that may, because of their scale, profiling and autonomy, require a DPIA.
Agents: DPIA and FRIA
With AI agents a second layer is added. The analysis DSGVO for AI Agents argues that agents which process personal data in a risky manner may The analysis DSGVO for AI Agents argues that agents which process personal data in a risky manner may need both a DPIA under Article 35 GDPR and a Fundamental Rights Impact Assessment (FRIA) under Article 27 of the AI Act.. The article refers to CNIL statements that a DPIA is in principle necessary for high-risk AI systems processing personal data, and sketches a practical step-by-step approach: map the agent's data flows and decision paths, assess the risks to data subjects and fundamental rights, and document and review both assessments periodically.
For agentic systems this means the DPIA describes not only the data, but also the agent's tool permissions, its memory functions and the way autonomous actions come about. Data streams, tool calls and decision paths thus become part of the risk analysis — not as an afterthought, but as its core.
From static report to living risk map
Together, these sources point in the same direction: in our analysis, the DPIA for generative AI and AI agents works best as a living risk map. Per AI workflow it becomes visible which data, models and agents are involved, which GDPR and AI Act criteria trigger the DPIA obligation, which mitigations have been chosen — think of least privilege, logging, human review and unlearning — and how those choices relate to the risks to data subjects.
The tricky part is that a DPIA on paper is something other than what happens in practice. This is where, to our assessment, the need arises to operationalise DPIA findings into concrete controls. A verification layer such as Vera from IamVera.ai can support this: Vera is not a chatbot and not its own language model, but a privacy-focused layer that can route a task through selected independent AI models and expose the verification steps, corrections and disagreements. That gives more insight into what happens in the chain, without guaranteeing correctness or eliminating hallucinations; the final judgement remains with the professional.
On the point of data flows, the architecture aligns with what the DPIAs intend. The Semantic Privacy Shield can replace sensitive document values before processing with synthetic, session-only equivalents on EU infrastructure; the AI chain analyses that synthetic version and the original values are restored locally after the workflow. The architecture is designed so that only anonymised content is sent onward, and the workflow is fail-closed: when a privacy check fails, the document is not sent onward. Within Vera Office, users can view and edit documents within that protected workflow. This is a design choice and not a legal guarantee of GDPR compliance.
The common thread remains the same as in the guidance from the CNIL, EDPS and the EDPB: a DPIA is only valuable if the mitigations it describes are also demonstrably set up in daily practice and can be verified. To our analysis, a verification console can help bridge that gap by linking DPIA and FRIA findings to concrete controls, audits and incident analyses — with the DPIA as a living document rather than a ticked-off report.