A UK DPIA for an AI agent should assess each capability separately: what data it uses, where the data goes, whether a less intrusive design would do, what could harm people, and which measures reduce it. The ICO will look for an assessment specific to the agent, done before deployment, with measures that were actually built and a trigger for review.
What does UK GDPR require of a DPIA?
Article 35 of UK GDPR requires a data protection impact assessment before processing that is likely to result in a high risk to people's rights and freedoms. In substance, a DPIA must contain:
- a systematic description of the processing and its purposes;
- an assessment of whether the processing is necessary and proportionate;
- an assessment of the risks to individuals;
- the measures envisaged to address those risks and show compliance.
The controller must seek the advice of its data protection officer where it has one. If a DPIA shows a high risk that cannot be reduced, the controller must consult the ICO before starting. The ICO publishes a list of processing types that require a DPIA, including uses of innovative technology combined with other risk factors and processing that decides access to services. For the EU equivalent, see GDPR Article 35 DPIA for agents.
Who does it apply to?
Controllers under UK GDPR. The firm deploying the agent is the controller, so the DPIA is its responsibility. A vendor may provide information to help, but cannot complete the assessment for you, because the risks depend on your data, your customers and your configuration. To decide whether one is needed at all, see how to run DPIA screening for new processing with an agent; for most agents that touch customer data, the answer is yes.
How should the DPIA handle an agent?
A DPIA written for "the AI system" as a whole will be too vague to help. Write it around the agent's capabilities.
Describe each capability. What the agent does, which data it reads, which systems it changes, who is affected, and how the data flows, including to the model provider and any processing outside the UK.
Test necessity per capability. Could the purpose be met with less data, or with less authority? An agent that drafts for a person may achieve the purpose with lower risk than one that acts alone. Recording why you chose the level of authority you did is the agent-specific heart of proportionality.
List risks specific to agents. The standard DPIA risks apply, but agents add their own:
- retrieval that pulls in more data than the task needs;
- actions taken on inaccurate or manipulated inputs;
- disclosure to the wrong person through tools or shared context;
- significant decisions without meaningful human involvement;
- handling of vulnerability and special category information;
- transfers of prompts and logs to a model provider abroad;
- long retention of conversation histories.
Record measures and residual risk. For each risk, the measure, who implements it, and what risk remains. Measures should be concrete: "retrieval limited to the authenticated customer's billing records", not "appropriate access controls".
Set review triggers. A new capability, a new data source, a model provider change, a change in who is affected, or an incident.
Take an illustrative case. A UK building society plans an agent to help members update their mortgage details and answer arrears questions. The DPIA separates three capabilities: answering questions, updating contact details, and arranging payment plans. For payment plans, it records that the agent will draft and a colleague will approve, because the risk to members in difficulty is high and drafting meets the purpose. It identifies vulnerability disclosures as the main special category risk and requires the agent to route them to a specialist. It records the model provider's processing location and the transfer mechanism. The DPO's advice is attached, and the DPIA names three review triggers.
What is the ICO likely to look for?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Systematic description | Capability-level description of data, systems and flows | DPIA description section; data flow diagram |
| Necessity and proportionality | Reasoned choice of data and authority level per capability | Proportionality analysis |
| Risks to individuals | Agent-specific risk list with likelihood and severity | Risk register in the DPIA |
| Measures | Concrete measures with owners, implemented before go-live | Measures table; implementation evidence |
| DPO advice | DPO consulted and advice recorded | DPO advice note |
| Views of people affected | Customer or colleague input where appropriate | Consultation notes |
| Prior consultation | ICO consulted where high residual risk remains | Consultation record |
| Review | Triggers defined and reviews recorded | Review log |
A ready structure is in our DPIA template for an AI agent.
What will the ICO ask?
- When was the DPIA completed, relative to deployment?
- Does it describe what this agent actually does, capability by capability?
- Why did you give the agent the authority it has, rather than less?
- Were the measures implemented, and how do you know?
- When was it last reviewed, and what triggered the review?
What does the DPIA not cover?
It assesses data protection risk; it does not settle conduct or prudential questions, though combining assessments saves effort. It does not make processing lawful on its own. It is not a one-off document. For firms running the same agent in the EU, the EU AI Act may require a separate fundamental rights impact assessment for certain uses; see how AI rules differ between the UK and EU. For the UK regime overall, see what UK GDPR requires of AI agents, and for the full map, our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Can one DPIA cover several agents?
Yes, if they process similar data in similar ways with similar risks. Agents with different capabilities, data or affected people usually need their own assessment, or at least their own sections.
Should the DPIA be updated when the model provider changes the model?
Review it. The data flows may be unchanged, but behaviour can shift, and if the provider's processing location or terms change, the transfer analysis needs updating.
Can the vendor's DPIA be reused?
As an input. A vendor can describe its processing and safeguards, but your DPIA must assess your processing, with your data, customers and configuration.