EU AI Act: What High-Risk Classification Means in Practice

The EU AI Act entered into force in August 2024. Its high-risk provisions — the most operationally demanding part of the regulation — apply from August 2026 for most deployers and providers. That window is shorter than it appears. Building the required governance infrastructure takes time, and organisations that wait for full enforcement clarity before acting will find themselves under-prepared.

This note sets out what high-risk classification actually means in practice: which systems are affected, what obligations are triggered, and what a compliant operating model looks like.

What makes an AI system "high-risk"?

The EU AI Act defines high-risk AI systems across two categories. The first covers AI systems used as safety components in products already regulated under existing EU product safety legislation — medical devices, machinery, aviation systems, and similar. The second, and more broadly applicable, covers AI systems deployed in specific high-risk use cases listed in Annex III of the Act.

Annex III covers eight domains: biometric identification and categorisation; management and operation of critical infrastructure; education and vocational training; employment and workers management; access to essential private and public services; law enforcement; migration and border control; and administration of justice and democratic processes.

For most regulated organisations — particularly in financial services — the most relevant Annex III categories are creditworthiness assessment, risk scoring in life and health insurance, and AI used in recruitment or HR decisions. The EBA has also signalled that AI systems used in credit risk modelling, fraud detection, and AML screening may fall within scope depending on their design and deployment context.

The eight core obligations

Once an AI system is classified as high-risk, the Act imposes eight categories of obligation on providers (those who develop or place the system on the market) and, to a lesser extent, on deployers (those who use the system in a professional context). The obligations are cumulative — they must all be satisfied, not selected from.

What deployers must do

The Act distinguishes between providers and deployers. Providers bear the primary compliance burden — they must satisfy all eight obligations before placing a system on the market. Deployers — organisations that use a high-risk AI system in a professional context — have a narrower but still significant set of obligations.

Deployers must: use the system in accordance with the provider's instructions; assign human oversight to qualified individuals; monitor the system's operation and report serious incidents; conduct a fundamental rights impact assessment where required; and register the system in the EU database where applicable.

In practice, the deployer obligations are more demanding than they appear. "Using the system in accordance with instructions" requires that deployers actually understand those instructions — which in turn requires technical and governance capability that many organisations do not yet have. The fundamental rights impact assessment, in particular, requires a structured methodology that most organisations will need to build from scratch.

The governance infrastructure required

Satisfying the EU AI Act's high-risk obligations is not primarily a legal exercise — it is an operational one. The obligations require governance infrastructure: processes, roles, documentation standards, monitoring capabilities, and escalation mechanisms that must be embedded in how AI systems are developed, deployed, and managed.

Organisations that approach compliance as a documentation exercise — producing policies and registers without changing how AI systems are actually governed — will satisfy the letter of the regulation but not its intent. More importantly, they will remain exposed to the operational risks that the regulation is designed to address.

A compliant operating model requires, at minimum: an AI inventory with risk classification for each system; a risk management process that is genuinely integrated into the AI development lifecycle; data governance controls that can demonstrate dataset quality and lineage; human oversight mechanisms that are operationally effective rather than nominally present; and incident management processes capable of detecting, investigating, and reporting AI-related incidents within the required timeframes.

Where to start

For most organisations, the practical starting point is an AI inventory and risk classification exercise. This establishes which systems are in scope, what obligations apply to each, and where the most significant gaps exist. Without this foundation, compliance efforts tend to be fragmented and incomplete.

The second priority is typically the risk management system — both because it is the most substantive obligation and because it provides the framework within which the other obligations are managed. A well-designed risk management system creates the structure for data governance documentation, technical documentation, and human oversight mechanisms to be developed consistently.

The third priority, often underestimated, is human oversight. Many organisations have nominal human oversight processes — a human in the loop who approves AI outputs — but these processes are not designed to be effective. The Act requires that oversight mechanisms allow humans to genuinely understand, monitor, and override AI systems. Designing those mechanisms requires both technical and organisational work.

The timeline pressure

August 2026 is the compliance date for most high-risk AI system obligations. For organisations that have not yet begun their compliance programs, that is approximately 14 months from the time of writing. Building a compliant AI governance operating model — including inventory, risk classification, risk management system, data governance documentation, and human oversight mechanisms — typically takes 9–18 months for a mid-sized regulated organisation.

The organisations that will meet the deadline comfortably are those that start now. Those that wait for enforcement guidance, final regulatory technical standards, or peer benchmarks will find themselves in a difficult position in the second half of 2026.