Most human oversight I see written for the AI Act lives in a policy document no operator has read, asserting a control the interface never actually grants. Article 14 is not a paragraph you write. It is behaviour you build into the system.
Article 14 of the EU AI Act requires that high-risk AI systems be designed and developed so that they can be effectively overseen by natural persons while in use. The word that does the work is effectively. A line in a standard operating procedure saying “the analyst reviews the model’s output before acting” satisfies nobody once you ask the obvious follow-up: reviews it how, with what information, and with what power to stop the thing. If the answer is that the operator sees a decision already taken and a button that does nothing an automated pipeline has not already done, you have oversight on paper and automation in fact. That gap is exactly what a market surveillance authority is built to find.
The obligations for Annex III high-risk systems apply from 2 August 2026, and those for the Article 6(1) product-safety route from 2 August 2027. Either way, the design work has to happen well before, because oversight you retrofit is oversight you bolt onto an interface that was never shaped to carry it.
What Article 14 actually asks the system to do
Strip the article to its operative content and Article 14(4) names five capabilities the person doing the oversight must be enabled to exercise. Enabled is a design verb, not a training one. They must be able to understand the system’s capacities and limitations and monitor its operation for anomalies; to stay aware of the tendency to over-rely on the output, known as automation bias; to correctly interpret the output, using whatever interpretation tools are provided; to decide not to use the system or to disregard, override or reverse a given output; and to intervene or interrupt through a stop function.
Read that as a list of interface requirements rather than a list of good intentions. “Understand capacities and limitations” means the screen has to show the operator when the model is outside the conditions it was validated for. “Remain aware of automation bias” means the interface must not present a machine output as a settled fact the human is nudged to rubber-stamp. “Correctly interpret the output” means a confidence figure, the salient inputs, and enough of the case to form an independent view. “Disregard, override or reverse” and “interrupt through a stop” mean the control flow must genuinely pause on a human decision and must genuinely act on the reversal. None of that is policy. All of it is build.
Where oversight is designed away without anyone deciding to
The common failure is not a bad policy. It is a good policy contradicted by the product. Three patterns recur.
The decision is already made when the human sees it. The model classifies, the downstream action fires, and the review screen shows a fait accompli with an “undo” that has to chase a side effect already in flight. Reversal that races the consequence is not the reversal Article 14 has in mind. The gate has to sit before the effect, not after it.
The interface hides the uncertainty. A single confident sentence with no confidence signal, no view of the inputs that drove it, and no flag when the case is unusual is an interface engineered for automation bias. The operator has nothing to be sceptical with. Treating model uncertainty as a first-class thing to surface is the same discipline I have argued for in treating hallucination as a design constraint rather than a bug: you assume the output can be wrong and you build the screen around that assumption.
Escalation dead-ends. The edge case routes to a human who lacks the context, the authority or the time to do anything but wave it through. Article 26(2) puts the matching duty on the deployer, which must assign oversight to natural persons who have the necessary competence, training and authority. A queue that lands hard cases on someone who can only approve is not oversight; it is a laundering step for the model’s decision.
The gate is the pattern
Reduced to its structure, meaningful oversight is a gate in the control flow with three branches: act automatically when the model is confident and the case is ordinary; require review before any effect when confidence is low or the case is flagged; and always route a defined set of high-consequence or legally sensitive decisions to a human regardless of confidence. The thresholds are a governance choice, not a data-science one, and they belong in the same risk analysis that Article 9 drives — the point I make at length on the Article 9 risk management system. The engineering job is to make the gate real: the automated branch cannot proceed while a mandatory-review branch is pending, and the stop has to reach the actuator, not just the log.
# Human-in-the-loop gate: confidence thresholds + mandatory review
# Pseudo-code. The gate runs BEFORE any downstream effect fires.
def decide(case, model_output):
conf = model_output.confidence # calibrated, 0..1
review = ReviewRecord(case, model_output) # always written, for Art. 12 logs
# 1. Certain decisions never auto-execute, however confident the model is.
if case.category in MANDATORY_REVIEW_CATEGORIES:
return escalate(review, reason="mandatory-review category")
# 2. Out-of-distribution or flagged input => a human must look first.
if model_output.out_of_scope or conf < REVIEW_THRESHOLD:
return escalate(review, reason="low confidence / out of scope")
# 3. Confident and ordinary: act, but keep the reversal window open
# and surface the basis so the operator can override, not rubber-stamp.
action = enact(case, model_output, reversible_until=REVERSAL_WINDOW)
notify_overseer(review, action, allow_override=True)
return action
def escalate(review, reason):
# No effect fires while this is pending. The human sees confidence,
# salient inputs and the case, and holds a real stop & override.
queue_for_human(review, reason,
context=review.salient_inputs,
controls=["approve", "override", "stop"])
return Deferred(review.id)
The pseudo-code is deliberately dull, because the substance is in the constraints, not the cleverness. The review record is written on every path, which is what makes the oversight evidenceable rather than merely asserted — it feeds directly into the record-keeping I cover under automatic logging under Article 12. The mandatory-review categories are enforced in code, not left to an operator remembering the policy. The stop and override are passed as real controls to a human who has been given the context to use them.
What a supervisor can actually be shown
When oversight lives in the interface, the evidence is concrete. You can show the gate in the code path and the thresholds it enforces. You can show a low-confidence case that stopped and waited for a person. You can show an override that reversed a model output before the effect landed, with the operator’s decision recorded against it. You can show that a mandatory-review category never auto-executed across a sample of production traffic. That is a demonstrable control an auditor can test.
When oversight lives in the SOP, the evidence is a document and a hope. The document says the analyst reviews; the telemetry says the analyst approved 99.4 per cent of cases in a median of four seconds. One of those is the truth, and it is not the one on headed paper. For the specific biometric identification systems in Annex III, Article 14(5) goes further and requires that no action be taken on an identification unless it has been separately verified by at least two people — a rule you cannot satisfy with wording at all, only with a two-person step wired into the flow.
Write the policy last. It should describe a control the system already enforces. If your Article 14 compliance begins and ends in a Word file, you have documented an intention the interface is quietly overriding every time it runs.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.
Full Governance by Sixteen Pillars
Govern your business. Prove your compliance.
A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.
See what's coming