The EU AI Act's High-Risk Categories: A Practical Guide for Product Teams

Your team ships a feature: a model that shortlists job applicants, or one that predicts which water mains are likeliest to fail. Nobody in the room calls it "high-risk". Then a customer in Germany asks for the EU declaration of conformity, the technical documentation, and your registration number in the EU database.

That moment is what this guide is for. The EU AI Act sorts systems into four tiers — prohibited, high-risk, limited-risk with transparency duties, and minimal-risk — and the high-risk tier carries by far the heaviest workload. Most of it falls on whoever builds the system, but the people deploying it have real obligations too. Here is what the categories actually contain, and a sensible order of operations for the next two quarters.

What makes a system high-risk

There are two doors into the high-risk tier. The first is product safety: AI used as a safety component of a product already covered by EU product-safety law — machinery, medical devices, toys, lifts and similar. Those duties arrive later than the rest of the regime. The second door is the one that catches most software teams: a list of eight use areas that applies regardless of your sector, industry or company size.

Notice that the trigger is the intended purpose, not the technology. Two systems running identical model weights can sit in different tiers because one recommends a film and the other filters CVs. That single fact drives everything practical about compliance, so write the purpose down in a sentence you would be comfortable defending.

The eight use areas that define the tier

These are the areas where the Act presumes a significant risk to health, safety or fundamental rights:

• Biometrics. Remote identification of people, categorising them by sensitive attributes, and emotion recognition.
• Critical infrastructure. Safety components used to manage or operate electricity, water, gas, heating, road traffic, or critical digital infrastructure.
• Education and vocational training. Admission decisions, evaluating learning outcomes, steering learners towards a level of education, and monitoring prohibited behaviour during tests.
• Employment and worker management. Recruitment and selection, promotion, termination, task allocation, and performance monitoring.
• Access to essential services. Creditworthiness and credit scoring, risk assessment and pricing for life and health insurance, emergency call triage, and eligibility for public benefits.
• Law enforcement. Risk assessment of individuals, evidence reliability checks, profiling, and crime analytics.
• Migration, asylum and border control. Visa and asylum processing, risk assessment, and document verification.
• Justice and democratic processes. Tools assisting judicial research and the interpretation of law, plus systems intended to influence elections or voting behaviour.

The list is not frozen. The Commission can amend it, and the wording of individual entries matters — "intended to be used" appears in several of them for a reason. Check the current text before you conclude a category is closed to you.

The exemption is narrower than it looks

There is a carve-out for systems in that list that do not pose a significant risk. It covers narrow procedural tasks, improving the result of work a human has already completed, detecting decision-making patterns without replacing human assessment, and preparatory tasks. It is genuinely useful, and genuinely easy to lose.

Two things to remember. First, if the system performs profiling of natural persons, it is always high-risk — no exemption. Second, claiming the carve-out is not a judgement call you make silently. You have to document the assessment and register the system. If you rely on it, date the reasoning, name the person who signed it off, and file it with the system's technical documentation. A slide that says "not high-risk" will not survive a customer's procurement review.

Provider, deployer, or both

The Act assigns duties by role, and the roles are not always what job titles suggest.

• Provider. You develop the system or have it developed, and place it on the market under your own name. This is the heavy load: risk management, data governance, technical documentation, logging, instructions for use, human oversight design, accuracy and cybersecurity, a quality management system, conformity assessment, CE marking, registration, post-market monitoring, and incident reporting.
• Deployer. You use the system under your own authority in a professional capacity. You must follow the instructions for use, assign human oversight to people with the competence and authority to exercise it, ensure input data is relevant, monitor operation, keep logs, and inform affected workers and their representatives. Some deployers — public bodies, private providers of public services, and those using credit scoring or life and health insurance pricing — must also run a fundamental rights impact assessment.
• Importers, distributors, authorised representatives and product manufacturers. Lighter duties, but not zero. Verifying conformity before placing a system on the market is the common thread.

Watch for accidental promotion. A deployer who substantially modifies a high-risk system, or rebrands it as their own, becomes a provider and inherits the full set of obligations. Health and safety teams are often surprised by this one, so flag it in your change-management process.

A working order of operations

1. Inventory and classify. List every AI feature you build or buy, with the intended purpose, the users, and whether outputs reach the EU. Include systems that predate the Act.
2. Assign roles per system, in writing. Provider and deployer responsibilities need named owners, not a shared inbox.
3. Gap-assess against the core requirements. Risk management, data governance, technical documentation, logging, transparency and instructions for use, human oversight, accuracy, robustness and cybersecurity.
4. Stand up a quality management system. The Act expects documented, repeatable processes. Building this in the final quarter before a deadline produces paperwork nobody trusts.
5. Draft technical documentation early. Design specifications, data provenance, validation results, monitoring plans. Retrofitting this from memory is the single most expensive mistake teams make.
6. Choose the conformity route. Internal control is typical, but certain biometric systems require a notified body unless harmonised standards cover you.
7. Register, declare, mark. Enter the system in the EU database, sign the EU declaration of conformity, and apply CE marking.
8. Plan monitoring and incident reporting before launch. Serious incidents have reporting timelines, and you cannot meet them without logging and a named contact.

Two complications worth planning for. Building on a general-purpose model does not make you responsible for that model's own transparency duties, but it does mean documentation travels with your supply chain — ask for it contractually. And if you sit outside the EU, the Act can still apply where your system's output is used in the Union.

Start with the inventory, not the lawyers

The teams that struggle with this treat it as a documentation sprint that begins eighteen months too late. The teams that cope do three things now: they finish an inventory with intended purposes written down plainly, they name an owner for each role, and they keep an honest gap list with dates against it.

Then add a review cadence. The use-area list, the harmonised standards and the guidance are all still moving, and a classification you made in one quarter may not hold in four. If a product's purpose can genuinely be re-scoped to something lower-risk, that is a legitimate design decision — but document the reasoning, because it will be read by someone who is not on your side.

Finally, treat this piece as a map rather than advice. Classification turns on wording that lawyers argue about, and the stakes include market access. For anything material to your business, get qualified counsel who can look at your specific system and your specific contracts.

Photo: GregMontani / Pixabay