Article 14 of the EU AI Act requires high-risk AI systems to support effective oversight by natural persons while the systems are in use. For an AI agent, that requirement reaches the moments where a generated output becomes an action: sending a payment, changing a customer record, publishing content, calling a sensitive tool, or making a recommendation that affects a person. This guide turns the five Article 14 oversight capabilities into an operating design for approvals, overrides, safe interruption, reviewer competence, and evidence. Regulation (EU) 2026/1744, published on 24 July 2026 and in force from 27 July 2026, amended Article 113 so the high-risk rules apply from 2 December 2027 for Article 6(2) and Annex III systems and 2 August 2028 for Article 6(1) and Annex I product-embedded systems. The Article 14 control text is unchanged. General information only; confirm classification, role, applicable dates, and sector-specific duties with qualified counsel.
Article 14 in one page
Article 14 sits in Chapter III, Section 2 of Regulation (EU) 2024/1689. Its scope is high-risk AI systems. The system must be designed and developed with suitable human-machine interface tools so natural persons can oversee it effectively during use.
The purpose is to prevent or minimise residual risks to health, safety, or fundamental rights when the system operates as intended or under reasonably foreseeable misuse. Measures must match the system’s risks, autonomy, and context. The provider can build measures into the system, identify measures for the deployer to implement, or use both routes.
Paragraph 4 defines the practical capability test. The assigned person needs enough visibility and authority to understand, monitor, interpret, disregard, override, reverse, intervene, and interrupt. A named owner and a policy document are supporting governance. The deployed controls still have to make those actions possible.
| Legal hook | Operational control | Evidence to preserve |
|---|---|---|
| Article 14(1)–(2) | Place effective human oversight in the live operating path and connect it to residual risks from intended use and foreseeable misuse. | Risk analysis, intended-purpose boundary, misuse scenarios, oversight design, and live control tests. |
| Article 14(3) | Allocate built-in provider measures and deployer-operated measures. Scale them to risk, autonomy, and context. | Provider instructions, deployer configuration, control owner, version, and proportionality rationale. |
| Article 14(4)(a) | Show capabilities, limitations, current state, anomalies, dysfunctions, and unexpected performance to the overseer. | Reviewer view, alert history, operating metrics, anomaly records, and follow-up actions. |
| Article 14(4)(b)–(c) | Train the overseer on automation bias and provide the context and interpretation tools needed to assess the output. | Training record, limitations briefing, evidence presented with each review, and reviewer rationale. |
| Article 14(4)(d) | Give the overseer authority and a usable path to decline use, disregard an output, or override or reverse it. | Decision or override record, reviewer identity and authority, rationale, timestamps, and resulting state. |
| Article 14(4)(e) | Provide intervention and interruption that brings the system to a safe state. | Stop request, propagation result, affected work, final state, recovery approval, and tested safe-stop procedure. |
| Article 14(5) | For the specified Annex III point 1(a) remote biometric identification systems, require separate verification and confirmation by at least two competent, trained, and authorised natural persons, subject to the stated exception. | Two distinct verification records, reviewer qualifications and authority, timestamps, and the exception basis where used. |
Provider design and deployer operation form one control
Article 14 divides implementation across the provider and deployer. The provider identifies the measures, builds in technically feasible controls, and describes them in the instructions for use. Article 13(3)(d) requires those instructions to cover the human oversight measures and the technical measures that help deployers interpret outputs.
Article 26(2) makes the deployer responsible for assigning oversight to natural persons with the necessary competence, training, authority, and support. The deployer also configures the controls for its own people, data, policies, workflow, and operating environment.
| Provider | Deployer | Shared acceptance test |
|---|---|---|
| State capabilities, limitations, intended purpose, foreseeable risk conditions, and interpretation methods. | Map those statements to the real operating context and the people affected. | An overseer can identify when the system is outside its intended boundary. |
| Build or specify monitoring, override, reversal, and safe-interruption measures. | Configure access, escalation, staffing, service levels, and recovery authority. | A drill proves that the assigned person can exercise the control in time. |
| Describe required inputs, logging mechanisms, maintenance, and relevant system changes. | Connect source data, local policies, incident response, and record retention. | The record reconstructs the request, control decision, human action, and result. |
Choose oversight intensity by action risk
Article 14 names three proportionality variables: risk, autonomy, and context of use. It leaves organisations to turn them into control thresholds. Human-in-the-loop, human-on-the-loop, and human-in-command are useful operating labels for that design. They are not terms defined in Article 14.
Classify the individual action as well as the overall AI system. One agent can draft a summary, query a record, update a status, and release a payment in the same run. Each action has a different consequence and reversibility profile.
| Action tier | Suggested oversight | Typical trigger | Control objective |
|---|---|---|---|
| Tier A: consequential or hard to reverse | Human-in-the-loop before the side effect, with a second reviewer where policy or applicable law requires one. | Material financial action, adverse decision, external publication, deletion, privilege change, or safety-critical command. | Keep the action on hold until an authorised person decides with sufficient context. |
| Tier B: material and reversible | Bounded execution with active monitoring, exception routing, and a tested intervention path. | Sensitive record update, customer communication, case routing, or an action near a policy threshold. | Detect exceptions quickly and let the overseer pause, correct, reverse, or escalate. |
| Tier C: routine and bounded | Published policy boundaries, monitoring, representative sampling, and escalation on anomaly or drift. | Read-only retrieval, categorisation, drafting, or a low-consequence update within tight limits. | Maintain visibility and intervention authority while directing human attention to meaningful exceptions. |
Build approval gates around the side effect
Article 14(4)(d) gives the overseer authority in a particular situation to decline use, disregard an output, or override or reverse it. For an irreversible tool action, a pre-execution gate is usually the strongest implementation. The system constructs the proposed action, evaluates the applicable rules, and holds the side effect until the authorised person decides.
The reviewer needs the decision context in one place. Show the action, target, material parameters, agent and requesting principal, applicable rule and reason, source evidence, known uncertainty and limitations, consequence, reversal path, and decision deadline. A bare approve button beside a generated sentence gives the reviewer too little information to exercise meaningful oversight.
Treat timeout, reviewer unavailability, stale evidence, and failed policy evaluation as explicit states. Each state needs a defined safe outcome. A pending request must never become an implicit approval because a queue, webhook, or reviewer is unavailable.
- Before the gate: bind a stable request identifier to the exact proposed action and parameter set.
- At the gate: verify reviewer eligibility and separation-of-duties rules at decision time.
- During review: surface current evidence, limitations, policy reason, consequence, and available alternatives.
- At decision: record approve, reject, request changes, or escalate with identity, authority, rationale, and timestamp.
- Before execution resumes: confirm that the action, policy, evidence, and authority snapshot remain current.
- After execution: attach the real downstream result or failure to the same record.
Design override, reversal, and safe stop as separate controls
Article 14(4)(d) and 14(4)(e) describe related capabilities with different effects. An override changes how one output is used. A reversal restores or compensates for an action that already happened. An intervention changes a running operation. An interruption halts the system through a stop button or similar procedure and brings it to a safe state.
A stop control earns that label when the request reaches every relevant worker, tool call, delegated agent, queued job, and retry path. The system must define which in-flight operations can finish, which are cancelled, which credentials or leases are revoked, and what data remains trustworthy. It also needs a controlled recovery path.
Test propagation and final state under realistic failure conditions. Include a slow external API, a lost worker heartbeat, a queued retry, a partially completed multi-step action, and an unavailable evidence service. Record the time from operator action to containment and every operation that remained in flight.
| Control | Required design question | Acceptance evidence |
|---|---|---|
| Disregard output | Can the reviewer prevent this output from influencing the downstream decision? | Output disposition, reviewer rationale, and downstream decision state. |
| Override | Can an authorised person replace the proposed result while preserving both versions? | Original output, replacement, reviewer authority, reason, and resulting action. |
| Reverse | Can a completed action be undone or compensated safely? | Original action, reversal or compensation request, outcome, and unresolved residue. |
| Interrupt | Can the operator stop active and queued work and reach the declared safe state? | Stop request, propagation trace, containment latency, cancelled work, final state, and restart approval. |
Give overseers competence, training, authority, and support
Article 26(2) supplies the deployer-side personnel standard. The assigned natural persons need the competence, training, authority, and support required to carry out oversight. Recital 73 also connects effective oversight to competence, training, and authority.
Competence covers the domain decision and the AI system. A credit reviewer may understand lending policy while lacking the system knowledge needed to recognise distribution shift, missing source data, or an out-of-scope request. A platform operator may understand the system while lacking authority to decide the customer outcome. The role design must close both gaps.
Article 26(2) sets an outcome-based standard and no fixed training interval. Set a cadence from the action risk, rate of system change, operating volume, incident history, and reviewer performance. Trigger renewed training after material model, policy, data, interface, or intended-purpose changes.
- Competence: domain rules, affected rights, system capabilities and limitations, input quality, and known failure modes.
- Training: automation bias, interpretation tools, escalation criteria, stop and recovery drills, and evidence handling.
- Authority: access to decline, override, reverse, interrupt, escalate, and delay an action without operational pressure to approve.
- Support: sufficient time, staffing, specialist escalation, usable interfaces, current instructions, and incident assistance.
- Ongoing assurance: queue load, decision quality, override rate, disagreement, stale requests, drill performance, and training renewal.
Design against automation bias
Article 14(4)(b) expressly calls out the tendency to rely or over-rely on AI output, especially where the system supplies information or recommendations for a human decision. A reviewer who approves every recommendation adds latency and a misleading appearance of control.
The interface and operating procedure should make independent judgment possible. Present source evidence and material limitations before the recommendation rationale. Distinguish observed facts from model inference. Avoid defaults that preselect approval. Rotate or sample cases that expose reviewers to errors. Measure agreement and overrides by action type, reviewer, policy, and system version, then investigate both unusual conformity and unusual disagreement.
- Require a reason tied to the evidence for consequential approvals and overrides.
- Mask the model recommendation during an independent first-pass review where the risk justifies it.
- Insert known test cases and controlled counterfactuals into reviewer assurance exercises.
- Alert on rapid decisions, repeated identical rationale, high reviewer load, and sustained near-perfect agreement.
- Give reviewers a clear route to challenge source data, request specialist input, or suspend the workflow.
Assemble evidence that proves the control operated
Annex IV places human oversight measures, including technical interpretation measures, in the provider’s technical documentation. Article 13 carries the measures into the instructions for use. Article 12 requires high-risk systems to support automatic event logging over their lifetime, while Article 19 and Article 26 assign retention duties for logs under provider and deployer control.
A practical Article 14 evidence pack therefore draws from several connected duties. It should show the design, the assigned people, the live decisions and interventions, the resulting state, and the control tests. Cryptographic integrity can show whether an exported record changed. It cannot establish that every relevant event was captured or that the chosen control was legally sufficient.
| Evidence family | Minimum useful record | Assurance question |
|---|---|---|
| Scope and risk | Classification, role, intended purpose, action inventory, affected people, foreseeable misuse, and residual risk. | Why did this action receive this oversight intensity? |
| Control design | Provider instructions, deployer configuration, policy version, reviewer routing, override path, safe-state definition, and change history. | Could the assigned person exercise every required capability? |
| People and authority | Role description, eligibility rule, training, competence assessment, delegated authority, support model, and coverage. | Was the person qualified, supported, and authorised at decision time? |
| Decision and action | Proposed action and parameters, evidence presented, policy result, reviewer identity, decision, rationale, timestamps, and actual downstream outcome. | Did the side effect match the reviewed request and recorded decision? |
| Intervention | Override, reversal, stop, escalation, propagation, final state, recovery approval, and unresolved impact. | Did intervention work within the required time and reach the safe state? |
| Effectiveness | Queue load, stale items, decision latency, agreement, overrides, incidents, drills, sampled reviews, findings, and remediation. | Does the oversight model continue to reduce the identified risk? |
How KLA implements the governed control path
The KLA Control Plane governs instrumented agent actions at decision points. The KLA Policy Engine evaluates a proposed tool call against published rules and returns allow, warn, require_approval, or block. A require_approval result holds the proposed call and creates a Decision Request for Decision Desk. A block prevents the governed call from reaching the tool.
Decision Desk checks decision permission, the required reviewer role, and pending state for governed tool-call Decision Requests. It records the decision actor, role snapshot, decision, reason, and time. The request exposes a due time. Late-decision rejection and requester-reviewer identity comparison are absent from the current governed tool-call decision path. Treat deadline enforcement and requester-decider separation of duties as deployment controls outside that path until they are enforced end to end. Lineage Explorer and Audit Trail surface the policy and human-decision records attached to governed execution. Evidence Room can package selected records into a Sealed Evidence Bundle whose service and tenant signatures, artifact hashes, and bundle Merkle root can be checked offline.
These capabilities implement parts of an Article 14 operating model. The organisation still owns legal classification, proportionality, provider-deployer allocation, reviewer competence, staffing, operating procedures, and system-specific safe-state engineering. A pre-action block at one checkpoint does not stop every worker or reverse every external side effect. Instrument every consequential path and test interruption across the deployed system.
| Control need | KLA capability | Organisation or system owner |
|---|---|---|
| Risk-based routing | Policy Builder expresses action conditions and the KLA Policy Engine returns one of four outcomes. | Classify the system and actions, approve the rules, and keep them current. |
| Human decision | Decision Desk works a held Decision Request and records the decision context. | Assign qualified reviewers, authority, support, service levels, and escalation. |
| Prevented action | require_approval holds and block prevents the instrumented tool call before execution. | Cover every consequential path, define failure behavior, and test bypass resistance. |
| Intervention and safe stop | Policy can prevent new governed calls and route exceptions for human action. | Propagate interruption through workers, queues, tools, credentials, retries, and recovery to a verified safe state. |
| Evidence integrity | Lineage Explorer and Audit Trail surface governed records. Evidence Room packages selected records with signatures, artifact hashes, and Merkle-root membership. | Confirm source completeness, retention, access, legal sufficiency, and the evidence population. |
A 10-step Article 14 implementation sequence
Start with one consequential agent action and prove the complete path. Expand after the control works under nominal, failure, and recovery conditions.
- 1. Confirm scope. Record the system classification, your provider or deployer role, intended purpose, context, and applicable date.
- 2. Inventory actions. List every read, recommendation, write, external communication, financial action, permission change, delegation, and recovery action.
- 3. Score action risk. Use consequence, reversibility, affected rights, volume, detectability, autonomy, and foreseeable misuse.
- 4. Assign oversight. Choose pre-execution review, active monitoring with intervention, or bounded operation with sampling and escalation.
- 5. Design the reviewer view. Present the proposed action, evidence, policy, uncertainty, limitations, consequence, alternatives, and deadline.
- 6. Implement authority. Enforce reviewer eligibility, separation of duties, escalation, timeout behavior, and stale-request invalidation.
- 7. Engineer intervention. Build disregard, override, reversal, interruption, safe-state, and controlled-restart paths.
- 8. Prepare people. Assess competence, train on the system and automation bias, grant authority, and provide operational support.
- 9. Capture the record. Correlate the request, control result, human action, downstream outcome, and integrity evidence.
- 10. Test effectiveness. Run bypass, outage, overload, partial-action, lost-worker, stale-evidence, stop-propagation, and recovery exercises; track remediation.
Frequently Asked Questions
Does EU AI Act Article 14 apply to every AI agent?
Article 14 is a Chapter III requirement for high-risk AI systems. An AI agent falls within it when the relevant AI system is classified as high-risk and the obligation applies on the relevant date. Other laws, contracts, sector rules, or internal risk policy can still require human oversight for agents outside Article 14.
Does Article 14 require human approval for every high-risk AI action?
Article 14 requires effective oversight measures that are proportionate to risk, autonomy, and context. It gives overseers the ability to monitor, interpret, disregard, override, reverse, intervene, and interrupt as appropriate. A pre-execution approval gate is a strong design for consequential or hard-to-reverse actions. Routine bounded actions may use monitoring, sampling, and exception routing where that model remains effective for the identified risk.
What is the difference between override and stop?
An override changes how a particular output is used or replaces it. A reversal undoes or compensates for a completed action. A stop interrupts system operation and brings it to a defined safe state. Each control needs its own authority, propagation, outcome, and evidence.
Who can perform human oversight under the EU AI Act?
Article 26(2) requires deployers of high-risk AI systems to assign oversight to natural persons with the necessary competence, training, authority, and support. The right profile depends on the domain decision, system limitations, action risk, and operating context.
What evidence supports an Article 14 review?
Useful evidence connects the oversight design, provider instructions, deployer configuration, reviewer competence and authority, proposed action, evidence presented, policy result, human decision, intervention, actual outcome, and control tests. Article 14 works alongside Annex IV technical documentation, Article 13 instructions, Article 12 logging, and the provider and deployer duties in Articles 19 and 26.
Does a tamper-evident evidence bundle prove Article 14 compliance?
A verified bundle can show that the exported artifacts, hashes, signatures, and bundle Merkle root remain intact. Legal compliance also depends on classification, control design, source completeness, reviewer competence, operating effectiveness, and other applicable duties. Treat integrity verification as one evidence property within the wider assessment.
How does Article 14 connect to Article 12 and Article 26?
Article 14 defines the human oversight capabilities for high-risk AI systems. Article 12 logging supports traceability of the system’s operation. Article 26 deployer duties cover operating measures, assigned oversight personnel, monitoring, incident action, and retention of logs under deployer control. The three articles form a connected operating and evidence model.
Key Takeaways
Effective Article 14 oversight is a live control path: the right person receives enough context, holds real authority, can change or stop the outcome, and leaves a record tied to the resulting system state. Use the accountable autonomy guide to set the broader operating model, the AI agent accountability matrix to assign roles, and the KLA human oversight architecture to inspect how Decision Requests, Decision Desk, Execution Lineage, and evidence connect. General information only; confirm your obligations and implementation with qualified legal, risk, and technical specialists.