AI Risk Assessment Under the EU AI Act: Two Layers, One Framework

Risk assessment under Regulation (EU) 2024/1689 — the EU AI Act — is not a single exercise you complete before launch. It is two distinct, sequential layers of analysis with different owners, different timescales, and different legal consequences. Get them confused and you will either over-engineer a chatbot or under-engineer a recruitment system that can get you fined up to €15 million or 3% of worldwide turnover.

Layer One: The Classification Assessment

Before any obligations attach, you must determine which risk tier your system falls into. The Act sorts every system into one of four tiers.

Tier 1 — Unacceptable risk (Article 5): banned outright since 2 February 2025. No compliance pathway exists. The list covers real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions), subliminal manipulation, social scoring by public authorities, certain predictive policing, emotion recognition in workplaces and educational institutions, and untargeted scraping of facial images. Fine ceiling: €35 million or 7% of worldwide annual turnover (Article 99(3)).

Tier 2 — High risk (Article 6 + Annex III, and Article 6(1) for Annex I product-safety components): the heavy-obligation tier. Obligations under Articles 9–15 apply from 2 December 2027 for stand-alone Annex III systems, and from 2 August 2028 for AI embedded as safety components in Annex I products. These dates reflect the Digital Omnibus political agreement of May 2026, which deferred the original August 2026 deadline.

Tier 3 — Limited risk (Article 50): chatbots, deepfakes and synthetic media, emotion recognition in consumer contexts, AI-generated content. Transparency disclosure duties only, from 2 August 2026.

Tier 4 — Minimal risk: everything else. No mandatory obligations.

GPAI models (Chapter V, Articles 51–56) are a separate cross-cutting category — not a fifth tier. A system built on an LLM is classified by what the system does, not by what the underlying model is.

The Article 6 Classification Test

Step 1 — Article 6(1) / Annex I: Is the system a safety component of an Annex I product (machinery, medical devices, radio equipment, toys) that requires third-party conformity assessment? If yes, automatically high-risk. No self-assessment exemption. Obligations apply from 2 August 2028.

Step 2 — Article 6(2) / Annex III: Does the intended use fall within one of the eight Annex III areas? These are: biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services (including creditworthiness under point 5(b) and life/health insurance pricing under point 5(c)); law enforcement; migration, asylum, and border control; administration of justice and democratic processes. A matching intended use makes the system presumptively high-risk.

Step 3 — Article 6(3) filter: An Annex III system is not high-risk if the provider documents that it poses no significant risk of harm. One of four conditions may support the exemption: narrow procedural task; improving a previously completed human activity; detecting decision patterns without replacing or influencing human assessment; or performing preparatory work. One caveat overrides all four: any system that profiles natural persons is always high-risk. Providers claiming the exemption must document the assessment and still register under Article 49.

A 20-person HR-tech firm building a tool that flags missing required qualifications — and only flags them — might plausibly invoke Article 6(3). A tool that scores and ranks candidates cannot: it directly influences human assessment and may profile by proxy.

Deployers do not run the classification. That duty belongs to the provider. If a deployer substantially modifies a system or repurposes it beyond its declared intended use, Article 25 converts the deployer into a provider, inheriting the full provider stack.

Layer Two: The Article 9 Risk Management System

Once a system is confirmed high-risk, Article 9 requires the provider to establish, implement, document, and maintain a risk management system across the system's entire lifecycle. This is not a launch checklist. It is a continuous governance process.

Article 9(2) specifies the core obligations: identify known and foreseeable risks to health, safety, and fundamental rights — including risks from reasonably foreseeable misuse; estimate and evaluate those risks (probability and severity); adopt mitigation measures and test them; judge residual risk acceptable before going to market; and iterate as operational experience accumulates. Article 9(4) links the system explicitly to post-market monitoring under Article 72 — the field data must feed back in.

The AI-Specific Risk Taxonomy

The Act does not prescribe a taxonomy, but Article 9 risks for AI systems cluster into five areas practitioners should address:

Bias. Training data that under-represents a protected group produces discriminatory outputs at scale. Disaggregated performance testing by protected characteristic is the baseline identification step; mitigation may require resampling, re-weighting, or targeted adversarial evaluation.

Robustness. Does the system perform consistently under edge cases, out-of-distribution inputs, or unusual operational conditions? Article 15 requires accuracy, robustness, and cybersecurity to be maintained throughout the lifecycle.

Security. High-risk systems are targets. A credit-scoring model may be vulnerable to adversarial inputs engineered to cause misclassification. Both Article 15 and the Article 9 identification duty reach this.

Drift. Production data distributions shift. A model that performed acceptably at launch may degrade silently over time. Post-market monitoring under Article 72 must specify what triggers a retraining or withdrawal decision.

Transparency. Article 13 requires high-risk systems to be designed so deployers and users can understand the outputs and exercise human oversight under Article 14. A black-box system with unexplained outputs is both an Article 13 gap and an Article 9 risk factor.

Article 9 and Its Close Neighbours

GDPR Article 35 DPIA. The Data Protection Impact Assessment is a GDPR obligation focused on data-processing risks to data subjects' rights. Article 9 is broader — it covers risks to health, safety, and fundamental rights from the system's outputs, not just its data handling. They can be run together and share a risk register, but each needs its own documentation trail: the DPIA to the DPO; the Article 9 record into the technical file under Article 11.

Article 27 Fundamental Rights Impact Assessment (FRIA). This is an AI Act deployer obligation — not a provider obligation — and it applies only to specific categories: public-body deployers of high-risk systems, and private deployers of systems in Annex III point 5(b) (creditworthiness) or point 5(c) (life/health insurance). A private employer deploying a high-risk recruitment tool does not automatically owe a FRIA. The FRIA covers deployment-context impacts; Article 9 covers design-stage risks. They are complementary, not substitutes.

A Seven-Step Process

1. Confirm the risk tier. Run the Article 6 test. Document the reasoning. If you invoke Article 6(3), document that separately and register under Article 49.
2. Define scope and use context. Write out intended purpose, deployment environment, users, and affected natural persons. Include foreseeable misuse scenarios.
3. Identify risks by category. Work through bias, robustness, security, drift, and transparency. Be specific: "the model may perform less accurately for applicants with non-Western name structures" is actionable; "bias risk exists" is not.
4. Estimate probability and severity. Rate likelihood and harm severity, including reversibility. A wrongly denied credit application is recoverable; a wrongly suppressed asylum claim may not be.
5. Design and test mitigation. For each risk above threshold, define a measure and test it against the performance metrics in the technical documentation under Article 11 / Annex IV.
6. Evaluate residual risk. Document and sign off the acceptability judgment. If not acceptable, iterate before proceeding to conformity assessment under Article 43.
7. Set up post-market monitoring. Define the Article 72 data collection, the thresholds that trigger a risk-system review, and the Article 73 serious-incident escalation path.

How Confir Helps

Confir's classification module uses deterministic, rule-based logic to map intake answers against Articles 5 and 6 and Annex III — same intake, same finding, no black box — and derives your role as provider or deployer under Article 25. The structured assessment then covers the Article 9 ground across four compliance areas: AIGM (Governance & Post-Market Monitoring, Articles 9, 72–73), AITR (Data & Technical Robustness, Articles 10, 11, 15), AIRC (Risk Classification & Compliance, Articles 5, 6, 43, 50), and AITO (Transparency & Human Oversight, Articles 13, 14, 27, 50). The Article 27 FRIA runs as a separate workflow for deployers who trigger it. The output is a print-ready technical documentation pack under Article 11 / Annex IV and an immutable audit log.

Frequently Asked Questions

What is the difference between the Article 6 classification assessment and the Article 9 risk management system?

They are sequential and legally distinct. Article 6 asks one binary question before market placement: is this system high-risk? The Article 9 risk management system is what follows that determination — a continuous lifecycle process that identifies specific risks, estimates their probability and severity, specifies mitigation, and feeds from post-market monitoring data. You cannot run Article 9 without first completing Article 6.

Do I need a notified body for my risk assessment?

Most Annex III systems (points 2–8) use the Annex VI internal self-assessment route — no notified body required. Annex III point 1 (biometrics) generally requires the Annex VII notified-body route where harmonised standards have not been applied. AI embedded in Annex I products follows the conformity route of the relevant product law, with the 2 August 2028 deadline. Article 43 sets out the routes.

How does the Article 9 risk management system relate to a GDPR DPIA?

A GDPR Article 35 DPIA focuses on data-processing risks to data subjects' rights. Article 9 covers risks to health, safety, and fundamental rights arising from the system's outputs, whether or not personal data is involved. A high-risk system processing personal data typically needs both. They can share infrastructure — the same risk register, the same workshop — but each needs its own documentation trail and sign-off.

Does every deployer of a high-risk system need to run a Fundamental Rights Impact Assessment?

No. Article 27 applies to public-body deployers of any high-risk system, and to private deployers of Annex III point 5(b) (creditworthiness) or 5(c) (life/health insurance) systems. A private employer deploying a high-risk recruitment tool does not automatically owe a FRIA. And Article 27 targets deployers, not providers.

What happens when I update the AI system after deployment?

A significant change to intended purpose, training data, or output logic may constitute a substantial modification under Article 3(23), converting the modifier into a provider under Article 25 and requiring a fresh Article 6 classification before relaunch. Even below that threshold, Article 9 requires the risk management system to be reviewed. Post-market monitoring under Article 72 should define the thresholds that make a review mandatory.

What are the penalties for an inadequate risk assessment?

Non-compliance with Article 9 is a breach of the high-risk requirements. The ceiling under Article 99(4) is €15 million or 3% of total worldwide annual turnover, whichever is higher. For start-ups and SMEs, Article 99(6) caps the fine at the lower figure — a proportionality provision, not a safe harbour. The deadline for stand-alone Annex III systems is 2 December 2027.

Related guides

• Articles 6-11 risk classification levels
• Article 6 high-risk criteria
• Annex III high-risk use cases
• Article 3 definitions and scope
• EU AI Act overview and requirements
• Article 43 conformity assessment procedures