EU AI Act Article 14: What Human Oversight Actually Means — and How to Prove It

Here is a question most compliance teams get wrong: does EU AI Act Article 14 require a human to approve every AI decision before it takes effect?

It does not. And this misconception is causing organisations to either massively over-engineer their oversight processes, or to assume they are compliant when they are not.

Article 14 requires something more specific than "a human checks the AI." It requires that you can prove a named, qualified, authorised person had the genuine ability to understand, question, override, and stop the AI — and that this was not just policy, but practice.

That distinction — between having an oversight process and being able to evidence one — is where most Article 14 compliance gaps actually live.

First, the timeline question everyone is now asking

Following the AI Omnibus agreement reached on 7 May 2026, the timeline picture changed. Some Annex III high-risk categories — including biometric systems, critical infrastructure, education, and certain employment systems — now have a revised deadline of 2 December 2027. Systems integrated into physical products face an August 2028 deadline.

But this does not mean August 2026 no longer matters. Transparency obligations under Article 50 still apply from August 2026. And critically, many of the most common high-risk AI deployments in financial services, credit scoring, and employment decision support retain their August 2026 obligations under the original schedule.

If you are unsure which deadline applies to your specific AI system, do not assume the extended date. Check your system against the current Annex III categories and take advice if the position is unclear. Getting this wrong in the other direction — believing you have until 2027 when you do not — carries fines of up to €15 million.

What Article 14 actually says

The Article requires that high-risk AI systems be designed so they "can be effectively overseen by natural persons during the period in which they are in use." Four capabilities are specified:

The oversight person must be able to understand the system's capabilities and limitations — not just read its outputs, but understand what conditions might cause it to behave unreliably, what its known failure modes are, and how confident its outputs actually are.

They must be able to detect when something is wrong — anomalies, unexpected performance, results that do not align with what the system should be doing.

They must understand and actively resist automation bias — the tendency to trust the AI's recommendation without applying independent judgement. The regulation specifically names this. It is not enough to tell someone they can override the AI. They need to understand why they might need to, and be trained to recognise the pressure not to.

And they must have the authority — not just the technical access, but the genuine organisational authority — to override or halt the AI system. This one fails more often than it should. Many oversight arrangements give the oversight person the ability to flag a concern, not to act on it without approval from above. That is not Article 14 compliance.

The provider versus deployer split

This is where organisations deploying third-party AI systems — which is most of them — sometimes get confused about who is responsible for what.

The AI system provider (the company that built it) is responsible for designing oversight capabilities into the system: the monitoring interfaces, the explainability tools, the override mechanisms, and the instructions for use that specify what competencies the oversight person needs.

Your organisation, as the deployer, is responsible for actually implementing those capabilities. Assigning the right person. Making sure they have the training the instructions specify. Giving them the authority the role requires. And maintaining evidence that it all works in practice.

One important flag: if your organisation has significantly modified an AI system beyond its original intended use — not just configured it, but changed how it functions — you may have been reclassified as a provider under Article 25. That carries a different set of obligations. It is worth checking if this applies to you.

What auditors will actually look for

When a regulator or external auditor reviews your Article 14 position, they are not reading your governance policy. They are asking three things:

Is there a named role with documented responsibility for this AI system's oversight? Not a team or a function. A role with a job title, written responsibilities, and a name currently sitting in it.

Does that person have documented authority to override the AI — and can they exercise it without seeking approval first? There is a useful test here. If the halt procedure takes more than a few minutes to execute, or requires the oversight person to call IT or get manager sign-off before acting, it does not satisfy the spirit of Article 14. The requirement is for meaningful, timely intervention — not theoretical access.

Can you show it happened? This is the gap that will catch the most organisations. A policy describes what should happen. A log shows what did happen. Auditors want the logs — override records, review completion rates, escalation trails, monthly performance reviews of the AI's outputs.

Showing a SHAP chart to an oversight officer with no data science background and calling it explainability is compliance theatre, as one academic commentary on Article 14 put it. The explanation has to be tailored to the actual competence level of the person doing the oversight, not to a technical reviewer who will never use the system.

A practical example

Take a credit scoring AI used to assess loan applications. The compliance team has written a policy stating that a Senior Credit Risk Manager reviews AI recommendations before any decision is communicated to the applicant. The policy looks solid on paper.

In practice: the manager receives the AI's recommended decision via email with a confidence score they have never been trained to interpret. There is no documented procedure for what they should do if they disagree with the recommendation. There are no logs of whether any decisions have ever been overridden. The manager has not been told they have the authority to reject the AI's output without escalating first.

This is the most common failure pattern — not bad intent, just the gap between a policy and an evidenced process.

What Article 14 compliance looks like for this system: the Senior Credit Risk Manager role has an updated job description that explicitly includes responsibility for oversight of the credit scoring AI. They completed documented training on the system's scoring methodology, its known limitations, and the risk of automation bias, delivered in March 2026 and recorded in the HR system. All applications where the AI score is below a defined threshold are reviewed before any decision is communicated. Override decisions are logged in the LOS with a mandatory reason code. The override rate for Q1 2026 was 12.4%. This is reviewed monthly by the Head of Risk.

The difference between the first version and the second is not the existence of oversight — both organisations had a person reviewing decisions. The difference is evidence.

The five documentation gaps most commonly found

The role is assigned but the authority is not written down. "We have a reviewer" and "the reviewer has documented authority to override without approval" are different statements. Write it down.

Training happened but was never recorded. For compliance purposes, an unrecorded training event did not happen. Even an informal briefing from the AI vendor needs a record — who attended, what was covered, when it took place.

The override mechanism exists technically but not operationally. The system allows overrides. Nobody has been told what the threshold is for using one, and nobody has ever pressed the button. Untested oversight is not effective oversight.

Policy-level evidence but no operational evidence. The governance document is not the evidence. The logs, the review records, the monthly reporting — those are the evidence. Regulators will ask for both.

Oversight documented at system level but not at decision type level. If your AI system handles several types of decisions — routine applications and exceptions, say — the oversight process for each may need to be documented separately. A single oversight description for a system handling multiple decision types may not be sufficient.

Where to start

If you are approaching August 2026 and Article 14 documentation is not in place, the practical starting point is not the policy. The policy can follow. Start by identifying the AI systems you deploy that fall under Annex III, assigning the oversight role for each, and opening an honest conversation with whoever holds that role about whether they actually have the training, tools, and authority the Article requires.

Then document what exists. And where it does not exist yet, create it.

The time available to do this before the first enforcement actions arrive is now measured in weeks, not months. The documentation work takes longer than most compliance teams expect.

References: EU AI Act, Official Journal of the European Union, L-series, 2024. AI Omnibus political agreement, 7 May 2026. Article 14 text sourced from the European Commission AI Act Service Desk (ai-act-service-desk.ec.europa.eu). This article does not constitute legal advice.