Give the person a layered explanation built around what they need to act on: the reason for the outcome, who is responsible, what data was used, how fairness and accuracy are checked, and what the decision means for them. These are the ICO's explanation types; for agents, each must come from verifiable records, not the model's narrative.
What does the ICO expect?
UK GDPR requires processing to be fair and transparent and, for significant automated decisions, requires meaningful information about the logic, significance and consequences, plus safeguards. The ICO's guidance on explaining decisions made with AI turns those duties into practice. It describes six types of explanation, in substance:
- Rationale: the reasons that led to the decision, in accessible terms.
- Responsibility: who is involved in developing, managing and running the system, and who to contact for a human review.
- Data: what data was used and how, including the person's own data.
- Fairness: the steps taken to make decisions unbiased and fair.
- Safety and performance: the steps taken to maximise accuracy, reliability, security and robustness of the system.
- Impact: the effect the system and its decisions have on the individual and wider society.
The guidance also separates process-based explanations, showing that you followed good governance, from outcome-based explanations, about this person's decision. People generally need both.
Who does it apply to?
Controllers making or supporting decisions about people with AI under UK GDPR. The legal duty is strongest for solely automated significant decisions, covered in ICO and automated decision-making by AI agents. But the ICO expects explanations wherever AI materially shapes an outcome a person cares about, including decisions a person signs off with an agent's help.
What is hard about explaining an agent's decision?
Each explanation type has a specific difficulty when the system is an agent.
| Explanation type | Agent difficulty | What to use instead |
|---|---|---|
| Rationale | The agent's written reasoning may not reflect what actually drove the output | The facts used, the criteria in the brief and the limits that applied |
| Responsibility | Platform, model provider and firm all play a part | The firm as accountable party; a named team for review |
| Data | Agents retrieve different data per case | A per-case list of facts and their sources |
| Fairness | Language outputs are harder to test for bias than scores | Outcome testing across groups on real cases |
| Safety and performance | Accuracy varies by task | Per-capability test results, with the date last tested |
| Impact | Agents can act, not just recommend | What happened as a result and how to undo it |
The rationale row matters most. If you give a person the model's narrative as the reason, and that narrative is wrong or incomplete, you have given a misleading explanation. Build it from what you can show. A reason such as "your stated income could not be matched to the payslip you provided" is checkable; "the model assessed your profile as higher risk" is not.
How do you produce an explanation the ICO would accept?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Rationale explanation | Per-decision record of facts, sources, criteria and limits; translated into a plain message | Decision records; message templates |
| Responsibility explanation | Each decision communication names the team and the route to a person | Templates; routing records |
| Data explanation | Customer can request the facts used about them | Fulfilled requests |
| Fairness explanation | Process summary of fairness testing for each decision capability | Testing reports; public summary |
| Safety and performance | Summary of how the agent is tested and certified | Certification records |
| Impact explanation | Message states what changes for the person and their options | Templates |
| Layered delivery | Short reason first, detail on request, full process summary published | Communication design records |
| Tested for understanding | Explanations reviewed with people outside the firm | Review notes |
Layering is what makes this workable, because no single message can carry all six types without losing the reader. The first layer, delivered with the decision, should be a few sentences: the outcome, the main reason, what the person can do. The second layer, on request, gives the data used and how to correct it. The third, published, explains the process: how the agent is governed, tested and overseen.
Some decisions must be explained carefully because full disclosure would cause harm. A sanctions match cannot be fully explained to the person without tipping off. Our article on sanctions hits and explaining a match without clearing it covers that tension.
What will the ICO ask?
- What do people receive when an agent contributes to a decision about them?
- Where does the stated reason come from, and how do you know it is accurate?
- Can a person find out what data about them was used?
- Who outside the firm has tested whether the explanations make sense?
- How do people reach someone who can review the decision?
- Does your published material describe how agents are tested and overseen?
What does the guidance not cover?
It does not require disclosure of model internals or trade secrets. It does not override legal limits on disclosure, such as anti-tipping-off rules. It is guidance on good practice and on how the ICO reads the law; the legal duties themselves come from UK GDPR. For the wider set of ICO expectations, see ICO expectations for AI agents processing personal data; for where agent decisions tip into the automated category, see automated decisions under GDPR: where agents cross the line. For the full map, see 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
Should the explanation mention that an AI agent was involved?
Yes, where the agent materially shaped the outcome. People are entitled to know how decisions about them are made, and hiding the agent's role undermines the responsibility explanation.
How long should a first-layer explanation be?
A few sentences. State the outcome, the main reason in plain words, and how to get it reviewed. More detail belongs in the next layer.
Who should write the explanation templates?
The team that owns the decision, with compliance and a plain-language reviewer. Test them with people who have never seen your products, and revise when they misunderstand.