EU AI Act Article 14 Human Oversight: Requirements Explained

What does Article 14 of the EU AI Act require?

Article 14 requires high-risk AI systems to be designed and developed so that natural persons can oversee them effectively while they are in use. Oversight must aim to prevent or minimise risks to health, safety and fundamental rights, and the measures must be proportionate to the risks, the level of autonomy and the context of use.

The article sits in Chapter III of Regulation (EU) 2024/1689, alongside the other requirements for high-risk systems such as risk management, logging and transparency. It has five paragraphs:

• Paragraph 1: high-risk systems must be built, including with suitable human-machine interface tools, so that people can oversee them effectively during use.
• Paragraph 2: the purpose of oversight is to prevent or minimise risks to health, safety or fundamental rights, including under reasonably foreseeable misuse.
• Paragraph 3: oversight measures must match the risks, autonomy and context. They can be built into the system by the provider, identified by the provider for the deployer to implement, or both.
• Paragraph 4: the people assigned to oversight must be enabled to do five things, covered in detail below.
• Paragraph 5: for remote biometric identification systems, an identification must be separately verified and confirmed by at least two people before anyone acts on it, subject to limited exceptions.

The official consolidated text is published on the European Commission's AI Act Service Desk. This guide explains what the requirements mean in practice. It is not legal advice, and whether a particular system is high risk should be confirmed with qualified advisers.

Which AI systems does Article 14 apply to?

Article 14 applies only to high-risk AI systems. These are systems used as safety components of products covered by EU product legislation listed in Annex I, such as machinery and medical devices, and systems used for the sensitive purposes listed in Annex III. Most everyday AI tools, such as writing assistants, are not high risk.

Annex III lists eight areas:

• biometrics, where permitted by law
• critical infrastructure
• education and vocational training
• employment, workers' management and access to self-employment
• access to essential private and public services and benefits, such as credit scoring
• law enforcement, where permitted by law
• migration, asylum and border control, where permitted by law
• administration of justice and democratic processes

The employment area is the one most organisations meet first. It covers AI used to recruit or select people, including filtering applications and evaluating candidates, and AI used to make decisions about promotion, termination, task allocation or the monitoring and evaluation of staff. An employer using an AI tool for any of these purposes is likely to be a deployer of a high-risk system.

Article 6(3) allows some Annex III systems to fall outside the high-risk category where they do not pose a significant risk of harm, for example because they perform a narrow procedural task. That assessment must be documented, and it is one of the questions to settle with legal advice before deciding that Article 14 does not apply.

When do the human oversight requirements apply?

Following the Digital Omnibus on AI, the high-risk requirements, including Article 14, apply to Annex III systems from 2 December 2027 and to Annex I product systems from 2 August 2028. These dates replace the original deadlines of 2 August 2026 and 2 August 2027 respectively.

The changes were made by Regulation (EU) 2026/1744, adopted on 8 July 2026 and in force since 27 July 2026. The Omnibus moved the dates but, on the consolidated text published by the AI Act Service Desk, did not amend the wording of Article 14 or of the deployer duties in Article 26.

The extra time is best used to design oversight properly rather than to defer it. Assigning trained people, writing procedures and testing that alerts and stop controls work all take longer than most teams expect, and the evidence that oversight works builds up only once it is running.

The five capabilities Article 14 requires

Paragraph 4 is the practical core of Article 14. It says the system must be provided to the deployer in a way that enables the people assigned to oversight, as appropriate and proportionate, to do five things. The table sets out each one, what it means in practice, and the evidence an organisation might keep to show it is in place.

None of these capabilities is achieved by technology alone. Each depends on a person who has the authority to act, receives the right information in time, and responds in a way that can be shown afterwards.

What is the difference between provider and deployer duties?

Providers, who develop a high-risk system and place it on the market, must design it for effective human oversight under Article 14 and explain the oversight measures in the instructions for use. Deployers, who use the system under their authority, must assign oversight to competent people and use the system as instructed under Article 26.

The full deployer text is on the AI Act Service Desk page for Article 26. For most organisations, which buy rather than build AI systems, Article 26(2) is where Article 14 becomes their responsibility: the provider makes oversight possible, and the deployer makes it happen.

Does Article 14 require a human to approve every AI decision?

No. Article 14 does not require a person to approve each output of a high-risk system. It requires that people can monitor the system, interpret it, override it and stop it, with measures proportionate to the risk. The exception is remote biometric identification, where two people must verify an identification before anyone acts on it.

That leaves room for different oversight models. A person can approve each decision before it takes effect, which is usually called human in the loop, or supervise a system that acts within agreed limits and step in when something looks wrong, which is often called human on the loop. Many deployments use both, choosing per action according to its impact and reversibility. Our human in the loop AI guide explains how these models work and when each fits.

Where approval is used, it should still meet the Article 14(4) tests. An approver who receives requests in a crowded inbox, cannot see why the system made its recommendation, or approves everything by habit is not providing effective oversight, however many approvals are recorded.

What does automation bias mean under Article 14?

Automation bias is the tendency to rely too heavily on an AI system's output, particularly when the system usually performs well. Article 14(4)(b) requires overseers to remain aware of it, especially where a high-risk system provides information or recommendations for decisions that people then take.

It is the most human of the five capabilities and the hardest to evidence. Practical measures include:

• Training on failure modes. Show overseers real examples of where the system has been wrong, not just how it works when it is right.
• Tracking override rates. A reviewer who never amends or rejects an output over a long period may be deferring rather than reviewing.
• Sampling accepted outputs. A second person periodically checking decisions that were accepted catches drift that never triggers an alert.
• Rotating reviewers where volumes allow, so that familiarity does not turn into routine acceptance.
• Periodic reminders. Short, acknowledged briefings keep the risk in view between formal training sessions.

How to put Article 14 human oversight into practice

For a deployer preparing for the 2 December 2027 date, the work falls into a sequence of practical steps.

1. Inventory your AI systems. List every AI system in use or planned and record its purpose. Flag any that touch the Annex III areas, especially employment.
2. Confirm which are high risk. For each flagged system, confirm with legal advice whether it is high risk or falls within an Article 6(3) exception, and document the conclusion.
3. Read the instructions for use. Identify the oversight measures the provider expects you to implement, the interpretation tools available and how the stop function works.
4. Name the overseers. Assign oversight for each system to specific people, not a team inbox, and confirm they have the authority to override and stop it.
5. Train and brief them. Cover the system's limitations, automation bias, how to interpret output and the escalation route, and record who has completed it.
6. Decide how decisions reach people. Define which outputs need approval, which raise exception alerts, and how quickly each must be seen. Make sure requests and alerts reach the named person on a channel they will notice.
7. Set escalation and cover. Decide what happens when an overseer does not respond in time, is absent or is unsure, so that oversight does not depend on one person being at their desk.
8. Test the stop procedure. Rehearse halting the system and returning to a manual process, and record the test.
9. Keep the logs. Retain automatically generated logs for at least six months and keep your own records of approvals, overrides and acknowledgements alongside them.
10. Inform the workforce. Where the system is used at work, inform workers' representatives and affected staff before it goes into service.

For more on how to plan where people sit in AI workflows as adoption matures, see the three stages of AI adoption and where human oversight belongs.

What evidence shows human oversight is working?

The Act does not prescribe an evidence format, but a deployer should be able to show who was responsible for overseeing each high-risk system, that they were trained, that they saw the requests and alerts they needed to see, and what they decided. Timestamped records tied to named individuals are the most persuasive form.

Useful records include:

• a register of high-risk systems with the named overseers and their deputies
• training and briefing records, with acknowledgement by each overseer
• logs showing when approval requests and exception alerts were delivered, seen and acknowledged, and by whom
• approval, rejection and override records with reasons
• stop procedure tests and incident reports
• the system's own automatically generated logs, retained for at least six months

A common gap is the link between the AI system and the person. The system's logs show what it produced; they rarely show that a specific person received and understood an alert in time. That is a communication problem as much as an AI one, and it is explored further in our article on why Slack and email are not a human-in-the-loop strategy for AI agents and our guide to audit-ready communication.

What are the penalties for failing to meet human oversight obligations?

Under Article 99(4), breaching the obligations of providers under Article 16 or deployers under Article 26 can lead to fines of up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, each fine is capped at whichever of the two amounts is lower.

Article 14 itself is a design requirement on high-risk systems, so a provider that fails to meet it is in breach of its Article 16 obligations. A deployer that fails to assign competent oversight or to use the system as instructed is in breach of Article 26. The actual level of any fine depends on the circumstances of the case, which national authorities must take into account. The full text is on the AI Act Service Desk page for Article 99.

Where Heed fits in Article 14 oversight

Heed is internal communication software built to make sure important messages are seen, acknowledged and recorded. Several Article 14 and Article 26 tasks depend on exactly that: getting an approval request or exception alert to a named overseer, making sure they act on it, and keeping a record that shows they did.

• Triggered by your systems. Desktop alerts can be triggered via API and webhooks, or from ServiceNow, Splunk, SCOM and Jira, so an AI system or monitoring tool can raise a request or alert automatically.
• Sent to the named people. Alerts can be targeted by department, location or role through Active Directory and SAML sync, so they reach the overseers assigned under Article 26(2).
• Escalated when nobody responds. Approval requests can include action buttons, and unanswered requests can escalate to a secondary approver, as described on our approvals solution page.
• Acknowledged and recorded. Acknowledgement can be required before a high-priority alert is dismissed, giving named, timestamped proof of who read and confirmed it. The same approach works for overseer briefings on automation bias and procedure changes.
• Deployed where your data must stay. Heed offers true on-premises deployment as well as regional cloud options, and is ISO 27001 certified.

Heed does not decide which AI systems are high risk, does not monitor AI systems itself and does not make an organisation compliant with the EU AI Act on its own. It supports oversight by providing the dependable delivery, acknowledgement and audit trail that an oversight process relies on. Our compliance solution page covers how the same records support other regulatory obligations. Book a demo to see how oversight alerts and acknowledgements work in practice.