The question that actually blocks these projects
Not “can it work” — it can. The blocker is almost always the same: what is this thing allowed to decide on its own?
UK GDPR Article 22 gives people the right not to be subject to a decision based solely on automated processing where that decision produces legal effects or similarly significantly affects them. The phrase doing the work is solely. An agent that drafts, recommends, prepares or flags is not deciding. An agent that declines, cancels, prices or terminates without a person in the loop is.
That distinction is an architecture decision, not a policy one, and it is much cheaper to make at the start. We scope agents so that consequential actions have an approval step and routine ones do not, then write down which is which. The written plan from discovery names every action the agent can take unattended, which is the artefact your DPO actually needs and rarely gets.
Where the DPIA fits
The ICO expects a Data Protection Impact Assessment before high-risk processing, and its screening criteria catch a lot of what makes an agent useful: using innovative technology, processing at scale, combining datasets, and automated decision-making with significant effects. Assume you need one and be pleasantly surprised if you do not.
The useful sequencing is to run the DPIA against a scoped design rather than a vague intention. “We want an AI agent for customer service” cannot be assessed. “An agent reads inbound email, classifies it against six categories, drafts a reply from these four templates, and routes anything it scores below threshold to a human without replying” can be — and the assessment usually comes back fine, because the risky behaviours were designed out before anyone wrote them down.
We build the second kind of specification during discovery. It is the same document that makes the build estimable, so it is not extra work bolted on for compliance.
Where the data goes, and why that matters more for agents
Everything on our UK page about US processing applies here, and applies harder. An agent is a system that repeatedly sends your operational data to a model provider, which means the transfer question is not a one-time export — it is the runtime behaviour of the product.
Three things we do about that, in order of how much they help:
Reduce what crosses the boundary. Most agent tasks do not need a name, an email address or a full record. Resolve identifiers on your side, send the agent the shape of the problem, and map the answer back. This is usually a day of extra engineering and it removes entire categories of argument.
Choose the provider deliberately. Retention terms, training-use terms and regional processing options differ substantially between providers and between tiers of the same provider. This belongs in the scope document with a named decision, not in a default someone picked during a spike.
Log what the agent did, not what it saw. An audit trail that reconstructs every action, input hash and approval is what makes an incident investigable. An audit trail that stores the full prompt makes your log store a second copy of the personal data, with a longer retention period than the system it came from.
What this changes about the engagement
Very little about how we work, quite a lot about the order. UK engagements front-load the data-protection design into discovery rather than treating it as a pre-launch review, because a review at the end can only find problems, and by then they are expensive.
Contracting, currency and hours are the same as for any client and are set out on the UK page: quoted and invoiced in USD, contracted under Colorado law, with a UK-afternoon overlap that most engagements settle into. If UK or EU data residency is a hard requirement for the system we build you, that is a scoping input we can design to — say so on the first call.