AI Agents Under GDPR and the AI Act: When the Software Decides and Acts, Who Is Accountable?

CORE THESIS An AI agent does not merely process personal data — it perceives, plans, and acts, calling tools and reaching systems no one listed in advance. That autonomy changes nothing about who is accountable: the agent is a technical means, and the deploying organisation remains the controller of — or at least accountable for — what the agent does in its name. What it does change is where compliance has to live. Purpose limitation, Article 22, and least-privilege tool access can no longer sit in a document signed before launch; they must be enforced at runtime, because the agent rewrites its own plan mid-task. The decisive question is no longer “what data did we process?” but “when the agent acted, who decided — and who can pull it back?”

A chatbot answers a question and stops. An agent is given a goal and does not stop — it reads the brief, drafts a plan, pulls data through APIs, calls a tool, inspects the result, changes course when a step fails, and closes the loop. The difference is not a matter of degree. A general-purpose model is a thing you query; an agent is a thing you delegate to. And the moment an organisation delegates a goal to an autonomous system that touches personal data, it has created a compliance situation that the contracts, assessments, and controls built for ordinary software do not cover.

Consider a concrete case, of the kind that is now appearing across customer support, finance, and HR functions. An organisation deploys an agent to triage an inbox, draft replies, and manage a calendar. A user types a single instruction: “Schedule a follow-up with Dr. Rossi the week of 14 October.” Innocuous. But to satisfy it, the agent pulls recent email threads for context, inspects calendars, checks travel time through a maps API, uploads the doctor’s last message to a third-party summariser to extract proposed dates, runs an Italian phrase through a translation service hosted outside the EEA, and stores a derived note for next time.¹ In one sentence of user intent, the agent has carried out a chain of processing operations across at least three external services — at least one of them a third-country transfer — none of which appeared in the brief, and quite possibly none of which appeared in the organisation’s Data Protection Impact Assessment.

This is the structural fact that makes agents different. With a prompt, you decide what to send. With an agent, you decide the goal, and the agent determines the steps — including, within its configured permissions, which personal data to access and which tools to invoke. The question this article answers is the one that follows directly: when the agent acted, who decided, and who can pull it back? Everything that matters under both the GDPR and the AI Act flows from how seriously an organisation takes that question before it grants an agent the autonomy to act.

The agent is not a legal actor — you are

The first instinct, when a system acts autonomously, is to treat its autonomy as a transfer of responsibility: the agent decided, so the agent is accountable. This instinct is wrong, and the Spanish supervisory authority (AEPD), in the most detailed regulatory guidance on agentic AI published to date, removes any doubt about it. An AI agent is a technical means through which processing is carried out — not an autonomous legal actor.² Autonomy at the technical level does not alter the legal qualification of the processing or the allocation of responsibility between controllers, joint controllers, and processors. The AEPD frames the distinction precisely: the line that matters is between execution and responsibility. The agent executes; the organisation that deploys it and determines its purposes and essential means remains the controller of everything it does.³

This sounds reassuring until its full weight lands. It means that every API call the agent makes on its own initiative, every third-party tool it decides to invoke, every piece of personal data it chooses to pull into context, is — legally — the controller’s processing, attributable to the controller, governed by the controller’s obligations. The agent’s autonomy does not create a buffer of deniability. It creates a span of processing the controller is answerable for but did not individually authorise. “The system did it” is not a defence; it is a confession that the controller deployed an autonomous processor without adequate control over what it would do.

The role-mapping gets more tangled, not less. The AEPD notes that the deploying organisation is typically the controller, while the external LLM provider, the workflow-automation platform, and the cloud-memory service may be processors — or, in some configurations, independent controllers in their own right.⁴ Each must be identified, and a data processing agreement must be in place with each. The EDPB’s settled position applies with full force here: role allocation is functional, determined by who actually decides purposes and means, not by what a contract label says.⁵ An agent that silently reaches a new tool has, in that instant, extended the controller’s processing chain to a party that may have no agreement in place at all.

Article 22 and the AI Act: when an action becomes a decision

The deepest shift agents introduce is that they do not only process — they decide and act. That moves the analysis out of pure data-handling and into the territory of automated decision-making, where the GDPR and the AI Act overlap directly.

Under Article 22 GDPR, a person has the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects. The common error is to assume agents automatically trigger Article 22 because they are autonomous. The AEPD is careful here: whether an agentic action amounts to Article 22 automated decision-making depends on the effects of the decision and the degree of meaningful human intervention — not on the mere use of autonomous technology.⁶ An agent that drafts a reply for a human to send has a human in the loop. An agent that autonomously declines a refund, reschedules a patient, or filters a candidate — with no meaningful human review — is making a decision with effect, and Article 22’s restrictions and its transparency duty (meaningful information about the logic involved, on request) attach.⁷ The AEPD’s warning is sharper still: even actions that affect individuals indirectly, through downstream processes, must be assessed — because an agent’s consequences are not confined to the step a human watched.⁸

The cost of getting this wrong is not hypothetical, and the most instructive example predates the agent era by years. In the Dutch toeslagenaffaire — the childcare-benefits scandal — the tax administration used a self-learning risk-classification algorithm to flag families for fraud investigation, partly on the basis of nationality and dual citizenship.⁹ Between 26,000 and 35,000 families, by various counts, were wrongly accused; many were driven into financial ruin, some had children taken into care, and the resulting political fallout brought down the Dutch government in January 2021. The Dutch Data Protection Authority later fined the tax administration €2.75 million, finding the processing unlawful and discriminatory.¹⁰ Two features of that disaster transfer directly to agentic AI. First, there was nominally a “human in the loop” — officials acted on the algorithm’s flags — but the human review was not meaningful; it rubber-stamped a machine output it could neither interrogate nor override in practice. This is exactly the failure mode the AEPD warns against: the presence of a human is not the same as meaningful human intervention, and Article 22 looks at the latter. Second, the harm propagated downstream — the model’s output was shared with other public and private bodies, so a single flawed classification rippled into bank-account closures and custody decisions. An agent that calls tools and passes its conclusions to other systems reproduces precisely this downstream-propagation risk, at machine speed and with less visibility. The toeslagenaffaire is what an automated decision with “legal or similarly significant effect” looks like when no one can pull it back.

The AI Act adds a second, parallel layer. Where an agent constitutes or is embedded in a high-risk AI system that makes or assists decisions about natural persons, the deployer must, under Article 26(11), inform the affected individuals that they are subject to its use.¹¹ The timing matters and is easy to get wrong. The AI Act’s Article 50 transparency obligations — including the duty to disclose when a person is interacting with an AI system — apply from 2 August 2026. The high-risk regime that Article 26(11) belongs to, however, was deferred by the Digital Omnibus agreement of 7 May 2026: for stand-alone Annex III high-risk systems, the deployer and provider obligations are set to apply from 2 December 2027 (subject to formal adoption), rather than the original August 2026 date.¹² The practical consequence is not that the obligation can be ignored — it is that the GDPR is doing the live work now, while the AI Act’s high-risk duties sit on a near, agreed-but-not-yet-final horizon. An organisation running a decision-making agent today already faces an Article 22 analysis under the GDPR, and should build against the high-risk classification and transparency duties on the timetable the co-legislators have agreed — treating the December 2027 date as a planning baseline that formal adoption is expected to confirm, not as permission to defer the design until then.

Memory, purpose drift, and the “technological fog”

Agents carry a feature ordinary software does not: persistent memory. To improve performance, an agent stores context, user preferences, and past interactions — and the AEPD flags this as a significant compliance risk in its own right.¹³ Memory that accumulates “just in case” or to “optimise performance” collides head-on with purpose limitation and data minimisation. Worse, when a single agent serves several processing activities, its memory becomes a vector for purpose drift: data gathered for one purpose silently informs another. The AEPD’s remedy is concrete — memory must be compartmentalised between different processing activities and different users, held under strict retention periods, and designed so that data-subject rights (access, rectification, erasure) reach into it.¹⁴ An agent’s memory is not a convenience cache; it is a record of processing, subject to every obligation that attaches to one.

Around this sits a problem the AEPD names memorably: the technological fog. Because an agent’s decisions emerge from chains of inference distributed across several tools and sub-agents, the people affected — and often the operators themselves — have no visibility into which services were queried, what data was used, or how intermediate results shaped the outcome.¹⁵ The fog has a compliance consequence and a cultural one. The compliance consequence is that transparency obligations become genuinely hard to meet: you cannot disclose a decision logic you cannot reconstruct. The cultural one is more insidious — the temptation to accept an agentic system as legitimate simply because it is “AI”, without understanding or evidence. The fog is not a reason to trust the system. It is the precise thing the controller’s accountability obligation exists to dispel.

Why static controls collapse — and what replaces them

Here is the operational heart of the matter. The GDPR’s principles still point true: purpose limitation, minimisation, transparency, storage limitation, accountability. What fails with agents is not the principles but the operating model built around them — the assumption of stable data flows, predictable toolchains, and human approval at fixed points.¹⁶ When an agent rewrites its plan mid-run and calls an API that never made it into the DPIA, a control that lives only in a document signed before launch has already been bypassed. The assessment described a workflow the agent no longer follows.

The fix, as the IAPP framing puts it, is to shift compliance from documents to mechanisms — to make governance travel with the system at runtime.¹⁷ In practice, drawing on both the AEPD’s minimisation guidance and runtime-governance practice, that means several concrete controls:

Least-privilege tool and data access. Define explicit policies for every repository and tool the agent can reach; the agent gets access to what its purpose requires and nothing more. The AEPD’s minimisation guidance is specific here — catalogue and tag data to identify what is appropriate for the agent to use, flag problematic unstructured sources, and enforce effective access restrictions per repository.¹⁸ An agent governed as an identity, with the same access controls and audit trails as a human user, is the working form of data minimisation for autonomous systems.

Runtime guardrails over one-time review. Allow-lists for tools and plugins, data-egress filters, geofencing to keep processing inside the EEA, sensitive-category detectors, and a kill switch when the agent strays out of bounds — these enforce the policy at the moment of action, not in a quarterly audit.¹⁹ A predeployment test against synthetic and edge-case scenarios, to detect over-collection, unauthorised tool use, and purpose drift before launch, is the agentic equivalent of the DPIA done as engineering.

Traceability by run and by user. Because the fog is the enemy of transparency, the antidote is lineage: a complete record of what the agent did, which data it accessed, which tools it called, and how it reached a decision — anchored per run and per user, so that a DSAR or an Article 22 explanation request can be answered from evidence rather than guesswork.²⁰ Logging, though, is itself processing: the AEPD cautions that excessive logs create their own risk of over-collection and intrusive monitoring, so traceability must be designed, not maximised.²¹

These three are not a menu to pick from but a sequence to build in order: scope the agent’s access before it runs (least privilege), enforce the scope while it runs (runtime guardrails), and capture what it did after each run (traceability) — each layer assuming the one before it. An agent that has the third without the first is merely well-documented as it oversteps.

The DPIA does not disappear in this model — it changes character. It becomes the document that specifies these mechanisms and the boundary of the agent’s authority, rather than a snapshot of a workflow the agent will not respect. And because deploying an autonomous system that processes personal data at scale, takes consequential actions, and may meet the high-risk threshold almost certainly crosses the Article 35 line, the DPIA is not optional — it is the instrument in which the agent’s purpose, its tool boundary, its memory rules, and its human-oversight points are fixed before it is given the autonomy to act.

Four questions before an agent is given a goal

The architecture reduces to a short diagnostic a DPO or system owner can run before granting an agent autonomy over personal data.

First: what is the agent’s purpose, and is its tool and data access bounded to exactly that? If the agent can reach repositories or call tools beyond what its purpose requires, minimisation has already failed — autonomy plus over-broad access is purpose drift waiting to happen.

Second: does the agent take decisions with legal or similarly significant effect on people, solely automatically — and is there meaningful human oversight where it does? If yes to the first and no to the second, Article 22 GDPR restrictions apply now, and the AI Act’s high-risk deployer duty under Article 26(11) is on its way (Annex III: from 2 December 2027 under the Omnibus, subject to formal adoption). The effect plus the absence of meaningful human review, not the autonomy itself, is the trigger.

Third: where does the agent’s memory live, what is in it, and can data-subject rights reach it? Memory compartmentalised by purpose and user, with retention limits and erasure pathways, or an undifferentiated store accumulating context “just in case”? The second is an open finding.

Fourth: when the agent strays — calls an unlisted tool, transfers data outside the EEA, exceeds its purpose — what stops it, in real time? If the only answer is “the next audit”, the controls are static and the agent has already outrun them. There must be a runtime mechanism: an allow-list, an egress filter, a kill switch.

If any of these has no answer, the agent is not ready to be given the goal.

A stress test: the agent that books the wrong outcome

Take the inbox-and-calendar agent from the opening and give it slightly more authority — the version organisations are actually deploying in 2026. It does not just draft replies; it is allowed to act: cancel and rebook appointments, decline meeting requests that fail a rule, and escalate “high-risk” senders to a separate queue. One morning it processes a message from a patient asking to move an appointment. The agent reads the thread, infers from a phrase that the patient is a “frequent canceller,” applies an internal rule that deprioritises such patients, declines the request, and offers a slot six weeks out. No human saw the decision; it was one of four hundred the agent handled before lunch.

Walk it through the four questions and the failures stack up. Was the action a decision with significant effect? For a patient waiting on care, plausibly yes — and if it was a solely automated decision producing legal or similarly significant effects, Article 22 is in play, and the “frequent canceller” inference is an automated judgement the patient is entitled to contest and to have explained. Was there meaningful human oversight? None — and as the toeslagenaffaire showed, even a nominal human checkpoint would not satisfy the standard unless the reviewer could actually interrogate and override the inference. Did the harm propagate downstream? The six-week slot and the “high-risk” tag now sit in the agent’s memory and may shape every future interaction with this patient — purpose drift encoded as a persistent label. And when it went wrong, what stopped it? Nothing, until someone complained — by which point the decision was weeks old and the reasoning was lost in the “technological fog” of an inference chain no one recorded.

The stress test makes the thesis concrete: nothing here required a malicious actor or a dramatic failure. It required only an agent with authority to act, a plausible-looking rule, and the absence of a runtime control that could catch the consequential decision as it was made. The agent did exactly what it was delegated to do. That is precisely the problem — and it is why the controls have to live at runtime, where the decision happens, not in a DPIA filed before the agent ever saw a real patient.

The takeaway

SUMMARY FOR DECISION-MAKERS An AI agent’s autonomy transfers no responsibility: it is a technical means, and the deploying organisation is, in the typical deployment, the controller — or at least accountable for determining the purposes and essential means of the processing — for the tools the agent calls and the data it touches, even the ones it reached without being told to, while the external model, automation and memory services act as processors or, in some configurations, independent controllers. Agents do not only process — they act, so where an agent’s action is a solely automated decision producing legal or similarly significant effects, with no meaningful human involvement, Article 22 GDPR is engaged (not every agent action meets that bar — effect and the absence of meaningful human review are what trigger it); and the AI Act’s high-risk deployer duties (Article 26(11), for high-risk systems that make or assist decisions about natural persons) sit on an agreed timetable (Annex III: 2 December 2027 under the Omnibus, subject to formal adoption). The agent’s persistent memory is, throughout, a record of processing subject to minimisation, retention, and erasure. The controls cannot live in a document signed before launch, because the agent rewrites its own plan mid-task; purpose limits, least-privilege tool access, egress filters, and a kill switch must be enforced at runtime — and the one question that governs all of it is: when the agent acted, who decided, and who can pull it back?

An agent’s autonomy is not a transfer of accountability. The system executes; the organisation is responsible — for the steps it watched and, more dangerously, for the steps it did not. “The agent did it” names the problem; it does not answer for it.

Agents move the question from processing to action. The moment a system decides and acts with effect on a person, the analysis is no longer only about data — it is about automated decision-making under the GDPR now, and about the AI Act’s high-risk deployer obligations as they phase in, on the same deployment.

Static controls collapse against a system that rewrites its own plan. The defence is not a thicker DPIA; it is governance that runs — bounded tool access, egress and geofencing filters, traceability per run, and a kill switch. Decide who can pull the agent back before you let it act, and the autonomy is an asset rather than an unallocated liability.

Glossary of abbreviations

Legal notice: This article serves general information purposes and does not constitute legal advice. For a legally sound assessment in a specific case, consultation with a specialised data protection lawyer is recommended. As of: June 2026.