Human Oversight and Intervention Points: The EU AI Act's Article 14 Requirement

[GROUND TRUTH] (Sources/ncp-aai/domain-10-human-ai-interaction-oversight.md) Objective 10.4 enables human oversight and intervention for accountability and trust, and the regulatory anchor is the EU AI Act's Article 14, which requires high-risk AI to be designed for effective human oversight during use. The system must provide points where a human can step in — review, approve, override, or halt. This is worth reading precisely, because each of the four named actions is doing distinct work:

• Review — inspect a proposed or completed action before or after it takes effect, without necessarily changing anything.
• Approve — explicitly permit an action to proceed, converting a proposal into an effect.
• Override — replace the agent's proposed action with a different one, or correct it, rather than simply blocking it.
• Halt — stop an action, or an entire process, from continuing at all.

Four distinct capabilities, not one generic "human can intervene somehow." A system that supports review and approve but not override or halt gives a human the ability to slow things down and sign off, but no ability to actually change course or stop a runaway process — which is a materially weaker form of oversight than one supporting all four, even if both configurations technically have "a human in the loop" in some sense.

L1 — Intuition: an emergency stop button has to be reachable, not just exist in the building

A factory can have a safety officer on staff, fully trained and authorized to stop a production line, and still be unsafe if the actual machinery has no emergency stop button within reach of where a problem would occur — the authority to intervene and the physical point of intervention are two different things, and only having both together produces real safety. An agentic system's intervention points work the same way: a human reviewer with full authority to override a decision is not actually providing oversight if the system's architecture gives them no point at which that override can take effect before the consequential action has already happened.

L2 — Mechanism: where an intervention point has to sit relative to an action's effect

A designed intervention point is a specific location in an agent's execution path, before an action's effect becomes irreversible, where the system pauses and waits for one of the four Article 14 actions before proceeding — or, for post-hoc review, a location where the action's record remains inspectable and, if a halt or override authority extends to undoing effects, reversible after the fact. The critical design question for any specific risky action an agent might take is: at what point, before this action's consequence becomes real and hard to undo, does the system actually stop and give a human the chance to act? A refund that has already processed, a message that has already sent, a database record that has already been overwritten cannot be meaningfully "overridden" after the fact in the way the action could have been blocked before it happened — which is why intervention points are placed as gates before a consequential effect, not as after-the-fact review of something already irreversible, whenever the stakes justify the added latency M10-01 costed out for exactly this kind of gate.

L3 — The exam-relevant edge case: escalation is the trigger, the intervention point is the destination

[GROUND TRUTH] (Sources/ncp-aai/domain-9-safety-ethics-compliance.md) names escalation protocols as part of Domain 9's layered safety framework — objective 9.4 calls for combining multiple detection methods with escalation, routing risky cases to a human, explicitly tying this mechanism to Domain 10. This is the specific connective fact worth being precise about: escalation is the mechanism that decides a case is risky enough to route to a human, and the intervention point this lesson is about is where that routed case actually lands and what the human can do once it arrives. A system can have excellent escalation logic — correctly identifying every case that should go to a human — and still fail Article 14's requirement if the point the case escalates to offers only a review capability with no ability to override or halt. Escalation without a capable intervention point at the destination is oversight theater: the risky case correctly gets flagged, and then nothing effective can actually be done about it.

Reading this table's third column is the design checklist Article 14 is effectively asking a system architect to satisfy: for each of the four actions, is there an actual mechanism in the system that makes it possible, or does the system merely assume a human "could" do this in principle without ever building the point where they actually can?

Constructed scenario, invented for teaching, illustrative only. An agent autonomously manages a company's cloud infrastructure spending, with the authority to shut down underutilized compute resources to control cost. A compliance audit checks whether the system satisfies Article 14 for this specific high-risk action.

Step 1 — check for review. The system logs every shutdown decision with the resource identifier, utilization metrics that triggered it, and a timestamp, visible in a dashboard a human can inspect. Review: satisfied — a human can see what happened and why, connecting to M10-04's traceability requirement.

Step 2 — check for approve. Shutdown actions execute immediately upon the agent's decision, with no gate waiting for a human signal beforehand. Approve: not satisfied for the pre-action case — nothing pauses for a human's explicit permission before the shutdown takes effect. (A human can review after the fact, but review is not the same as approval before an effect occurs, per the section 1 distinction.)

Step 3 — check for override. Once a resource is shut down, there is no built-in mechanism for a human to substitute a different action — say, scaling the resource down rather than shutting it off entirely — before the shutdown itself takes effect. Override: not satisfied, for the same structural reason approval is not: nothing pauses at a decision point where an alternative action could be substituted.

Step 4 — check for halt. The system includes an administrative control that can immediately stop the agent from taking any further shutdown actions across the whole fleet, usable at any time regardless of what the agent is currently doing. Halt: satisfied — a human can stop the process, even though they cannot intervene on a single decision before it takes effect.

Step 5 — read the audit result. This system satisfies review and halt, but not approve or override, for this specific action. That is a real, describable gap: a human can see what happened and can stop the agent from doing more of it, but cannot approve or redirect any individual shutdown decision before it takes effect. Whether that gap is acceptable depends on the actual stakes of a single wrong shutdown — if an individual bad shutdown decision could take down a production service, the missing approve/override capability is a serious compliance and safety gap; if the worst case is a resource getting turned back on with minor inconvenience, the halt capability alone might be judged adequate. Either way, the audit's value comes from checking all four actions explicitly against the architecture, rather than concluding "there's a dashboard, so oversight exists" and stopping there.

A second scenario, this time comparing several action types the same infrastructure-management agent from section 4 might take, to work through how the "before an effect becomes irreversible" placement rule from section 2's L2 actually plays out across a range of stakes.

Constructed scenario, invented for teaching, illustrative only.

Action type                        Reversibility if wrong          Intervention design
------------------------------------------------------------------------------------
Scaling a resource up               Fully reversible — scale back    Post-hoc review sufficient;
(costs money, no data risk)         down at any time, no data loss   pre-effect gate adds latency
                                                                       for little added protection

Shutting down a resource            Reversible with effort — may     Pre-effect approve gate for
(risk: service disruption)          cause a service outage before    resources above a usage
                                     it is noticed and restarted      threshold; halt capability
                                                                       for the whole fleet regardless

Deleting a resource's stored data   Irreversible — deleted data      Pre-effect approve gate,
(risk: permanent data loss)         cannot be recovered              mandatory, no exceptions;
                                                                       override capability to
                                                                       redirect to an archive
                                                                       action instead of deletion

Step 1 — read why the three rows get different treatment. The reversibility column is doing the actual work here: an action whose consequence can be fully undone at negligible cost (scaling up) does not need the added latency of a pre-effect gate, because a post-hoc review that catches an unnecessary scale-up and reverses it loses very little. An action whose consequence is difficult but not impossible to undo (a shutdown causing a service disruption) justifies a pre-effect gate for the higher-usage, higher-stakes cases specifically, while a fleet-wide halt capability remains available regardless of usage level as a backstop. An action whose consequence is genuinely irreversible (permanent data deletion) justifies a mandatory pre-effect gate with no exceptions, because no amount of post-hoc review can undo data that no longer exists.

Step 2 — connect this back to Article 14's four actions concretely. For the data-deletion row, "approve" is the load-bearing action — nothing proceeds without an explicit human signal beforehand, because review-after-the-fact provides no protection once the data is gone. For the scaling-up row, "review" alone is arguably sufficient, because the low stakes and full reversibility mean the added latency of requiring approval before every scale-up is not justified by the risk it would prevent — an instance of M10-01's cost-versus-benefit arithmetic applied specifically to where a gate belongs, not just whether one exists at all.

Step 3 — see the general design rule this produces. The correct intervention design is not "the same four actions, uniformly available for every action type an agent can take" — it is a stakes-and-reversibility-weighted decision about which of the four actions need a pre-effect gate, which can be satisfied by post-hoc review, and which need a fleet-wide backstop regardless of any single decision's stakes. Applying the heaviest intervention design (mandatory pre-effect approval on every action) uniformly would reintroduce the full cost M10-01 priced out for every single decision, most of which do not carry data-deletion-level stakes; applying the lightest design (review only) uniformly would fail Article 14 for exactly the irreversible actions where it matters most.

Seven mistakes, and every one of them traces back to the same gap: authority to intervene existing on paper while the technical mechanism that would let it act does not exist in the system itself.

Review gives a human visibility into what happened, but visibility is not the same as the ability to change an outcome. For a genuinely high-stakes, hard-to-reverse action — the data-deletion example in section 5 — a reviewer who can only inspect the deletion after it has already occurred has no way to prevent the harm the regulation is concerned with; the data is already gone by the time review happens. Article 14 names approve, override, and halt alongside review specifically because a regulation aimed at preventing harm from high-risk systems has to require a mechanism that can act before the harm occurs, not merely document it afterward. A system that offers review as its only intervention action is documenting outcomes, not preventing them, and documentation alone does not satisfy what the regulation is actually trying to accomplish.

Article 14 requires a high-risk AI system to be designed for effective human oversight during use, specifically by providing points where a human can review, approve, override, or halt the system's actions. The requirement is architectural, not organizational: it is not satisfied merely by having a qualified human somewhere in an organization with the authority to intervene, but by the system itself containing the specific gates, controls, and visibility that make review, approval, override, and halting technically possible at the points where they matter.

Escalation is the mechanism that decides a case is risky enough to route to a human and sends it there; the intervention point is the destination that case escalates to, and what a human can actually do once it arrives. A system can have excellent escalation logic — correctly flagging every case that needs human attention — and still fail to provide effective oversight if the destination those cases escalate to only supports review, with no way to approve, override, or halt the action in question. Satisfying Article 14 requires both halves working together: accurate routing, and a capable destination once the case lands.

• Article 14 names four distinct actions — review, approve, override, halt — and a system needs a designed mechanism for each, not just organizational authority for a human to act somehow.
• An intervention point is architectural, not organizational — a qualified reviewer with no actual gate in the system to act through does not satisfy the regulation's intent.
• Intervention points belong before a consequential effect becomes irreversible, whenever the stakes justify the added latency a pre-action gate costs.
• Escalation and the intervention point are two different things — escalation routes a risky case; the intervention point is what a human can actually do once the case arrives there, and both have to work together.
• Auditing a system against all four actions explicitly, as this lesson's worked example does, surfaces gaps that a vague "oversight exists" assessment misses — a system can satisfy some of the four actions and not others for the same risky action type.

⭐ THE EARNED INSIGHT

"A human can intervene" is not a single fact about a system — it decomposes into four separate, independently satisfiable or failable capabilities, and a regulation that names all four is implicitly warning against exactly the shortcut this lesson's worked example demonstrates: building the two that are easy (review, halt) and quietly skipping the two that require harder architectural work (approve as a real pre-action gate, override as a real substitution mechanism), then describing the result as "the system has human oversight" without specifying which of the four that oversight actually covers.

Where a human can intervene, and what regulation requires of that intervention, only matters if the interface through which they intervene is one a human can actually use under real time pressure. Next: M10-06 closes this module by turning to exactly that interface — the intuitive UI that makes review, approval, override, and halting practical rather than theoretical, and the surface on which every oversight mechanism this module has covered actually gets exercised.