Structuring a Data Protection Impact Assessment for agentic systems
GDPR Article 35 requires a DPIA before deploying AI agents that process personal data at scale. Here's the five-component structure and the evidence your DPO needs.
How to structure a Data Protection Impact Assessment for agentic systems under Article 35
Most enterprise AI deployments access personal data. A customer service agent reads account histories. A document processing agent extracts names and addresses. A research agent queries HR records. Under GDPR, autonomous processing of personal data at scale — especially processing that makes or informs decisions affecting individuals — triggers the Article 35 obligation to conduct a Data Protection Impact Assessment before the processing begins.
The DPIA requirement is not new. What is new is that AI agents make DPIA compliance substantially harder: the agent's behavior is probabilistic, its data access patterns emerge at runtime, and demonstrating effective control requires evidence that traditional software doesn't generate automatically.
This guide covers the five required components of a GDPR-compliant DPIA, the specific evidence challenge that AI agents create, and how to structure the documentation your DPO needs to sign off and your DPA can review.
GDPR Article 35(1) requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." The Article 29 Working Party (now EDPB) guidance identifies criteria that, when two or more apply, make a DPIA mandatory. Agentic AI systems typically trigger multiple criteria simultaneously.
| EDPB Criterion | Applies to AI Agents? | Common Scenario |
|---|---|---|
| Automated decision-making with legal/significant effect | ✅ Frequently | Agents that approve, reject, score, or route |
| Large-scale processing of personal data | ✅ Common | Agents processing customer data at volume |
| Systematic monitoring | ✅ Common | Agents with ongoing data access to user activities |
| Processing of sensitive categories (Art. 9) | ⚠️ Depends | Health, financial, HR agents |
| Innovative use of technology | ✅ Yes — LLMs are explicitly cited | Any LLM-based agent deployment |
| Processing that "prevents data subjects from exercising rights" | ⚠️ Depends | Agents with access to communication channels |
If your enterprise AI agent accesses personal data and operates with any degree of autonomy — especially if it can take actions that affect individuals — assume a DPIA is required. The cost of a missed DPIA is enforcement action; the cost of an unnecessary one is documentation effort.
Document the nature, scope, context, and purposes of processing. For AI agents, this must include: which personal data categories the agent accesses, what tools it can invoke on that data, the logic of automated decisions it influences, and data retention and deletion behaviors. The description must be specific enough that a reviewer can trace data flow through the agent's operation.
Demonstrate that the processing is necessary for the stated purpose and proportionate to the privacy intrusion. For AI agents, this requires justifying not just that the agent uses personal data, but why it needs the specific categories of data it accesses, why automated processing is necessary rather than manual, and what limiting measures are in place (data minimization, purpose limitation, access scoping).
Identify the risks to individuals' rights and freedoms: risks of unauthorized access, unintended disclosure, inaccurate decisions, discriminatory outcomes, or loss of control over personal data. For AI agents, this must address the probabilistic nature of model behavior — the agent can produce unexpected outputs under novel inputs that no static risk assessment can fully anticipate.
Describe the technical and organizational measures that address each identified risk — and demonstrate that those measures actually work. This is where most AI DPIAs fail: describing controls is insufficient. Evidence that controls function in production is required. For AI agents, this means behavioral testing records, runtime enforcement logs, and access audit trails.
Consult the DPO (if appointed) and record their opinion. Where the risk assessment concludes that residual risk remains high after mitigation, also consult the supervisory authority (DPA) before beginning processing. Document both consultations and any opinions received.
Traditional software DPIAs describe controls like "access is restricted by role-based permissions" and point to the RBAC system configuration as evidence. The control is static, verifiable, and testable.
AI agents make this harder in two ways. First, what data the agent accesses and what actions it takes depend on runtime context — not a fixed access control list. Second, the agent's behavior is probabilistic: the same input can produce different outputs, and demonstrating control means demonstrating it across the distribution of possible outputs, not just a single test case.
| Risk Mitigation Control | Evidence Required | AgentTrust OS Source |
|---|---|---|
| Data minimization (agent accesses only necessary data) | Permission contract per agent, tool access logs | Trust Runtime policy records |
| Purpose limitation (agent uses data only for stated purpose) | Behavioral certification across test scenarios | Trust Certify certification report |
| Accuracy (agent doesn't make decisions on incorrect data) | Confidence scoring records, human escalation logs | Trust Runtime + Trust Audit |
| Right to explanation (automated decisions are explainable) | Decision trace with reasoning and confidence signals | Trust Audit records |
| Human oversight for high-risk decisions | Escalation routing logs, approval records | Trust Runtime escalation + Trust Audit |
Trust Certify, Trust Runtime, and Trust Audit generate the documentation your DPIA's risk mitigation section requires — before your DPA ever asks for it.
View Compliance Resources →