Classifying isn't the same as assessing
These are two different exercises under the AI Act, and it's worth not conflating them. Classifying risk (Article 6 and Annex III) is a one-off legal exercise: deciding whether your system falls under prohibited risk, high risk, limited risk (with the Article 50 transparency obligations) or minimal risk. It answers "which legal category does my system fall into?".
Assessing risk (Article 9) is something else: the continuous methodological process — identify, analyze, estimate, mitigate, monitor — required once you already know your system is high-risk. It isn't a one-time exercise you file away; it's a living management system that follows the AI system throughout its entire lifecycle.
What Article 9 literally requires
Article 9 requires providers of high-risk systems to establish, implement, document and maintain a continuous iterative process, with four phases that repeat throughout the system's lifecycle:
| Phase | What it requires |
|---|---|
| Identification and analysis | Detect "known and reasonably foreseeable" risks to health, safety or fundamental rights when the system is used as intended — including reasonably foreseeable misuse. |
| Estimation and evaluation | Assess risks that may arise both under normal use and under reasonably foreseeable misuse, including interaction with other systems. |
| Post-market review | Feed in whatever the post-market monitoring system (mandatory under another article of the Regulation) reveals, as an active source of newly detected risks. |
| Mitigation | Adopt "appropriate and targeted" risk-management measures through design, development or technical documentation — plus testing before placing on the market, using predefined metrics and thresholds, with particular attention to impact on minors and vulnerable groups. |
Which framework to use to operationalize it
Article 9 says what needs to be achieved, not how to do it step by step — that's where voluntary frameworks come in (not certifiable on their own, except ISO 42001), which do give a concrete methodology:
NIST AI RMF 1.0
Organizes risk management into 4 functions: Govern, Map, Measure, and Manage. It's the most widely used reference as an operational framework outside a certifiable management system.
ISO/IEC 42001:2023
A certifiable AI management system (like ISO 27001 for security). Its Annex A provides a catalogue of controls — governance, impact assessment, lifecycle management, data, third parties — that the organization selects via a Statement of Applicability. It provides the structure, not the assessment methodology itself.
ISO/IEC 23894:2023
A technical guideline (not certifiable) that adapts ISO 31000 — generic risk management — to the specific context of AI, covering data, model performance, security and bias throughout the lifecycle. It's the natural methodological complement to ISO 42001.
The timeline changed in 2026 — but don't scale back the work because of it
The AI "Digital Omnibus" entered into force on July 27, 2026, and pushed back the application date of Annex III high-risk obligations from August 2, 2026 to December 2, 2027. High-risk systems under Annex I (safety components of already-regulated products, like medical devices) keep their August 2, 2028 date. What didn't change: the Article 5 prohibitions (in force since February 2025), GPAI model obligations (August 2025), and Article 50 transparency (August 2026).
The delay buys time, but building a real risk-management system — identification, testing, continuous monitoring — isn't a matter of weeks. Starting now is still the reasonable option, not a wasted urgency.
How to set it up: 4 steps
Step 1 — Starting point: the classification you've already done
It only makes sense to assess the risk of systems you already know are high-risk. If you haven't done that exercise yet, start by classifying your AI systems by risk before moving on.
Step 2 — Choose a methodology
NIST AI RMF if you want something operational and quick to adopt; ISO 23894 if you already work with ISO 42001 and want consistency between the two. You don't have to pick just one — many organizations combine NIST's four functions with ISO 42001's control catalogue.
Step 3 — Document the process, not just the outcome
Article 9 requires the process to be "documented and maintained" — a conclusion ("low risk") without a trail of how you got there isn't enough. That documentation is also what a market surveillance authority will ask for during an inspection.
Step 4 — Schedule the review, not just do it once
Since it's an iterative process, you need a review calendar (many organizations opt for quarterly or half-yearly cycles) plus a mandatory review whenever there's a substantial change to the system or new data from post-market monitoring.
Frequently asked questions
Is classifying an AI system's risk the same as assessing its risk?
No. Classification (Article 6, Annex III) is a one-off legal exercise: deciding whether a system is prohibited, high-risk, limited-risk, or minimal-risk. Risk assessment (Article 9) is the continuous methodological process — identify, measure, mitigate, monitor — required afterwards, throughout the system's entire lifecycle, once it has been found to be high-risk.
How often does the risk assessment need to be repeated?
Article 9 requires a continuous iterative process, with regular systematic review and updating throughout the system's lifecycle, fed in part by data from post-market monitoring — it is not a one-off assessment done at deployment.
Is implementing ISO 42001 enough to comply with Article 9 of the AI Act?
ISO 42001 provides the governance structure and a catalogue of controls in its Annex A, but it doesn't prescribe a specific risk-assessment methodology per system, nor does it replace legal compliance with the Regulation. It's worth pairing it with an operational methodology such as ISO 23894 or the NIST AI RMF, together with the technical documentation the AI Act itself requires.
With the deadline pushed to December 2027, can we delay this work?
It's not advisable. The Digital Omnibus only postponed the application date of Annex III obligations — it didn't reduce what Article 9 requires. Building a real risk-management system — identification, testing, monitoring — takes months, and other obligations (such as Article 50 transparency) keep their original timeline.