EU AI Act

EU AI Act High-Risk AI Systems: The Full Compliance Checklist

Every Annex III high-risk category and every Article 8–15 obligation explained, with a working checklist for providers and deployers to scope their compliance program.

Jasper Claes

July 6, 2026 · 18 min read

EU AI Act

Most of the EU AI Act's compliance weight sits on one classification: high-risk. If your AI system falls into one of eight Annex III categories — or is embedded in a product already regulated under EU product-safety law — Articles 8 through 15 apply in full, and there is no light version. This is the complete, practical checklist: every high-risk category, every obligation, and who owes what between providers and deployers.

TL;DR

High-risk status comes from two paths: Annex III (8 listed use-case categories) or Annex I (AI embedded in products already regulated under other EU law, like medical devices or machinery).
Article 6(3) contains a carve-out — an Annex III system isn't automatically high-risk if it doesn't pose a significant risk to health, safety or fundamental rights, but providers must document that assessment, not just assume it.
High-risk systems must satisfy Articles 9–15: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, and accuracy/robustness/cybersecurity.
Providers and deployers owe different obligations — providers build the compliance foundation; deployers must use the system as instructed and maintain human oversight in practice.
Penalties for high-risk non-compliance reach up to €15M or 3% of global annual turnover, separate from the €35M / 7% tier reserved for prohibited-practice violations.

What Makes an AI System 'High-Risk'

The EU AI Act doesn't classify AI systems as high-risk based on how advanced the technology is — classification is based on use case and potential impact on health, safety and fundamental rights. There are two routes into the high-risk category.

The EU AI Act's risk pyramid — obligations scale with classification, and high-risk carries by far the most.

The 8 Annex III High-Risk Categories

Category	Examples
Biometrics	Remote biometric identification, biometric categorization by sensitive attributes, emotion recognition
Critical infrastructure	Safety components managing digital infrastructure, road traffic, water, gas, heating or electricity supply
Education & vocational training	Systems determining access, admission or assessment of learning outcomes
Employment & worker management	Recruitment screening, promotion/termination decisions, task allocation and performance monitoring
Access to essential services	Credit scoring, insurance pricing, eligibility for public benefits
Law enforcement	Risk assessment of individuals, evidence evaluation, crime analytics
Migration, asylum & border control	Risk assessment, examination of applications, verification of travel documents
Justice & democratic processes	Systems assisting judicial research, decision-making, or influencing elections

Annex I: The Other Path to High-Risk

Separately, an AI system is high-risk if it's a safety component of — or is itself — a product already regulated under specific EU product-safety legislation listed in Annex I, such as medical devices, machinery, toys, or lifts, and that product is required to undergo third-party conformity assessment. These systems follow a slightly later compliance timeline than Annex III systems under both the original text and the proposed Digital Omnibus delay.

The Article 6(3) Carve-Out: Not Every Annex III System Is High-Risk

Don't assume — document

Article 6(3) allows a provider to determine that an Annex III system is not high-risk if it doesn't pose a significant risk of harm to health, safety or fundamental rights — for example, because it performs a narrow procedural task or doesn't materially influence a decision outcome. This is not a self-certifying loophole: providers must document the assessment that supports this conclusion and keep it available to authorities on request. Getting this wrong in either direction — over-claiming the carve-out, or missing a genuine high-risk classification — creates real exposure.

The Full Obligation Checklist: Articles 9–15

Article	Obligation	What you need to produce
Art. 9	Risk management system	Continuous risk identification, evaluation and mitigation process across the system's lifecycle
Art. 10	Data & data governance	Training, validation and testing data quality, relevance and bias review
Art. 11	Technical documentation	Documentation sufficient to demonstrate compliance to authorities (a 'Model Card'-style record)
Art. 12	Record-keeping	Automatic logging capability to trace the system's operation over its lifetime
Art. 13	Transparency & instructions for use	Clear information to deployers on capabilities, limitations and intended use
Art. 14	Human oversight	Measures enabling humans to understand, monitor and intervene in the system's operation
Art. 15	Accuracy, robustness & cybersecurity	Testing and controls appropriate to the system's intended purpose

Provider vs. Deployer: Who Owes What

Provider obligations	Deployer obligations
Build the risk management system (Art. 9)	Use the system per the provider's instructions
Ensure data governance (Art. 10)	Assign human oversight to competent, trained staff
Produce technical documentation (Art. 11)	Monitor operation and report serious incidents
Enable logging (Art. 12)	Keep logs generated by the system where required
Undergo conformity assessment & CE marking	Conduct a fundamental rights impact assessment where required (Art. 27, mainly public bodies and certain private deployers)

Obligations That Continue After Launch

Article	Obligation	What it requires
Art. 17	Quality management system	A documented QMS covering regulatory compliance strategy, design controls, testing, data management, risk management, post-market monitoring and incident reporting — proportionate to organization size
Art. 26	Deployer obligations	Detailed operational duties: use per instructions, assign competent human oversight, monitor operation, retain automatically generated logs
Art. 72	Post-market monitoring	An active plan to collect and review real-world performance data after deployment, not just pre-launch testing
Art. 73	Serious incident reporting	Providers must report serious incidents to market surveillance authorities within defined timeframes

Article 27: The Fundamental Rights Impact Assessment

Article 27 requires certain deployers — mainly public bodies and private entities providing public services, plus deployers of credit-scoring and insurance-pricing systems — to conduct a Fundamental Rights Impact Assessment (FRIA) before putting a high-risk system into use. Unlike the provider's technical risk assessment under Article 9, the FRIA specifically looks at impact on individuals’ fundamental rights, including who could be affected and what safeguards exist for them.

Conformity Assessment and CE Marking

Before placing a high-risk AI system on the market, providers must complete a conformity assessment — for most Annex III systems, this can be done through internal control, though some categories (like certain biometric systems) require a notified body's involvement. A successful assessment results in a declaration of conformity and CE marking, plus registration in the EU database for high-risk AI systems before deployment.

Registration in the EU Database

Most standalone high-risk AI systems (Annex III) must be registered in a public EU database before being placed on the market or put into service — covering the provider’s identity, a description of the system, and its intended purpose. This registration step is often underestimated in project planning because it happens right before launch, after all the harder documentation work is already done — but it's a hard gate, not a formality.

A Note on Timing

These obligations were originally set to apply from August 2, 2026 for Annex III systems. A provisional political agreement reached in May 2026 (the Digital Omnibus) proposes pushing this to December 2, 2027, with Annex I systems moving to August 2028 — but that delay is not yet formally adopted law. See our full breakdown in EU AI Act Deadlines in 2026 and 2027 for the complete legal status.

Building Your Compliance Checklist, Step by Step

Inventory every AI system your organization builds or uses, including third-party and embedded AI.
Classify each system: check it against the 8 Annex III categories and Annex I product overlaps.
Where a system falls in Annex III, document the Article 6(3) assessment — high-risk or genuinely exempt, with reasoning.
For confirmed high-risk systems, run a gap analysis against Articles 9–15.
Assign ownership: providers build the compliance foundation; deployers implement oversight and monitoring on their end.
Complete conformity assessment, CE marking and EU database registration before deployment.
Set a recurring review cadence — these obligations don't end at launch; they apply across the system's lifecycle.

Penalties for Non-Compliance

Violation	Maximum penalty
Prohibited AI practices	€35M or 7% of global annual turnover, whichever is higher
High-risk system obligations (Art. 9–15) & other requirements	€15M or 3% of global annual turnover, whichever is higher
Supplying incorrect, incomplete or misleading information to authorities	€7.5M or 1% of global annual turnover, whichever is higher

How Unorma Helps Scope This

Where Unorma fits

Unorma’s AI inventory includes EU AI Act risk classification for every registered system, and gap analysis scores each one against Articles 9–15 directly. See the full EU AI Act framework page or start with what AI compliance software does end to end.

Primary Sources

EUR-Lex — Regulation (EU) 2024/1689 — full legal text, including Annex I, Annex III and Articles 8–15.
European Commission — Regulatory framework for AI

Frequently asked questions

How do I know if my AI system is high-risk under the EU AI Act?

Check it against the 8 Annex III use-case categories and any Annex I product overlap. If it falls into Annex III, apply the Article 6(3) assessment to confirm it poses a significant risk before finalizing the classification — and document that assessment either way.

Can a provider self-declare that an Annex III system isn't high-risk?

Yes, under Article 6(3), but it requires a documented assessment showing the system doesn't pose a significant risk to health, safety or fundamental rights — it's not a self-certifying exemption you can claim without evidence.

What's the difference between provider and deployer obligations?

Providers build the compliance foundation — risk management, data governance, technical documentation, conformity assessment. Deployers must use the system as instructed, maintain human oversight in practice, and monitor its operation, including reporting serious incidents.

Do high-risk obligations apply from August 2026?

That's the original legal deadline. A provisional agreement in May 2026 proposes delaying it to December 2027 for Annex III systems, but it isn't yet formally adopted — see our dedicated post on the Digital Omnibus timeline for the full status.

What happens if we misclassify a high-risk system as limited or minimal risk?

You'd be operating without the required risk management, documentation, oversight and conformity assessment — exposing the organization to penalties of up to €15M or 3% of global turnover, plus the operational risk of an unmanaged high-risk AI system.

Does the EU AI Act apply to companies outside the EU?

Yes, if the AI system's output is used within the EU or affects people in the EU, regardless of where the provider or deployer is based — similar in reach to how GDPR applies extraterritorially.

What is a Fundamental Rights Impact Assessment (FRIA) and who has to do one?

It's an Article 27 requirement, mainly for public bodies and private entities providing public services, plus deployers of credit-scoring and insurance-pricing systems, assessing a high-risk system's impact on individuals' fundamental rights before it's put into use.

Do high-risk obligations end once the system is deployed?

No — Article 72 requires ongoing post-market monitoring, and Article 73 requires reporting serious incidents to authorities. High-risk compliance is a lifecycle obligation, not a one-time launch gate.

What is the quality management system requirement under Article 17?

Providers must maintain a documented QMS covering regulatory compliance strategy, design and testing procedures, data management, risk management, post-market monitoring and incident reporting — scaled proportionately to the size of the organization.

Key terms in this article

About the author

Jasper Claes

Compliance Manager & AI Governance Consultant

Compliance Manager and consultant specializing in AI governance for high-scale technology companies operating in regulated markets.

View full profile

Keep reading