What does Article 14 of the EU AI Act require for human oversight?

Updated 9 August 2026 for Regulation (EU) 2026/1744.

Article 14 requires providers to design and develop high-risk AI systems so that natural persons can effectively oversee them while in use, through appropriate human-machine interface tools. Deployers must then assign that oversight to people with the necessary competence, training, authority and support under Article 26(2).

Quick answer

• Two duties, two actors: Article 14 is the provider's design duty; Article 26(2) is the deployer's assignment duty.
• The design standard: systems must be built "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" (Article 14(1)).
• Proportionate, not maximal: measures must be "commensurate with the risks, level of autonomy and context of use" (Article 14(3)) — the Act does not demand a human approval for every output.
• The overseer's toolkit: Article 14(4) lists five capabilities, from understanding the system's limitations to a "stop" button, enabled "as appropriate and proportionate".
• The special rule: remote biometric identification (point 1(a) of Annex III) additionally requires separate verification by at least two natural persons before the deployer acts on a match (Article 14(5)) — with a narrow carve-out.

Who carries the human oversight duty — provider or deployer?

Both, in sequence. Article 14 sits in Section 2 of Chapter III, whose requirements the provider must ensure are met under Article 16, point (a). Article 14(1) frames it as engineering: 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." Oversight that exists only in a policy document fails this — the capability must be in the product.

The deployer's half is Article 26(2): "Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support." Article 14(4) supplies the hinge — "natural persons to whom human oversight is assigned": the provider enables, the deployer staffs. Unsure which role you hold? See provider vs deployer.

What is human oversight supposed to achieve?

Article 14(2) states the aim: to "prevent or minimise the risks to health, safety or fundamental rights" that may emerge under the intended purpose "or under conditions of reasonably foreseeable misuse, in particular where such risks persist despite the application of other requirements set out in this Section." That last clause makes human oversight the residual-risk layer: the human stands between the risks your other Section 2 measures could not eliminate and the person affected. Design it for the failure modes your risk register could not close, not as a generic approval step.

How much oversight is enough?

Article 14(3) sets the yardstick: oversight measures "shall be commensurate with the risks, level of autonomy and context of use of the high-risk AI system". Three variables: the same model can legitimately carry different oversight in different products, and a low-autonomy recommender does not need the apparatus of an autonomous decision pipeline.

The measures come in two forms, "either one or both":

• Article 14(3), point (a) — measures "identified and built, when technically feasible, into the high-risk AI system by the provider" before it is placed on the market or put into service.
• Article 14(3), point (b) — measures "identified by the provider" before market placement "that are appropriate to be implemented by the deployer".

Both routes run through the provider before launch. "We'll let customers figure out oversight" is not point (b): even deployer-implemented measures must be identified by the provider first, and communicated — the instructions for use must describe "the human oversight measures referred to in Article 14" under Article 13(3), point (d), covered in the transparency-to-deployers guide.

What must the assigned overseers actually be able to do?

Article 14(4) turns the design duty into a delivery duty: the system "shall be provided to the deployer in such a way that natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate" to do five things:

• Article 14(4), point (a) — "properly understand the relevant capacities and limitations" of the system and "duly monitor its operation, including in view of detecting and addressing anomalies, dysfunctions and unexpected performance."
• Article 14(4), point (b) — "remain aware of the possible tendency of automatically relying or over-relying on the output" (automation bias — the Act's own term), "in particular for high-risk AI systems used to provide information or recommendations for decisions to be taken by natural persons."
• Article 14(4), point (c) — "correctly interpret the high-risk AI system's output, taking into account, for example, the interpretation tools and methods available."
• Article 14(4), point (d) — "decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output of the high-risk AI system."
• Article 14(4), point (e) — "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state."

The chapeau's "as appropriate and proportionate" matters: the five points are the menu, and Article 14(3)'s risk-autonomy-context test sets the portion. But points (d) and (e) are hard to argue away for systems that decide about people — an overseer who cannot override the output in the interface, whatever the org chart says, is not "enabled".

What is the special rule for remote biometric identification?

Article 14(5) adds a two-person rule for one category only: "high-risk AI systems referred to in point 1(a) of Annex III" — remote biometric identification systems. For those, the measures must ensure that, "in addition", "no action or decision is taken by the deployer on the basis of the identification resulting from the system unless that identification has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority."

Read the boundary precisely. Point 1(a) of Annex III itself excludes "AI systems intended to be used for biometric verification the sole purpose of which is to confirm that a specific natural person is the person he or she claims to be" — so a face-match login flow is not caught. And the second subparagraph of Article 14(5) disapplies the two-person requirement for systems "used for the purposes of law enforcement, migration, border control or asylum, where Union or national law considers the application of this requirement to be disproportionate". The carve-out needs both limbs: the listed domain, and a disproportionality judgement in Union or national law. Neither on its own is enough.

The rule leaves a paper trail: for point 1(a) systems, Article 12(3), point (d) requires the logs to record "the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5)" — see the logging requirements guide.

What does Article 26(2) require deployers to do?

Assign oversight to named, equipped humans. Article 26(2) lists four elements: "the necessary competence, training and authority, as well as the necessary support". Each fails separately. A competent overseer with no authority to override cannot exercise Article 14(4), point (d); an authorised one with no training cannot spot the anomalies point (a) contemplates.

Article 26(3) then protects how you organise it. The obligations in Article 26(1) and Article 26(2) are "without prejudice" to two things: other Union or national law duties, "and to the deployer's freedom to organise its own resources and activities for the purpose of implementing the human oversight measures indicated by the provider." The measures themselves come from the provider — under Article 26(1), deployers must use the system "in accordance with the instructions for use" — but the staffing model is yours.

Where do the oversight measures get written down?

Twice, by the provider. The technical documentation must contain an "assessment of the human oversight measures needed in accordance with Article 14", including the technical measures facilitating interpretation of outputs (point 2(e) of Annex IV) — see the technical documentation guide. And the instructions for use must describe the oversight measures to the deployer under Article 13(3), point (d). If the two do not match, one of them is wrong.

What this means for you

If you're a provider: Article 14 applies from 2 December 2027 to systems high-risk under Article 6(2) and Annex III, and from 2 August 2028 to systems high-risk under Article 6(1) and Annex I (Article 113, third paragraph, point (c), as amended by Regulation (EU) 2026/1744). The high-risk obligations overview maps the full set. Work Article 14 as a design ticket, not a policy: pick measures against Article 14(3)'s three variables, build the Article 14(4) capabilities into the interface, write the Annex IV assessment and mirror it in the instructions for use. Complipath's documentation workspace gives each system one structure — overview, data description, risks and mitigations, human oversight — with base fields auto-filled from the register record, so the Article 14 assessment stays with the rest of the Annex IV file.

If you're a deployer: Your duty is Article 26(2), and it is organisational: name the overseers per system, and verify all four elements — competence, training, authority, support — against what the instructions for use ask of them. If the provider's instructions describe oversight measures your people cannot operate, raise it before go-live: Article 26(3) leaves you free to organise the resourcing, but not to skip the measures the provider indicated.

Which of your systems need a named person watching?

Classify your system now — 7 questions on the main line, plus follow-ups where they apply, no account, and the classification runs in your browser: answers stay there unless you choose to keep the result.

FAQ

Does the EU AI Act require a human to approve every AI decision? No. Article 14(3) requires oversight measures "commensurate with the risks, level of autonomy and context of use", and Article 14(4) enables the overseer capabilities "as appropriate and proportionate". Only remote biometric identification under point 1(a) of Annex III carries a mandatory two-person verification before the deployer acts (Article 14(5)).

Who is responsible for human oversight — the provider or the deployer? Both, differently. The provider must design the system so it can be effectively overseen, with measures identified before market placement (Article 14(1) and Article 14(3)). The deployer must assign oversight to natural persons with the necessary competence, training and authority, as well as the necessary support (Article 26(2)).

Which systems need two-person verification under Article 14(5)? Only high-risk systems under point 1(a) of Annex III: remote biometric identification. That entry excludes biometric verification systems that merely confirm a claimed identity. The requirement is also disapplied for law enforcement, migration, border control or asylum uses where Union or national law considers it disproportionate.

When do the human oversight requirements start to apply? Article 14 and Article 26(2) apply from 2 December 2027 for systems high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems high-risk under Article 6(1) — the Annex I product route — under Article 113, third paragraph, point (c), as amended by Regulation (EU) 2026/1744.

Sources: Regulation (EU) 2024/1689 (EUR-Lex), Articles 12, 13, 14, 16, 26 and 113, and Annexes III and IV, as amended by Regulation (EU) 2026/1744 (EUR-Lex), which replaced Article 113, third paragraph, point (c). Article 14 and Article 26 are themselves unamended; only their date of application moved. The Regulation does not further define "effectively overseen" or quantify "commensurate", and the Article 40 harmonised standards expected to concretise the Section 2 requirements were still incomplete at the time of writing; the obligations apply on the dates stated regardless, and the calibration of oversight measures remains the provider's documented judgement until standards or case law say otherwise.