High risk AI under the EU AI Act: what counts and what it requires

An AI system is high risk under the EU AI Act when it is used for one of a defined list of purposes, mostly decisions about people: hiring and managing staff, access to education, creditworthiness and essential services, biometric identification, law enforcement, migration, and safety components in regulated products. High risk does not mean banned. It means the system has to be built to a standard, tested, documented, logged and overseen by a competent human, and it means the organization using it carries duties of its own. A separate, much shorter list of practices is banned outright regardless of how carefully they are done.

This is general information about how the rules are structured, not legal advice. Whether a particular tool falls inside the list is a fact specific question, and the answer often turns on exactly what the system outputs and what the decision is used for.

The four tiers

The Act sorts uses, not technologies. The same underlying model can sit in three different tiers depending on the job you give it.

Most software in most companies lands in the bottom row. The mistake is assuming that because your tool is an ordinary chatbot, the use is ordinary too. An assistant asked to rank applicants is doing a listed high risk job, even though the same assistant answering questions about the staff handbook is not. The model tier is a separate question, covered in how the Act treats general purpose models.

What is prohibited outright

The banned list is short and specific. In general terms it covers:

• Manipulative or deceptive techniques that work below the level of conscious awareness and distort someone's behavior in a way likely to cause significant harm.
• Exploiting vulnerabilities of age, disability or a specific social or economic situation to distort behavior harmfully.
• Social scoring: evaluating people based on their behavior or personal traits and using that score to treat them badly in unrelated contexts, or disproportionately.
• Predicting the risk that someone will commit a crime based solely on profiling or personality traits, as opposed to objective facts tied to criminal activity.
• Building or expanding facial recognition databases through untargeted scraping of images from the internet or CCTV.
• Inferring emotions in the workplace or in education, except for medical or safety reasons.
• Biometric categorization that infers sensitive characteristics such as race, political opinions, trade union membership, religion or sexual orientation.
• Real time remote biometric identification in public spaces for law enforcement, with narrow exceptions subject to authorization.

Two of these reach ordinary employers. Emotion inference is sold in sales coaching tools, interview software and call center analytics, and the workplace ban applies to the employer using it, not only to the vendor. Biometric categorization shows up in audience analytics products aimed at retail.

What counts as high risk

There are two routes into the high risk category. The first is product safety: AI that acts as a safety component of a product already covered by EU product legislation, such as machinery, medical devices, lifts, vehicles and toys. The second is a list of use areas, which is the one most businesses need to read:

• Biometrics, including remote identification, categorization and emotion recognition where those are permitted at all.
• Critical infrastructure, such as safety components managing electricity, water, gas, heating or traffic.
• Education and vocational training: admissions, assigning people to institutions, evaluating learning outcomes, and proctoring software that monitors for cheating during exams, where the reliability problems described in why an AI detector score is not evidence become a legal question as well as a fairness one.
• Employment and worker management: recruitment, posting job openings, filtering applications, evaluating candidates, promotion and termination decisions, task allocation, and monitoring performance and behavior.
• Access to essential services: eligibility for public benefits, creditworthiness and credit scoring, risk pricing in life and health insurance, and emergency call triage and dispatch.
• Law enforcement, migration and border control, including risk assessments, evidence evaluation, visa and asylum processing.
• Administration of justice and democratic processes, including tools assisting judges and systems influencing election outcomes.

There is a narrow filter. A system in one of those areas can fall outside the regime if it performs only a narrow procedural task, improves the result of previous human work, detects patterns or deviations without replacing the human assessment, or is merely preparatory. Any system that profiles people is high risk regardless. A provider relying on the filter has to document that assessment, so it is a reasoned exemption, not a shrug. Credit scoring is the standard example of where fairness problems concentrate, and the mechanism behind them is the subject of where AI bias comes from.

What the builder has to do

Providers of high risk systems carry the bulk of the obligations, and they apply before the product reaches a customer and continue afterwards.

• Risk management run as a continuous process across the lifecycle, not a document written once.
• Data governance: training, validation and test data that is relevant, sufficiently representative and examined for bias, with attention to the population the system will actually be used on.
• Technical documentation and record keeping detailed enough for an authority to assess conformity.
• Automatic logging of events over the system's lifetime so that incidents can be reconstructed.
• Instructions for use that tell the deployer the system's accuracy, known limitations, intended purpose and the oversight measures it needs.
• Human oversight by design: the system must be built so a person can understand its output, override it and stop it.
• Accuracy, robustness and cybersecurity appropriate to the purpose, with declared accuracy metrics.
• Quality management, conformity assessment, CE marking and registration in an EU database before the system goes on the market, plus post market monitoring and serious incident reporting.

An important trap: a deployer can become a provider. If you put your own name or trademark on a high risk system, substantially modify one, or repurpose a system so that it now serves a high risk use it was not designed for, the provider duties transfer to you. Buying a general tool and pointing it at recruitment can be exactly that, which is why what hiring screening software really does is worth understanding before you switch one on.

What the employer using it has to do

Deployer duties are lighter but they are real, and they are the ones ordinary organizations trip over. In general terms, a deployer of a high risk system must:

1. Use the system according to the instructions that came with it, which means reading them.
2. Assign human oversight to people who are competent, trained and given the authority and time to actually override the output. Oversight by someone with no power to say no is not oversight.
3. Make sure input data is relevant and representative for the purpose, to the extent the deployer controls that data.
4. Monitor operation, suspend use and inform the provider and the authorities if the system presents a risk or a serious incident occurs.
5. Keep the automatically generated logs for a defined period, where the logs are under the deployer's control.
6. Inform workers and their representatives before putting a high risk system into use in the workplace.
7. Tell affected people when a high risk system is being used in decisions about them, and give an explanation of the role the system played in a decision that affects them, when asked.
8. Carry out a fundamental rights impact assessment, where the deployer is a public body or is providing certain public or essential private services such as credit or insurance.

There is also a general duty on providers and deployers to ensure staff dealing with AI have a sufficient level of AI literacy for their role. That applies well beyond high risk uses, and it is the clearest reason to have a written AI policy people will actually follow and a record of who was trained on what.

The work worth doing now

Build the inventory first. List every AI tool in use, including features quietly switched on inside HR software, recruitment platforms, call center systems and monitoring tools. For each one, record what decision it touches and about whom. That list alone will show you whether you are anywhere near the high risk categories, and most organizations find they are in exactly one or two places: hiring and staff monitoring.

Then check those one or two properly. Ask the vendor in writing whether they class the system as high risk and what documentation and instructions for use they provide, which belongs alongside the other clauses worth checking before you sign. Name the person who exercises oversight and give them authority to overrule the output. Tell your staff the tool exists. If a product claims to read emotions from faces or voices in your workplace, treat that as a stop and check, not a procurement detail.