EU AI Act Article 14 — Human Oversight Requirements

What Article 14 actually requires

Article 14 of Regulation (EU) 2024/1689 obliges providers of high-risk AI systems to design and build into the system human oversight measures that allow natural persons to effectively oversee the system during its use. The article splits responsibility:

• Providers design the oversight measures into the system before it is placed on the market and document them in the Article 11 technical file and the Article 13 instructions for use.
• Deployers assign oversight to natural persons with the necessary competence, training, authority and support — see Article 26(2).

Reg text — Article 14(1): "High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use."

The keyword is effectively. A "human-in-the-loop" review that costs the reviewer 200 milliseconds and provides no real oversight is not Article 14 compliance; it is Article 14 theatre.

The four oversight outcomes — Article 14(4)(a)–(d)

Article 14(4) lists four outcomes that the oversight measures must enable for the persons assigned to oversee:

• (a) Properly understand the relevant capacities and limitations of the high-risk AI system and be able to duly monitor its operation, including detecting and addressing anomalies, dysfunctions and unexpected performance.
• (b) Remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias), in particular for systems used to provide information or recommendations for decisions to be taken by natural persons.
• (c) Correctly interpret the system's output, taking into account, for example, the interpretation tools and methods available.
• (d) Decide, in any particular situation, not to use the high-risk AI system or otherwise disregard, override or reverse the output.

Plus a fifth, in (e): the ability to intervene on the operation or interrupt the system through a stop button or similar procedure that allows the system to come to a halt in a safe state.

For specific Annex III systems — biometric identification systems used by law enforcement (Annex III §1) — Article 14(5) layers on a two-person rule: no action or decision by such a system may be taken on the basis of identification unless verified and confirmed by at least two natural persons.

Who is covered

Article 14 imposes design obligations on providers of high-risk AI systems. Operational obligations fall on deployers under Article 26(2).

If you are a SaaS vendor of a high-risk system (Annex III), you must:

• Build interpretation tools (model cards, calibration curves, confidence scores, attention/SHAP visualisations) into the user interface.
• Document the competencies required to oversee the system in the Article 13 instructions for use.
• Provide a stop control that the deployer's overseer can invoke without engineering support.
• Document automation-bias mitigations — for example, periodic forced-disagreement prompts, or A/B switches that conceal the model recommendation in a sample of cases for calibration.

If you are a deployer:

• Assign overseers who are competent, trained, authorised and supported (Article 26(2)).
• Track override rates as a leading indicator. Anomalously low override rates suggest automation bias; anomalously high override rates suggest the model is wrong or untrusted — both demand action.
• Keep training records for every overseer. Regulators ask.

What to do — the deployer side

1. Pick the overseer profile. Job title, qualifications, hours-per-week dedicated, reporting line. "Whoever is on shift" is not a profile.
2. Train them. Specific to the system, not generic AI literacy. Document the curriculum, the trainer, the duration and the assessment.
3. Empower them. Authority to stop, override, escalate. Authority must be in writing — a job description amendment, an SOP, or both.
4. Resource them. Time per decision. If oversight requires 90 seconds and you give them 8 seconds, oversight does not exist.
5. Monitor. Override rate, time-per-decision, agreement rate with model output. Trends matter more than absolutes.
6. Audit. Quarterly review of a sample of overseen decisions. Did the overseer have the information to make a real call? Did they exercise it?

A worked example

A mid-sized German hospital deploys a third-party diagnostic-imaging triage system (high-risk under Annex III §5 health). The provider has built into the UI: confidence score, attention heat-map over the image, three differential diagnoses ranked by probability, a "this case does not match training distribution" warning when applicable, and a stop control that disables the recommendation for a given case.

The hospital's deployer-side oversight design:

• Overseer: the radiologist on shift, supplemented by a registrar for high-volume periods.
• Training: 16-hour curriculum (4h on the model architecture, 6h on the training-data limitations including under-representation of <2-year-old paediatric cases, 4h on the override workflow, 2h assessment).
• Authority: unconditional override authority; documented in the radiologist's job description as amended 2026-03-01.
• Time: minimum 60 seconds per case, regardless of model confidence.
• Monitoring: weekly override-rate dashboard reviewed by the head of radiology; monthly drift report; quarterly sample audit of 30 overseen cases.

That hospital can produce, on 14 days' notice from a market surveillance authority, the SOP, the training records of every overseer, the override-rate trend, and the audit reports. That's Article 14 + Article 26(2) compliance.

What regulators look at first

Three things, in order:

1. The training records of the overseers. If you cannot produce them, the entire human-oversight compliance is in question.
2. The override rate trend. A flat zero is a red flag. A flat 100% is also a red flag.
3. The stop-control documentation. Where is it in the UI? Who can reach it? When was it last tested?

Inline crosswalk to ISO 42001 and NIST AI RMF

• ISO/IEC 42001:2023 Annex A.9.2 — Human oversight of AI systems. Article 14 oversight measures + operator competence map directly here.
• NIST AI RMF GOVERN 3.2 — Policies and procedures define and differentiate roles and responsibilities for human-AI configurations. Article 14 documented oversight measures and operator roles map directly to GOVERN 3.2.
• NIST AI RMF MEASURE 2.8 — Risks associated with transparency and accountability are examined and documented. Operator override paths and stop-controls are the accountability mechanisms MEASURE 2.8 examines.

Penalties

Article 99(4) sets non-compliance with Article 14 (a Chapter III Section 2 obligation) at up to €15 million or 3% of worldwide annual turnover. The realistic enforcement risk is, again, Article 79 market-removal during remediation rather than the fine itself.

Common mistakes

1. Treating "human in the loop" as a compliance label rather than a design constraint. A 200ms confirmation click is not oversight.
2. No training records. The single most common Article 14 failure.
3. Stop control buried in an admin panel. It must be reachable from the operational UI.
4. No override-rate monitoring. Without it, you cannot evidence that overseers are actually exercising their authority.
5. Skipping the two-person rule for biometric law-enforcement. Article 14(5) is non-negotiable for Annex III §1 systems.

Generate Article 11 documentation with AI

The Article 14 measures must be documented in Annex IV §3 and §2(e). Governancer Pro includes a LLM-assisted Article 11 drafting tool that pre-fills the human oversight section based on your system description.

---

Disclaimer. This page is a reference summary of EU AI Act Article 14. It is not legal advice. Verify with qualified counsel before relying on it for compliance decisions. Reg text quoted from the Official Journal version of Regulation (EU) 2024/1689.