Automated decisions after the Data (Use and Access) Act

Since 5 February 2026, UK GDPR Articles 22A to 22D have allowed significant decisions made solely by automated processing on most lawful bases, where the old Article 22 confined them to three narrow exceptions. Special category data and the new recognised legitimate interest basis stay restricted. Every such decision needs four safeguards: information about the decision, a chance to make representations, human intervention and a route to contest it.

Under the amended UK GDPR, a decision is solely automated when there is no meaningful human involvement in taking it, and significant when it has a legal or similarly significant effect on the person it concerns. A significant decision with meaningful human involvement falls outside these articles, and so does an automated one that affects nobody much. The work is in knowing which of your decisions sit where.

What changed on 5 February 2026

In section 80, the Data (Use and Access) Act 2025 replaced Article 22 with four new articles, and SI 2026/82 brought them into force on 5 February 2026. Decisions taken before that date still sit under the old article.

The law has moved from a prohibition with exceptions to a permission with conditions, and meeting those conditions is engineering work. A company that used to avoid automated decisions by never quite making them can now make them openly, provided it builds the machinery around them.

Is the decision significant, and is a person meaningfully in it?

Significant means a legal effect or a similarly significant one: refusing someone credit, rejecting a job application, suspending an account. Article 22D lets the Secretary of State define "meaningful human involvement" and "similarly significant effect" further by regulations, and we found none made by late September 2026.

The most detailed reading of "meaningful" is the regulator's draft guidance from March 2026. It says the person reviewing should look at each decision before it is applied, and be able to influence the outcome and have the authority to change it. They should understand the system well enough to know when it is wrong, and take the relevant information into account. Ad hoc spot-checking does not count, because some decisions never get checked. Neither does having designed the system (ICO draft guidance, March 2026).

That rules out a familiar arrangement: a person who approves a batch of the model's outputs at the end of each day without the power or the time to disagree. On paper there is a human in the loop. On the draft's reading, the decisions are still solely automated. It is the line compliance work draws between reading and deciding, applied to decisions about people.

The draft adds one line that turns into an engineering requirement: organisations should keep a record of how the human was involved. Plenty of products have no such record, because nobody designed the review to leave one.

Which decisions are still restricted?

Two kinds of significant, solely automated decision remain restricted under Article 22B.

The first involves special category data: health, ethnic origin, religious belief, trade union membership, biometrics and the rest of the Article 9 list. A decision based on it, even partly, may be solely automated only if it rests entirely on data the person explicitly consented to. The other route needs a contract or a legal requirement, and a substantial public interest condition. If your product decides things about people from health data, the relaxation largely passed you by, and the UK GDPR questions for AI and client health data come first.

The second is new. The same Act inserted Article 6(1)(ea), a lawful basis called recognised legitimate interest, and Article 22B(4) forbids significant solely automated decisions that rely on it wholly or partly. Ordinary legitimate interests under Article 6(1)(f) are not barred. The trap is choosing the new basis for its convenience elsewhere in the product and finding it has ruled out automating the decision that mattered.

The four safeguards, as things you build

Article 22C(2) requires safeguards for every significant solely automated decision, whatever the lawful basis. The law names outcomes, and your product has to supply the mechanisms.

The complaints duty makes the last row harder to skip. Since 19 June 2026 every controller has had to make it easy to raise data protection complaints and acknowledge them within 30 days (Data (Use and Access) Act 2025, section 103).

We would add a fifth item the article does not name: a record of each automated decision and of every human review of one. Without it you cannot show which decisions were solely automated, which is the question everything else depends on.

Human review that counts

On a healthcare platform we build, one planned AI feature turns an intake form into a suggested appointment type and an urgency, to help a practice order its waiting list. We designed it as ranked suggestions a person accepts or overrides, never a single verdict, and every override is recorded. It has not shipped, and when it does it ships switched off.

The ranking is the design decision. A single answer invites a click, and a reviewer clicking "accept" on every item is the kind of involvement the draft guidance says does not count. A ranked list puts the alternatives in front of the person and asks them to choose, so overriding the software becomes an ordinary act instead of a confrontation.

The override record is the evidence. A log of who reviewed which suggestion, what they chose and when is the record the draft guidance asks for, produced as a side effect of doing the job. It also answers the awkward follow-up. If nobody ever overrides anything, either the suggestions are excellent or the review has become a rubber stamp, and only the log can tell you which.

We worked that feature out on paper, safeguards included, before writing any of it. Our AI governance work with clients always starts there, with a list of every decision the product makes about a person.

Automating a default, and what the record keeps

On the same platform, sessions whose end time has passed are marked attended automatically, and that automation deliberately writes nothing to the activity history. The reasoning was that attendance is the default, so only exceptions earn a line. It was a fair call for attendance, which is not a significant decision about anyone. Apply the same shortcut to a decision about someone's credit, job or account and you have deleted the evidence the safeguards depend on.

The same work settled a second rule. A state that software sets by itself needs a route back out, one a person can use without calling an engineer. For a significant decision that route is the human intervention safeguard, and it has to exist on the day the automation ships rather than after the first complaint.

Protecting the record is cheap. On that platform the activity history is append-only because the endpoints to edit or delete an entry were never built. One trade-off there does not transfer. Activity logging is fire-and-forget, so a logging failure can never fail somebody's real work. For an override record we would choose the other way and write it in the same transaction as the decision, because a review nobody can prove happened cannot be told apart from no review. That rule belongs in code, as every real guardrail does, where nobody can skip it.

Build now, while the final guidance is drafted

The detail is still being written. The regulator's final guidance on automated decisions is due in winter 2026 (ICO plans, September 2026). Regulations in force since 12 May 2026 require the regulator to prepare a statutory code of practice on AI and automated decisions, which does not exist yet (SI 2026/425). That regulator is now the Information Commission, which took over from the Information Commissioner on 30 September 2026, with existing guidance and consultations carried over (SI 2026/1015).

Waiting for the final text is a poor reason to delay, because the four safeguards are in the Act rather than the guidance. List every decision your product makes about a person, and mark which are significant and which have a person meaningfully in them. File the result with the records you already keep for each AI system, beside the system it belongs to. If the same decisions reach people in the EU, recruitment and creditworthiness are among the uses the AI Act treats as high-risk from 2 December 2027, and the Annex III walk-through settles whether yours are.

Questions about the new rules

Does a person in the loop take us outside these rules?

Only if their involvement is meaningful. On the regulator's draft reading, the reviewer must see each decision before it applies, be able and authorised to change it, and understand the system well enough to disagree with it. Spot-checking a sample does not count, and neither does having built the system.

Do we still need consent for automated decisions?

Usually not, unless special category data is involved. Since 5 February 2026 a significant solely automated decision can rest on any lawful basis except recognised legitimate interest. With special category data you need explicit consent, or a contract or legal requirement plus a substantial public interest condition.

Does this apply to AI tools we buy rather than build?

Yes. The duties sit with the controller making the decision, whoever wrote the software. If a bought tool decides something significant about a person with no meaningful human involvement, the safeguards are yours to provide. Ask the vendor how its output becomes a decision, and write the answer down.

Which regulator enforces this now?

The Information Commission, the regulator since 30 September 2026, when it replaced the Information Commissioner and inherited its guidance and consultations. Its final guidance is due in winter 2026, and a statutory code of practice on AI and automated decisions is being prepared.