Glossary

High-Risk AI System (EU AI Act)

An AI system classified under the EU AI Act (Regulation (EU) 2024/1689) as posing significant risk to health, safety, or fundamental rights — triggering specific provider and deployer obligations under Articles 9-15 and Article 26 respectively.

The EU AI Act does not regulate AI uniformly — it sorts systems into risk tiers and attaches obligations proportional to the tier. High-risk is the tier that carries the heaviest compliance burden short of outright prohibition: systems in this tier require a risk management system (Article 9), technical documentation (Article 11), human oversight design (Article 14), and — for deployers — usage-monitoring and instruction-compliance obligations (Article 26), among others.

Classification runs primarily through Annex III, which lists specific use-case categories: certain uses in employment and worker management, access to essential services (including credit scoring), law enforcement, migration and border control, administration of justice, and several others. A system's classification depends on its use case, not on the underlying model technology — the same foundation model can power both a high-risk and a minimal-risk application depending on what it's deployed to do.

Two roles carry distinct obligations. Providers develop and place the AI system on the market and carry the bulk of Article 9-15 obligations (risk management, technical documentation, quality management, conformity assessment). Deployers use the AI system in their operations and carry a narrower but still substantial set of obligations under Article 26: using the system per the provider's instructions, monitoring its operation, maintaining logs where provided, and — for certain contexts — informing affected persons.

An organisation that procures a high-risk AI feature from a vendor is a deployer, not a provider, but deployer obligations are not satisfied by 'the vendor is responsible.' The deployer's own risk record, monitoring evidence, and instructed-use documentation are the deployer's obligations specifically, separate from whatever the provider has done on their side.

Classification is not self-evident from a product description alone, and getting it wrong in either direction has real cost: over-classifying wastes compliance effort on a system that doesn't need it; under-classifying is the actual regulatory exposure. A structured classification assessment, revisited when the system's use case changes, is the practical control.