Human-in-the-Loop: A Practice Term, Mapped to Article 14
Human-in-the-loop, on-the-loop and in-command explained, mapped to the EU AI Act Article 14 human-oversight requirement for high-risk AI. A practice term.
"Human-in-the-loop" describes a design where a person is embedded in an AI system's decision cycle and a human acts on, or signs off, each individual output before it takes effect. It is a practice term from the AI-engineering and governance world — useful shorthand, but not a phrase the EU AI Act uses. The Act's binding requirement is human oversight under Article 14, which applies to high-risk AI systems. If you are reaching for "human-in-the-loop" to describe a compliance control, the statutory anchor you actually need is Article 14.
The value of the term is that it sits on a spectrum — human-in-the-loop, human-on-the-loop, human-in-command — that helps you reason about how much human control a given system needs. The Act doesn't prescribe which point on that spectrum to pick; it requires that whatever oversight you design is effective and proportionate to the risk.
The three oversight postures
These three terms are governance vocabulary, not statutory categories. They describe escalating degrees of human control:
| Posture | What it means | Typical fit |
|---|---|---|
| Human-in-the-loop | A human reviews and acts on each output before it has effect; the system cannot complete the decision alone | Individual high-stakes decisions — a loan denial, a flagged medical image, a recruitment rejection |
| Human-on-the-loop | The system operates autonomously, but a human monitors it and can intervene, override or stop it | High-throughput settings where per-item review is impractical but supervision and a kill-switch are essential |
| Human-in-command | A human retains overall authority over whether, when and how the system is used — strategic control over the system's role, not individual outputs | The governance layer above any specific decision; sets the conditions under which the system may run at all |
These are not mutually exclusive: a well-governed deployment usually has human-in-command at the top (the organisation decides the system may be used at all and under what limits), with either in-the-loop or on-the-loop operating at the decision layer, chosen by how much risk each decision carries.
How they map to Article 14
Article 14 requires that high-risk AI systems be designed and developed so they can be effectively overseen by natural persons during the period they are in use. The purpose is to prevent or minimise risks to health, safety and fundamental rights. The Act does not mandate "human-in-the-loop" by name — it requires effective oversight, and the three postures are simply ways to deliver it.
Article 14 splits the work between two actors:
The provider designs the measures (Article 14, with Article 16). The provider must build in, or specify, oversight measures before the system reaches the market — so that the persons overseeing it can:
- properly understand the system's capacities and limitations and monitor its operation, including watching for anomalies and unexpected performance;
- remain aware of, and counter, the tendency to over-rely on the system's output — the "automation bias" guarded against in Article 14(4)(b);
- correctly interpret the output;
- decide, in any particular case, not to use the system or to disregard, override or reverse its output; and
- intervene in or interrupt the system, including through a "stop" function.
The deployer assigns competent persons (Article 26). Oversight is only real if a capable human is actually doing it. Under Article 26, the deployer must assign human oversight to natural persons who have the necessary competence, training and authority, and the resources to perform it. A provider can design a beautiful oversight interface; if the deployer staffs it with someone who lacks the authority to override a decision, the oversight fails in practice. The duty therefore runs across both roles — provider (design) and deployer (execution) — and dovetails with the Article 4 AI-literacy obligation, in force since 2 February 2025 — since 27 July 2026 worded as a duty on providers and deployers to take measures to support the AI literacy of staff dealing with AI.
For especially sensitive systems — notably certain remote biometric identification systems — Article 14 imposes a stricter standard: action on the system's output requires verification by at least two natural persons with the necessary competence (the "four-eyes" requirement).
Why "human-in-the-loop" alone doesn't equal compliance
Two cautions:
A human in the loop is not automatically effective oversight. Putting a person at the end of the pipeline who rubber-stamps the AI's output — because they trust it, lack the time, or lack the authority to push back — satisfies the label but fails Article 14. The requirement is that the overseer can genuinely understand, question, and override. This is precisely why Article 14(4)(b) calls out automation bias: oversight that the design does not protect from over-reliance is oversight in name only.
The right posture depends on the decision, not on a slogan. For a single irreversible decision affecting a person's rights, in-the-loop review may be warranted. For a monitoring system processing thousands of events, on-the-loop supervision with intervention capability may be the effective and proportionate choice. Article 14 wants the appropriate level — picking "in-the-loop everywhere" can even degrade safety if it overwhelms reviewers into reflexive approval.
Worked example
Sør-Helse Klinikk AS, a ~250-employee, ~€44M-turnover Norwegian diagnostics provider that also reads scans for hospitals in Sweden and Denmark (so its output is used in the Union under Article 2(1)(c)), deploys a high-risk AI system that flags potential abnormalities on radiology scans (a medical-device-route high-risk use under Article 6(1) and Annex I). It has to design oversight under Article 14 and staff it under Article 26.
- Posture chosen: human-in-the-loop at the decision layer. The AI flags and prioritises; a radiologist reviews every flagged scan and makes the diagnostic call. The system cannot issue a diagnosis on its own.
- Provider's Article 14 design (delivered by the system vendor): the interface shows the model's confidence and the regions driving each flag; it surfaces known limitations; it lets the radiologist disregard or override any flag and records the override; and there is a "stop" control.
- Deployer's Article 26 execution (Sør-Helse's job): it assigns oversight to qualified radiologists with the authority and time to overrule the AI, and trains them — including explicitly on not deferring to the flag (the Article 14(4)(b) automation-bias point). It documents who is competent and authorised.
- On-the-loop where appropriate: for a low-stakes worklist-ordering feature that merely re-sorts the reading queue, Sør-Helse runs human-on-the-loop — a lead radiologist monitors the ordering and can intervene, rather than re-checking every re-sort.
The result is human-in-command at the top (the clinic decides the system may be used, and under what limits), in-the-loop for diagnostic flags, on-the-loop for queue ordering — all delivering the single statutory requirement: effective human oversight under Article 14.
(Timing: the high-risk regime applies from 2 August 2028 for Annex I product-embedded systems such as this one, and from 2 December 2027 for stand-alone Annex III systems — dates set by the Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026.)
How Confir helps
Confir's structured assessment covers Transparency & Human Oversight (Articles 13, 14, 27 and 50) alongside the other high-risk requirement areas. For a high-risk system it surfaces the Article 14 oversight measures the provider must design and the Article 26 competence-and-authority duties the deployer must staff — including the automation-bias guard of Article 14(4)(b) — as concrete, documentable controls. The engine is deterministic and rule-based: the same intake produces the same oversight checklist, and the rule behind each item is human-readable, so you can show an auditor exactly why a control is required.
Frequently Asked Questions
Is "human-in-the-loop" an EU AI Act term?
No. It is a practice term from AI governance, not statutory language. The Act's binding requirement is "human oversight" under Article 14, which applies to high-risk AI systems. Human-in-the-loop (and on-the-loop and in-command) are ways of describing how much human control a design provides; Article 14 requires that whatever you choose delivers effective oversight proportionate to the risk. Map the slogan to Article 14 when you are documenting compliance.
What is the difference between human-in-the-loop and human-on-the-loop?
In-the-loop means a human reviews and acts on each individual output before it takes effect — the system can't complete the decision alone. On-the-loop means the system runs autonomously while a human monitors it and can intervene, override or stop it. In-the-loop suits individual high-stakes decisions; on-the-loop suits high-throughput settings where per-item review is impractical but supervision and a stop function are essential. Article 14 lets you choose what is effective for the specific risk.
Who is responsible for human oversight — the provider or the deployer?
Both. Under Article 14 (with Article 16) the provider must design and build in the oversight measures before the system is placed on the market — the interface, the override and stop functions, the safeguards against over-reliance. Under Article 26 the deployer must assign oversight to natural persons with the necessary competence, training, authority and resources. Provider design without competent deployer staffing — or vice versa — leaves the oversight ineffective and non-compliant.
Does putting a person at the end of the process satisfy Article 14?
Not by itself. Article 14 requires effective oversight: the overseer must be able to understand the system's limits, interpret its output, decide not to use it, and override or stop it. A reviewer who rubber-stamps outputs — through over-trust, lack of time, or lack of authority — meets the label but fails the requirement. Article 14(4)(b) specifically requires that the design help the person counter automation bias, the tendency to over-rely on AI output.
Does Article 14 ever require more than one person?
Yes. For certain high-risk systems — in particular some remote biometric identification systems — Article 14 imposes a stricter "four-eyes" standard: action on the system's output must be verified and confirmed by at least two natural persons with the necessary competence, training and authority. This is an exception to the general rule; most high-risk systems require effective oversight by competent persons without a fixed two-person minimum.
How does human oversight relate to AI literacy under Article 4?
They reinforce each other. Article 4 (in force since 2 February 2025, applying to all AI) requires providers and deployers to take measures to support the AI literacy of staff who deal with AI systems — since the Digital Omnibus, without guaranteeing any specific individual level. Article 14 then requires that the specific persons assigned to oversee a high-risk system can genuinely understand, question and override it. Article 4 builds the general competence; Article 26 assigns competent people to the oversight role; Article 14 sets what that oversight must achieve.
Related guides
- Article 14: human oversight
- Human oversight implementation
- Human oversight in practice
- Automation bias — glossary
- AI literacy — glossary
- High-risk AI system — glossary
- Deployer obligations (Article 26)
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →