Human Oversight of AI Under the EU AI Act: A Plain Summary

The EU AI Act’s human-in-the-loop rule is Article 14, and it applies to high-risk AI systems only. The provider, whoever builds the system and puts it on the market, must design it so that people can oversee it while it is in use: understand it, notice when it goes wrong, override it and stop it. The deployer, the organisation using it, must under Article 26 give that oversight to people with the competence, training and authority to do it. The Act does not require a person to approve every output of every AI tool, and ordinary business use of a chatbot or coding assistant is not high-risk by default. After the 2026 amendments, the high-risk rules for the Annex III areas apply from 2 December 2027. This is a plain summary, not legal advice; for a real decision, read the text and ask a lawyer.

Human in the loop for AI agents uses Article 14’s list as a test for any agent setup. This post is the other half: what the law itself says, who it binds, and when.

Provider or deployer: which one are you?

The Act gives different duties to different roles, so start there. Article 3↗ (opens in a new tab) defines a provider as the person or body that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, paid or free. A deployer is a person or body using an AI system under its authority, except in the course of a personal non-professional activity.

• A company that buys an AI screening tool and uses it on job applicants is a deployer.
• The company that sells that tool is the provider.
• A team that builds its own AI system and uses it internally can be both.
• Someone using a chatbot to plan a holiday is neither, because the use is personal and non-professional.

The roles can shift. Under Article 25, a deployer becomes the provider of a high-risk system if it puts its own name or trademark on one, makes a substantial modification to one, or changes the intended purpose of an ordinary or general-purpose system so that it becomes high-risk. Pointing a general chatbot at candidate screening is the classic way to do that without meaning to.

Which systems are high-risk

There are two routes. AI that is a safety component of a product already covered by EU product law, listed in Annex I, such as machinery, toys, lifts or medical devices. And AI used in one of the eight areas in Annex III↗ (opens in a new tab): biometrics; critical infrastructure; education and vocational training; employment, workers’ management and access to self-employment; access to essential private and public services and benefits; law enforcement; migration, asylum and border control; and the administration of justice and democratic processes.

The employment area is the one most ordinary businesses should read closely. It covers AI intended for recruitment or selection, including placing targeted job adverts, filtering applications and evaluating candidates, and AI intended to make decisions about promotion or termination, to allocate tasks based on individual behaviour or personal traits, or to monitor and evaluate people’s performance and behaviour at work. A work-management tool that ranks staff or hands out tasks by personality falls squarely in it.

Article 6(3) takes some Annex III systems back out, where they do not pose a significant risk of harm: for example, a system that performs a narrow procedural task, improves the result of a human activity already completed, or performs a preparatory task for an assessment. That exception never applies to a system that profiles people; profiling in an Annex III area is always high-risk.

What Article 14 asks of providers

Article 14↗ (opens in a new tab) says high-risk systems must be designed and developed, including with suitable human-machine interface tools, so that people can effectively oversee them while they are in use. The aim is to prevent or minimise risks to health, safety or fundamental rights. Oversight measures are either built into the system by the provider, or identified by the provider for the deployer to put in place. The system must be delivered so that the people assigned to oversee it are able, as appropriate and proportionate:

1. to understand its capacities and limitations and monitor its operation, including spotting anomalies, dysfunctions and unexpected performance;
2. to remain aware of automation bias, the tendency to rely or over-rely on the system’s output, especially where it gives recommendations for people’s decisions;
3. to interpret its output correctly;
4. to decide, in any particular situation, not to use it, or to disregard, override or reverse its output;
5. to intervene in its operation or interrupt it through a “stop” button or similar procedure that brings it to a halt in a safe state.

For remote biometric identification there is an extra rule: no action or decision is taken on an identification unless at least two people with the necessary competence, training and authority have separately verified and confirmed it, with limited exceptions for law enforcement, migration, border control and asylum.

What Article 26 asks of deployers

If you use a high-risk system rather than build one, Article 26↗ (opens in a new tab) is your article. The duties that bear on oversight:

• Use the system in line with its instructions for use, with appropriate technical and organisational measures.
• Assign human oversight to people who have the necessary competence, training and authority, as well as the necessary support.
• Monitor its operation, and if you have reason to think it presents a risk, tell the provider or distributor and the market surveillance authority, and suspend its use.
• Keep the logs the system generates, to the extent they are under your control, for a period suited to its purpose and of at least six months.
• If you are an employer, tell workers’ representatives and the affected workers before putting a high-risk system into use at work.
• For Annex III systems that make or help make decisions about people, tell those people they are subject to it.

Notice what “authority” means here. A reviewer who can see the output but has no power to overrule it, or who would be blamed for slowing the process down, does not meet the test. Oversight is a role with teeth, not a person watching a screen.

What it does not require

• A human in the loop for every AI system. Article 14 is a high-risk requirement. Drafting emails, writing code, summarising meetings or triaging a backlog with an AI assistant is not high-risk unless it is used for one of the Annex III purposes.
• A person approving every single output. The Act asks that people be able to understand, override and stop the system, and that the level of oversight fit the risks and context of use.
• Anything from you about the model itself. The obligations on general-purpose AI models fall on the model’s provider.

Some duties do reach ordinary use. The transparency rules in Article 50 apply from 2 August 2026: people must be told when they are talking to an AI system unless it is obvious, deepfakes must be disclosed, and AI-generated text published to inform the public on matters of public interest must be disclosed unless a person has reviewed it and someone holds editorial responsibility. Human in the loop for generative AI content covers that in practice. Article 4 on AI literacy, which has applied since February 2025, was rewritten by the 2026 amendments, so if you have a policy built on the original wording, check it against the amended text.

The dates

The Act was amended by Regulation (EU) 2026/1744, known as the AI Omnibus, which entered into force on 27 July 2026. The Commission’s implementation timeline↗ (opens in a new tab) now reads:

• 1 August 2024: the Act entered into force.
• 2 February 2025: definitions, AI literacy and the prohibited practices apply.
• 2 August 2025: the rules for general-purpose AI models and governance apply.
• 2 August 2026: most of the Act applies and enforcement starts, including the Article 50 transparency rules.
• 2 December 2026: prohibitions added by the amendments apply, and the transition ends for machine-readable marking under Article 50(2) for generative systems already on the market before 2 August 2026.
• 2 December 2027: the high-risk rules for Annex III systems apply, including Articles 14 and 26 for them.
• 2 August 2028: the high-risk rules for AI in products covered by Annex I apply.

Some summaries written before July 2026 still give 2 August 2026 for the high-risk rules. That date was moved. Check the date on anything you read about the Act, and check the official text for anything you rely on.

What a small team can sensibly do anyway

1. List your AI uses: the tool, what it is used for, and whose lives it touches. Check each use against Annex III. Anything touching hiring, staff evaluation, credit, insurance pricing, education or access to services is where to get proper advice.
2. Borrow Article 14’s list as a design test for everything else. Can someone understand what the AI did, overrule it, and stop it? If not, fix that before it matters.
3. Name a person for each AI use who can stop it, and make sure they are allowed to. That is Article 26’s competence, training and authority, applied to a team of five.
4. Keep the record. A log you can read six months later is what lets you answer “what did the AI do, and who approved it?”
5. Tell people when they are dealing with AI, and label what the rules say to label. That part applies now.

On a fenbs board, part of that record comes with the board. Every change is recorded in History with who made it, an assistant’s as “Claude via” the person it acts for. The Decisions page keeps what was decided, why, by whom and when, and a decision is always made by people, never an AI assistant, which may write it down but is never the decider. Sign-off can require named board members to approve. And revoking an assistant’s token stops it at once without signing its person out.