Human oversight (AI Act)

What is human oversight under the AI Act?

Human oversight is the requirement that a person can follow what a high-risk AI system is doing, understand it well enough to judge what comes out, and set it aside or stop it. In the EU AI Act this is two rules, in two articles, landing on two different companies.

Article 14 tells the provider, the company that builds the system and puts it on the market under its own name, to design the system so that oversight is possible at all. Article 26 tells the deployer, the company that uses the system under its own authority, to organise that oversight and carry it out. Most Belgian SMEs never build a high-risk system. They buy one, which makes them the deployer, so Article 26 is the article that lands on their desk.

Human-in-the-loop and a stop button are design patterns, and choices. Articles 14 and 26 are a legal duty with a fine attached. The GDPR already had a cousin of it in Article 22, the right not to be subject to a decision based solely on automated processing. That is a right someone has to invoke. The AI Act duty applies whether or not anyone ever complains.

What Article 14 asks the provider to build in

Article 14(1) says a high-risk system has to 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". The word carrying the weight is effectively. A screen that shows a score and nothing else is overseen in name only.

Paragraph 3 says the measures have to match the risk, the level of autonomy and the context of use, and that they come in two shapes: measures the provider builds into the system, and measures the provider identifies for the deployer to put in place. Article 13(3)(d) then obliges the provider to describe those measures in the instructions for use. If the documentation of a high-risk system you bought says nothing about oversight, the gap is on the provider's side, and worth a written question.

Paragraph 4 is the concrete list. Whoever oversees the system has to be able to:

• Understand the capacities and the limitations of the system, and monitor how it is running.

• Stay aware of automation bias, the pull towards accepting whatever the system produces, which the article singles out for systems that give people information or recommendations to act on.

• Interpret the output correctly, with whatever tools and methods exist for that.

• Decide not to use the system in a given case, or to disregard, override or reverse its output.

• Intervene, or interrupt the system "through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state". A safe state, not simply off; the agent kill switch entry goes into what that means.

Paragraph 5 adds a separate rule for remote biometric identification: no action or decision on the basis of an identification unless at least two natural persons with the necessary competence, training and authority have separately verified and confirmed it. Four eyes, written into the regulation, with an exception for law enforcement, migration, border control and asylum where Union or national law finds it disproportionate.

What Article 26 asks of you as the deployer

Article 26 is a list of duties for the company that uses the system. Five of them touch oversight directly.

Use it the way the manual says. Paragraph 1 asks for technical and organisational measures so the system is used in line with the instructions for use. Reading them is the step most often skipped.

Assign oversight to people, by name. Paragraph 2 reads: "Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support." Competence means the person understands the domain. Training means you gave them some. Authority means they may overrule the system without asking permission first. Support means time, and a colleague to ask.

Monitor, and suspend when something is off. Paragraph 5: monitor operation on the basis of the instructions, and if you have reason to think that using the system presents a risk, inform the provider or distributor and the market surveillance authority without undue delay, and suspend use.

Keep the logs for at least six months. Paragraph 6 covers the logs the system generates automatically, to the extent they are under your control, for a period appropriate to the purpose and at least six months. FOD Economie repeats the six months in its guidance for Belgian companies.

Tell the people involved. Paragraph 7: before a high-risk system goes into use at work, you inform the workers' representatives and the affected workers. Paragraph 11: people about whom the system makes or assists a decision have to be told they are subject to it.

Paragraph 3 gives you room: you organise your own resources for implementing the provider's oversight measures, with no prescribed job title or procedure. A 60-person company that buys a CV screening tool can put oversight with the HR manager and a named deputy, on paper, and be in order.

Article 14 versus Article 26

What separates Article 14 from Article 26 is who has to make oversight possible and who has to actually do it.

Article 14 is about capability. The provider has to build a system that a person can follow, interpret and halt, and has to say in the instructions how. If the system has no way to override an output, the provider has not met Article 14, and no procedure you write can repair that from the outside.

Article 26 is about practice. You name the people, give them competence, training, authority and support, use the system as instructed, monitor it, suspend it when needed and keep the logs. Buying a system that ticks every Article 14 box does not discharge one line of Article 26.

The gap between the two is where companies get caught. A tool can be entirely in order on the shelf and still run with nobody watching it. That is a deployer failure, fined under Article 99(4): up to 15 million euros or 3 percent of worldwide turnover, whichever is higher, and for SMEs the lower of the two.

What makes oversight more than a signature

Competence, training, authority and support come down to four questions in a working week, and if one of them fails the oversight is a rubber stamp.

Time. A reviewer with 300 credit decisions a day and forty seconds each is not exercising judgement, whatever the process document says. Either the volume drops, or the review becomes a sample with clear rules, or you stop calling the system human-overseen.

Information. A score on its own cannot be checked. The reviewer needs to see which inputs drove it and what the system is bad at, which is what Article 13 obliges the provider to supply.

Authority. The person has to be able to overrule the output on their own judgement. If every deviation has to go up a level first, the deviations stop happening.

Consequences. If overriding the system slows down a handling time that gets measured, or if being wrong once about an override is career-limiting while agreeing with the system never is, people will agree with the system. That is automation bias arriving through the incentive scheme rather than through psychology.

The training half links to Article 4, the AI literacy duty, which has applied since February 2025 and was not moved by any deadline shift. The Digital Omnibus softened it: you no longer have to guarantee a sufficient level of AI literacy, only take measures that support its development. A person assigned to oversight with no training at all is still hard to defend under Article 26(2).

Five lines per high-risk system, and when this starts to apply

Oversight that happened but left no trace is hard to tell apart from oversight that did not happen. You do not need a policy document for that. Per high-risk system, five dated lines in a shared file are what an inspector would want to see.

1. What it is and what it decides. The system, the decision it makes or influences, and about whom.

2. Who oversees it. A name and a deputy, with the date they were assigned. A role nobody currently holds is a finding.

3. What that person may do. Overrule an output, decline to use the system in a given case, and stop it, with the exact steps for stopping it. Keep the provider's instructions for use next to this line.

4. Where the logs are. System or vendor, who can export them, and how long they are kept. With a SaaS tool the logs sit at the vendor, so put log access and export in the contract before you need them.

5. Who was told, and when. Workers and their representatives, from before go-live, and the wording shown to the people the decisions are about.

One number is worth adding to line three: how often the reviewer disagreed with the system. An override rate of zero over six months is the strongest single signal that the oversight is nominal.

On timing: the high-risk obligations, Articles 14 and 26 included, moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026, pushed stand-alone Annex III high-risk systems to 2 December 2027 and AI embedded in regulated products under Annex I to 2 August 2028. Neither article was rewritten, only delayed. The AI literacy duty and the transparency obligation in Article 50 already apply, and the five lines above are the same five lines you would want anyway the first time a candidate asks why they were rejected.