EU AI Act High-Risk AI Systems
Most AI systems in a typical company are not high-risk under the EU AI Act. A chatbot that answers product questions, a model that forecasts demand or a tool that drafts emails sits outside the strictest rules. But a small group of use cases, from screening job applicants to scoring creditworthiness, carries the full weight of the regulation: risk management, technical documentation, logging, human oversight and a conformity assessment before the system goes live.
This guide explains how the AI Act decides what is high-risk, gives examples for each category, walks through the main requirements and sets out the deadlines as they stand after the Digital Omnibus amendment of July 2026.
What makes an AI system high-risk
The AI Act (Regulation (EU) 2024/1689) uses two routes to classify a system as high-risk, both set out in Article 6.
Route 1: safety components of regulated products. An AI system is high-risk if it is a product, or a safety component of a product, covered by the EU harmonisation legislation listed in Annex I, and that product needs a third-party conformity assessment. Think of AI in medical devices, machinery, lifts, toys, cars or aviation equipment.
Route 2: the use cases listed in Annex III. An AI system is high-risk if it is used in one of the areas listed in Annex III, such as hiring, credit scoring or access to public services. This route catches most business software, because it is about what the system is used for, not what kind of product it sits in.
There is an important exception for Annex III systems. Under Article 6(3), a system in an Annex III area is not high-risk if it does not pose a significant risk to health, safety or fundamental rights. That applies when the system only:
- performs a narrow procedural task,
- improves the result of an activity a person has already completed,
- detects patterns or deviations in past decisions without replacing human assessment, or
- performs a preparatory task for an assessment listed in Annex III.
The exception never applies when the system profiles natural persons. And a provider who relies on it must document the assessment and register the system in the EU database before placing it on the market. In other words, the exception reduces your obligations, but it does not remove the paperwork.
High-risk categories with examples
Annex III lists eight areas. The examples below show the kind of systems that fall into each one.
| Area | Examples of high-risk AI systems |
|---|---|
| Biometrics | Remote biometric identification, biometric categorisation by sensitive attributes, emotion recognition |
| Critical infrastructure | Safety components for road traffic, digital infrastructure, or the supply of water, gas, heating and electricity |
| Education and vocational training | Deciding admission, evaluating learning outcomes, steering the learning process, detecting cheating in tests |
| Employment and workers management | Screening and ranking CVs, evaluating candidates, decisions on promotion or termination, allocating tasks based on behaviour, monitoring performance |
| Access to essential services | Eligibility for public benefits, creditworthiness and credit scoring (except fraud detection), risk assessment and pricing in life and health insurance, triage of emergency calls |
| Law enforcement | Assessing the risk of a person becoming a victim or offender, evaluating evidence, profiling in investigations |
| Migration, asylum and border control | Assessing security or health risks, examining asylum and visa applications |
| Justice and democratic processes | Assisting courts in researching and interpreting facts and law, systems intended to influence elections |
For most private companies, three areas matter in practice: employment (any AI that filters, ranks or evaluates people at work), credit and insurance (scoring and pricing of individuals) and critical infrastructure for utilities and transport operators.
A useful test: if the output of the system can change what happens to a specific person in one of these areas, assume it is high-risk until a documented assessment shows otherwise.
Risk management system requirements
Article 9 requires providers of high-risk systems to run a risk management system for the whole life of the system, not a one-off assessment before launch. In practice it covers four steps that repeat:
- Identify and analyse the known and reasonably foreseeable risks to health, safety and fundamental rights when the system is used as intended.
- Estimate and evaluate the risks that can arise from intended use and from reasonably foreseeable misuse.
- Evaluate new risks that appear from data collected after the system goes live, through post-market monitoring.
- Adopt risk management measures that reduce the remaining risk to an acceptable level, and test the system to confirm those measures work.
Testing has to happen against defined metrics and thresholds, before the system is placed on the market and throughout development. Where the system affects people under 18 or other vulnerable groups, the risk assessment has to consider them specifically.
Article 10 adds requirements for the data behind the system: training, validation and test data must be relevant, sufficiently representative and, as far as possible, free of errors and complete for the intended purpose. Providers must examine data for possible biases and take measures to detect, prevent and reduce them.
Technical documentation
Before a high-risk system can be placed on the market, the provider must draw up technical documentation (Article 11) with the content listed in Annex IV. It has to show that the system meets every requirement, in a form an authority or notified body can assess. The main elements are:
- a general description of the system, its intended purpose and the versions of relevant software and hardware,
- a detailed description of how the system was developed: design choices, architecture, data sources, labelling and data cleaning,
- information on monitoring, functioning and control, including the human oversight measures,
- the metrics used to measure accuracy, robustness and cybersecurity, and the test results,
- the risk management system,
- changes made to the system during its lifecycle,
- the standards applied and the EU declaration of conformity.
The documentation must be kept up to date and kept available for ten years after the system is placed on the market. SMEs and the newly defined small mid-cap companies can use a simplified documentation form introduced by the Digital Omnibus.
Providers also need a quality management system (Article 17), a conformity assessment (Article 43), an EU declaration of conformity, CE marking and registration in the EU database before the system goes live.
Logging requirements (Article 12)
Article 12 requires high-risk systems to record events automatically over their whole lifetime. The logs have to make it possible to:
- identify situations in which the system may present a risk or has been substantially modified,
- support post-market monitoring by the provider, and
- monitor the operation of the system by the deployer.
Logging has to be built into the system design. It is not something a deployer can add later with a spreadsheet. For remote biometric identification, the Act sets a minimum: the period of each use, the reference database, the input data that led to a match and the people who verified the result.
Retention matters too. Providers must keep the logs under their control for at least six months (Article 19), and deployers must keep the logs generated by the systems they use for at least six months as well (Article 26), unless other EU or national law, such as data protection rules, requires something different.
A practical tip: design the logging so it answers the questions an auditor will ask. Which input led to which output, which model version produced it, who saw it and what happened next.
Human oversight
Article 14 requires high-risk systems to be designed so that people can oversee them effectively while they are in use. The people assigned to oversight must be able to:
- understand the capacities and limitations of the system and monitor its operation,
- stay aware of automation bias, the tendency to rely on the output too much,
- correctly interpret the output, using the tools and methods available,
- decide not to use the system in a particular case, or disregard, override or reverse its output, and
- intervene in its operation or stop it safely.
For deployers, Article 26 turns this into concrete duties: assign human oversight to people with the necessary competence, training and authority, use the system according to the provider's instructions, make sure input data is relevant, monitor the operation, report serious incidents, and inform workers and their representatives before using a high-risk system in the workplace. Public bodies, providers of public services, and deployers who use AI for credit scoring or life and health insurance pricing also need a fundamental rights impact assessment (Article 27) before first use.
Human oversight is where many projects get the design wrong. A "human in the loop" who approves hundreds of AI decisions an hour without the information to question them is not effective oversight. Build the interface so the reviewer sees why the system decided, how confident it is and what data it used.
Deadlines
The Digital Omnibus amendment (Regulation (EU) 2026/1744, in force since 27 July 2026) moved the high-risk deadlines. The current dates are:
| Date | What applies |
|---|---|
| 2 February 2025 | Prohibited practices banned, AI literacy duty (Article 4) |
| 2 August 2025 | Rules for general-purpose AI models, governance, penalty provisions |
| 2 August 2026 | Transparency duties (Article 50) and most remaining provisions |
| 2 December 2027 | Obligations for high-risk systems listed in Annex III |
| 2 August 2028 | Obligations for high-risk AI in products covered by Annex I |
High-risk systems already placed on the market before their deadline only fall under the requirements if they are significantly changed afterwards. Systems intended for use by public authorities have until 2 August 2030.
Fourteen months sounds like a lot. It is not, if you have to build logging into an existing system, write the technical documentation, set up a quality management system and complete a conformity assessment. Most teams need the first months just to find out which of their systems are in scope.
Violations of the high-risk obligations can lead to fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher. For SMEs and start-ups the lower of the two amounts applies.
If you want help classifying your systems and planning the work, our EU AI Act compliance team starts with an inventory and a gap analysis.
FAQ
Q: What are the high-risk AI categories under the EU AI Act? A: Annex III lists eight areas: biometrics, critical infrastructure, education, employment, access to essential services such as credit and insurance, law enforcement, migration and border control, and justice and democratic processes. AI systems that are safety components of products covered by Annex I, such as medical devices or machinery, are also high-risk.
Q: What are examples of high-risk AI systems? A: CV screening and candidate ranking tools, credit scoring models, risk pricing in life and health insurance, AI that decides admission to education, emotion recognition at work, and safety components in energy or water supply.
Q: What does Article 12 require for logging? A: High-risk systems must record events automatically over their lifetime, so that risks and substantial modifications can be identified and the system can be monitored. Providers and deployers must keep the logs for at least six months.
Q: Is a human in the loop enough for compliance? A: Only if the oversight is effective. The people overseeing the system need the competence, information and authority to understand the output, override it and stop the system. Rubber-stamping AI decisions does not meet Article 14.