EU AI Act Risk Management System Requirements 2026: Article 9 Explained
Knowing you're classified as high-risk is only step one. Article 9 requires an operating process — one that keeps running for as long as your AI system is on the market — and most teams building toward the August 2, 2026 deadline are still treating it like a document to file away.
Why This Deadline Is Different From the Classification One
Deciding whether your AI system is high-risk is a one-time analytical exercise. Article 9's risk management system is the operational machinery that classification unlocks — and it's the piece most compliance timelines underbudget, because it can't be finished in a sprint. It has to be running, with evidence of having run, by the time August 2, 2026 obligations become enforceable for most Annex III systems.
Auditors and market surveillance authorities aren't looking for a single well-written risk memo. They're looking for a process with a start date, a review cadence, and change history that tracks your system as it evolved.
The Four Steps Article 9 Requires, In Order
Identify and Analyze Known and Foreseeable Risks
Catalog risks to health, safety, and fundamental rights that the system could pose when used as intended — including risks that only emerge in combination with other systems the AI interacts with.
Estimate and Evaluate Risks From Intended Use and Reasonably Foreseeable Misuse
Go beyond the happy path. Reasonably foreseeable misuse — a use the provider didn't design for but could anticipate — is explicitly in scope, not just risks arising from correct usage.
Evaluate Risks Based on Post-Market Monitoring Data
Once deployed, real-world performance and incident data feeds back into the risk analysis. A system that behaved as expected in pre-market testing but shows drift or edge-case failures in production must have that data folded back into the risk register.
Adopt Appropriate, Targeted Risk Management Measures
Design and mitigation measures must eliminate or reduce risks as far as possible through design, with adequate mitigation and control measures for risks that can't be designed away, and adequate information and training for risks that remain.
"Continuous and Iterative" Is Doing Real Legal Work
Article 9 explicitly describes the risk management system as a process that runs throughout the entire lifecycle of the high-risk AI system, requiring regular, systematic review and updates. This is the sentence that distinguishes the requirement from a conventional pre-launch risk assessment.
In practice, that means your risk register needs a revision date, an owner, and a defined trigger for re-review — a new model version, a new training data source, a new deployment context, or a post-market incident should each kick off a documented re-assessment, not just an informal Slack thread.
Testing Requirements Are Part of the Same Obligation
Article 9 folds testing directly into risk management: high-risk AI systems must be tested specifically to identify the most appropriate risk mitigation measures, using metrics and probabilistic thresholds defined in advance and appropriate to the system's intended purpose.
Pre-market testing
- ☐Test throughout development, not only at the end
- ☐Define metrics and thresholds before testing, not after seeing results
- ☐Test for reasonably foreseeable misuse, not only correct usage
- ☐Retain test results as part of technical documentation
Post-market monitoring loop
- ☐Collect production performance data on an ongoing basis
- ☐Feed incident and near-miss data back into the risk register
- ☐Re-run risk evaluation when monitoring data reveals new failure modes
- ☐Document each re-assessment with a date and rationale
Residual Risk: What "Acceptable" Means
You are not required to eliminate all risk — the Act recognizes that some residual risk is unavoidable. What you must do is drive residual risk down through the hierarchy above (design elimination, then mitigation controls, then information/training), and the residual risk that remains must be judged acceptable in light of the system's intended purpose. That judgment call has to be documented, not assumed.
For vulnerable groups, including children, the Act specifically directs that risk management take their heightened vulnerability into account — a residual risk level acceptable for a general adult user base is not automatically acceptable where the system's foreseeable users include minors or other at-risk populations.
What Auditors and Enterprise Buyers Will Ask For
- A dated risk register showing identified risks, severity, and mitigation status — with a visible revision history, not just a current snapshot.
- Evidence of pre-defined test thresholds, not thresholds chosen after seeing how the model performed.
- A named owner and review cadence for the risk management process — "we'll revisit if something breaks" is not a process.
- A post-market monitoring pipeline that demonstrably feeds production data back into the risk register.
- Documented reasoning for residual risk acceptance, especially where vulnerable users are in the foreseeable user base.
See where your AI product is exposed
RatedWithAI helps SaaS and platform teams surface compliance and trust gaps across their web properties. Start with a free scan to understand how your product presents to users and regulators alike.
Scan Your Product for Free →Frequently Asked Questions
Can we satisfy Article 9 with an ISO 42001 or ISO 31000 program?
Aligning your risk management with ISO/IEC 42001 (AI management systems) or ISO 31000 (general risk management) is a reasonable and commonly used foundation, and harmonised standards are expected to eventually create a presumption-of-conformity path. But until those harmonised standards are formally adopted and cited, mapping to ISO alone doesn't automatically discharge Article 9 — you still need to show the specific four-step process (identify, estimate/evaluate, evaluate via monitoring, mitigate) and the lifecycle-long cadence the Act describes.
Does a small AI startup really need a formal risk management system, or is this for enterprise-scale providers only?
Article 9 applies to providers of high-risk AI systems regardless of company size once your system falls into an Annex III category or the safety-component route. There's no small-business carve-out for the risk management obligation itself, though the Act does direct authorities to consider proportionality for SMEs in areas like documentation format. Build the process at whatever scale matches your team — a lightweight but genuinely iterative risk register beats an elaborate one-time document.
How is this different from the Annex IV technical documentation requirement?
Technical documentation (Annex IV) is the record you produce describing your system, data, and design choices — largely static per version. The risk management system (Article 9) is the ongoing process that generates inputs into that documentation and keeps getting re-run as the system, its data, and its deployment context change. Technical documentation is a snapshot; risk management is the process that keeps the snapshot honest.
What happens if we classified as high-risk late and haven't built the risk management process yet?
Start now and document the build-out honestly — a risk management system with a recent start date and evidence of active iteration is a defensible position; having nothing in place after the August 2026 general application date is not. Prioritize the highest-severity risk categories first (fundamental rights and safety), and be prepared to show market surveillance authorities a credible remediation timeline if asked before the process is fully mature.