TL;DR: Article 9 requires a continuous, iterative risk management system for every high-risk AI system, covering four mandatory elements: risk identification, risk estimation, residual risk evaluation, and risk mitigation measures. This is not a one-time audit. It must run throughout the full system lifecycle and be documented in a format auditors can inspect.
EU AI Act Article 9 is the backbone of the high-risk AI compliance regime. Every other technical obligation for high-risk AI systems, from the instructions for use in Article 13 to the human oversight controls in Article 14, traces back to what your risk management system identified and documented. Getting Article 9 right means getting high-risk AI compliance right.
This guide walks through every element Article 9 requires, how to document each one, what notified bodies check during conformity assessment, and the most common gaps that cause audit findings.
What Article 9 actually requires
Article 9 establishes a risk management system, not a risk assessment. The distinction matters. A risk assessment is a snapshot. A risk management system is a documented, version-controlled process that runs from initial design through decommissioning and gets updated whenever the system changes.
The text of Article 9(1) makes this explicit: the risk management system shall be "a continuous iterative process run throughout the entire lifecycle of a high-risk AI system." This is not a checkbox. It is an ongoing obligation.
The system must consist of four mandatory elements.
Element 1: Identification and analysis of known and foreseeable risks. You must identify risks that the AI system could create for health, safety, or fundamental rights. This covers both the intended use case and reasonably foreseeable misuse. "Reasonably foreseeable misuse" is interpreted broadly. If a hiring algorithm is designed for screening CVs but could be used to rank candidates by inferred protected characteristics, that foreseeable misuse must appear in your risk record.
Element 2: Estimation and evaluation of risks. For each identified risk, you must estimate its probability and severity, and evaluate it across both the intended use and foreseeable misuse scenarios. Article 9(2)(b) specifically requires estimation of risks "that may emerge when the high-risk AI system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse." This is where protected characteristics, data quality limitations, and deployment context all need documented analysis.
Element 3: Evaluation of residual risks after mitigation. After you have applied risk mitigation measures, you must evaluate what risks remain. The residual risk evaluation must conclude either that remaining risks are acceptable (with documented reasoning) or that additional mitigations are needed. If residual risks cannot be reduced to an acceptable level, the system cannot be placed on the market.
Element 4: Adoption of appropriate risk management measures. Mitigation measures must be implemented, documented, and linked back to the risks they address. Article 9(4) sets a priority order: eliminate or reduce risks through design and development first; implement adequate control and protection measures for risks that cannot be eliminated; and provide information about residual risks in the instructions for use.
What "continuous" means in practice
Most organizations treat Article 9 as a pre-launch exercise. They document risks, implement mitigations, sign off, and move on. This does not satisfy the regulation.
The risk management system must be reviewed and updated in at least four circumstances:
-
Before initial deployment. The baseline risk assessment and mitigation record must be complete before the system is placed on the market or put into service.
-
After any incident or near-miss. If an AI system produces a harmful or potentially harmful output in production, the risk management record must be updated. This means your incident response process must have a formal handoff to the risk management process.
-
After any significant model update. Fine-tuning, retraining on new data, changes to input preprocessing, or changes to decision thresholds all require re-evaluation. The regulation does not define "significant" precisely, but notified bodies apply a test of whether the change could plausibly affect the risk profile.
-
After any change in deployment context. If the system is deployed in a new member state, used by a different type of deployer, or applied to a new user population, the risk assessment must be revisited. A credit scoring model deployed in Germany and then extended to Romania needs a new context evaluation.
Practically, this means maintaining a version-controlled risk management record with dated revision entries. Each review cycle should produce a new version with a summary of what changed and why.
Risk categories to assess
Article 9 does not list risk categories exhaustively, but the Regulation identifies four areas that must be addressed for any high-risk AI system:
Health and safety risks. Can the system produce outputs that lead to physical harm? Most obvious in medical, transport, or critical infrastructure contexts, but applies more broadly than many providers assume.
Fundamental rights risks. Can the system affect rights to privacy, non-discrimination, due process, or access to essential services? For Annex III systems (employment, education, credit, law enforcement), this category typically generates the most substantive findings during review.
Discrimination risks. Article 9(7) specifically requires bias testing before placing the system on the market and after significant modifications. The testing methodology and results must be documented.
Data protection risks. Article 9 risk assessments overlap with GDPR DPIAs for systems that process personal data. Both regulators will expect consistency between the two records.
How to document the risk management system
The risk management record does not have a mandatory template, but auditors expect to see specific elements present. A record that satisfies notified body review typically includes:
Header section: System name, provider identity, version number, date of this revision, and reference to the broader technical documentation file.
Scope and intended purpose: A precise description of the system's intended purpose, intended deployment context, and intended users. This is the baseline against which risks are evaluated.
Risk identification log: A table or structured list of identified risks, each with a unique reference ID, a plain-language description, the risk category (health/safety, fundamental rights, discrimination, data protection), and the evidence source that identified it.
Risk estimation table: For each identified risk: probability of occurrence (with rationale), severity of potential harm, affected population, and overall risk level before mitigation.
Mitigation measures register: For each identified risk: the mitigation measure applied, whether it is a design measure, a control measure, or a disclosure in the instructions for use, and the party responsible for implementing and verifying it.
Residual risk log: For each mitigated risk: the residual risk level after mitigation, the basis for accepting or rejecting that level, and any outstanding actions.
Review history: A dated log of every review cycle, what triggered it, what changed, and who approved the revision.
Bias testing record: Methodology, dataset description, test results, and any remediation actions taken as a result.
Notified body review vs. internal audit
For high-risk AI systems that require third-party conformity assessment (primarily Annex III categories where a harmonized standard does not provide a presumption of conformity), a notified body will review the Article 9 record directly. Internal audits by a qualified AI auditor or legal counsel are appropriate for systems not requiring notified body involvement.
Notified bodies apply a higher standard than internal reviewers. Their key checks are:
- Is the risk management system referenced in the technical documentation and consistent with it?
- Does the risk identification log include reasonably foreseeable misuse scenarios, not just intended-use scenarios?
- Are mitigation measures traceable to specific identified risks (no orphan mitigations, no unmitigated risks)?
- Is the residual risk evaluation supported by evidence, not just asserted?
- Does the bias testing record include the dataset description, methodology, and quantified results?
- Is there a documented review trigger for incidents and model updates?
Internal audits can use the same checklist, but organizations should be aware that what satisfies an internal reviewer may not satisfy a notified body. The standard for notified body review is whether the documentation would allow an independent technical expert to reproduce the risk evaluation conclusions.
Article 9 interaction with Article 13 and Article 14
Article 9 is not an isolated requirement. Its outputs feed directly into two other high-risk AI obligations.
Article 13 (transparency and instructions for use): The instructions for use that providers must give deployers must include information about the system's capabilities, limitations, and the circumstances under which outputs may be unreliable. This information comes from the Article 9 risk management record. If your risk record identifies that the system performs poorly on certain demographic groups, that limitation must appear in the instructions for use. Auditors will check for consistency between the two documents.
Article 14 (human oversight): Article 14 requires that high-risk AI systems be designed to allow natural persons to effectively oversee them, including the ability to override or shut down the system. The specific oversight mechanisms required depend on the risks identified in the Article 9 record. A system with high-severity risks requires more robust override capability than one with lower-severity risks. The risk management record should explicitly note what oversight measures are required and why.
Template structure for an Article 9 risk management record
A minimal Article 9 record that satisfies audit review has these sections:
- Document header (system ID, version, date, reviewer)
- System scope and intended purpose
- Risk identification log (table format: ID, description, category, source)
- Risk estimation table (ID, probability, severity, overall level, affected users)
- Mitigation measures register (risk ID, measure description, measure type, responsible party, verification method)
- Residual risk log (risk ID, residual level, acceptance decision, basis)
- Bias testing record (methodology, dataset, results, remediation)
- Review history log (date, trigger, changes made, approver)
- Cross-references to Article 13 instructions for use and Article 14 oversight design
Common gaps auditors find
Based on reported notified body findings and legal commentary on early conformity assessments, the most frequent Article 9 gaps are:
Scope too narrow for misuse scenarios. Risk records often cover intended use only. Article 9 explicitly requires reasonably foreseeable misuse. If the system is a resume screener, the risk record must address misuse for age or nationality discrimination even if the provider does not intend that use.
Mitigation measures not linked to risks. Some organizations document risks and mitigations separately without tracing which mitigation addresses which risk. Notified bodies require a traceable link.
No residual risk conclusion. Many records list residual risks but do not include a documented decision about whether they are acceptable. Article 9(4) requires that residual risks be communicated to deployers via the instructions for use. If the record does not document the acceptance decision, there is no basis for that communication.
No bias testing record. Article 9(7) is explicit about the testing requirement. Records that describe testing methodology in general terms without quantified results or dataset descriptions do not satisfy the requirement.
No review trigger for incidents. Records that document a pre-launch review but have no provision for post-incident re-evaluation fail the "continuous" requirement from Article 9(1).
Inconsistency with the instructions for use. A risk record that identifies a limitation but does not trace it to the Article 13 instructions will generate a finding. Both documents must be internally consistent.
What to do now
If you provide a high-risk AI system and do not yet have a documented Article 9 risk management record, the August 2027 compliance deadline sets the outer boundary. But notified body conformity assessment takes time, and the record must be complete before that process begins. Map your system to the Annex III categories first, then build the risk identification log from internal engineering knowledge and existing privacy or security assessments. Bias testing typically takes the longest, so start it early.
For teams already operating under ISO 42001 or NIST AI RMF, much of the underlying analysis will already exist. The task is mapping existing documentation to the Article 9 record format, not starting from scratch.
Related reading
- EU AI Act high-risk AI documentation templates
- Which AI systems are high-risk under Annex III
- EU AI Act August 2026 compliance checklist
- EU AI Act deployer evidence gaps for SMEs
- One documentation set for EU AI Act, NIST AI RMF, and Texas TRAIGA
- EU AI Act Article 13 transparency: what deployers must tell users of hig
- EU AI Act Compliance for Small Teams: The Complete Guide (2026)
- EU AI Act Conformity Assessment: What It Is and Who Must Do It
- EU AI Act high-risk classification: what the May 2026 draft guidelines chan
