← Back to Lab

I asked an agent to book me flights to Lisbon last week. Nothing dramatic - just find the cheapest option, check it against my calendar, use my saved payment details. The whole thing took about forty seconds. I didn’t visit a website. I didn’t click “I accept cookies.” I barely looked up from my coffee.

And then it occurred to me, quite slowly, that my personal data (calendar entries, email content, financial information, travel preferences) had just flowed through at least four different organisations’ systems. Without any of the usual rituals we associate with consent. No checkboxes. No privacy banners. No moment where I, as a human being, actively decided to hand anything over.

Whose GDPR obligations just got triggered?

Everyone’s.

GDPR doesn’t care whether a human or a piece of software kicks off the processing of personal data. What matters is whether personal data belonging to an identifiable natural person is being processed. If the agent reads my email to extract a booking reference, that’s processing. If it sends my name and passport number to an airline, that’s a data transfer. If the airline stores that to build a profile of my travel habits, that’s a new processing purpose - one that needs its own lawful basis.

The agent is an extension of me. It acts on my behalf, with my authority, using my data. GDPR’s protections follow the data, not the mechanism. This isn’t a novel interpretation. It’s just the existing law applied to a new pattern. But the new pattern makes the existing law significantly harder to comply with, and I’m not convinced most of us have thought about that properly yet.

Luckily for me, the scenario above was a thought exercise and not reality - I’m not sure my family would be impressed by me flying to Lisbon by myself.

The ICO said the quiet part out loud

In January this year, the UK Information Commissioner’s Office published its Tech Futures report on agentic AI. Sixty-odd pages of careful regulatory thinking, and the headline is deceptively simple: organisations remain fully responsible for data protection compliance, regardless of how much autonomy they hand over to software.

The interesting bits are in the detail.

Purpose limitation, for instance. Under GDPR, we need a specific, defined purpose for processing personal data. But the whole point of a general-purpose agent is that it handles whatever you throw at it. The ICO explicitly warns against drafting broad purpose statements just because the system is open-ended. They want purposes defined at each processing stage — which is sensible in principle and nightmarish in practice when the software is deciding in real time which services and databases to reach for.

Then there’s data minimisation. An agent that can access everything is more useful than one that can’t. But the principle of least privilege, only grant access to data necessary for the defined task, is a core GDPR requirement. The ICO recommends letting users choose which services and data sources the agent can access. Which means the design of your permission model isn’t just a usability decision. It’s a compliance decision. I don’t think most teams are treating it as one.

Accuracy is where it gets properly thorny. When an agent fabricates a detail about a person (infers they’re a medical professional based on their browsing history, say) that inaccurate personal data is still personal data, and GDPR’s accuracy principle still applies. The ICO notes that fabricated information can cascade across services, databases, and other agents, compounding the problem. There are techniques to reduce fabrication, but they don’t eliminate it. The underlying mechanics remain.

And automated decision-making triggers enhanced obligations under Article 22. When an agent makes or contributes to a decision that has legal or similarly significant effects on an individual, the individual must be informed, must be able to contest the decision, and must have meaningful human intervention available. This is fine when the agent is recommending restaurants. It’s considerably less fine when it’s negotiating insurance terms on your behalf.

Now flip the perspective.

If you’ve been reading this blog you’ll know I’m fond of turning things around to stare at them from the other side.

That’s the individual’s side - my agent, acting on my behalf, carrying my rights with it. But what about the companies on the other end?

If your business deploys agents that interact with individuals (customer service, sales, financial advice, whatever) you are processing personal data. You are almost certainly a data controller. And every obligation that entails is yours to manage.

Here’s where I keep coming back to. Imagine two agents talking to each other. My personal agent contacts your company’s customer service agent. Mine provides my account details, purchase history, and complaint. Yours processes all of that, decides whether I’m eligible for a refund, and communicates the outcome back to mine. No human was involved at either end. But personal data was processed, a decision was made about an identifiable individual, and GDPR applied at every step. The rights of access, rectification, erasure, and objection all hold. The obligation to provide transparent information about processing holds. The requirement for a lawful basis holds.

And, this is the bit that gives compliance teams heartburn, if the two systems were exchanging data in a way that wasn’t directly observable to humans on either side, how exactly do we demonstrate accountability?

I think this is one of the harder open questions in data protection right now, and I haven’t seen a satisfying answer from anyone.

Who’s the controller?

The traditional GDPR model is relatively clean: a data controller determines the purposes and means of processing; a data processor acts on the controller’s instructions. You write a data processing agreement, everyone knows their role, the ICO has someone to hold accountable.

Autonomous agents muddy this considerably. If I deploy software that independently decides how to achieve a goal (choosing which data to access, which third-party services to call, which tools to use) then who determined the means of processing? The user who set the goal? The developer who built the system? The platform that hosts it? The third-party service that received the data?

The CNIL, France’s data protection authority, has been thinking about this. Their guidance is clear enough: if you determine the purpose of processing, you’re a controller; if you only process data on someone else’s instructions, you’re a processor. But autonomous agents sit in the messy middle where the “instructions” are a high-level goal and the software determines everything else.

I expect joint controller determinations to become much more common. And the associated agreements will be significantly more complex than anything most organisations have in place today. Whether we’re ready for that complexity is another question entirely.

What this means if we’re building things

The agent’s permission model is the GDPR compliance architecture. The choices we make about what data the software can access, which external services it can call, and what decisions it can make on its own - those aren’t just product decisions. They’re the technical implementation of purpose limitation and data minimisation. Design them accordingly. And if your team currently treats permissions as a UX concern to be figured out later, you might want to have a conversation with your DPO sooner rather than later.

System-to-system communication needs to be auditable. If two pieces of software are exchanging personal data without human observation, we need logging, traceability, and the ability to reconstruct what happened and why. This is table stakes for accountability under Article 5(2). It’s also the thing most early implementations quietly ignore, because it’s unglamorous work that slows down demos.

And DPIAs (Data Protection Impact Assessments) are no longer something we can defer. If the system processes personal data with significant autonomy, makes decisions that affect individuals, or introduces data flows that weren’t contemplated when we wrote our original privacy notices, the assessment needs to happen before deployment. The ICO’s report makes this expectation clear, even if enforcement is still catching up.

The bit that actually gives me hope

The ICO isn’t trying to kill this technology. Quite the opposite - they explicitly encourage innovation that supports data protection. They see opportunities for software that helps individuals manage their own personal data, assists with data subject access requests, even performs data protection officer functions. Privacy-enhancing tools are as much a possibility as privacy-violating ones.

The Digital Regulation Cooperation Forum has launched a Thematic Innovation Hub for this, bringing together the ICO, the CMA, the FCA, and Ofcom. A statutory code of practice on automated decision-making is expected this year. Guidance on profiling is being updated. The regulatory infrastructure is being built. Whether the engineering keeps pace… well, that depends on us.

Most companies building these systems aren’t thinking about GDPR at all. They’re thinking about capability, speed, cost, and user experience. Data protection is an afterthought - something legal will figure out before launch, bolted onto a system whose architecture has already been decided. That worked, barely, for traditional software. It doesn’t work for systems that autonomously decide what data to process, who to share it with, and what conclusions to draw.

GDPR was written before anyone had a clear picture of what autonomous software would look like. But the principles (lawful basis, purpose limitation, data minimisation, accuracy, accountability) are technology-agnostic for a reason. They apply to the processing, not the processor.

Your agent inherits your GDPR rights. Your company’s agent inherits your GDPR obligations. The regulation hasn’t changed. The architecture of the systems it applies to has. And that makes it a design problem, not a legal one - which means it’s ours to solve, not the lawyers’.

Whether we actually will is, I think, the question worth sitting with.