GDPR Evidence Mapping for AI Agents
GDPR predates tool-using AI agents, but Articles 22, 25, 30, 32, and 35 already constrain what an agent can do with personal data. The hardest question is Article 22: are decisions solely automated? Inserting an approval workflow at the runtime boundary is how you keep the right answer to that question while still running the agent.
Last updated: May 20, 2026
What is GDPR?
Regulation (EU) 2016/679, the General Data Protection Regulation, entered into force May 25, 2018. It applies to any controller or processor handling personal data of individuals in the European Union, regardless of where the organization is established. The European Data Protection Board (EDPB) issues guidance; supervisory authorities in each member state investigate and enforce. For AI agents, the regulation matters most through Articles 22, 25, 30, 32, and 35: automated decisions, data protection by design, records, security, and DPIAs.
Why it applies to AI agents
Any agent that processes personal data, regardless of architecture, is a processing operation under GDPR. The governed tool path is where the regulation bites: an agent that drafts an email is one thing; an agent that sends a debt-collection letter, denies a service, or shares records with a third party is processing with legal or significant effects on the data subject.
Article 22 is the article most often misread. It does not prohibit AI-assisted decisions; it prohibits decisions based solely on automated processing where they produce legal or similarly significant effects. The runtime authorization boundary is where that prohibition either bites (deny by default with no review) or is satisfied (route to a human approver before execution).
Control mapping: GDPR articles to Veto features
The table maps the articles that most directly govern AI agent processing.
| Article | Requirement | Veto feature |
|---|---|---|
| 5(1)(c) | Data minimisation: personal data adequate, relevant, limited to what is necessary | Per-tool argument validation; field-level allowlists in policy YAML |
| 5(1)(f) | Integrity and confidentiality: appropriate security against unauthorized processing | Deny-by-default authorization; per-agent scoping; environment isolation |
| 22(1) | Right not to be subject to a decision based solely on automated processing | Approval workflow routes significant decisions to human reviewers before execution |
| 22(3) | Right to obtain human intervention, express their view, and contest the decision | Approval queue with reviewer identity; decision record preserves contestable evidence record |
| 25(1) | Data protection by design: technical and organisational measures from the outset | Policy-as-code authored before agent deployment; validation gates can flag missing policy before release |
| 25(2) | Data protection by default: only personal data necessary for each specific purpose processed | Least-privilege default: agents allowed only what policy explicitly permits |
| 30(1) | Records of processing activities for each category of processing | Policy YAML acts as records of processing for agent operations; auto-exportable for Article 30 |
| 32(1) | Appropriate technical and organisational measures to ensure security | Runtime authorization, decision records, alerting, and incident response evidence |
| 33(1) | Notification of personal data breach to supervisory authority within 72 hours | Forensic decision records reconstruct incident timeline for breach notification narrative |
| 35(1) | DPIA required when processing likely to result in high risk to rights and freedoms | Policy files and decision records supply operational evidence input for the DPIA |
| 35(3)(a) | DPIA mandatory for systematic evaluation including profiling with significant effects | Approval workflow + decision record demonstrate human oversight to lower assessed risk |
| 5(2) | Accountability: controller responsible for and able to demonstrate control | Versioned policy history, decision record retention, exportable reports |
Evidence Veto provides
Supervisory authority investigations rarely accept a privacy notice as evidence. They want documented processing records, security measures, and the operational artifacts that support the data protection by design claim.
Records of processing
Policy YAML lists each tool, allowed arguments, intended purpose, and approval rules. Exportable as Article 30 records of processing activities.
DPIA evidence
Decision records show risk treatment effectiveness: approval rates, denial counts, latency. Direct input to the DPIA risk assessment matrix under Article 35(7).
Article 22 evidence
Approval queue records show human reviewers are involved in significant decisions. Reviewer ID, justification, and timestamp documented per decision.
Breach notification material
Filtered decision record reconstructs exactly what an agent did before, during, and after a suspected incident. Feeds the Article 33 narrative within 72 hours.
Implementation timeline
Article 83 creates tiered penalty exposure for records, security, DPIA, lawful-basis, transparency, data-subject-rights, and cross-border-transfer failures. Veto's role is the action-layer evidence: policy, purpose, verdict, and log.
Frequently asked questions
Does an AI agent count as automated decision-making under Article 22?
How does Veto support data protection by design (Article 25)?
When is a DPIA required for an AI agent?
What are the GDPR fines for non-compliance?
Related evidence resources
Article 22 is not a prohibition. It is a design constraint. Build for it.