An approval click is not yet control. It may merely confirm that a person appeared at one point in the process. Whether that person can assess a recommendation, challenge it and actually stop an action is a different question.
I regard this distinction as fundamental. When an organisation introduces AI into decisions, it does not need a second loop everywhere, nor a rigid full review of every routine. It needs an effective right of challenge wherever a wrong recommendation would have tangible consequences. Otherwise, human oversight becomes a signature on a process that nobody can assess independently any longer.
The right of challenge, not mere presence
A reviewer is not a control function simply because their name appears in the approval log. They become one only when four things come together: they can understand the relevant facts from the original data; they know the decision criterion and the threshold at which a case may no longer proceed automatically; they may amend or halt the recommendation; and they can escalate a disputed decision to the responsible authority.
That sounds self-evident. In day-to-day work, however, at least one of those conditions is often missing. The reviewer sees only the AI's summarised reasoning. The necessary contract, customer or process data sits in another system. There is no time to reject the recommendation. Or the throughput KPI rewards fast approval more strongly than a reasoned challenge. In that case, the approval click is not a control point. It is an additional task without decision-making authority.
The evidence does not support easy reassurance. A 2024 meta-analysis in Nature Human Behaviour synthesised 106 experiments, whose original studies were published between 1 January 2020 and 30 June 2023. It compared the performance of humans working with AI against the better stand-alone condition, meaning either humans alone or AI alone. On average, the combination performed below that benchmark. The effect size is not a percentage. Nor does it mean that humans using AI always perform worse than humans without AI or that human oversight is worthless. It shows something more specific: simply combining two actors does not reliably produce superior performance. 1
For the organisation, this does not mean retreating from AI. It means asking a tougher question before approval: what must the reviewing person be able to assess for themselves before they see the recommendation?
The independent-challenge test
I would not tick this point off in a policy. I would test it on a specific, risk-relevant decision case in a safe exercise. Deliberately flawed recommendations must not trigger real customer actions. The test deliberately begins without an AI recommendation. The reviewer receives the original information, the expected decision criterion and sufficient time to form their own provisional assessment. Only then do they see the AI recommendation and its reasoning.
The test then establishes whether the reviewer detects a deliberately incorrect or incomplete recommendation. Can they substantiate the challenge with the available data? May they stop execution immediately? Do they know who decides when a conflict remains unresolved? And does the fallback actually work when the AI recommendation is not adopted?
Independence is decisive. In this exercise, the reviewer forms their assessment before the AI recommendation appears. This tests whether they could assess the case independently; it is a practical test method, not a universal rule for every live decision. An instruction to “review critically” is not enough. The sequence of the process must enable independent judgement. Rights on paper are not enough either. A reviewer who must obtain another approval before challenging a decision or who is pressured by approval rates, processing time and automation targets, has no practical right of challenge.
The NIST AI Risk Management Framework is a useful but voluntary reference framework for this purpose. It is neither a binding legal requirement nor a certification. NIST recommends clear roles, accountable leadership, differentiated human oversight, testing and monitoring in operation and safe ways to intervene, amend or stop. In practical terms, this means that the depth of control must match the potential harm and that the reviewer needs competence, information, time and decision-making authority. 2
For a minor, reversible routine, sampling may be sufficient. For a decision that is difficult to reverse, has significant customer consequences or constitutes an exception to the standard, an independent challenge step is appropriate. This is not solely a technology question. It is an organisational decision.
The first step
First, I would select one AI-supported decision process where an error would genuinely have consequences and where an approval is already in place. I would not revise the entire catalogue of controls. I would not begin with a new governance committee.
For that one process, a short, specific definition is enough at first: which original data must the reviewer see? Which decision do they form before the AI recommendation? Which deviation requires a halt? Who decides an escalation? Which manual or rules-based fallback applies? And which KPI must not penalise challenge?
This is followed by a documented test case. The result should not be “approval granted”. It should answer whether an incorrect recommendation could be identified, rejected with reasons, stopped and then processed properly. If any one of these actions is missing, the control is not yet operational.
An approval click can be part of good control. It is not proof of it.