AI risk classification: how to map your use cases under the AI Act

The entire architecture of the EU AI Act rests on an idea that is simple to state and laborious to apply: obligations depend on the system's risk, so until a company has classified its systems it does not even know which articles apply to it. Classification is the passage from the regulation as read to the regulation as applied, and it is also the point where compliance programmes meet their first concrete obstacle, because before classifying you need to know what to classify, and almost nobody truly does.

The four categories, briefly

Regulation (EU) 2024/1689 organises systems into a pyramid. At the top, unacceptable-risk practices, banned since 2 February 2025: harmful subliminal manipulation, social scoring by public authorities, emotion recognition in the workplace and in education (with narrow exceptions), indiscriminate scraping of facial images. Here the only useful classification exercise is making sure you are not inside, even indirectly through a supplier.

Below sit the high-risk systems, the operational heart of the regulation. Annex III lists the domains: biometrics and identification, critical infrastructure, education and training, employment and worker management (from CV screening to decisions on promotions and dismissals), access to essential public and private services (credit scoring included), law enforcement, migration and justice. To these are added systems acting as safety components in already-regulated products (Annex I). For high risk the heavy obligations kick in, from risk management to technical documentation, from human oversight to registration, on an application calendar that the Digital Omnibus proposal presented by the Commission in November 2025 seeks to recalibrate, without touching its substance.

The third level is limited risk, where the main obligation is transparency: whoever interacts with a chatbot must know it, generated content must be recognisable. At the base, minimal risk, which covers the large majority of systems and carries no specific obligations beyond existing general law.

The method: from census to system card

Classification done properly is a four-move process, and the first move is not legal: it is a complete census of what the organisation uses. Complete means including systems bought as such, AI features activated inside software already under licence (the screening module of the HR suite, the recommendation engine of the e-commerce platform), internal developments, and tools used informally by teams, because shadow AI is not exempt from the regulation just because nobody authorised it.

The second move assigns each system the company's role, which determines the package of obligations: provider if you develop it or place it on the market under your name, deployer if you use it under your authority, with intermediate cases (substantial customisations can turn a deployer into a provider, one of the most underestimated traps in contracts).

The third move is the classification itself, system by system, with a card documenting the purpose, the Annex III domain possibly touched, the data processed, the people impacted and the assigned category with its rationale. The written rationale counts as much as the outcome, because in the event of an inspection it demonstrates that the evaluation was done with method rather than reconstructed after the fact. The fourth move links each classification to its consequent obligations and to an owner, turning the map into a plan.

The mistakes we see most often

Three mistakes recur with a frequency that makes them predictable. The first is delegating classification to the supplier, accepting their self-assessment as final: the vendor has an obvious incentive to classify low, and the deployer's responsibility remains with the deployer. Supplier declarations should be obtained, verified and integrated into your own analysis, with contractual clauses covering updates and changes of purpose.

The second mistake is classifying by technology instead of by use. The same language model can be minimal risk when it summarises internal documents and high risk when it enters a personnel selection process: the category follows purpose and context, which means every new use case of an already-censused tool requires a new evaluation, not a reference to the previous one.

The third mistake is treating classification as a one-off exercise. Systems evolve, suppliers update, teams find new uses, and a map frozen six months ago describes a company that no longer exists. Classification lives inside the AI systems register and gets updated through a process, typically hooked to procurement and to the release of new use cases.

From obligation to prioritisation tool

There is a side benefit that makes this work less thankless than it seems: the map of systems classified by risk is also a map of where AI touches the decisions that matter, and therefore an excellent starting point for prioritising investments and controls. In our AI Rating the census and the classification feed the Risk dimension, and the gaps that emerge (uncensused systems, unmotivated categories, ambiguous contractual roles) enter the roadmap with their priority.

If your map today is a partial list in a spreadsheet, you are in large company, and the next step is shorter than feared: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. We leave you the question to start from: of the AI systems your company is using this week, how many have a risk category written down anywhere?