Art 14: human oversight by design
Lesson 4 of 6 in Inside the High-Risk Rulebook: Arts 8–15 Article by Article.
Art 14 is where the autonomy-spectrum lesson from Foundations becomes hard law. High-risk systems must be designed — including with appropriate human–machine interface tools — so that natural persons can effectively oversee them during use, with the aim of preventing or minimising risks to health, safety and fundamental rights. Three design decisions follow.
Oversight is a product feature, not a staffing promise. The measures must be commensurate with the risks, the level of autonomy, and the context of use — and Art 14(3) splits delivery into two channels: measures the provider builds into the system where technically feasible, and measures the provider identifies for the deployer to implement. The provider cannot simply write ‘ensure a human reviews outputs’ and walk away; it must design the interface that makes such review possible, and Art 13 must tell the deployer exactly how.
Oversight has a capability checklist. Art 14(4) enumerates what the overseeing humans must be enabled to do, as appropriate and proportionate:
(a) Understand capacities and limits — and spot anomalies
Properly understand the system’s relevant capacities and limitations and monitor its operation, including to detect and address anomalies, dysfunctions and unexpected performance. An overseer who does not know the model’s known failure modes cannot recognise one happening — this links straight back to the Art 13 instructions and forward to Art 26’s deployer training duty.
(b) Remain aware of automation bias
The statute names the psychology: overseers must remain aware of the tendency to automatically rely or over-rely on the output — automation bias — particularly for systems providing recommendations for human decisions. A law that cites a cognitive-science finding is telling you where enforcement will look: at approval rates and review times, not at org charts.
(c) Correctly interpret the output
Correctly interpret the output, taking into account, for example, the interpretation tools and methods available. A confidence score without a calibration explanation, or a saliency map nobody was trained to read, fails this limb — interpretation support is part of the product.
(d) Decide not to use, disregard, override, or reverse
The overseer must be able to decide not to use the system in a particular situation, or to disregard, override or reverse its output. Note the last verb: reverse implies outputs must remain reversible long enough for a human to act — an architectural constraint on how downstream automation is wired.
(e) Intervene or interrupt — the stop button
Intervene in the operation or interrupt the system through a “stop” button or similar procedure that lets it halt in a safe state. For physical systems, ‘safe state’ does real work: cutting power to a robot mid-motion is a stop, not a safe stop.
Why single out RBI for four-eyes verification? Because a face-match error operationalises instantly — an arrest, a removal, a denied crossing — and the base-rate arithmetic of 1:many search means even a 99.5%-accurate system searching large databases produces a stream of confident false matches. The wrongful arrests of Robert Williams and Porcha Woodruff in Detroit, both flowing from unverified face-recognition hits, are the case studies the drafters had on the table. Two independent, competent, authorised humans are the statutory answer — with the oversight quality bar of Art 14(4) applying to both of them.
Key terms: human oversight, automation bias, stop button, remote biometric identification
Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.