Reliable Enterprise AI

The classification system in simple terms

The EU AI Act organizes AI systems into four risk levels.

Unacceptable Risk refers to all those systems that are outright prohibited: social scoring by governments, real-time biometric surveillance in public spaces, AI that exploits psychological vulnerabilities. If you’re developing something like this in the private sector, you have much more serious problems than legal compliance.

High Risk is the level where most enterprise engineering teams should focus their attention. Systems in this category are permitted, but subject to mandatory requirements before implementation. The list is specific and should be read carefully rather than assuming your system isn’t on it.

Limited Risk mainly applies to systems with transparency obligations: for example, chatbots must disclose that they are AI, and deepfakes must be labeled. The requirements are less stringent, but not nonexistent.

Minimal Risk encompasses most AI applications. There are no mandatory requirements beyond existing legislation, although voluntary codes of conduct apply.

Engineering work is almost entirely performed at the high-risk level. Everything that follows refers to this category.

What is considered high risk?

According to the EU AI Act, high-risk systems are divided into two groups.

The first group comprises AI systems used as safety components in products already covered by European product safety legislation: machinery, medical devices, vehicles, and aviation equipment. If an AI system is integrated into a product that already requires CE marking, that system automatically inherits the high-risk category.

The second group is more relevant to most business teams. It consists of a list of specific application areas defined in Annex III of the Act:

• Biometric identification and categorization of natural persons.

• Management and operation of critical infrastructure: water, gas, electricity, and transport.

• Education and vocational training: specifically, systems that determine access to educational institutions or assess students. This includes automated grading, admissions selection, and performance evaluation tools.

• Employment and workforce management: resume screening, promotion decisions, performance tracking, and task assignment systems.

• Access to essential public and private services: credit scoring, insurance risk assessment, and emergency service dispatch.

• Law enforcement: risk assessment tools, evidence evaluation, and crime prediction.

• Migration, asylum, and border control: risk assessment, document verification, and application processing.

• Administration of justice and democratic processes: AI that assists in judicial decisions and applies the law to the facts.

It’s a long list, and many of the systems being developed today fall within it: educational platforms that assess student performance, human resources systems that select candidates, credit scoring tools, and more.

What does High-Risk classification really require?

This is where the implications of this classification become clearest from an engineering perspective.

The timeline

The AI ​​Act came into force in August 2024, and is mandatory for high-risk Schedule III systems (HR, banking, education) from August 2026. If it is a security component of an already regulated product (such as a medical device), the date is extended to August 2027.

While this may seem like plenty of time, I believe it isn’t, for two reasons.

First, documentation and risk management requirements are applied retroactively to systems already in operation when a “substantial change” occurs (but let’s be realistic: in the AI ​​world, retraining a model with new data, drastically changing a directive, or updating weights is generally considered a substantial change).

If you created a high-risk system before the provisions of the Act came into effect, you will still need to adapt it before the deadline. Retroactive compliance is more difficult than adapting from the outset: it involves documenting decisions made months or years ago, often without the necessary records to do so accurately.

Second, the human oversight requirements typically necessitate architectural changes. A system not designed for human intervention doesn’t become one simply by adding a “reject this output” button to the interface. Meaningful human oversight, as required by law, means that operators can understand what the system is doing and why, intervene at appropriate times, and that such intervention actually affects the system’s behavior. Adapting this to a system designed for autonomous operation is costly.

A practical first step

Before assessing compliance requirements, it is necessary to determine if your system presents a high risk. This determination is not always obvious.

First, you should read the application domains listed in Annex III and see if your system fits any of them. The definitions are broader than they initially appear. For example, an AI system that “assesses and ranks” student results is different from a teacher grading exams: the Act treats automated assessment differently from human assessment, and this distinction is important for ranking.

If your system could present a high risk, the next step is to establish the documentation, starting with a written description of what the system does, what data it uses, how decisions are made, and where human oversight exists or does not exist. This document becomes the foundation for everything else.

With this documentation in place, teams find it easier to navigate the conformity assessment process, as it simplifies the process for them to answer any questions about their systems.

Conclusion

The high-risk classification under the EU AI Act is not a compliance issue that can be delegated to the legal department.

The requirements (risk management, data governance, technical documentation, human oversight) are engineering problems that require engineering solutions. Most of them should be integrated from the initial design stage.