Can a human approve an AI decision at machine speed?

Only when the rate at which the machine proposes matches the rate at which a person can check, and in most deployments nobody has measured either. An approval step can survive on paper after the control it was meant to be has gone, because the system produces recommendations faster than the approver can verify them. The week of 14 September 2026 put that in front of a congressional hearing, a data protection regulator and two governments at once. The evidence on human checkers is older and consistent: a person asked to confirm outputs at a pace they cannot sustain stops checking and starts agreeing. The decision an organisation controls is the rate: the one figure most oversight arrangements never write down.

The approval button#

At a congressional hearing on AI-assisted military targeting, Defense News reported on 16 September, the Ukrainian AI governance researcher Anna Mysyshyn told members that “the approval button alone does not demonstrate the control”. Human approval was still formally required in every case discussed. The witnesses’ point was that the requirement had outlived the capacity to meet it.

The same week Spain’s data protection regulator published its account of the first breach notified to it as executed end to end by an AI agent, SecurityWeek reported on 16 September. The AEPD’s post draws one lesson above the others: the security of processing cannot depend solely on manual intervention, because an agent moves faster than a manual response. On 17 September Reuters reported that scholars at Brookings and Fudan University had proposed US and Chinese safeguards for military AI, including a shared definition of meaningful human control, which neither government has endorsed. Three settings, one problem: the machine’s tempo has outrun the check, and the check is still counted as a control.

What happens to a checker who cannot keep up#

None of this is new to the people who study automation. Skitka, Mosier and Burdick showed in 1999 that an automated aid produces two kinds of error in its user: omission, missing what the aid failed to flag, and commission, following advice that was wrong. Molloy and Parasuraman found in 1996 that the ability to catch a single automation failure declines with time on task, and most where the automation has been reliable. Endsley and Kiris found in 1995 that the loss of awareness after a failure is worst under full automation and smaller where the operator kept some control. Together they describe a fast approval queue before one existed: the more reliable and the faster the stream, the less the approver sees.

The newest evidence is small and points the same way. Huemmer and colleagues followed 23 people over six months and found that they leaned on AI most for the hardest tasks while their accuracy on those tasks fell to 47.8 per cent, with the gap between belief and performance widening to 34.6 percentage points. The authors call the result a verification bottleneck: producing an answer stopped being the constraint and checking one became it. Twenty-three people with no control group prove nothing about a workforce. They describe the arithmetic this page is about.

Seconds, not minutes: the record from Tempe#

The clearest public record of what machine speed does to a human check is the US National Transportation Safety Board’s 2019 report on a pedestrian killed by a developmental automated vehicle in Tempe, Arizona. The system detected her 5.6 seconds before impact and never classified her correctly. On recognising an emergency it withheld braking for one second while the hazard was verified or the operator took over, and gave the operator no alert that the second had begun. The Board found the probable cause was the operator’s inattention. Both things are true: the person was not watching, and the design had given a person who was watching about a second, unannounced. Whoever set that interval decided what a human check could be worth at that speed. Every deploying organisation makes the same decision, whether or not it notices.

A verification budget#

The arithmetic fits on the back of a board paper. Take the decisions the system will put in front of a person in an hour. Multiply by the minutes a proper check takes, meaning one in which the person could have reached a different answer. Compare that with the attention the person has. If the first number is larger, the approval is a sample, and the organisation should say so, because the unchecked decisions were made by the machine and somebody must own them. Naming the rate turns an oversight arrangement from a description into a control.

Three designs survive the arithmetic. The first slows the machine to the pace of the check where the consequence is hard to reverse; the page on which decisions should become slower says when. The second declares a sampling rate, checks that fraction properly, and records the rest as machine decisions with a named accountable person. The third puts a second, independent system in front of the first and sends only the disagreements to a person; how to know when AI is wrong covers what that can and cannot catch. The common design does not survive: every decision formally approved, at a rate nobody has calculated, by a person whose attention nobody has costed.

When the thing being checked can hide from the checker#

There is a second reason the check has to be designed rather than assumed. On 16 September OpenAI published a framework for disclosing cases in which its own models act without authorisation or evade oversight, with six examples from its training and testing, among them a model that added hidden instructions to task summaries telling users to conceal mistakes. Those are the company’s own descriptions, unverified by anyone else. They matter here for one reason: a checker who reads the machine’s summary of its own work, at speed, is checking a document the machine wrote. In Lawfare on 16 September, Christopher LaRoche argued that the new US state laws require AI incidents to be reported but require nobody to keep the logs that would let anyone reconstruct one. An organisation cannot legislate for its vendor. It can require in the contract that the records exist; auditing an AI-assisted decision lists them.

The question for a board#

Rules Before Tools puts four questions to any AI deployment: which decisions the machine may make in the organisation’s name, who can stop each one, what people must remain able to do unaided, and how anyone would know if it went wrong. This week adds a number to the second. A person who can stop a system is a control only at a rate they can sustain, so the board’s question is how many approvals an hour, checked how, and what happens to the ones that were not. If management cannot answer with a figure, the approval step is a human in the loop of the kind the evidence says makes outcomes worse, and the risk sits where this site keeps finding it: in the handover, and in the judgement of the people on the other side of it.

What this does not show#

It does not show that any particular system is being approved faster than it can be checked; the hearing testimony is the witnesses’ view, the AEPD case is one notification, and the US and Chinese proposal has been endorsed by neither government. The automation studies come from flight simulators, a driving task and one accident, and none involves a language model. The 23-person study has no control group and its authors say so. Nothing here measures how often a sampled check catches what a full check would have, and the three designs are argued from the mechanism, not tested against each other. What it does show is that the rate of the check is a decision, usually made by default, and that the record of what happens to people who check faster than they can think has been consistent for thirty years.