Article 14: human oversight for high-risk AI

What Article 14 actually says

Article 14(1) requires that 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."

In practice, this breaks down into four things the human must be able to do (Article 14(4)):

1. Understand the AI system's capacities and limitations, including the degree of accuracy and the conditions under which it can be expected to function correctly.
2. Monitor the system's operation, including by being able to detect anomalies, dysfunctions, and unexpected performance.
3. Decide not to use the system, disregard its output, or override its output in any particular situation.
4. Intervene or stop the system entirely via a "stop button" or similar mechanism.

The provider must build this into the system design. The deployer must ensure trained staff actually exercise the oversight. Both sides have obligations.

What this looks like in code

The simplest way to think about Article 14 compliance at the code level: does every path from an AI model output to a user-facing action pass through a human review gate?

Consider a loan approval system. The AI model scores an application. If that score directly triggers an approval or rejection email with no human in the loop, Article 14 has a problem. If the score goes into a queue for a credit officer to review before the decision is communicated, that is an oversight pattern.

# No human oversight (Article 14 problem)
def process_application(app):
    score = model.predict(app.features)
    if score > threshold:
        send_approval_email(app)     # AI output goes directly to user
    else:
        send_rejection_email(app)

# With human oversight (Article 14 pattern)
def process_application(app):
    score = model.predict(app.features)
    recommendation = "approve" if score > threshold else "review"
    queue_for_officer_review(app, recommendation, score)
    # Human reviews before any communication to applicant

The difference is one function call. The regulatory difference is whether you can show a natural person reviewed the decision before it affected someone.

How Regula checks for oversight patterns

Regula's oversight command does cross-file data flow analysis. It traces AI model outputs from the file where they are generated through the codebase to the point where they reach an endpoint, API response, or user-facing function. At each step, it checks whether the data passes through a human review gate.

$ regula oversight .

Article 14 Human Oversight Analysis
====================================
Traced 3 AI output flows across 12 files.

Flow 1: model.py:predict() -> api.py:recommend() -> review.py:officer_queue()
  Status: OVERSIGHT DETECTED
  Review gate: review.py:officer_queue (line 42)

Flow 2: model.py:predict() -> batch.py:nightly_run() -> email.py:send_result()
  Status: NO OVERSIGHT
  AI output reaches email.py:send_result() with no human review gate.

Flow 3: model.py:predict() -> dashboard.py:display_score()
  Status: DISPLAY ONLY (no action taken on output)

The output above is illustrative. Your actual results depend on your codebase structure. The point is that Regula traces the flow, not just the presence of a function called review.

What code scanning covers and what it does not

Regula can detect:

• Whether human review functions exist in the call chain between AI outputs and user-facing actions
• Whether AI model outputs are queued for review rather than acted on directly
• Whether "stop" or "override" mechanisms exist in the codebase

Regula cannot verify:

• Whether the human review is meaningful (a rubber-stamp review fails Article 14 even if the code has a review gate)
• Whether oversight staff are adequately trained (Article 14(4)(a))
• Whether the system provides enough information for the human to understand why it made a particular recommendation
• Whether the "stop button" actually works under load in production

Presence is not effectiveness. A codebase can pass Regula's oversight check and still have rubber-stamp oversight that a regulator would reject. Runtime testing, user studies, and operational audits are needed to verify the oversight is real.

Using the gap analysis

The gap analysis scores Article 14 based on detected oversight patterns:

$ regula gap --project .

Article 14 — Human oversight
  Score:    45 / 100
  Status:   PARTIAL
  Evidence: 1 of 3 AI output flows pass through a review gate.
  Gap:      batch.py nightly_run flow has no human oversight.
  Effort:   ~3-5 hours to add review queue to batch pipeline.

A score below 50 means most AI output flows lack oversight gates. A score above 80 means all traced flows pass through a review point. A score of 100 is rare and requires every AI output path to have a verifiable human review mechanism.

Practical steps

1. Run regula oversight . to see which AI output flows have review gates and which do not.
2. Prioritise flows that affect people. An AI output that goes into an internal dashboard is lower risk than one that triggers an automated email to a customer.
3. Add review queues, not just approval buttons. Article 14(4)(c) requires the ability to "disregard" the AI output. A simple approve/reject button is not enough if the human cannot see why the AI made its recommendation.
4. Document the oversight design. Use regula conform --organisational to generate a structured self-assessment that covers Article 14 requirements.
5. Test the override mechanism. Can an operator actually stop the system mid-process? Test it. regula guardrails . checks for the presence of guardrail implementations, but you need runtime testing to verify they work.

Deadline

Article 14 applies to high-risk AI systems. The Digital Omnibus (provisional agreement 7 May 2026, approved by European Parliament 16 June 2026) defers Annex III high-risk obligations to 2 December 2027. Annex I product-embedded AI is deferred to 2 August 2028. The Council approved it on 29 June 2026; publication in the Official Journal is expected before 2 August 2026. Until Official Journal publication, the original 2 August 2026 deadline remains legally binding.

---

Related

• Article 9: risk management system requirements
• EU AI Act risk tiers explained with code examples
• How to classify your AI system under the EU AI Act
• Does the EU AI Act apply to you?
• About Regula: what it does and does not do

---

Last verified: 25 June 2026 · Author: Kuziva Muzondo · Not legal advice. Regula identifies risk indicators in code for developer review. It does not determine compliance or replace professional legal counsel.