High-Risk AI Systems Under the EU AI Act: Obligations, Deadlines, and the Two Routes In

The EU AI Act does not impose the same obligations on every AI system. It sorts systems into four risk tiers and attaches a heavy obligation stack only to the top one — high risk. If your system lands there, you face roughly fifteen interlocking requirements covering risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, quality management, conformity assessment, registration, and post-market monitoring. Miss those and the penalty ceiling under Article 99(4) is €15 million or 3% of worldwide turnover, whichever is higher.

The deadline used to be 2 August 2026. Under the Digital Omnibus (political agreement reached 7 May 2026, formal adoption expected before that original date), the high-risk regime now applies from 2 December 2027 for stand-alone Annex III systems and from 2 August 2028 for AI embedded as a safety component in a regulated product covered by EU product law (Annex I). That extension is breathing room, not a reprieve — the documentation alone takes months to assemble.

Two Routes to High-Risk Status

Article 6 of Regulation (EU) 2024/1689 creates two independent classification paths. You only need one to be high-risk.

Route 1 — Article 6(1) + Annex I: safety component of a regulated product. If your AI system is a safety component of a product that already needs a third-party conformity assessment under one of the harmonised product-safety regimes listed in Annex I (machinery, medical devices, in-vitro diagnostic devices, civil aviation, vehicles, and others), it is high-risk. The conformity assessment for the AI component is integrated into the product's existing EU-law assessment. The deadline for these systems is 2 August 2028.

Route 2 — Article 6(2) + Annex III: the eight listed areas. Certain stand-alone AI applications are high-risk by virtue of where they are used. Annex III lists eight areas:

1. Biometrics — remote biometric identification (where permitted), biometric categorisation of natural persons, and emotion recognition.
2. Critical infrastructure — safety components in digital infrastructure, road traffic, and utilities supply.
3. Education and vocational training — determining access to institutions, evaluating attainment, monitoring exam conduct.
4. Employment, workers management, and access to self-employment — recruitment screening (Annex III point 4(a)), promotion and termination decisions, task allocation, monitoring during work.
5. Access to essential private and public services — creditworthiness assessment and credit scoring (Annex III point 5(b), excluding fraud detection); health and life insurance risk assessment and pricing (5(c)); emergency-services dispatch; public-benefits eligibility.
6. Law enforcement — assessing risk of offending or re-offending, polygraph-like systems, evidence reliability evaluation, profiling in investigations.
7. Migration, asylum, and border control — risk-assessment of applicants, examination of applications, document verification.
8. Administration of justice and democratic processes — assisting judicial authorities in fact-finding or applying the law; influencing elections or referenda.

The deadline for stand-alone Annex III systems is 2 December 2027.

The Article 6(3) Filter — and the Profiling Exception

Not every system that technically falls within an Annex III area is automatically high-risk. Article 6(3) lets providers self-classify downward if the system poses no significant risk of harm to health, safety, or fundamental rights — for example, it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing or influencing human assessment, or does only preparatory work.

The filter has a hard limit: any system that profiles natural persons is always high-risk, regardless of how narrow or preparatory the task appears. There is no route around that.

Providers claiming the Article 6(3) exemption must document the self-assessment and register the system in the EU database under Article 49. The exemption is not a blanket: a competent authority can challenge the assessment, and the burden of proof sits entirely with the provider.

The Obligation Stack

A system that is high-risk — by either route — inherits a layered set of requirements. These apply to providers (Article 16) in full; deployers carry a lighter but still material set under Article 26.

Provider obligations

Article 9 — Risk management system. An ongoing process running from development through decommissioning. Identify foreseeable risks and failure modes; assess severity and likelihood; implement controls; update the system when the deployment context or the model changes.

Article 10 — Data and data governance. Training, validation, and testing datasets must be relevant, representative, and sufficiently free from errors. Known biases and limitations must be documented. Article 10 covers data, not staff competence — that is Article 4 (AI literacy).

Article 11 — Technical documentation. Compiled before market placement, updated throughout the lifecycle. Annex IV sets out the minimum content: system description, design logic, training data characteristics, performance metrics, known limitations, and human-oversight design.

Article 12 — Logging. The system must automatically generate event logs that allow post-hoc reconstruction of the system's operation over the relevant period. Providers must retain logs they control for at least six months.

Article 13 — Transparency and information to deployers. Users and deployers must receive clear information about the system's capabilities, limitations, and intended purpose, in a form that lets them make informed decisions.

Article 14 — Human oversight. The system must be designed so that a person can understand its outputs, interpret them correctly, and intervene — pausing, overriding, or disregarding the system — before any output causes harm. Oversight mechanisms must be built in; they cannot be bolted on post-deployment.

Article 15 — Accuracy, robustness, and cybersecurity. The system must perform consistently to its declared accuracy levels across its intended lifetime, remain stable against foreseeable perturbations, and resist adversarial manipulation.

Article 17 — Quality management system (QMS). Providers must operate a documented QMS covering design and development, testing, data management, post-market monitoring, and corrective actions. This is the governance wrapper around all technical requirements.

Article 43 — Conformity assessment. Before placing a system on the market, providers must demonstrate compliance through the appropriate conformity assessment procedure. For most Annex III systems this is Annex VI internal self-assessment; Annex III point 1 (biometrics) generally requires the Annex VII notified-body route. Article 43, not Article 27, is the conformity assessment obligation.

Articles 47–49 — Declaration of Conformity, CE marking, and registration. Article 47 requires an EU Declaration of Conformity (DoC) certifying that the system meets the Act's requirements, drafted per Annex V. Article 48 requires affixing the CE marking. Article 49 requires registration in the EU database — the database itself is established under Article 71.

Article 72 — Post-market monitoring. Providers must actively collect and analyse data on the system's performance in real-world conditions and feed findings back into the risk management system.

Article 73 — Serious incident reporting. If a high-risk system causes or contributes to a serious incident — death, serious injury, or significant harm to fundamental rights — providers must report it to the relevant market-surveillance authority.

Deployer obligations — Article 26

Deployers are not off the hook. Article 26 requires them to follow the provider's instructions for use, ensure qualified personnel oversee the system, monitor its operation, and inform their workforce before using AI in employment contexts (Article 26). Deployers must keep logs they control for at least six months under Article 26.

FRIA — Article 27

Certain deployers must also run a Fundamental Rights Impact Assessment before deployment: public bodies, and private deployers of creditworthiness systems (Annex III point 5(b)) and life or health insurance risk systems (5(c)). The FRIA is not a general deployer obligation — private employers deploying recruitment or HR AI are not automatically required to conduct one.

What the Two Deadlines Mean Practically

A recruitment-screening tool deployed by an HR-tech firm sits in Annex III point 4(a). Obligations apply from 2 December 2027. The provider needs Article 9 risk management, Article 11 technical documentation, and Article 43 conformity assessment in place before that date — and those all take meaningful time to build properly.

A diagnostic AI that is a safety component of a medical device regulated under MDR 2017/745 enters via Article 6(1) + Annex I. Obligations apply from 2 August 2028, and the conformity assessment integrates with the MDR assessment process.

Neither deadline is close enough to delay planning. Technical documentation under Article 11 requires months of structured data work. A QMS under Article 17 requires documented processes across the whole development organisation. Starting in late 2027 to meet a December 2027 deadline is not feasible.

How Confir Helps

Confir's classification engine applies the Article 6 rules and Annex III logic to plain-English answers about how your system works and where it is used. The output is a deterministic, rule-based finding — same intake produces the same result — that tells you whether you are high-risk, which route got you there, and whether the Article 6(3) exemption could apply. No inference, no ambiguity, no guesswork.

For confirmed high-risk systems, Confir drives the Article 11 / Annex IV technical documentation pack and the Article 47 / Annex V Declaration of Conformity, and it runs the Article 27 FRIA for deployers who need one. The compliance health score and immutable audit log give you a defensible record of what decisions were made, when, and on what basis.

Frequently Asked Questions

What is the difference between the Article 6(1) and Article 6(2) routes to high-risk status?

Article 6(1) applies when your AI is a safety component of a product already subject to EU product-safety law (Annex I) — for example, a medical device or machinery. Classification follows from the product's existing regulatory perimeter, and obligations apply from 2 August 2028. Article 6(2) applies to stand-alone AI in the eight Annex III areas regardless of any product-safety framework, with obligations from 2 December 2027. A single system can technically qualify under both; the stricter obligations apply.

Can I use the Article 6(3) self-assessment to avoid the high-risk obligation stack?

Yes, but only if the system poses no significant risk of harm to health, safety, or fundamental rights, and only if you document that analysis and register the system under Article 49. The exemption does not apply to any system that profiles natural persons — those are always high-risk. A competent authority can challenge your assessment, so the documentation needs to be substantive, not a checkbox exercise.

Which Annex III systems require a notified body for conformity assessment?

Annex III point 1 (biometric identification and categorisation systems) generally requires the notified-body route under Annex VII of the Act. Most other Annex III systems use the Annex VI internal self-assessment procedure. This is set out in Article 43.

What does the FRIA under Article 27 require, and who must do it?

The Fundamental Rights Impact Assessment must be completed before deployment and must identify the fundamental rights at risk, assess the likelihood and severity of adverse effects, and document mitigation measures. It applies to public bodies and to private deployers of creditworthiness-assessment systems (Annex III point 5(b)) and health/life insurance risk systems (5(c)). Private employers using recruitment AI are not automatically within scope.

What are the penalties for non-compliance with high-risk obligations?

Under Article 99(4), non-compliance with high-risk provider or deployer obligations carries a maximum fine of €15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. For SMEs and start-ups, Article 99(6) caps the fine at the lower of the fixed amount or the percentage — a proportionality protection worth noting. Supplying incorrect information to a notified body or competent authority is a separate, lower tier: €7.5 million or 1% under Article 99(5).

When does the high-risk deadline actually apply?

Under the Digital Omnibus agreed in May 2026: stand-alone Annex III systems from 2 December 2027; AI safety components in Annex I products from 2 August 2028. The original date of 2 August 2026 has been deferred. Penalties under Article 99 have applied since 2 August 2025 for other obligations, so the enforcement infrastructure is already live.

What is the deployer's main obligation that differs from a provider's?

Deployers do not run conformity assessments or compile Annex IV technical documentation — those sit with the provider. The deployer's core obligations under Article 26 are: follow the provider's instructions, ensure human oversight with qualified staff, keep operational logs for at least six months (Article 26), notify workers' representatives before deploying AI in the workplace (Article 26), and report serious incidents. Some deployers also owe a FRIA under Article 27.

Related guides

• biometric identification in Annex III
• risk classification framework
• Article 6 high-risk designation
• eight mandatory Annex III categories
• compliance checklist for Articles 6–29
• EU AI Act overview