The throughput number tells you whether oversight is real

There is one measurement that distinguishes oversight from its imitation, and almost nobody collects it: how many items each reviewer handles per hour.

The reason it works is arithmetic. Article 14(4) requires the reviewer to interpret the output correctly, stay alert to automation bias, and be able to decide to disregard or override. Those are cognitive acts with a floor on how long they take. If a case needs the file read, the model's recommendation understood, and an independent view formed, that is minutes. A reviewer clearing four hundred an hour is spending nine seconds each. Nine seconds is enough to click. It is not enough to disagree.

Why throughput is the giveaway

Documentation will not reveal a rubber stamp, because the documentation is usually accurate. The procedure says a qualified person reviews every decision. A qualified person does. The signature is genuine. Nothing in the paper record is false.

The override rate is a better signal but still ambiguous. A very low override rate can mean the model is excellent or that nobody is looking. You cannot tell from the rate alone.

Throughput resolves it, because it is a constraint rather than an outcome. If the time per case is below the time the task takes, the conclusion does not depend on anyone's honesty or on how good the model is. The review is not happening, whatever the record says.

The conditions that manufacture rubber-stamping

Nobody sets out to build this. It assembles itself from four ordinary management decisions.

• A throughput target set from the pre-AI baseline, then raised because AI was supposed to make things faster. The efficiency gain is booked in advance and taken out of review time.
• Defaults that make agreement free and disagreement expensive. Accept is one click; override opens a justification form. The friction is on the side the Act is trying to protect.
• Override treated as an exception to explain. If disagreeing with the model attracts a conversation and agreeing never does, the reviewer learns quickly.
• No feedback on outcomes. Reviewers who never learn which of their approvals turned out wrong have no way to calibrate, so they default to trusting the model. This is automation bias arriving through a management gap rather than a psychological failing.

Questions that surface it in twenty minutes

You do not need an audit to find this. Five questions will do it.

• How many cases does one reviewer handle in a shift, and how long is the shift?
• What proportion of recommendations were overridden last month, and can you see the trend since deployment?
• What happens, procedurally, when a reviewer overrides? Who sees it and what do they do?
• When was a reviewer last told the outcome of a case they approved?
• Is review time counted in the reviewer's performance measures, and in which direction?

If the answer to the first is a number in the hundreds and the answer to the fourth is "never", you have found it, and you have found it without accusing anyone of anything.

What to do with the finding

The fix is rarely more training. It is usually a change to the throughput target, the default action, or the incentive, because those are what created the behaviour. Training a reviewer to resist automation bias while paying them by volume is asking a person to absorb a design fault.

Where the volume genuinely cannot come down, the honest response is to stop describing the process as human oversight and to redesign it: sample-based deep review with a stated sampling rate, automatic escalation of low-confidence cases, or a narrower scope for automated handling. A defensible process that reviews ten per cent properly is better than an indefensible one that claims to review everything.

As of 24 September 2026.