Anyone can contest an automated decision, in any channel, and a trained person looks at it afresh with the model's inputs and reasons in front of them. Reviewers can and do overturn, overturn rates and response times are tracked, explanations are in plain English, and decisions involving special category data are never solely automated.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
A broadband and mobile provider makes hundreds of thousands of decisions a month without a person: whether a customer can take a handset on a credit agreement, what spend cap applies, and whether a new order is held for a fraud or identity check. Most are right. Some are wrong, because the credit file is out of date, the address didn't match, or the model has never seen someone like this customer.
Since 5 February 2026, the Data (Use and Access) Act 2025 has replaced the old Article 22 with new UK GDPR Articles 22A to 22D. Solely automated significant decisions are now allowed in many more cases, but only with safeguards: telling people about the decision, letting them make representations, letting them get a person to step in, and letting them contest it. A decision is solely automated when there is no meaningful human involvement, so a reviewer who just clicks 'confirm' doesn't count.
Today, those safeguards exist on paper. A customer who disagrees phones the contact centre, writes to the complaints team or replies to an email, and each route works differently. Reviewers see the same red flag the model raised and rarely change it. Nobody can say how many decisions were contested last month, how quickly they were answered, or how often the model was wrong.
The stricter limit still applies where special category data is involved. A customer who explains that a health condition caused missed payments, or who mentions a disability when asking for help, has just put special category data into the process. From that point, the decision must not be solely automated unless one of the narrow conditions applies, and in this design it is always made by a person.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Share of reviewed decisions changed, by decision type and reason. Near zero suggests reviews are a rubber stamp; very high means the model or its data is wrong.
ExampleTracked monthly; any sharp change investigated
From the person's request to a reference and an expected date.
ExampleSame working day
From request to the person being told the outcome.
ExampleWithin 10 working days for most cases
A weekly sample re-reviewed by a second reviewer who doesn't see the first outcome. Low agreement shows where guidance is unclear.
ExampleAgreement reviewed weekly, disagreements discussed
Requests to contest spotted later in complaints, calls or chats that were never routed. Each one is a gap in recognition.
ExampleFalling every month
Decisions involving special category data made without a person.
ExampleZero
Cross-sector rules are on the UK regulation map.
A decision is based solely on automated processing when there's no meaningful human involvement, and the extent to which profiling was used counts when judging that. A significant decision is one with a legal or similarly significant effect, such as refusing a credit agreement or blocking an order. So the design treats these decisions as significant, and makes sure a reviewer's involvement is real: they see the evidence, have the authority to change the outcome, and use it.
A significant decision based wholly or partly on special category data can't be solely automated unless the person gave explicit consent, or the decision is needed for a contract or required or authorised by law and the substantial public interest condition applies. Solely automated significant decisions also can't rely on the new recognised legitimate interests basis. In this design, any case touching special category data is decided by a person.
Where a significant decision is solely automated, the controller must tell the person about it, let them make representations, let them obtain human intervention, and let them contest the decision. One route covers all four, in every channel, and every step is logged.
The government can make regulations saying when there is or isn't meaningful human involvement, which decisions are or aren't significant, and adding to the safeguards. None had been made when we checked. Keep the rules about which decisions go to review as configuration, so new regulations mean a settings change.
The ICO consulted on draft automated decision-making guidance from 31 March to 29 May 2026; it is still a draft. Regulations in force since 12 May 2026 require a statutory code of practice on AI and automated decisions, and the ICO's call for evidence on AI agents, open until 20 November 2026, will inform it. Design against the draft now.
Organisations must make it easy to complain about how they use personal data, acknowledge a complaint within 30 days, investigate and tell the person the outcome. Someone contesting a decision is often complaining too. Both use the same intake, one reference and both clocks, and the review answer also closes the complaint properly.
Since 8 April 2026, customers can take an unresolved complaint to alternative dispute resolution after six weeks. A contested decision that becomes a complaint needs an answer well inside that, and the letter tells the customer about their right to go to the scheme.
The review route itself must be accessible, with reasonable adjustments such as a phone call instead of a form. Overturn rates and outcomes are compared across the groups you can measure, to catch a model that treats one group worse.
Handset credit agreements are regulated credit, so the Duty's expectations on fair value, customer understanding and support apply to those decisions and their reviews too.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Intake: forms, email, calls and chatA review form in the app and on the web, plus recognition in every other channel. People shouldn't have to use the right words. | API Gateway, Amazon SES, S3 | API Management, Logic Apps connectors, Blob Storage | Kong or your existing API gateway; your mail server; Ceph |
| Recognising contestsFlags messages that contest a decision, ask for a person or contain special category data. When unsure it routes to the queue, never away from it. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Decision recordFor every automated decision: the inputs, the model version, the reasons and the outcome, stored when the decision is made. A review is only as good as this record. | Amazon S3 with Object Lock | Blob Storage with immutable storage | Ceph with S3 Object Lock |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| Plain-English explanationsBoth clouds offer a choice of models, including Claude. Explanations are written only from reason codes and the reviewer's recorded reason. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Monitoring the safeguardsSageMaker Clarify and Model Monitor closed to new customers on 30 July 2026, so the tests run in your own pipeline. Overturns are a labelled signal the model owners can use. | Amazon SageMaker AI pipelines with open-source tools (e.g. Evidently, Fairlearn) | Azure Machine Learning pipelines with open-source tools (e.g. Evidently, Fairlearn) | MLflow and Kubeflow on Kubernetes, with Evidently and Fairlearn |
| Review workflow and clocksTracks the review target, the 30-day complaint acknowledgement and the six-week dispute resolution point together. | AWS Step Functions | Logic Apps or Durable Functions | Temporal, or n8n |
| Reviewer permissionsOnly a trained reviewer can record a review decision; special category cases need the senior reviewer role. Enforced by the platform, not the prompt. | Amazon Verified Permissions, IAM Identity Center | Entra ID app roles | Keycloak, or your existing Active Directory |
| Human reviewReviewers work where complaints are already handled, not in a new screen. | In your existing case management tool | In your existing case management tool | In your existing case management tool |
| Middleware and events | Amazon EventBridge, SQS | Event Grid, Service Bus | Apache Kafka or RabbitMQ |
| GuardrailsBlock explanations that add reasons not in the record, or mention health, disability or other protected characteristics. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Identity, keys, data protection | KMS, Macie | Key Vault, Purview | OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog each request, what the reviewer saw, their decision, their reason and the answer sent. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK or EU provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
The decision engine, billing and the customer accounts system stay where they are, with the decision record next to the engine if that's where the data lives today.
Uses cloud AI
Recognising contests, preparing review packs and drafting explanations can run in a UK cloud region, or on your own GPUs with open-weight models. Only the fields a review needs are sent, with the account reference in place of the name where possible.
How they connect
A private link (AWS Direct Connect or Azure ExpressRoute) and the API layer. Each request and each review decision is an event on your queue, so the case tool and the decision engine stay in step.
If the link drops
Requests are still taken and logged with a reference, and the clocks keep running. Reviewers work cases by hand from the decision record, and packs are prepared for the backlog when the link returns.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Review preparation assistant
Where a person signs offA trained reviewer makes a fresh decision on every review and records their reason; special category and vulnerable cases go to a senior reviewer. The reviewer approves the answer before it is sent. The assistant's permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.
The decision engine has to write a full decision record at the moment it decides: inputs, model version, reasons and outcome. Without that, a reviewer can only guess what the model saw. This is often the biggest piece of integration work, and it should be done first.
Requests arrive as events from every channel and are matched to the decision by account and date. If a match is uncertain, a person links them. A request is never dropped because the match failed.
A review decision is written back to the decision engine and billing through the API layer as an override with its reason, so the customer's account changes once, and a retry never applies it twice.
If the AI is paused, requests still reach the queue through the form and the contact centre, and reviewers work them by hand. The safeguards don't depend on the AI.
List every automated decision and decide which are significant, check what the decision engine records today, map every channel where contests arrive, and measure today's volumes, times and overturns.
Gate · must be true to passDecision list agreed with legal and the DPO, decision record gaps known, DPIA updated, baseline measured.
One decision type, such as fraud holds on new orders: full decision records, one queue, review packs and plain-English answers, with reviewers deciding every case.
Gate · must be true to passEvery sampled contest recognised and routed, response times met, a blind re-review in place, and no special category case decided without a person.
Go live for the first decision type, with the monthly safeguards review, the complaint link and the dispute resolution clock.
Gate · must be true to passMonitoring, support model, rollback plan and reviewer training in place.
Add decision types one at a time, such as credit checks for handset agreements, then spend caps.
Gate · must be true to passEach new decision type passes the same pilot gate.
| Activity | Customer operations director | Product owner | Model owners | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | DPO & legal | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Which decisions are significant, and the review policy | Accountable | Consulted | Consulted | Consulted | Informed | Informed | Responsible | Informed |
| Decision record in the decision engine | Informed | Consulted | Responsible | Accountable | Consulted | Responsible | Consulted | Consulted |
| Target architecture | Informed | Consulted | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Consulted |
| Build and integration | Informed | Consulted | Consulted | Accountable | Responsible | Responsible | Informed | Consulted |
| Reviewer training and authority | Accountable | Responsible | Consulted | Informed | Consulted | Informed | Consulted | Informed |
| Monthly safeguards review | Accountable | Consulted | Responsible | Consulted | Informed | Consulted | Responsible | Informed |
| Run, monitor and improve | Informed | Accountable | Consulted | Consulted | Responsible | Responsible | Consulted | Consulted |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the decision record in your decision engine, intake from every channel, the review queue and its clocks, the assistant and its limits, and the monitoring that shows the safeguards work. I'd report to your programme board and work closely with your DPO and legal team.
Option B
If your partner or your own team already has an architect, I'd take on the decision record, the integration with your decision engine and case tool, and the monitoring pipeline under their lead, and give them a second senior opinion on the rest.
Goes wrong
Reviewers see the model's verdict first, agree with it almost every time, and the review is a rubber stamp.
How the design avoids it
The person's account comes first, there's no suggested outcome, reviewers aren't measured on agreement, and a blind re-review checks the reviews.
Goes wrong
The decision engine never recorded the inputs, so the reviewer can't see what the model saw.
How the design avoids it
Fix the decision record before the pilot. A review isn't meaningful without it.
Goes wrong
A customer contests a decision in a chat or a complaint, and it never reaches review.
How the design avoids it
Recognition in every channel, uncertain cases sent to the queue, and a monthly sample of complaints and calls to find any that were missed.
Goes wrong
A customer mentions a health condition, and the case goes back through the same automated path.
How the design avoids it
Special category data routes to a senior reviewer, and the platform blocks a solely automated decision on that case.
Goes wrong
Overturns pile up, but nobody tells the model owners, so the same mistakes repeat.
How the design avoids it
A monthly safeguards review with the model owners, and a rule that a pattern of overturns triggers a fix.
Changes already announced or under way that affect this design. More in the UK horizon scan.
If agents take part in decisions about people, check that the safeguards cover the whole chain, not just the final step.
Design against the draft now: meaningful human involvement, information for people, and a route to contest every decision.
Keep decision records, review decisions, reasons and overturn reports in a form you could show the ICO.
Keep the lists of significant decisions and review rules as configuration, so new regulations mean a settings change.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
