There is a comfortable reading of Professor Ana Beduschi’s paper on agentic AI and data protection, and most of the coverage took it. The GDPR survives. Agents are tools, not legal persons. Nothing needs rewriting. All of that is true, and all of it misses what the finding costs a British business. Because on 5 February 2026, the UK rebuilt its rules on automated decision-making around a single test — whether a human was meaningfully involved — and the entire commercial case for agentic AI is that humans are not.
What the study actually says, and why the reassurance is the problem
Beduschi, a professor at the University of Exeter, published her analysis in Computer Law & Security Review; the University publicised it on 28 May. Her conclusion is deliberately unspectacular: “Agentic AI does not render the GDPR obsolete. But it does show why data protection cannot operate in isolation from broader questions of governance, accountability, and fundamental rights.”
On the question everyone asks first, she is unequivocal. “AI agents should not be treated as data controllers under the GDPR. They remain tools, albeit sophisticated ones, deployed by natural or legal persons.” No new legal category. No shifting of liability onto the software or its vendor. The organisation that switched the agent on owns the processing, in full.
That is the reassuring half. The other half is where the work is. Agents choose their own route — which methods to use, which sequence to run, which strategy to adapt to mid-task. Beduschi’s point is that this creates “complex accountability chains, making it harder to exercise and enforce data subject rights such as access, portability, and erasure”. The liability stays exactly where it was. The ability to discharge it does not.
Strategic Reality: The finding that agents are not controllers is not a lightening of your obligations. It is confirmation that autonomy you bought from a vendor produces compliance duties you cannot delegate back to them.
She frames the legal difficulty in a way that should worry anyone who has scoped an AI project around explainability: the challenge is “not only to explain a single output, but to understand and oversee an evolving process of action, adaptation, and decision-making”. Most enterprise AI governance built over the past three years was designed for the first job.
The UK collision nobody is pricing in
Here is what the study, written against the EU GDPR, does not address — and what makes it far more pointed in Britain than in Brussels.
Section 80 of the Data (Use and Access) Act 2025 removed Article 22 of the UK GDPR and put Articles 22A to 22D in its place. Those provisions came fully into force on 5 February 2026. The government’s own summary is candid about the direction: the Act “creates a more permissive framework under the UK GDPR for organisations to make decisions based solely on automated processing” where those decisions carry legal or similarly significant effects for the person concerned.
Permissive, but conditional. Article 22A sets the trigger: a decision counts as solely automated “if there is no meaningful human involvement in the taking of the decision”. Cross that line on a significant decision and Article 22C obliges you to build four safeguards — tell the person a decision was made, let them make representations, let them obtain human intervention, let them contest the outcome.
So Britain’s automated-decision regime now turns on a phrase. And nobody has defined it.
| The UK position, dated | Status |
|---|---|
| ICO publishes its agentic AI Tech Futures report | 8 January 2026 |
| Articles 22A–22D UK GDPR in force (SI 2026/82) | 5 February 2026 |
| Beduschi paper appears in Computer Law & Security Review vol 61 | July 2026 issue, online since May |
| ICO consultation on updated automated decision-making guidance | Promised for 2026, not yet opened |
| ICO guidance on agentic AI and UK GDPR compliance | Committed to, undated |
| Government call for evidence on data rules for AI closes | 9 September 2026 |
Article 22D reserves to the Secretary of State the power to specify, by regulations, when there is or is not meaningful human involvement. That power has not been used. Every UK organisation currently procuring an agentic system is therefore making a judgement about where the Article 22A threshold sits, in the knowledge that a minister can move it later by statutory instrument, and that the regulator’s guidance on the point has not arrived.
Critical Context: Deployments signed in 2026 will be assessed against a definition written in 2027. Build the audit trail now that would let you argue your case then, because reconstructing it afterwards from agent logs is not realistic.
The regulator got there first, and said the same thing
The ICO published its Tech Futures report on agentic AI on 8 January 2026, four months before the Exeter paper reached the press. Reading them together is the useful exercise, because they converge from opposite directions — one from doctrine, one from horizon-scanning — and land on an identical list of pressure points.
The ICO names eight novel risks. Four should be read as a procurement checklist rather than a research finding:
- working out who is controller and who is processor across the agentic supply chain
- purposes set too broadly, because open-ended tasks resist tight purpose limitation
- agents touching personal data beyond what the instruction actually required
- complexity that degrades transparency and makes information rights harder to exercise
The regulator is also blunt about where responsibility sits, in almost the same terms Beduschi uses: organisations stay responsible for data protection compliance of the agentic AI they develop, deploy or integrate. Its most practically useful line is about architecture — the specific design of an agentic system determines how the law applies to it and how easily people can exercise their rights. Systems with no clear purpose, wired into databases they do not need, with no way to monitor or halt activity, are named as the failure pattern.
That is a regulator describing default vendor configurations.
Reality Check: If your agent has broad database credentials because narrowing them was fiddly during the pilot, the ICO has already published the paragraph that will be quoted back at you.
Our analysis of the summer’s containment failures made the operational version of this argument: approval is not a control, and governance that ends at sign-off cannot see what an agent does at runtime. The data protection version is stricter still, because Article 22C safeguards are not aspirations. They are obligations owed to a named individual who can complain to the ICO.
The erasure problem is the one that breaks the model
Of everything in the study, one finding deserves separate treatment. Beduschi observes that erasure becomes harder to deliver once personal data has shaped how an agentic system decides and adapts, and describes the result as a gap between what the law requires and what the technology can do.
Consider what a right-to-erasure request means against a running agent. The record in the vector store is straightforward. But the agent may have used that person’s data to select an approach, form a preference, or adjust a strategy that now runs against other people. Deleting the source record does not unwind the adaptation. You can honour the request at the level of storage and still be unable to honour it at the level of effect.
The same shape defeats subject access and portability. An access request asks what personal data you hold and how it was used. For a multi-step agent, the honest answer involves a chain of decisions that was assembled at runtime and may never have been persisted anywhere a DPO can read.
Hidden Cost: Agentic deployments are usually costed on licences and integration. The recurring cost that gets missed is the decision-trace infrastructure needed to answer a data subject access request within one month — and it has to be designed in, because it cannot be retrofitted from logs that were never written.
| Who carries what | Exposure under the UK regime |
|---|---|
| Deploying organisation | Controller. Owns Article 22C safeguards, DPIA, and every rights request |
| Agent vendor | Usually processor. Contractual duties only; the ICO complaint lands on the deployer |
| DPO / compliance lead | Must evidence “meaningful human involvement” against an undefined standard |
| Data subject | Rights to information, representation, human intervention and contest — enforceable now |
| Board | Accountability under Article 5(2), which is not satisfied by a vendor assurance |
What to do before the definition arrives
Beduschi’s recommendation is the right organising principle, and it is a design instruction rather than a policy one: “As AI agents’ autonomy increases, safeguards should shift from embedded human involvement and intervention to more structured, system-level, ongoing oversight that can recalibrate and, if needed, stop autonomous processes.”
Read that as a ladder. The safeguard has to match the autonomy, and the two move in opposite directions.
Tier 1 — agent proposes, human commits. A person reviews and approves each action that touches personal data. Article 22A is not engaged, because the human involvement is real. Slow, and the correct starting point for anything affecting customers, employees or citizens.
Tier 2 — agent acts within a bounded remit. Scoped credentials, a defined purpose, an explicit list of permitted actions, and human review on exceptions. This is where the Article 22A judgement gets genuinely hard, and where your documentation has to be strongest.
Tier 3 — agent runs continuously. Human involvement is structural, not per-decision: live monitoring, anomaly detection, defined recalibration triggers, and a kill switch someone is accountable for pressing. Assume Article 22C applies and build the four safeguards as product features.
Priority actions, sequenced by where you actually are:
- Not yet deployed. Fix the purpose statement before anything else. An agent scoped to “assist with customer queries” has no defensible purpose limitation; one scoped to a named list of tasks against named data sources does. This is cheap now and expensive later.
- Piloting. Run the DPIA on the agent’s maximum capability, not its pilot configuration. Pilots are narrow because integration was incomplete, and the risk assessment should reflect what the system can reach once it is finished.
- In production. Test one erasure request and one access request end to end, with a stopwatch. Whatever that exercise reveals is your real compliance position; everything in the policy is a claim about it.
- Scaling across functions. Map controller and processor roles for every agent-to-agent handoff. Where one agent invokes another vendor’s service, establish which organisation determines the purpose of that processing before the first complaint forces the question.
Implementation Note: The single highest-value artefact is a decision trace that records what the agent did, which data it touched, and what a human could have seen at the time. It answers the access request, evidences the safeguard, and forms the audit trail for the Article 22A argument. One build, three obligations.
Four things that will not be in the vendor deck
Meaningful human involvement erodes without a decision to erode it. A human approver who signs off 400 agent actions a day is not meaningfully involved by month three, whatever the process document says. Article 22A(2) explicitly directs attention to how far the decision was reached by profiling. Measure approval rates and time-per-review; a 99% approval rate is evidence against you.
Purpose limitation is where agentic architecture and data protection law disagree most. The commercial appeal of a general-purpose agent is that you do not have to anticipate the task. The law requires you to specify the purpose in advance. There is no clever drafting that resolves this — only narrower agents, or accepted risk that someone has consciously signed.
Special category data arrives by inference, not collection. Article 22B keeps the tighter restriction on significant decisions involving special category data. An agent inferring health status from a browsing pattern or a support-ticket history has produced special category data you never chose to collect, and the restriction attaches to it anyway.
A permissive regime raises the evidential burden, it does not lower it. The DUAA made solely automated significant decisions lawful in more circumstances, but conditioned on safeguards you must demonstrate. Firms reading the reform as deregulation are budgeting for less compliance work at the exact moment their obligations became more evidential. The ICO’s own research on a statutory data sandbox is candid that flexibility only works where individual rights get equivalent protection by another route.
⚠️ Warning: Treating “more permissive” as “lower risk” is the most expensive misreading of the DUAA available. The Act moved the compliance burden from prohibition to proof.
The strategic takeaway
The study’s real contribution is not the reassurance that the GDPR holds. It is the demonstration that data protection law, on its own, cannot carry the weight organisations are about to put on it — and that the shortfall has to be met with governance, documented accountability, rights assessments and oversight that is designed for a process rather than an output.
For UK businesses, three things follow.
- Autonomy is a compliance decision, not a technical one. Every increment of agent independence is a step toward the Article 22A threshold and the obligations behind it. Price it that way in the business case.
- Build the evidence before the standard exists. Meaningful human involvement will be defined by the ICO, by the Secretary of State under Article 22D, or eventually by a tribunal. Organisations with a decision trace will argue from a position; organisations without one will settle.
- Design constrains law here. Both the academic and the regulator reached the same conclusion independently: what an agent can access, and whether anyone can stop it, determines your legal position more than any policy document does.
Before your next agentic deployment goes live:
- Purpose statement narrow enough to survive an ICO question
- DPIA run against maximum capability, not pilot scope
- Article 22A position documented, with reasoning
- The four Article 22C safeguards built, if the threshold is crossed
- Erasure and access requests tested end to end, with timings recorded
- Controller and processor roles mapped across every agent handoff
- A named person who can stop the agent, and a tested route for doing it
Take Action: The government’s call for evidence on how data regulation helps or hinders AI closes on 9 September 2026. If the meaningful-involvement threshold is the thing blocking your deployment, that consultation is the mechanism for saying so — and we covered what the call for evidence is asking for when it opened.
The organisations that will handle this well are not the ones waiting for the guidance. They are the ones deciding now, in writing, where they think the line sits — and building the record that lets them defend it.
Sources
Ana Beduschi, “Data protection in the era of agentic artificial intelligence”, Computer Law & Security Review, vol. 61 (2026), article 106342, doi:10.1016/j.clsr.2026.106342. Summarised by the University of Exeter in Agentic AI tests the limits of data protection law, study finds, written up by Kerra Maddern and published on 28 May 2026.
Statutory provisions quoted from section 80 of the Data (Use and Access) Act 2025 as published on legislation.gov.uk, brought fully into force on 5 February 2026 by SI 2026/82. Departmental summary from the government’s guidance on the Act’s data protection and privacy changes. Regulatory position from the ICO tech futures report on agentic AI, released on 8 January 2026.
Analysis by Resultsense. Related reading: what the agent breaches change about buying agentic AI and the ICO’s position on regulating AI labs.