EU AI Act: working out whether your system is high-risk

Almost every question about EU AI Act obligations resolves to one prior question: what risk tier is this system, and are you the provider or the deployer? Get those two wrong and everything downstream is wrong with them.

The tiers

• Prohibited — a defined set of unacceptable practices, banned outright.
• High-risk — the tier carrying substantial obligations, and the one requiring careful analysis.
• Limited risk — transparency duties, such as telling people they are interacting with an AI system.
• Minimal risk — the majority of systems, with no specific obligations.

Two routes into high-risk

This is the part most summaries flatten. A system can be high-risk because it is a safety component of a product already covered by EU product legislation, or because it falls within the listed use cases covering areas such as employment and worker management, education access, essential services eligibility, creditworthiness, biometrics, critical infrastructure, law enforcement, migration and justice.

The second route catches organisations that do not consider themselves AI companies at all. A CV-screening tool, a system prioritising candidates, or one supporting decisions about access to a service can land in scope through use case alone, regardless of technical sophistication.

There is a narrow filter for systems in listed areas that perform only preparatory or narrow procedural tasks without materially influencing the outcome. It is genuinely narrow — document the assessment rather than assuming it applies, because the reasoning is what you will be asked for.

Provider or deployer

Obligations split sharply:

• Providers — develop the system or place it on the market under their name. They carry the heavy obligations: risk management system, data governance, technical documentation, logging, transparency and instructions for use, human oversight design, accuracy and robustness, conformity assessment, registration, and post-market monitoring.
• Deployers — use the system. Lighter but real: use it in accordance with instructions, ensure human oversight is actually exercised by competent people, monitor operation, keep logs, and inform affected individuals in defined cases.

A deployer can become a provider — by putting their name on it, substantially modifying it, or repurposing it for a high-risk use it was not intended for. Fine-tuning a general model for a listed use case is the route most organisations take without realising the reclassification.

What high-risk commits you to

For providers, the practical consequence is engineering and documentation discipline more than paperwork: a risk management process running across the lifecycle, data governance covering training and validation data quality and bias, technical documentation sufficient for an authority to assess conformity, automatic logging, and demonstrable human oversight design. Then conformity assessment, a declaration, CE marking and registration.

Where to start

1. Inventory your AI systems, including features embedded in tools you already bought.
2. For each, determine role — provider or deployer — per system, not per organisation.
3. Classify by tier, documenting the reasoning including any exclusion relied on.
4. Confirm timelines, which are staged by obligation type.
5. Treat general-purpose model obligations separately; they follow their own rules.

Key takeaways

• Tier and role determine everything — decide both per system.
• Listed use cases catch organisations that do not consider themselves AI companies.
• Deployers become providers by modifying or repurposing.
• Document the classification reasoning, including exclusions relied on.