DPIA for AI Agents: When You Need One and How to Run It

An AI agent that reads customer emails, pulls records from a CRM, and drafts responses is processing personal data at every step. Under GDPR, that alone does not automatically require a Data Protection Impact Assessment. But most agentic deployments trip the threshold without teams realizing it, because the criteria were written for static systems and agents combine several risk factors at once almost by default.

Getting this wrong in either direction costs you. Skip a required DPIA and a regulator can fine you for the gap itself, separate from any breach. Run one for every minor internal tool and you drown your privacy team in paperwork that adds no real risk reduction.

When Article 35 actually requires a DPIA

GDPR Article 35 requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." That phrase is vague by design, so the EDPB has published nine criteria to make the judgment concrete. Processing that meets two or more of these criteria should be presumed to require a DPIA:

• Evaluation or scoring, including profiling
• Automated decision-making with legal or similarly significant effect
• Systematic monitoring
• Sensitive data or data of a highly personal nature
• Data processed on a large scale
• Matching or combining datasets
• Data concerning vulnerable data subjects
• Innovative use or new technological solutions
• Processing that prevents data subjects from exercising a right or using a service

Look at that list against a typical support or HR agent. It scores against evaluation (the agent assesses ticket priority or candidate fit), automated decision-making (it drafts or sometimes sends a response without review), and innovative technology (large language models still qualify) almost immediately. Three criteria on a threshold of two. Most production AI agents handling personal data clear the bar without anyone intending to build a "high-risk" system.

The gap most DPIA templates have for agents

Standard DPIA templates were built for static processing: a fixed database query, a scoring model with a defined output range, a single decision point. Agentic systems break three assumptions those templates make.

The processing path is not fixed at design time. A traditional DPIA documents what the system does. An agent that dynamically chooses which tools to call and what data to retrieve does not have one fixed path, it has a distribution of possible paths depending on the input. Your DPIA needs to document the boundaries of what the agent is permitted to do, not just what it typically does, because "typically" is not a legal defense when it does something outside that range once.

Purpose limitation gets fuzzy when the agent chains tasks. An agent given a broad instruction ("resolve this ticket") may pull data for a purpose adjacent to but not identical to what the data subject consented to when that data was collected. A conventional DPIA checks one purpose against one processing activity; an agentic DPIA needs to check the tool-access boundary itself, not just the stated goal.

Retention and deletion become harder to enforce. If an agent's reasoning trace or intermediate tool outputs are logged for audit purposes (which they should be, for AI Act Article 12 compliance), that log itself contains personal data with its own retention clock, separate from the record it references. Most DPIA templates do not have a field for "personal data embedded in the audit trail of the personal data."

A practical DPIA process for agentic systems

1. Map every tool the agent can call, not just the ones it usually calls. List each data source, API, and action it has permission to reach, even ones rarely triggered. Risk lives at the boundary of what is possible, not the average case.
2. Score against the EDPB nine-criteria list per tool-access path, not once for the whole agent. A support agent that can only read tickets scores differently than one that can also issue refunds.
3. Document the human oversight point explicitly. Where does a person review or approve before an action with real-world effect happens? This is also your primary mitigation for the automated-decision-making criterion, and pairs directly with human-in-the-loop approval gates.
4. Set retention separately for the audit log and the underlying record. They are different personal data processing activities with potentially different lawful bases and retention periods.
5. Re-run the assessment when tool access changes. Adding a new integration to an existing agent is a material change to the processing, not a minor update, and should trigger a fresh (or at least delta) DPIA.
6. Consult the DPO before expanding scope, and the supervisory authority if residual risk stays high after mitigations, per the standard Article 36 prior-consultation obligation.

Where this overlaps with the AI Act

If the agent falls into an Annex III high-risk category, such as employment decisions or access to essential services, the AI Act requires its own fundamental rights impact assessment alongside the DPIA, and current guidance points toward integrating the two into a single document rather than running parallel assessments that duplicate the same risk analysis. Building that combined document from the start saves the rework of reconciling two separate assessments later.

Making this repeatable instead of a one-off project

The teams that handle this well treat the DPIA as a living document tied to the agent's actual tool permissions, updated whenever access changes, not a PDF filed away after launch and never revisited. That only works if the platform running the agent exposes tool-access boundaries and human-approval configuration as first-class, inspectable settings rather than something buried in code. When your privacy team can see exactly what an agent can touch and where the approval gates sit, the DPIA writes itself from the configuration instead of requiring a separate audit.