Human Oversight

Human oversight is the ability of assigned, competent people to monitor an AI system while it is in use, interpret its output, and override, reverse or stop it. Under the EU AI Act, Article 14 makes it a design requirement for high-risk AI systems, and Article 26(2) requires deployers to assign it to people who have "the necessary competence, training and authority, as well as the necessary support."

Article 14(1) requires high-risk AI systems to be designed so that natural persons can oversee them effectively while they are in use. Article 14(4) lists what those people must be able to do, as appropriate and proportionate: understand the system's capacities and limitations and monitor its operation; remain aware of automation bias, the tendency to rely too much on the system's output; interpret the output correctly; decide not to use the system, or disregard, override or reverse its output; and intervene, or interrupt the system through a "stop" button or a similar procedure. Article 14(3) requires the oversight measures to be commensurate with the risks, the level of autonomy and the context of use. For remote biometric identification, Article 14(5) requires two qualified people to verify and confirm an identification before the deployer acts on it.

The labels human-in-the-loop, human-on-the-loop and human-in-command come from the High-Level Expert Group's 2019 Ethics Guidelines for Trustworthy AI. The AI Act does not use them. They remain useful shorthand for three designs: approval before each decision takes effect, live monitoring with the power to intervene, and authority over policy, sampling and exceptions.

For AI agents, oversight works best at the action. The agent proposes a step, a policy decides whether the step can proceed, needs approval or is blocked, and a named reviewer approves or rejects a held step with the facts the policy used in front of them. Record who reviewed, what they saw, what they decided, when, and why; that record shows the oversight took place. Match the intensity to the risk: low-impact steps can run under monitoring, and steps that move money or affect a person's rights wait for a decision.

Oversight also fails when a reviewer cannot tell why they are blocked. In an internal evaluation in our own development environment, a reviewer who had completed every required check found the approve and reject buttons disabled behind a plain "View only" label. The block was correct, because the reviewer was not in the required approver group, but nothing said so. The Decision Desk now states why a reviewer cannot act, including when the reviewer created the request.

Following Regulation (EU) 2026/1744, the high-risk requirements, Articles 14 and 26 included, apply from 2 December 2027 to systems listed in Annex III and from 2 August 2028 to systems covered by Annex I. In KLA, a require_approval outcome holds the agent's action as a Decision Request in the Decision Desk, and the decision is recorded with the reviewer and the time.