General information, not legal advice. Data protection is fact-specific. Take advice from a qualified practitioner before processing personal data with AI, particularly special category data. Guidance in this area changes — check the ICO’s current position.
The question that matters is simple and often unanswered: when your agent processes a document containing personal data, where does that data physically go, who else can see it, and how long do they keep it?
If your supplier cannot answer that in one sentence, stop there.
Why agents raise the stakes
A chatbot that is wrong gives a bad answer. An agent reads your systems, makes decisions and takes actions. That means:
- It touches more data, because it decides what to look at
- It touches data nobody specified in advance, because the path varies
- It transmits data to a model provider, usually outside your infrastructure
- It acts on conclusions, so an error becomes an event rather than a bad answer
Each of those is a data protection consideration before it is a technical one.
Settle these before building
1. What is your lawful basis?
Under UK GDPR you need a lawful basis for processing personal data. For most business automation it is legitimate interests or contract.
Legitimate interests requires a balancing assessment — your interest against the individual’s rights. Document it. An agent reading customer emails to speed up responses is usually defensible; an agent profiling individuals to make decisions about them is a different question.
Write it down before the build. Retro-fitting a lawful basis after launch is how organisations end up switching systems off.
2. Where does the data physically go?
This is the question most people have not asked.
When an agent processes a document, the contents are typically sent to a model provider’s infrastructure. That may be in the UK, the EU, the US, or elsewhere.
Establish for your chosen provider:
- Which region the processing happens in, and whether you can pin it
- Whether a UK or EU data residency option exists
- What transfer mechanism covers any international transfer
- Whether the provider offers a Data Processing Agreement — you need one
Some providers offer UK or EU regional processing. Some do not. This should be a selection criterion, not a discovery.
3. Is your data used to train their models?
For most business and enterprise API tiers, the answer is no — but it varies by provider and by tier, and consumer tiers often differ from business ones.
Get it in writing in the DPA or terms, and check it applies to the specific tier you are on. A policy that applies to the enterprise plan does not help if your supplier wired the system to a consumer account.
4. How long is data retained?
Many providers retain inputs and outputs for a period for abuse monitoring — often around 30 days. Some offer zero-retention arrangements on certain tiers.
If you process sensitive data, zero retention may be a requirement rather than a preference. Ask specifically.
5. What can the agent actually reach?
Data minimisation is a UK GDPR principle and the single most effective control available to you.
An agent given broad database access will read broadly. An agent given a narrow, purpose-built view reads only what it needs.
Build the narrow view. Pass the three fields required, not the whole customer record. This reduces breach impact, reduces transmitted data, and is usually cheaper to run because less text is sent.
6. Are you making automated decisions about people?
Article 22 of UK GDPR gives individuals rights regarding decisions made solely by automated means that produce legal or similarly significant effects.
Agents making decisions about people — credit, employment, access to services, benefits — need careful handling: a human review route, a way to contest, and transparency about the logic.
Agents processing invoices, stock or logistics are usually well outside this.
Know which you are building. The difference is substantial.
Practical controls
| Control | What it does |
|---|---|
| Narrow data views | Agent sees only required fields. Biggest single risk reduction. |
| Redaction before transmission | Strip names, NI numbers, card details where the task does not need them |
| Pseudonymisation | Replace identifiers with tokens; reattach after processing |
| Regional processing | Pin to UK or EU where the provider supports it |
| Zero-retention tier | Where available and justified |
| Full audit logging | Every action, every record touched. Needed for accountability and for incident response |
| Authority boundaries | What the agent may never do, enforced in code |
| Retention policy | Logs and outputs deleted on schedule, not kept indefinitely |
Note that audit logs themselves contain personal data and need their own retention policy. This is routinely overlooked.
Your documentation obligations
If you process personal data with an AI agent, expect to need:
Record of Processing Activities (ROPA) — updated to include the agent, what it processes and who it is shared with.
Data Protection Impact Assessment (DPIA) — required where processing is likely to result in high risk. New technology processing personal data at scale frequently qualifies. If in doubt, do one — it is cheaper than the alternative and it surfaces design problems early.
Data Processing Agreement with your model provider, and with your development supplier if they handle live data.
Privacy notice updates — individuals should be able to understand that automated processing happens.
Legitimate interests assessment — if that is your basis.
Questions for your supplier
Ask all of these before signing. The answers vary enormously.
- “Which model provider, which region, and can we pin processing to the UK or EU?”
- “Is there a DPA, and does it cover our tier?”
- “Is our data used for training? Show me where it says so.”
- “What is the retention period, and is zero retention available?”
- “What data will the agent be able to access? Can we narrow it?”
- “Will personal data be redacted before transmission where possible?”
- “What is logged, where are logs stored, and for how long?”
- “If we need to delete an individual’s data, can you demonstrate it is gone — including from logs?”
That last one catches a lot of suppliers. Right to erasure applies to your agent’s logs too.
Questions your own team should answer
Before the supplier conversation, settle these internally. They are your accountability, not theirs.
Who is the controller? Almost certainly you. Your development firm and the model provider are processors. That means the obligations — lawful basis, DPIA, breach notification, responding to individuals’ requests — sit with you.
What is the retention period for the agent’s outputs? The decisions it records are themselves data about individuals in many cases. They need a retention schedule like anything else.
How will you handle a subject access request? Someone asks what data you hold about them. Can you include what the agent processed and what it decided? If the answer involves searching unstructured logs manually, design for it now.
How will you handle erasure? Right to erasure applies to the agent’s logs too. This catches most organisations, because logs are designed for debugging rather than for selective deletion.
Who reviews the agent’s decisions? Not technically — organisationally. Someone should be looking at a sample regularly, and that should be written down as a responsibility rather than assumed.
What is in your privacy notice? Individuals should be able to understand that automated processing takes place, in plain language.
Special category data
Health, biometric, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life or sexual orientation, and genetic data carry additional conditions under Article 9.
If your agent will touch any of it, take proper advice before building. The controls are stricter, a DPIA is near-certain, and a model provider’s standard terms may not be sufficient.
This is common in healthcare administration, HR and recruitment, and parts of insurance. It is not a reason to avoid AI — it is a reason to design for it from the start rather than discovering it in month four.
Vendor due diligence questions
For whichever model provider ends up underneath your system. Answers change, so check current documentation rather than relying on anything written here.
- Which regions can processing be pinned to? Is UK or EU residency available on the tier you will use?
- Is there a Data Processing Agreement, and does it cover your tier specifically?
- Is input or output used for training? Get the clause, and confirm it applies to your tier rather than to the enterprise plan generally.
- What is the retention period, and is a zero-retention option available?
- Who are their sub-processors, and are you notified of changes?
- What are their security certifications — ISO 27001, SOC 2 — and are the reports available?
- What happens to your data on termination, and how is deletion evidenced?
- What is their breach notification commitment, and does it fit inside your own 72-hour obligation?
The pattern worth noticing: consumer tiers and business tiers frequently differ on training and retention. A policy that applies to the enterprise plan does not protect you if your supplier wired the system to a consumer account. Ask which account the system actually uses.
What we do
Lawful basis established before build, documented, with a legitimate interests assessment where that is the basis.
Data minimisation by design — the agent gets a purpose-built view, not a database login.
Region pinned where the provider supports it, and you are told in writing where data is processed before anything is sent.
Redaction where the task permits — if the agent does not need the name to do the job, it does not receive the name.
Full audit logging with a retention policy that applies to the logs themselves.
DPIA support. We will not write your DPIA for you — that is your accountability — but we supply the technical detail it requires.
If your use case needs guarantees we cannot deliver with available providers, you will hear that before you commit, not after.
Doing a DPIA for an AI agent
A Data Protection Impact Assessment is a documented assessment of risk to individuals. For AI agents processing personal data it is frequently required, and where it is not required it is usually still the cheapest way to surface design problems early.
What it needs to cover:
1. The processing, described plainly. What the agent does, what personal data it touches, where that data comes from and where it goes — including the model provider and the region.
2. Necessity and proportionality. Why an agent rather than a narrower method. What data it genuinely needs, and what you have removed because it does not.
3. Risks to individuals. Specific, not generic. For an agent, the characteristic ones are: a wrong automated decision affecting someone; personal data transmitted to a third-party processor; data retained longer than intended in logs; and an action taken that nobody can reconstruct.
4. Mitigations, mapped to each risk. Narrow data views. Redaction before transmission. Regional processing. Confidence thresholds routing to a human. Audit logging. Retention schedules covering the logs. A kill switch.
5. Residual risk and sign-off. What remains after mitigation, and who accepted it.
Do it before the build, not after. A DPIA written after launch documents decisions rather than informing them, and the mitigations it identifies are far more expensive to retrofit.
When something goes wrong
Have this agreed before you need it.
Detection. Audit logs reviewed on a schedule, and alerting on anomalies — a spike in records accessed, actions outside normal patterns, an unusual volume of escalations.
Containment. The kill switch, operable by a non-technical person. Then revoke the agent’s credentials, which is why it should have its own rather than sharing a service account.
Assessment. What did it access, what did it change, whose data was involved. This is answerable only if you built the logging.
Notification. A personal data breach likely to result in a risk to individuals must be reported to the ICO without undue delay and within 72 hours of becoming aware. Know who makes that call before an incident.
Reversal. Which actions can be undone, and how. Agents performing irreversible actions should be the ones under the tightest boundaries.
Root cause. Was it the agent, the data, the boundaries or the instructions? Fix the class of problem, not the instance.
Frequently asked questions
Is using AI agents GDPR compliant?
It can be. Compliance depends on your lawful basis, where data is processed, what the agent can access, retention, and whether automated decisions about individuals are involved. It is a design decision, not a property of the technology.
Where does my data go when an AI agent processes it?
Typically to your model provider’s infrastructure, which may be in the UK, EU, US or elsewhere. Some providers offer regional pinning. Establish this before selecting a provider — it is a selection criterion.
Will my data be used to train AI models?
On most business and enterprise API tiers, no — but it varies by provider and tier, and consumer tiers often differ. Get it in writing and confirm it applies to the tier your system actually uses.
Do I need a DPIA for an AI agent?
Often yes. A DPIA is required where processing is likely to result in high risk, and new technology processing personal data at scale frequently qualifies. If uncertain, do one.
Can an AI agent make decisions about people?
With care. Article 22 gives individuals rights regarding solely automated decisions with legal or similarly significant effects. You need human review, a route to contest, and transparency. Agents handling invoices or stock are usually outside this entirely.
How do I minimise data protection risk?
Give the agent the narrowest possible data view, redact what the task does not need, pin processing regionally where possible, log everything, and set a retention policy covering the logs as well as the data.
What about special category data?
Health, biometric and similar data carry additional Article 9 conditions. Take proper advice before building, and expect a DPIA to be necessary.
Written by Jas Singh, Founder. Last updated 8 October 2026. General information, not legal advice. Data protection guidance changes — check the ICO’s current position and take advice on your specific circumstances.
