GDPR accountability for AI agents: why your governance must be reviewed per agent and per session

You must treat each AI agent as an identifiable, non-human actor within your governance framework. Assign each agent an owner, bind it to a defined purpose and specific data categories, enforce authorisation that adapts to context, and maintain a per-session record of which agent accessed which personal data, for what purpose and under whose authority. Without this, you cannot demonstrate GDPR accountability.

An analysis of 16 September 2026 on privacy governance and autonomous AI agents argues that classical privacy governance—data protection impact assessments, records of processing activities and policy frameworks—was built for predictable software with defined data flows, whereas autonomous agents select their own tools at execution time, traverse multiple data sources and initiate processing chains that were not anticipated at design. The practical consequence: your existing governance may no longer describe what is actually happening. In our assessment, this is not primarily a technical problem but an accountability problem. If you cannot establish which agent consulted which personal data, you cannot meet the GDPR's Article 5(2) accountability obligation. The question shifts from "which system processes data" to "which agent made which decision, and why"—a shift that demands visibility at agent level, not system level alone.

Why your records of processing activities no longer fit autonomous workflows

A record of processing activities assumes predefined, repeatable data flows. An autonomous agent, by contrast, decides during execution which source it will access, which tool it will call and which data it will combine to complete its task. This means the data flows you documented at design time may not match what the agent actually does. The agent may pull and recombine personal data from multiple sources in ways that were not foreseen when you completed your impact assessment. Your governance framework has no mechanism to capture this variance, and no way to show a regulator what actually happened in a particular session.

Which failure modes does agent autonomy create?

• Undocumented data access — an agent retrieves personal data from sources not listed in your records of processing activities.
• Purpose drift — an agent combines data for a purpose that differs from the one you documented, or uses data marked for one purpose to serve another.
• Untraced tool chains — an agent calls multiple tools in sequence without a record of which data passed between them.
• Context window leakage — personal data enters an agent's context window from multiple sources, and you cannot later establish which categories were present or why.
• Authorisation decay — an agent continues to access data under permissions that should have been revoked or narrowed based on context.

What must your governance demonstrate per agent and per session?

The EDPB's coordinated enforcement action is already asking controllers to document the processing of personal data within AI agent sessions. Many teams cannot provide that record. You must be able to show, for each session:

1. Identify the agent and its owner — document which agent performed the action and which person or team is accountable for its decisions.
2. Record the data categories accessed — specify which categories of personal data entered the agent's processing, from which systems, and at what point in the workflow.
3. Document the lawful basis and purpose — establish which purpose the agent was pursuing and which lawful basis justified access to each data category.
4. Log the tools and their sequence — record which tools the agent called, in what order, and which data passed between them.
5. Capture the authorisation context — document under whose authority the agent was permitted to act and whether that authority remained valid for the specific task.

How does this change what you must build into your infrastructure?

Treating agents as identifiable principals within your access control framework is the foundation. Each agent needs a lifecycle: provisioning with a defined scope, continuous authorisation that adapts to context rather than relying on static least-privilege rules, and deprovisioning when its purpose ends. This is not a one-time policy decision but a runtime property you must enforce and demonstrate per task. Most organisations currently lack standardised requirements for logging agent-initiated actions, and many have no lifecycle management for agent identities at all. You will need to establish both.

What tooling can support this, and what remains your responsibility?

Verification layers can make data flows visible and provide insight into which data entered a workflow and from where. Privacy-preserving technologies can replace sensitive values with synthetic, session-only equivalents before an AI chain processes content, and can halt processing if a privacy check fails. These tools support control and demonstrability. They do not guarantee that every autonomous action can be reconstructed or that an agent stayed within its task. The professional judgement about whether an agent's actions were appropriate, proportionate and within scope remains yours alone. Tooling can show you what happened; only you can decide whether it should have happened.