What meaningful human involvement now has to mean
An approval button records assent. It does not evidence involvement. Where a decision is about a person, section 80 of the Data (Use and Access) Act has made that difference a legal one. Everywhere else it is now the standard you will be measured against anyway.
What were the answers to the previous five questions?
1. Since 5 February 2026, what does UK law say makes a decision "solely automated"?
Section 80 of the Data (Use and Access) Act 2025 provides that a decision is based solely on automated processing where there is no meaningful human involvement in the taking of it. It replaced Article 22 of the UK GDPR and moved the framework from prohibition towards a risk based model with mandatory safeguards.
2. What four attributes does a human reviewer need before their involvement counts as meaningful?
ICO draft guidance names three: competence to understand the subject and the system, authority to alter or reject the output, and discretion that is genuinely exercised rather than nominal. Construction work makes a fourth essential: access to the reasoning and the sources. The test is whether the person can exercise real influence before the decision is applied.
3. What is automation bias, and what organisational conditions make it worse?
The tendency to give an output excessive credibility because a system produced it. It worsens when leadership visibly trusts the tool, when overrides require justification but acceptance does not, when review time is squeezed, and when the reviewer cannot see how the conclusion was reached.
4. "A competent person reviews it" is not a control. What would a written control have to specify before a reviewer at five o clock on a Friday knows exactly what to look at?
Seven things, and their point is specificity rather than completeness. What the AI does with no human step, what it may only recommend, the exact evidence a human must check, the judgement a human must make, the role authorised to make it, the triggers that force escalation, and what is kept. "Check it is right" satisfies none of those, which is why it is not a control.
5. Why should a firm log overrides as carefully as it logs approvals?
Because an override is the only signal that tells you where the system is wrong. A high override rate on one flag type means the rule is wrong, the knowledge is stale, or the process differs from the written policy. All three are worth knowing and none of them appear in an approval log.
What changed in law, and does it reach construction?
It reaches construction, though not by the route the statute itself takes. Section 80 bites on significant decisions about individuals involving personal data, so a great deal of construction work sits outside its direct scope. Reading it narrowly would still be a mistake.
The reason is that Parliament has now put a statutory test around the thing every AI governance framework leans on. A decision is solely automated where there is no meaningful human involvement in taking it. Note what was not done: the Act does not define meaningful human involvement, and Article 22D reserves that meaning to regulations the Secretary of State has power to make and has not yet made. What exists in the meantime is the draft ICO guidance, which is the clearest available statement of what a UK regulator considers oversight to be. It has no legal force over a commercial or technical decision, and it is still a sound working test to borrow for one: a firm that cannot meet it on a Red use case should assume the use case would not survive scrutiny.
The ICO position is unusually direct: involvement must be active and not a token gesture, and the test is whether a person can exercise real influence over the decision before it is applied, with the authority, discretion and competence to alter it. Reviewers should be trained to understand the system's logic, outputs, limitations and risks (ICO draft guidance, 2026).
What does the matrix actually contain?
Seven fields, completed for every Amber and Red entry in the register. This is the mechanism; everything else supports it.
| Field | What it captures | Worked example: contract clause analysis (Amber) |
|---|---|---|
| AI can | What happens automatically, with no human step first | Search the contract, identify clauses matching a query, summarise them, flag internal inconsistencies |
| AI may recommend | What it can propose for a human to consider | A position on how a clause should be interpreted, based on the wording and the document |
| Human must verify | The specific evidence that must be checked | That the cited clause number and wording match the signed contract, not a draft or superseded version, and that amendments have not been conflated with base terms |
| Human must decide | What can never be delegated | Whether the interpretation is correct and what commercial position to take |
| Authorised role | Who is competent and authorised | Senior QS or commercial manager. Not assistant or graduate level, however confident the output reads |
| Escalate when | Specific triggers, not "use judgement" | Exposure exceeds the set threshold, clauses conflict with no clear resolution, or the interpretation touches a live dispute |
| Record | What evidence is kept | The output, the reviewer's sign off, and one line on what was actually checked |
The value is in the third and fourth rows. "Human must verify: the output is accurate" is not a control, because it does not tell a tired reviewer at five o'clock what to look at. "Confirm the cited clause matches the signed and amended contract" does.
How does the gate fit into the flow of work?
It sits between the flag and the action, and it is chosen by the consequence of the decision rather than by whoever happens to be at the screen.
Two design decisions in that diagram do most of the work. The first is that the authority engine is deterministic. Whether someone is permitted to approve a given decision is a rules question with a correct answer, and answering it probabilistically is an unforced error.
The second is that the checker is not the drafter. If the same model both produces the analysis and confirms it is sound, the second step adds confidence without adding assurance. AI cannot mark its own homework, and where the consequence is high, the challenge function should sit on a different model family and a different prompt lineage.
Why do overrides matter more than approvals?
Because approvals tell you the system was used and overrides tell you where it is wrong.
ICO guidance on AI and data protection is explicit that human reviewers must have the authority to override the output and be confident they will not be penalised for doing so, and that policy and training alone cannot create that confidence: a supportive culture is also required. Its draft guidance on automated decisions adds that you should keep a record of how each review was carried out, and monitor the outcomes. In a construction business the culture half is the hard part. If every override triggers a conversation about why the expensive platform was ignored, the path of least resistance becomes acceptance, and automation bias becomes company policy.
Handled well, the override record becomes the most useful dataset the firm owns. A planner who overrides a criticality flag because finishing on Friday determines Monday mobilisation, which the programme does not model, has told you something true about either the programme or the rule. Either way the system improves, and the person who spotted it should be the one who gets the credit.
Practical rule: make the reason field mandatory, keep it free text, and read it monthly. See operational AI versus chatbots and instruction to be agreed for why recorded reasoning matters commercially as well as legally.
You now have classification and control. What you do not yet have is a clear picture of what you are controlling against, because most firms are watching for the wrong failure. part 7, construction AI does not usually fail by inventing things sets out the eight that actually happen.
What five questions should you be able to answer now?
Attempt these before tomorrow. Each has a defensible answer, and each is answered at the top of the next part.
- Why is "check for hallucination" the wrong instruction to give a construction team?
- In what three ways can an AI output be entirely factual and still wrong on a live project?
- Who in a construction business is best placed to catch a context failure, and why is it not the IT department?
- How would you test an AI system for the superseded document failure mode before deploying it?
- What should "human must verify" say for a use case involving contractual terminology?
Which sources is this part built on?
Every figure quoted above resolves to one of these. Each was checked before publication.
- Data (Use and Access) Act 2025, section 80
- ICO, consultation on draft guidance about automated decision-making, including profiling
- ICO, Guidance on AI and data protection: ensuring individual rights in AI systems
- RICS, Responsible use of artificial intelligence in surveying practice, 1st edition
- UK Government, AI Playbook for the UK Government