UK GDPR Article 22 automated decision-making is now board shorthand for the DUAA regime in Articles 22A to 22D: significant solely automated decisions are wider permitted, but controllers need a lawful basis, safeguards, special-category limits, review routes and evidence.
The live legal hook is precise. Section 80 of the Data (Use and Access) Act 2025 substituted the old Article 22 with a new Section 4A of the UK GDPR, Articles 22A to 22D. S.I. 2026/82 brought section 80 fully into force on 5 February 2026, with a saving provision for decisions taken before that date. The ICO's DUAA summary for organisations says the change opens more lawful bases for significant automated decisions, subject to safeguards, but not for special category data in the same way.
That is the shift a board needs to understand. The old mental model was close to "do not make a solely automated significant decision unless an exception applies." The current model asks a harder governance question: which decisions are significant, which are solely automated, which data categories are involved, what lawful basis is relied on, and what evidence proves the person can understand, challenge and obtain human intervention?
Key takeaways
- Article 22A defines a solely automated decision as one with no meaningful human involvement, and a significant decision as one with a legal or similarly significant effect on a person.
- Article 22C requires safeguards for significant solely automated decisions: information, representations, human intervention and contestability.
- The ICO's current draft ADM guidance says it uses ADM as shorthand for Article 22A decisions and the Article 22A to 22D provisions.
- The ICO's consultation page says the consultation closed on 29 May 2026 and was marked closed on 16 June 2026, so boards should date any reliance on the draft wording until final guidance is published.
- A board-level control set should start with a decision inventory, lawful-basis record, special-category screen, DPIA trigger assessment, human review route and evidence of outcomes.
UK GDPR Article 22 automated decision-making now means safeguards
Article 22A does two pieces of scoping work. It says a decision is based solely on automated processing where there is no meaningful human involvement in the taking of the decision. It also says a decision is significant if it produces a legal effect, or a similarly significant effect, for the data subject. When judging meaningful human involvement, Article 22A says the extent of profiling must be considered.
That definition is where many AI projects fall into the wrong risk bucket. A model that only drafts a recommendation for a trained officer, with authority and time to reject it, is different from a workflow where the officer merely presses approve after the system has already decided. The board should ask for evidence of the human's real authority, the information they see, the time they have, and whether overrides are recorded. For a technical pattern that enforces boundaries at system level, see our guide to read-only AI database access.
Article 22B is narrower but sharper. It restricts significant decisions based solely on automated processing where the decision is based entirely or partly on special category data. The conditions are explicit consent, or a contract or legal-authorisation route tied to Article 9(2)(g). The same section also blocks reliance on the recognised legitimate interests lawful basis in Article 6(1)(ea) for these decisions. The ICO's lawfulness guidance for ADM separates that from ordinary legitimate interests, which may still be relevant where the three-part test is met.
Article 22C is the operating burden. It requires safeguards where a significant decision is based solely on automated processing and personal data. The ICO's ADM safeguards guidance turns the legal text into practical expectations: decision-specific information, a way to make representations, human intervention with a possible changed outcome, and a route to contest the decision.
Who is in scope and what the board decides
This applies to a UK controller when an AI or other automated system uses personal data to take a significant decision about a person, and that decision has no meaningful human involvement. It is not limited to generative AI. A rules engine, profiling model, scoring system, fraud tool, triage model or vendor workflow can all be in scope if the legal tests are met.
The board does not need to approve every model parameter. It does need to decide the governance frame before the system goes live:
- Which automated or AI-assisted decisions are capable of producing legal or similarly significant effects?
- Which of those decisions are solely automated, and what evidence proves meaningful human involvement where management says they are not?
- Which lawful basis under Article 6 is being used, and is the recognised legitimate interests basis excluded for significant solely automated decisions?
- Does any stage involve special category data, including inferred data? The ICO's special-category ADM guidance says inferred information can count where the controller intends to infer or treat someone differently because of a protected category.
- What information, representation, intervention and contest routes will the affected person receive at the decision point?
- Which owner reports the review metrics to the board, and how often?
Put differently: Article 22 is no longer a clause for the privacy team to read after procurement. It is a decision-rights question. The board approves the categories of decisions the organisation will allow machines to take, and the evidence threshold for allowing them.
Controls and evidence for the board pack
The board pack should not ask directors to infer compliance from a privacy notice. It should show the control and the evidence. The table below is deliberately practical; it can sit inside an AI risk register or an approval paper. For the broader register pattern, see our guide to living AI risk evidence.
| Control | Evidence the board should see | Owner |
|---|---|---|
| Decision inventory | List of automated and AI-assisted decisions, with the affected group, decision effect, system owner and vendor where relevant | Data protection officer or risk owner |
| Article 22A scoping | Record showing whether each decision is significant and whether meaningful human involvement exists | System owner with DPO sign-off |
| Lawful basis and necessity | Article 6 basis, necessity rationale, legitimate interests assessment where used, and note that recognised legitimate interests is excluded for ADM | DPO or legal |
| Special-category screen | Assessment of explicit special category data and inferred special category data, with Article 9 and Article 22B condition where applicable | DPO |
| DPIA and risk assessment | DPIA decision, risk findings, mitigations, residual risk and approval date | DPO and executive owner |
| Safeguards route | Decision notice or user communication, representation channel, human-intervention workflow and contest route | Operations owner |
| Human review quality | Reviewer training record, decision review log, override rate, reasons for changed outcomes and unresolved appeal count | Operations owner with board assurance |
| Assurance cadence | Date of last management review, open actions, incidents, complaints and changes to the model or data | Board committee or risk committee |
The evidence matters because the ICO's draft guidance is procedural, not decorative. It expects the person to understand the decision about their own case, know how to make representations, obtain a human review that can change the outcome, and contest the decision. A route that exists only in a policy but is absent from the product, letter, portal or call-centre script will not hold.
Framework mapping for Article 22A to 22D
The Article 22A to 22D regime sits inside a wider AI governance system. That matters because the same evidence can satisfy more than one frame if it is designed properly. Our AI governance framework guide uses the same principle: connect policy, controls, evidence and assurance.
| Framework | What it asks for | Board artefact |
|---|---|---|
| UK GDPR Articles 22A to 22D | Scope significant solely automated decisions, restrict special-category uses, and run safeguards for information, representations, human intervention and contestability | ADM inventory, DPIA, lawful-basis record, safeguard workflow, review log |
| ICO draft ADM guidance | Apply the ADM provisions in practice, including decision-specific information, non-token human intervention and records of review | Decision notice, reviewer authority matrix, intervention outcomes, appeal metrics |
| ISO/IEC 42001 | The UKAS AI accreditation page describes ISO/IEC 42001 as the AIMS certification standard for establishing, implementing, maintaining and improving an AI management system | AIMS scope, roles, risk and impact assessment, Statement of Applicability, management review |
| NIST AI RMF | NIST describes the AI RMF Core as four functions: Govern, Map, Measure and Manage | Govern: policy owner; Map: decision context; Measure: bias, error and appeal metrics; Manage: mitigations and acceptance decisions |
| UK regulator principles | The government's AI regulation response confirms five cross-sector principles, including accountability, transparency, fairness and contestability | Principle-to-control map in the board paper, with named owners and dated evidence |
The mapping changes the board discussion. Directors do not need a separate Article 22 pack, ISO pack, NIST pack and UK-principles pack. They need one evidence set, indexed to each obligation. The same human-review log supports Article 22C contestability, the NIST Manage function, ISO management review and the UK contestability principle.
Common mistakes and the next step
The first mistake is treating human-in-the-loop as a job title. If the person cannot change the outcome, does not see the material factors, or is pressured to approve the system's result, the evidence for meaningful involvement is weak. The control is not "a human is present." The control is authority, information, time and a recorded decision.
The second mistake is missing inferred special category data. A model may not receive a field called health, ethnicity or trade union membership, but the ICO's special-category guidance says inferred information can still matter where the controller intends to infer or act on that category. Boards should ask for the inference analysis, not just the schema.
The third mistake is relying on a vendor's assurance pack without testing the organisation's own decision route. The controller still owns the Article 22A scoping, lawful basis, DPIA and safeguards in its own context. Supplier documentation helps, but it does not prove the person affected can understand, challenge and obtain human intervention from your organisation.
The fourth mistake is letting the regulatory wording go stale. The ICO's draft ADM pages were updated on 31 March 2026 to reflect the DUAA and the consultation was closed on 29 May 2026. Until final guidance lands, board papers should state which version of the guidance they used and which assumptions need review.
The next step is to baseline the decision inventory. If you do not yet know which AI systems influence decisions about people, start with the Board AI Scorecard. If you have known ADM exposure and need the controls mapped, the AI governance diagnostic turns the legal tests above into a board-ready evidence plan. For examples of controls built into systems rather than written after the fact, see our trust page, services and case studies.
Last reviewed: 18 June 2026.
Sources: Data (Use and Access) Act 2025 section 80 · S.I. 2026/82 regulation 2 · ICO DUAA summary for organisations · ICO consultation on draft ADM guidance · ICO draft ADM guidance · ICO ADM lawfulness guidance · ICO ADM safeguards guidance · ICO special-category ADM guidance · UK government AI regulation response · NIST AI Risk Management Framework · UKAS artificial intelligence accreditation
