Is your AI system a high-risk system?

The AI Act in brief

The AI Act is the EU's Regulation (EU) 2024/1689 – the first comprehensive legal framework for artificial intelligence. It is horizontal: it applies regardless of industry and covers both those who develop an AI system and those who use it, as long as the system is used in the Union. The underlying idea is risk-based – the greater the risk to health, safety and fundamental rights, the more numerous and onerous the obligations.

The rules are being phased in gradually rather than taking effect all at once. First come the prohibited practices, then the rules for general-purpose AI models (GPAI) and finally the most extensive requirements for high-risk systems, together with standards and the supervisory structure. The timetable has been adjusted in several rounds, so always check the current dates and transition periods in the Regulation or with the competent authority. Preparations start now regardless.

The four risk levels

The classification is determined by what the system is used for, not by the technology behind it. The same model can be a high-risk system in one context and entirely unregulated in another.

The table is a simplification to get you started. The levels, exceptions and boundaries are defined in the Regulation.

What makes a system high-risk?

There are two routes into high risk. The first is product safety: an AI system that is a safety component of a product covered by certain EU legislation – for example machinery, medical devices or vehicles – and where an independent assessment is required. The second route is the area of use.

Annex III of the Regulation lists the areas where an AI system is normally considered high-risk:

• Biometrics – identification and categorisation of individuals, and emotion recognition.
• Critical infrastructure – operation and management of, for example, electricity, water, gas, heating, transport and digital infrastructure.
• Education – admission, assessment and grading, or systems that determine what a student gets access to.
• Employment and HR – recruitment and selection, promotion, dismissal, allocation of tasks and performance monitoring.
• Access to essential services – public benefits and allowances, creditworthiness, insurance, emergency calls and prioritisation in healthcare.
• Law enforcement – risk assessment of individuals, evidence and investigative support.
• Migration and border control – asylum applications, visas and border checks.
• Administration of justice and democratic processes – support for courts and influence on elections.

The list should be read in the Regulation, not in a summary like this one – the wording determines what is covered. It is also possible to exempt a system that would otherwise be high-risk if it does not pose a significant risk to health, safety or fundamental rights. The exemption is not a shortcut: the assessment must be made against clear criteria, documented and in some cases registered – and it must hold up if someone scrutinises it.

Provider or deployer – two different roles

The AI Act assigns different responsibilities depending on your role, and many organisations are both. The role follows from who places the system on the market or puts it into use.

If you are a provider

• A risk management system covering the entire life cycle, updated when the system changes.
• Data governance: requirements for training, validation and test data, including relevance and bias.
• Technical documentation describing the system, its purpose, limitations and performance.
• Logging and traceability so that events in operation can be followed up afterwards.
• Human oversight built into the system, with clear interfaces for intervening.
• Accuracy, robustness and cybersecurity, including protection against manipulation of input data and the model.
• Quality management system, conformity assessment and CE marking, registration, instructions for use, and incident reporting.

A detail that is often overlooked: if you substantially modify a high-risk system, or put your own brand on it, you may yourselves be regarded as the provider – with the full list of obligations.

If you are a deployer

• Use the system in accordance with the provider's instructions, and for nothing other than its intended purpose.
• Ensure human oversight: designated people with the competence, mandate and time to actually review and intervene.
• Make sure input data is relevant and sufficiently representative for the purpose.
• Monitor operation, keep logs as the rules require and report incidents onwards.
• Inform the people concerned when the system makes or supports decisions about them.
• In some cases, carry out a fundamental rights impact assessment (FRIA) before the system is put into use – this applies to public bodies and certain private operators providing essential services.
• Register in the relevant register where required, and cooperate with the supervisory authority.

Data protection runs in parallel. If personal data is involved, GDPR applies as usual, with legal basis, data protection impact assessment (DPIA) and the rules on automated decisions. The AI Act does not replace that work but adds requirements – and the two tracks should be handled together. The requirements for incident management and the supply chain are also linked to NIS2, which we cover in NIS2: what applies to you – and what do you do first?

How to do a first classification in four steps

A first classification doesn't need to be complete – but it does need to be done, documented and open to revision. This is how we usually work:

1. Take stock. List all AI functions in operation or in planning – including those embedded in purchased systems, cloud services and tools that staff have taken up on their own. Describe what each system does, which decision it supports and who is affected.
2. Check the prohibited practices first. If something is prohibited, it has to go or be rebuilt – no matter how well documented it is.
3. Check the high-risk routes. Is the system a safety component in a regulated product? Does the use case match anything in Annex III? If so, assess whether the system nonetheless does not pose a significant risk – and document the assessment and your reasoning.
4. Decide role and requirements. Are you a provider, a deployer or both? Map yourselves against the requirements, do a gap analysis and set an action plan with an owner and dates. Deal with data protection at the same time.

Five common mistakes

• Believing everything is high-risk. The work becomes unmanageable and nobody has the energy to prioritise. Most everyday systems are not high-risk.
• Forgetting that you can be a deployer. You read the rules as a provider even though you are only buying in a system – and miss your own obligations.
• Not documenting the classification. An assessment that exists only in someone's head or in meeting minutes will not hold up under review.
• Losing track of the supply chain. Who is responsible for what, and what does the contract say? An unclear division of roles is the most common reason requirements fall between the cracks.
• Believing the GDPR work is enough. The regulations overlap but have different purposes. Among other things, the AI Act requires a risk management system, technical documentation and built-in human oversight.

Start with the classification

The classification determines how much work lies ahead of you – and for most organisations it can be done in a few days. What matters is that it is done before the systems are put into use, not that it is perfect. We help with the review, the documentation and the routines that keep the classification alive: classification and risk management under AI & the AI Act, and data protection questions under GDPR & data protection. Unsure where you stand? Book a meeting – we go through your systems and tell you what needs doing first.