Human Oversight Design Requirements for High-Risk AI (Article 14)

“Human oversight” is the phrase that shows up in every AI policy document and commits nobody to anything. Article 14 of the EU AI Act is unusual because it converts the phrase into a list of things a person must be able to do, which makes it a specification for an interface rather than a sentence for a governance charter.

What the article obliges, and of whom

Article 14(1) of Regulation (EU) 2024/1689 requires that high-risk AI systems be designed and developed — including with appropriate human-machine interface tools — so that they can be effectively overseen by natural persons during the period in which they are in use. The obligation lands on the provider, at design time, and it is about the system’s capabilities. It is not discharged by writing a policy that says a human will review the output.

Article 14(2) states the purpose: preventing or minimising risks to health, safety or fundamental rights that may emerge when the system is used in accordance with its intended purpose or under conditions of reasonably foreseeable misuse. That second limb matters more than it looks. Oversight has to survive the wrong-but-predictable use of the system, not only the use described in the brochure.

Article 14(3) then splits the work in two. Oversight measures are either built into the system by the provider before it is placed on the market, where that is technically feasible, or identified by the provider as appropriate for the deployer to implement. Both routes are the provider’s responsibility to decide and to document; only the second hands execution to somebody else. In practice this is the clause that makes the instructions for use load-bearing, because a measure the provider expects the deployer to implement exists nowhere else. Article 13(3)(d) requires those human-oversight measures to be spelled out in the instructions, and Article 26(2) requires the deployer to assign oversight to natural persons who have the necessary competence, training and authority, plus the necessary support.

The primary text is on EUR-Lex, Regulation (EU) 2024/1689, published in the Official Journal on 12 July 2024. For which systems the obligation applies to and from when, see the risk tiers and the phase-in timeline.

The five capabilities in Article 14(4)

This is the operative paragraph and it is short enough to be worth reading in the original. It says the oversight measures shall be commensurate with the risks, the level of autonomy and the context of use, and shall enable the person to whom oversight is assigned to do the following:

• (a) Understand and monitor. Properly understand the relevant capacities and limitations of the system and duly monitor its operation, including in order to detect and address anomalies, dysfunctions and unexpected performance. Note that the standard is about capacities and limitations: an interface that shows what the system did but not where it is known to be unreliable does not satisfy this.
• (b) Remain aware of automation bias. Remain aware of the possible tendency to automatically rely or over-rely on the output, in particular where the system produces information or recommendations for a decision to be taken by a natural person.
• (c) Correctly interpret the output. Taking into account, for example, the interpretation tools and methods available. The example is doing work: the drafters expect there to be interpretation tooling, not just a number.
• (d) Decide not to use it, or override it. Decide in any particular situation not to use the system, or to otherwise disregard, override or reverse its output. Override is not the same as reverse; a system that lets an operator refuse a recommendation but has already actioned it does not give both.
• (e) Intervene or stop. Intervene in the operation of the system or interrupt it through a stop button or a similar procedure that allows the system to come to a halt in a safe state. The safe-state qualifier is the design requirement here: a kill switch that leaves the process in an undefined condition is not the thing the article describes.

Summaries usually render this as four verbs — understand, monitor, interpret, intervene. That is a serviceable mnemonic and it loses point (b) entirely, which is the one capability that is about the human rather than about the machine, and the hardest to evidence.

Point (b): automation bias is a design problem

Automation bias is the documented tendency of people supervising an automated system to accept its output because it is the system’s output. Article 14(4)(b) does not ask the provider to educate the operator out of it; it asks that the oversight measures enable the person to remain aware of it. That is an interface and training-material obligation with a small number of practical expressions, and they are the ones a reviewer will look for:

• Showing the system’s confidence or uncertainty alongside the output rather than only the output, so “the system said so” is not the same signal every time.
• Surfacing the known failure modes from the technical documentation at the moment of use, not only in a manual the operator read at onboarding.
• Not defaulting the human action to the system’s recommendation. A pre-selected “accept” is a design choice that measures agreement rate rather than review.
• Recording the override rate and reviewing it. An oversight process in which the human never disagrees is evidence about the process, and it is exactly the evidence a market surveillance authority can ask for under Article 74.

None of that is spelled out in the article. It is what the article’s requirement looks like once you accept that the obligation is to make effective oversight possible, and that effectiveness is observable.

The four-eyes rule for biometric identification

Article 14(5) adds a specific rule for one Annex III category. For high-risk systems referred to in point 1(a) of Annex III — remote biometric identification — no action or decision may be taken by the deployer on the basis of the identification unless it has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority. This is the only place in the Act that puts a headcount on oversight.

It also carries an exception that is easy to read past. The two-person requirement does not apply where Union or national law considers its application disproportionate, for systems used for the purposes of law enforcement, migration, border control or asylum. So the strongest oversight rule in the Act is disapplied in the contexts where the consequences of misidentification are most severe, if a Member State legislates for that. Whether Member States will use that latitude, and how narrowly, is unresolved and will be visible in national implementing law rather than in the Regulation.

The neighbouring rules are covered separately: what Annex III(1) covers and the Article 5 exceptions for real-time identification.

What this means at design time

Read as a build checklist rather than a principle, Article 14 asks four concrete questions of a product design, and the answers belong in the technical documentation under Article 11 well before a conformity assessment.

First, who is the overseer, and what do they see? The article speaks of “the natural persons to whom human oversight is assigned”, which presumes a defined role rather than whoever happens to be looking at the screen. Second, at what moment can they act? A capability to override that exists only after the output has been delivered to the affected person is a capability to apologise. Third, what does the stop bring the system to? Answering that requires knowing what state the system holds, which is a systems-design question rather than a compliance one. Fourth, how would anyone show, a year later, that oversight happened? Article 12 logging and Article 26(5) log retention are what make the answer to that question something other than an assertion.

The recurring failure is treating Article 14 as satisfied by the existence of a human. The article never uses the phrase “human in the loop”. It describes capabilities, and a person who cannot interpret the output, cannot see the limitations, and cannot halt the system safely is in the loop and is not oversight.