Home Blog Governance
Governance

EU AI Act Article 14: human oversight in plain English

Article 14 is the part of the EU AI Act that talks about people overseeing AI. Here is what it says, when it applies and what it means for the workflows you build.

By The Cadrix team6 min read
A row of European Union flags in front of the Berlaymont building in Brussels
Photo by Guillaume Périgois on Unsplash

This post is a plain-English reading by a software team, not legal advice. Whether the Act applies to you, and in which role, is a question for a qualified lawyer. Every claim below links to its source.

First: does it apply to you at all?#

Article 14 is about high-risk AI systems. It is not a general rule for every chatbot or workflow. The Act decides what counts as high risk in two ways: AI that is a safety component of certain regulated products, and AI used in the areas listed in Annex III.

Annex III has eight headings: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice and democratic processes. Under employment, the examples include systems that screen applications or rank candidates, or that influence promotion, termination or task allocation. Under essential services, examples include credit scoring and risk assessment for life and health insurance.

So an agent that summarises meeting notes is very unlikely to be in scope. An agent that ranks job applicants or scores customers for credit probably is. Most business workflows sit somewhere in between, and the classification is the first thing to settle.

The dates moved#

The original start date for Annex III high-risk obligations was 2 August 2026. After the "Digital Omnibus on AI" was adopted in mid-2026, law-firm summaries report new dates: 2 December 2027 for Annex III systems and 2 August 2028 for those embedded in regulated products. The Omnibus entered into force on 27 July 2026, according to those summaries.

We read the dates in the consolidated text of Article 113 on a third-party site and in several law-firm notes. For anything you rely on, check the Official Journal.

What Article 14 actually asks for#

In paraphrase, the article says high-risk systems must be designed so natural persons can effectively oversee them while they are in use. The aim is to prevent or reduce risks to health, safety or fundamental rights. The oversight must fit the system's risks, level of autonomy and context. The measures can be built in by the provider, or identified by the provider for the deployer to put in place.

Then it lists what the people doing the overseeing must be enabled to do. They should be able to:

  • understand the system's capabilities and limits and monitor it for anomalies;
  • stay aware of the tendency to over-rely on its output, which the text calls automation bias;
  • interpret the output correctly;
  • decide not to use the system, or to override or reverse its output;
  • intervene or interrupt the system, for example with a stop button.

There is also a special rule for remote biometric identification: no action on an identification unless at least two competent people have separately verified it, with exceptions for certain law-enforcement and border uses.

Reading it as a workflow designer#

You can ignore the legal categories and still learn from the list, because each item maps to a design choice.

Understand capabilities and limits. The approver needs to know what the agent was given and what it is bad at. That is a documentation and training task, and it is also a screen-design task: the request in front of the person should show the inputs and the uncertainty, not just a verdict.

Automation bias. This is the rubber-stamp problem. If the answer is nearly always yes, people stop reading. Practical defences: keep the approval queue small by sending routine cases through a condition, show the reasons next to the recommendation, and periodically review approvals that were always accepted.

Interpret the output correctly. Do not hand the reviewer raw JSON. Write the request in plain language.

Override or reverse. The reject path must be real. When someone says no, something sensible must happen next. Reversal is harder: if the action has already happened, you need an undo or a compensating step.

Stop button. Know who can pause or switch off a workflow, and test that it works. A scheduled workflow that cannot be paused by the people responsible for it has no stop button.

How this looks in Cadrix#

Cadrix is a general workflow tool. It does not make a system compliant by itself, and compliance depends on how you use it and what the workflow does. These are the pieces that line up with the list above:

  1. Put a Human Input step directly before any action that is hard to undo. The run pauses and shows as Awaiting approval.
  2. Write the request description so it states the action, the target, the inputs and what the agent was unsure about.
  3. Use a Condition before the approval so only unusual cases reach a person.
  4. Connect both the approve and reject outputs, and decide what a rejection triggers.
  5. Use the run trace as the record: it shows what each step received and returned, and the approval is part of it.
  6. Control who can edit or run the workflow with roles.

Retries and re-runs create new linked runs, so a reversed decision does not overwrite the original record.

Where the human goes. Two places. Before the consequential action, where a named role decides with enough context to disagree. And after launch, where someone reviews approvals that were always accepted, because that is where automation bias shows up in your own data.

What Article 14 does not do#

It does not tell you how many approvals to require, or what the threshold should be. That is a risk decision for your team. It also sits inside a larger set of obligations for providers and deployers that we have not covered here, including documentation, logging and monitoring.

A sensible approach for a team that is not sure if it is in scope: classify each workflow, treat the borderline ones as if they were in scope for design purposes, and ask a lawyer about the ones that clearly are.

Sources#

Get new posts by email

Practical notes on governed AI workflows, in your inbox. Unsubscribe whenever you like.

Opens your email app to send the request. We use your address only to send the blog. See the privacy policy.

Keep reading