Filed under — EU AI Act · Article 9 · Risk Management · High-Risk AI · Compliance
Prefer this source on Google →EU AI Act Article 9: Risk Management for High-Risk AI Systems
Article 9 mandates continuous risk management for high-risk AI. Learn what documentation, processes, and testing you need before the December 2027 deadline.
Free check · no account
Check your own system against what this article describes.
EU AI Act Article 9: Risk Management for High-Risk AI Systems
Updated 2 October 2026 — correction. Earlier versions cited Article 61 for post-market monitoring (it is Article 72), called a breach of Article 9 a "high-severity infringement under Article 71" (Article 71 is the EU database; fines are set by Article 99(4)), framed Article 9 as a deployer's duty, listed human oversight among the measures Article 9 names, gave a 30-day deadline for producing records that the Act does not set, and said public buyers require proof of Article 9 compliance without a source. The guide now follows Article 9(2) to (8), Article 21 and Articles 79 and 99.
Updated 31 July 2026 — deadline changed. The Digital Omnibus (adopted by the European Parliament on 16 June 2026 and the Council on 29 June 2026) deferred the Annex III high-risk obligations from 2 August 2026 to 2 December 2027. The Article 50 transparency obligations were not deferred and still apply from 2 August 2026. This article has been corrected accordingly.
What Article 9 Actually Requires
Article 9 of the EU AI Act establishes the risk management framework that every provider of high-risk AI systems must implement. It's not a one-time checkbox—it's a continuous, documented process that must be in place before you place your system on the market and maintained throughout its lifecycle.
If you provide an AI system that falls under Annex III (HR tools, credit scoring, law enforcement, critical infrastructure, education, etc.), Article 9 applies to you. The statutory maximum fine is €15 million or 3% of global annual turnover, whichever is higher (Art. 99(4)); for SMEs, whichever is lower (Art. 99(6)). These obligations apply from 2 December 2027 (2 August 2028 for high-risk AI in products covered by Annex I).
Here's what Article 9 demands in plain language:
- Establish and document a risk management system that is continuous and iterative
- Identify and analyze known and reasonably foreseeable risks the system can pose to health, safety or fundamental rights when used as intended
- Estimate and evaluate risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse
- Adopt suitable risk management measures to address identified risks
- Test the system to ensure risk management measures are effective
- Evaluate other risks that emerge from post-market monitoring data (Article 72)
- Update the risk management process throughout the entire lifecycle of the system
The key word is continuous. You can't run a risk assessment in January 2026, file it, and forget it. Article 9 requires ongoing monitoring, testing, and documentation updates as your system evolves.
The Five-Step Risk Management Process
Article 9 doesn't prescribe a specific methodology, but it does outline a clear sequence. Here's how to structure your compliance:
Step 1: Risk Identification
Document every reasonably foreseeable risk associated with your AI system. This includes:
- Risks to health and safety
- Risks to fundamental rights (privacy, non-discrimination, freedom of expression)
- Risks arising from intended use
- Risks arising from reasonably foreseeable misuse
Concrete example: If you provide an AI-powered recruitment tool, foreseeable risks include discriminatory outcomes based on protected characteristics (gender, age, ethnicity), privacy violations from excessive data collection, and misuse by hiring managers who over-rely on the system without human review.
Step 2: Risk Analysis and Estimation
For each identified risk, estimate:
- Severity: What is the magnitude of harm if the risk materializes?
- Probability: How likely is this risk to occur?
- Affected populations: Who is exposed to this risk?
Document your methodology. If you use a risk matrix (e.g., 5×5 likelihood-impact grid), define your scoring criteria and thresholds.
Step 3: Risk Evaluation
Determine whether each risk is acceptable or requires mitigation. Articles 8(1) and 9(2) require you to evaluate risks in light of:
- The intended purpose of the system
- Reasonably foreseeable misuse
- The state of the art in risk mitigation
If a risk exceeds your acceptable threshold, you must implement controls. Article 9(5) requires the residual risk of each hazard, and of the system overall, to be judged acceptable.
Step 4: Risk Mitigation
Adopt measures to eliminate or reduce risks to an acceptable level. Article 9 requires:
- Design and development controls: Eliminate or reduce risks as far as technically feasible through design (Art. 9(5)(a))
- Mitigation and control measures: For risks that cannot be eliminated (Art. 9(5)(b))
- Information to deployers: Provide the information required by Article 13 and, where appropriate, training (Art. 9(5)(c))
- Testing and validation: Test against prior defined metrics and thresholds, in any event before the system is placed on the market (Art. 9(6)–(8))
Article 9(4) also requires the measures to take account of how the other requirements of Section 2 interact — including human oversight (Article 14).
Document every mitigation measure and map it back to the specific risk(s) it addresses.
Step 5: Continuous Monitoring and Update
Risk management doesn't stop at deployment. Article 9 requires you to:
- Evaluate risks arising from your post-market monitoring data (Art. 9(2)(c), Article 72)
- Update risk assessments when you modify the system or learn of new risks
- Maintain records of all risk management activities
This means version-controlled documentation, change logs, and periodic reviews—not a static PDF.
Article 9 Documentation Requirements
The EU AI Act doesn't specify a document template. Article 11 and Annex IV require the technical documentation to include a detailed description of the risk management system (Annex IV, point 5), and Article 18 requires it to be kept for ten years. The Act names no further documents; the set below is one practical way to meet that:
| Document | Purpose | Update Frequency |
|---|---|---|
| Risk Management Plan | Describes your overall process, methodology, roles, and review cadence | Annually or when process changes |
| Risk Register | Lists all identified risks with severity, probability, and status | Continuously (living document) |
| Risk Assessment Report | Detailed analysis of each risk, including evidence and evaluation | Per system version or major change |
| Mitigation Control Specification | Describes each control, its implementation, and effectiveness testing | Per control; updated when modified |
| Test and Validation Records | Evidence that mitigations work (test plans, results, pass/fail criteria) | Per test cycle |
| Monitoring and Incident Log | Production performance data, anomalies, user complaints, near-misses | Continuously (append-only log) |
All documentation must be explainable and auditable. On a reasoned request, a provider must give a competent authority all the information and documentation needed to demonstrate conformity (Art. 21(1)); the Act sets no fixed number of days.
Common Gaps and Anti-Patterns
Article 9 gaps tend to take predictable forms. Here are eight anti-patterns to look for:
- One-time risk assessment: Treating risk management as a pre-launch checklist instead of a continuous process
- No misuse analysis: Identifying intended-use risks but ignoring foreseeable misuse scenarios
- Undocumented methodology: Using subjective risk judgments without defined scoring criteria
- No traceability: Listing risks and controls in separate documents with no clear mapping
- Missing test evidence: Claiming mitigations are effective without documented validation
- No production monitoring: Deploying the system and never checking if risk assumptions hold in the real world
- Stale documentation: Risk registers that haven't been updated in 12+ months
- No version control: Overwriting old risk assessments instead of maintaining a change history
Each of these gaps would make it hard to show that a system meets Article 9. Article 9 compliance is not about having some documentation—it's about having the right documentation, kept current, and demonstrably used to make decisions.
How Article 9 Connects to Other Requirements
Article 9 is the foundation, but it doesn't stand alone. Your risk management system must feed into:
- Article 10 (Data Governance): Risk assessment informs what training data you need and how you validate it
- Article 13 (Transparency): Identified risks determine what information you must provide to deployers
- Article 14 (Human Oversight): Risk severity dictates the level of human control required
- Article 15 (Accuracy, Robustness, Cybersecurity): Risk mitigation drives your technical performance requirements
- Article 72 (Post-Market Monitoring): Continuous risk management requires ongoing performance tracking
If your Article 9 process is weak, every downstream obligation becomes harder to satisfy.
Practical Implementation Checklist
Here's a 30-day roadmap to establish Article 9 compliance:
Week 1: Scoping and Methodology
- Confirm your system is high-risk (check Article 6 and Annex III)
- Define your risk management process (who owns it, review cadence, escalation paths)
- Choose a risk assessment methodology (ISO 31000, NIST AI RMF, or custom)
- Document your risk scoring criteria (severity scale, probability scale, acceptability thresholds)
Week 2: Risk Identification and Analysis
- Conduct a structured risk workshop with engineering, product, legal, and compliance
- Identify risks to health, safety, and fundamental rights
- Analyze reasonably foreseeable misuse scenarios
- Populate your risk register with initial severity and probability estimates
Week 3: Risk Evaluation and Mitigation Planning
- Evaluate each risk against your acceptability criteria
- Design mitigation controls for unacceptable risks
- Map each control to the specific risk(s) it addresses
- Define test plans to validate control effectiveness
Week 4: Testing, Documentation, and Monitoring Setup
- Execute validation tests for each mitigation control
- Document test results and update risk register with residual risk levels
- Set up production monitoring (performance metrics, anomaly detection, user feedback channels)
- Schedule your first quarterly risk management review
This isn't a one-person job. Article 9 compliance requires cross-functional collaboration and executive sponsorship.
What Happens If You Don't Comply
The Act does not grade a breach of Article 9 separately: a provider must ensure its high-risk system meets Article 9 (Art. 16(a)), and a breach of that duty falls in the Article 99(4) tier. Under Article 79, national market surveillance authorities can:
- Require you to take corrective action, withdraw or recall the system within a period they set (at most 15 working days)
- Restrict or prohibit making your AI system available on their national market if you do not
- Impose administrative fines up to €15 million or 3% of total worldwide annual turnover (Art. 99(4)); for SMEs, whichever is lower
Beyond regulatory penalties, inadequate risk management exposes you to:
- Civil liability: If your AI system causes harm and you can't demonstrate reasonable risk management, you may face lawsuits under national product liability laws
- Reputational damage: Public disclosure of enforcement actions can destroy customer trust
The cost of non-compliance far exceeds the cost of getting it right.
This article provides general information about the EU AI Act and does not constitute legal advice. For specific compliance questions, consult a qualified attorney with expertise in EU AI regulation.
Related dispatches