DUAA and Automated Decision-Making: Re-Engineering Your Safeguards

The Data (Use and Access) Act did not hand you a licence to switch off your safeguards. It changed which safeguards you have to build, and rebuilt the test they answer to.

The headline read as a relaxation: the UK loosens the rules on automated decision-making. Plenty of people inside firms heard that as permission to automate more and govern less. That is the wrong read, and it is an expensive one. The Data (Use and Access) Act 2025 replaced the old Article 22 of the UK GDPR with a different mechanism entirely. The regime is not lighter. It is differently shaped, and the shape it now takes puts more weight on things most firms have never built properly: a decision log a regulator can inspect, a human-review route that actually reconsiders, and a contestation flow that leads somewhere. If you treat the change as an invitation to retire controls, you will fail an inspection you have not yet realised is coming.

What actually changed

The old Article 22 was a default prohibition. A decision producing a legal or similarly significant effect could not be taken solely by automated means unless you could stand up one of three narrow gateways: contractual necessity, explicit consent, or authorisation by law. The burden sat with the controller to justify the automation before switching it on.

Section 80 of the Act inverts that. It substitutes new Articles 22A to 22D and moves to a permission-plus-safeguards model. For ordinary personal data, a solely-automated significant decision is now permitted as a starting point, provided you implement the safeguards set out in Article 22C. The gateway logic is gone; the safeguards are the price of entry. These provisions commenced on 5 February 2026 under the Commencement No. 6 Regulations, so this is live law, not a proposal to prepare for.

Read that carefully. The old regime let a lot of firms avoid building safeguards at all, because they never relied on solely-automated decisions in the first place, or claimed they did not. The new regime assumes the decisions are happening and asks what you have wrapped around them. The obligation has moved from justifying the automation to evidencing the controls. That is more engineering, not less.

The load-bearing term nobody has pinned down

Article 22A says a decision is based solely on automated processing where there is no meaningful human involvement. That phrase is doing an enormous amount of work, and it is precisely the phrase that is not yet nailed down. Article 22D gives the Secretary of State a power to define it by regulation, and the ICO has consulted on draft guidance on automated decision-making and profiling, with final guidance expected later in 2026. Until that lands, the threshold that decides whether the Article 22C safeguards even apply is a matter of judgement.

For a technology function this is the single most important design question, because it determines classification. A caseworker who rubber-stamps a model’s output without the authority or information to overturn it is not meaningful involvement; a system where a human reviews, can access the underlying data, and routinely does reverse the outcome probably is. The distinction is architectural, not cosmetic. If your only defence against the rules is a human whose screen shows an approve button and nothing else, you have automation wearing a hi-vis jacket, and you should assume a supervisor will see through it. This is the same failure mode we have written about in the API decision your business is making without realising it: a consequential choice gets embedded in a system boundary and nobody registers that a decision was made at all.

Article 22C as an engineering specification

Strip the legal register away and Article 22C is a build sheet. It requires that the data subject be given information about decisions taken about them, be able to make representations, be able to obtain human intervention from the controller, and be able to contest the decision. Four requirements, each of which is a system, not a policy paragraph.

• Information means a durable, retrievable record that a specific decision was automated, when, on what inputs, and with what outcome. Not a privacy-notice sentence. A log entry per decision.
• Representations means a channel that accepts and stores what the individual says, tied to the decision it concerns.
• Human intervention means a review route where a person with authority and access reconsiders, and where the reconsideration is itself recorded.
• Contestation means the outcome of a challenge can change the original decision and leaves an audit trail showing it did.

Most firms have fragments of this. They have a model that emits a score, and somewhere a mailbox that receives complaints. What they rarely have is the connective tissue: a decision identifier that ties the log entry, the representation, the review and the eventual contest into one traceable record. That connective tissue is the deliverable. It is also the thing an inspector asks for first, because it is the only thing that proves the safeguards operate rather than merely exist.

The contract you should be able to produce on demand

The cleanest way to make the safeguards real is to define the decision log and the review-and-appeal route as an explicit contract, so every automated decision writes a record with a stable identifier and every challenge resolves against it. A minimal shape looks like this.

# ADM decision log + human-review/appeal contract (OpenAPI 3.1, abbreviated)
# British English throughout; illustrative, adapt to your estate.

components:
  schemas:
    DecisionRecord:
      type: object
      required: [decision_id, subject_ref, taken_at, solely_automated, outcome]
      properties:
        decision_id:      { type: string, format: uuid }   # stable, shared key
        subject_ref:      { type: string }                 # pseudonymised subject id
        taken_at:         { type: string, format: date-time }
        solely_automated: { type: boolean }                # Art 22A classification
        significant:      { type: boolean }                # legal/similar effect?
        special_category: { type: boolean }                # triggers Art 22B route
        model_ref:        { type: string }                 # model + version
        input_digest:     { type: string }                 # hash of inputs, not raw PII
        outcome:          { type: string, enum: [approved, declined, referred] }
        rationale_ref:    { type: string }                 # link to explanation record
    Challenge:
      type: object
      required: [decision_id, type, submitted_at]
      properties:
        decision_id: { type: string, format: uuid }
        type:        { type: string, enum: [representation, intervention, contest] }
        submitted_at:{ type: string, format: date-time }
        statement:   { type: string }                      # subject's representation
        reviewer_id: { type: string }                      # human with authority
        reconsidered_outcome: { type: string, enum: [upheld, overturned, varied] }
        resolved_at: { type: string, format: date-time }

paths:
  /decisions/{decision_id}:
    get:                     # Art 22C(a): information about the decision
      responses: { "200": { description: DecisionRecord } }
  /decisions/{decision_id}/challenge:
    post:                    # Art 22C(b)-(d): representation, intervention, contest
      requestBody: { $ref: '#/components/schemas/Challenge' }
      responses:
        "201": { description: Challenge logged; routed to human reviewer }
        "409": { description: No such decision_id }   # every decision must be logged

The point of writing it as a contract is not the tooling. It is that the contract forces the questions the regulation forces: is this decision solely automated, is it significant, does it touch special category data, and where is the human who can overturn it. If your systems cannot populate those fields, you do not yet meet Article 22C, whatever the policy says.

Special category data is the trap door

The relaxation does not reach everywhere. Article 22B keeps a near-prohibition for significant decisions taken solely by automated means on special category data, health, ethnicity, biometrics, political or religious data and the rest, permitting them only with explicit consent or where a substantial-public-interest or comparable legal basis applies. This is where firms that rushed to automate get caught. A creditworthiness or eligibility model that quietly ingests a proxy for health or ethnicity crosses into 22B territory without anyone deciding it should. Your special_category flag is not a nice-to-have field; it is the guard on the trap door.

The through-line here is one other jurisdictions are converging on from different directions. California’s forthcoming ADMT rules and Australia’s Privacy Act reform both push firms toward the same artefacts: a register of where automated decisions are made, transparency about them, and a route to human review. Build the DUAA safeguards as reusable machinery rather than a UK point-fix and most of that work transfers.

So map your automated decisions before you touch a line of policy. For each one, record whether it is solely automated, whether it is significant, and whether it reaches special category data, then wire the log, the review route and the contest so they share a key. The firms that read the DUAA as permission to relax are the ones who will discover, under inspection, that permission came with a build order attached.