Article 14, line by line.

The design obligation, verbatim.

The sentence does four things. It binds the system, not the operator's process. It uses shall in the operative regulatory sense. It names the human-machine interface as a load-bearing artefact, which means oversight is a design property, not a documentation artefact bolted on after the fact. It scopes the oversight horizon to the period in which they are in use, which is wider than any audit window and matches the lifetime-of-the-system perimeter that Article 12(1) binds for logging.

Placement matters. Article 14 sits inside Section 2 of Chapter III, the requirements every provider of a high-risk AI system must satisfy before placing the system on the Union market. Article 16(a) reads those requirements back as a provider obligation. Article 99(4)(a) reads Article 16 back as a fineable failure. Three steps from Article 14(1) to the EUR 15 million ceiling.

The verb that does the work is effectively. The five capabilities in Article 14(4)(a) through (e) are how a regulator tests the word. A high-risk system that ships with a screen reading system recommends APPROVE and a single button labelled confirm has not been designed for effective oversight. A high-risk system that ships with the recommendation, the basis on which it was reached, the confidence band, the override path, the interrupt control, and the documented bias-awareness prompt, has been.

The purpose · verbatim.

Three constructions in this paragraph carry meaning. Prevent or minimise is the verb pair, not monitor. Oversight is a control function, not an observation function. Health, safety or fundamental rights is the protected interest set, the same triple Article 9 risk management runs against. Reasonably foreseeable misuse extends the perimeter past intended use into the failure modes a competent provider should have anticipated.

The closing clause is the load-bearing one. Article 14 oversight is the residual control. It applies in particular where risks persist despite the application of the other Section 2 requirements. Risk management under Article 9, data and data governance under Article 10, technical documentation under Article 11, record-keeping under Article 12, transparency under Article 13, accuracy under Article 15. When all six controls have done their work and risk remains, Article 14 carries the residue. Oversight is the human standing where the engineering ends.

The drafting choice has a consequence. A provider cannot discharge Article 14 by pointing at a rigorous Article 9 risk-management system. Article 14 attaches independently. The five capabilities in paragraph 4 must be enabled even where the residual risk after Article 9, 10 and 15 is small. The regulator reads paragraph 2 as a why-clause for the design obligation in paragraph 1, not as a permission to omit it.

Provider-side and deployer-side measures.

Paragraph 3 is the split that most compliance officers misread on first contact. The article does not split oversight between provider and deployer. It splits oversight measures. The provider is responsible for both branches. Branch (a) is the set of measures the provider builds into the system. Branch (b) is the set the provider identifies and documents for the deployer to implement. Either or both. Never neither.

The phrase commensurate with the risks, level of autonomy and context of use is the proportionality test. A high-risk system with low autonomy operating in a tightly bounded use case carries lighter oversight measures than a high-risk system with high autonomy operating across many decision contexts. Regulators read commensurate by reference to the Article 9 risk-management output and the Annex IV technical documentation under Article 11.

The phrase when technically feasible in 14(3)(a) is narrow. It does not relieve the provider of building in measures the provider could have built in. It accommodates the case where a measure can only be exercised at deployer site. A provider of a credit-scoring agent cannot build the deployer's case-management system into the model. The provider can, and must, build the override path, the interrupt control, the explanation surface, and the bias prompt.

Paragraph 3(b) lands at Article 26 in the deployer chapter. Article 26(2) requires deployers to assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. The provider designs the oversight surface. The deployer staffs it. Both obligations are independent. Both attach to Article 99(4).

The five capabilities · verbatim.

The chapeau is structural. Paragraph 4 lists the five capabilities a natural person must be enabled to exercise. The qualifier as appropriate and proportionate reads back to the proportionality test in paragraph 3. The five sub-clauses, each verbatim:

The chapeau verb is enabled. Paragraph 4 does not require the natural person to exercise each capability on every decision. It requires the system to be designed so the capability can be exercised when the situation calls for it. The evidentiary burden, when a regulator asks, is to show the capability was reachable on the decision in question.

The four-eyes biometric rule · verbatim.

Paragraph 5 attaches to one and only one Annex III category. Point 1(a) of Annex III covers remote biometric identification systems, excluding biometric verification systems whose sole purpose is to confirm a specific natural person is who they claim to be. The article does not extend the four-eyes rule to biometric categorisation under Annex III(1)(b) or to emotion recognition under Annex III(1)(c).

The construction no action or decision is taken sets a bright line. The deployer cannot use the identification to act, even provisionally, before the second natural person has verified and confirmed it. The verification is on the identification, not on the underlying biometric input. The two natural persons each carry the same competence, training and authority qualifier that Article 26(2) imposes generally.

The carve-out is narrow on its face. It applies where Union or national law considers the application of this requirement to be disproportionate in the contexts of law enforcement, migration, border control or asylum. The carve-out is not self-executing. A Member State authority cannot decide locally that the requirement is disproportionate. Union or national law must so provide. Absent that legal basis, the four-eyes rule attaches even in those four contexts.

What Article 14 reads with.

Article 14 does not stand alone. It sits inside a set of Section 2 obligations that together form the high-risk requirements. Reading 14 without reading the cross-references reads it wrong.

Annex IV pulls the references together, in two places. Annex IV point 3 requires the technical documentation to give detailed information about monitoring, functioning and control including the human oversight measures needed in accordance with Article 14, including the technical measures put in place to facilitate the interpretation of the outputs of AI systems by the deployers. Annex IV point 2(e) separately requires an assessment of the human oversight measures needed in accordance with Article 14, including an assessment of the technical measures needed to facilitate the interpretation of the outputs of AI systems by the deployers, in accordance with Article 13(3), point (d). The Annex IV file is where a regulator under Article 21 looks first when assessing 14 compliance.

Automation bias under 14(4)(b), in plain English.

Paragraph 4(b) is the clause most production teams underestimate. The text names the failure mode in parenthesis · (automation bias). The behavioural literature is settled. Humans presented with a system recommendation will, in the typical case, defer to the recommendation, including when the recommendation is wrong, including when the available evidence contradicts the recommendation, including when the human nominally has the override path. The deference rate rises as the perceived competence of the system rises. It rises further as decision volume rises. It rises further still under time pressure.

Article 14(4)(b) does not ask the provider to eliminate automation bias. It asks the provider to enable the natural person to remain aware of the tendency. The verb is active. The regulator reads the obligation as a documented-evidence obligation, not a one-time training certificate. The five questions a competent compliance officer asks of a 14(4)(b) implementation are, in practice:

One · is the recommendation accompanied by a confidence band the reviewer must read before approving? Two · is the basis for the recommendation surfaced in the same view, not behind a click? Three · is the override path single-click reachable, with no friction asymmetry against approve? Four · does the workflow record the basis on which the reviewer reached the decision, not only the outcome? Five · is the cohort-level accept rate visible to the reviewer in real time, so the reviewer knows when their decision pattern is converging on the system's recommendation rate?

A workflow that ships system recommends APPROVE and a button labelled confirm answers none of the five. A workflow that ships the recommendation, the confidence, the top-three contributing features, the override and disregard paths each as single-click controls, and writes a structured event for each reviewer decision into Article 12 logs, answers all five.

The tickbox does not satisfy. A click on I have reviewed this does not evidence awareness. The Annex IV technical documentation file under Article 11 must show, for the 14(4)(b) measure, both the design and the runtime evidence the design produces.

Four-eyes in practice · scope and exemption.

Article 14(5) attaches when three conditions are met. The system is high-risk. The system falls within Annex III point 1(a), remote biometric identification. The deployer takes an action or decision on the basis of the identification. All three are facts about the deployment, not the model.

What counts as separately verified and confirmed. The two natural persons must each form an independent judgement. A workflow where the second person sees the first person's confirmation before forming their own is, on a strict reading, not separate verification. The standard architecture is double-blind · each reviewer sees the system identification and the underlying inputs (where lawful) without seeing the other reviewer's conclusion. Both must confirm. Disagreement routes to a third person or to a documented escalation procedure.

What counts as necessary competence, training and authority. The qualifier is the same one Article 26(2) imposes on all human oversight assignments. For biometric identification the practical reading is that both reviewers must be trained on the specific system's capacities and limitations under 14(4)(a), trained on automation bias under 14(4)(b), and authorised to disregard, override or reverse the identification under 14(4)(d). A junior staff member with no override authority is not a four-eyes participant.

The carve-out for law enforcement, migration, border control and asylum is conditional. Article 14(5) requires Union or national law to consider the application of the requirement disproportionate. The Member State legislator, not the Member State agency, makes that judgement. Absent legislation, the four-eyes rule attaches even in those four contexts. Where legislation does provide for the exemption, the exemption is read narrowly against the protected interests in Article 14(2).

How Article 14 sub-clauses map to evidence fields.

Article 14 is one of the six EU AI Act regimes the Warrant corpus carries, so every clause below resolves to a real row in the package rather than to a bespoke field. Each id in the third column exists verbatim in api/data/regulations.json at digest 6871ee8b, and the obligation-mapping stage may cite no id that is not in that corpus. Read the third column literally: it names where the clause is adjudicated, not where the underlying document is stored. What the package does not hold is set out beneath the table.

Every row lands in the same structure. obligations is an object keyed by action_id, so a row's own path is obligations.<action_id>[]; each row carries the sub-clause id verbatim from the corpus, a compliance verdict of satisfied, gap, uncertain or unvalidated, a confidence number, and an evidence string that must quote or paraphrase the action's own input, output or authorization text rather than restate the clause. coverage_by_regime["eu_ai_act_art_14"] carries the regime-level status. Where the regime's application date was still ahead of the attestation, obligations.<action_id>[].applies_from and the package-level deferred_regimes map are the fields that would record the row as a forward-looking mapping rather than a finding against law in force. Both are gated: under the shipped default those labels reach nothing — not the signed record, not the PDF, not the receipt — and they are emitted only where an operator has switched the deferral-label mode on. Read a package without them as silent on the question, not as an assertion that the regime was in force.

What the table does not say is that the clause is satisfied. An obligation row is an adjudication of the clause against one execution, not the artefact the clause requires. For 14(1) and 14(3), which bind provider and deployer at design time, the row can only read gap, uncertain or unvalidated: the package sees a single trace, and the oversight design, the human-machine interface specification and the deployer's written oversight plan are documents that live outside it. There is no field in api/spec/warrant-v1-evidence.schema.json for an oversight-design identifier, an operator-competence or training record, an automation-bias assessment, a recorded override event, or the two-natural-persons verification 14(5) requires. The schema sets additionalProperties: false at the root and on every action and authorization row, so those fields cannot be added to a package by a caller; they would need a new schema version.

The one Article 14 judgement the package makes on its own account is authorizations[].human_oversight_appropriate, recorded per action as yes, no, uncertain or n/a, with authorizations[].justification carrying the reasoning and authorizations[].reversible recording whether the effect could still be undone at the end of the trace. That is an assessment of whether the oversight present was appropriate to the action's risk, which is the question 14(4)(d) turns on, and it is not a log of a human exercising the override. A regulator reading the package under Article 21 reads those per-action judgements, then the obligation rows they support, and takes the design-time clauses from the provider's own documentation.

Questions a compliance officer asks first.

Read the source directly.

• Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689
• Article 14 human oversight · annotated text
• Article 26 obligations of deployers of high-risk AI systems
• Annex III high-risk AI systems referred to in Article 6(2)
• Article 99 penalties
• Article 16 obligations of providers of high-risk AI systems
• Per-obligation Warrant evidence field mapping

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. The verbatim quotation of Article 14(1) through (5) reflects the official English-language text of Regulation (EU) 2024/1689 as published in the Official Journal of the European Union on 12 July 2024.