Article 9 mandates a continuous, documented process that runs from the design phase through the entire operational lifecycle, covers reasonably foreseeable misuse as well as intended use, feeds into Annex IV technical documentation, and loops back through post-market monitoring data. Most providers are not yet there.
Your legal team has read Article 9. What your engineering and compliance teams need is a clear account of what the obligation actually requires to produce.
Key takeaways:
- Article 9 requires a continuous iterative risk management system, not a one-time assessment: it must be established, implemented, documented, and maintained throughout the entire lifecycle of every high-risk AI system.
- The obligation explicitly covers reasonably foreseeable misuse, not just intended use — providers cannot defend non-compliance by claiming harmful uses were unintended if they were predictable.
- The risk management system must integrate with Annex IV technical documentation, Article 10 data governance, Article 14 human oversight design, and Article 72 post-market monitoring as a unified architecture, not as parallel compliance workstreams.
What Article 9 Actually Requires
Article 9(1) states that a risk management system shall be "established, implemented, documented and maintained" in relation to high-risk AI systems. That four-verb formulation is deliberate. A system that is established and documented but not implemented and maintained does not satisfy the requirement.
Article 9(2) defines the structure as a "continuous iterative process planned and run throughout the entire lifecycle" of the system. It comprises four steps, taken in sequence but repeated as conditions change:
Step 1 — Identification and analysis of known and reasonably foreseeable risks. This covers risks to health, safety, and fundamental rights during intended use. "Reasonably foreseeable risks" extends beyond technical failure to discrimination risk, privacy harm, and autonomy impacts. A provider cannot limit risk identification to the scenarios they designed the system for.
Step 2 — Estimation and evaluation of risks. Risk evaluation must cover not only the intended purpose but also "reasonably foreseeable misuse." Article 9(2)(b) is the provision most commonly misread: providers frequently treat foreseeable misuse as a residual edge case. The legal standard is that any repurposing or over-reliance pattern that a reasonable person could anticipate must be assessed. A recruitment system redeployed outside its validated domain, a medical AI whose outputs are systematically over-relied upon, a scoring model applied to unvalidated populations — these are foreseeable, and they must be in the risk analysis.
Step 3 — Evaluation of risks arising from post-market monitoring data. Article 9(2)(c) creates an explicit link between operational experience and risk assessment. Once the system is deployed, data from Article 72 post-market monitoring feeds back into the Article 9 risk management cycle. This means the risk system is not closed at market placement — it must be capable of integrating new evidence and updating accordingly.
Step 4 — Adoption of targeted risk management measures. Measures must correspond to the specific hazards identified in steps 1 through 3. A general statement that "human review is in place" is not a targeted measure. The measure must map to a concrete identified risk.
The Three-Tier Mitigation Hierarchy
Article 9(5) establishes the order in which risk mitigation must be applied. This is not optional sequencing; it is a legal hierarchy:
Tier 1: Design elimination. Risks must be eliminated or reduced through system design and development as far as technically feasible. This means the design phase itself is a compliance obligation, not just the documentation phase. If a risk can be removed by adjusting the system's architecture, training methodology, or output constraints, that elimination must happen before resorting to warnings or operational controls.
Tier 2: Mitigation and control measures. For risks that cannot be eliminated through design, providers must implement mitigation measures: monitoring controls, output constraints, confidence thresholds, operational guardrails. These must be specific and verifiable, not generic.
Tier 3: Documentation and user information. Residual risks that survive tiers 1 and 2 must be communicated to deployers through the technical documentation, instructions for use, and training materials required under Article 13. Documentation is the last resort in the hierarchy, not the primary compliance mechanism.
Article 9(5) then requires that "the relevant residual risk associated with each hazard... shall be judged to be acceptable." That judgment must be documented: who made it, on what basis, and under what conditions it would be revisited.
Testing Requirements Under Article 9(6)-(8)
Testing is a formal obligation under Article 9, not a quality-assurance practice the provider can structure at discretion. Article 9(6) requires that high-risk AI systems "be tested for the purpose of identifying the most appropriate and targeted risk management measures." Testing is explicitly a risk management activity, not a separate engineering step.
Article 9(8) specifies that testing must use "prior defined metrics and probabilistic thresholds appropriate to the intended purpose of the high-risk AI system." This requires defining acceptable performance parameters before running the test, not after. Providers who define metrics retrospectively to match their results do not satisfy this requirement.
Testing must occur throughout development and before market placement (Article 9(8)). Article 9(7) notes that testing may include real-world conditions testing under Article 60, which establishes specific conditions for controlled deployment in real-world environments. Post-market performance data gathered under Article 72 must be fed back into the testing cycle.
Testing must include assessments of fairness and robustness across subgroups, not only aggregate accuracy. Article 9(9) specifically requires providers to consider adverse impacts on persons under 18 and on vulnerable groups when relevant to the intended purpose. In education, healthcare, welfare, recruitment, insurance, and public services contexts, that consideration is nearly always relevant.
This integrates directly with Article 10 data governance requirements: the quality of training and validation data directly determines the quality of risk identification. Providers cannot build a defensible Article 9 risk management system on top of an undocumented data pipeline.
How the Risk Management System Feeds Into Annex IV
Annex IV defines the technical documentation that high-risk AI providers must produce and maintain. Section 5 of Annex IV specifically requires "a detailed description of the risk management system in accordance with Article 9." The risk management system is not a standalone compliance artefact — it is a required section of the technical file that must be maintained alongside the other Annex IV elements throughout the system's lifecycle.
The Annex IV technical file also requires (in Section 2) "foreseeable unintended outcomes and sources of risks" and human oversight measures assessment. Both of these feed from the Article 9 risk management process. If the risk management system is thin or underdocumented, multiple Annex IV sections will be incomplete.
The practical implication is that the risk management system documentation must be treated as a living artifact, updated alongside engineering changes rather than as a point-in-time compliance document finalized at launch. If the system is materially updated — through retraining, architecture changes, or significant deployment context shifts — the Annex IV technical file and the Article 9 risk management system must both be updated to reflect the new risk profile.
For organizations already building EU AI Act technical documentation, the risk management system is the section most likely to be structurally absent. Most technical documentation drafts we have seen contain extensive system descriptions but only a paragraph on risk management that paraphrases Article 9 rather than documenting an actual assessment.
The Four-Article Integration Requirement
Article 9(4) specifies that the risk management system must take into account requirements in Articles 10, 13, 14, and 17 where applicable. These are not separate compliance workstreams — they are required inputs to and outputs from the risk management process:
Article 10 (Data governance): Risk identification in Article 9(2)(a) directly depends on data quality. Providers cannot identify fundamental rights risks from a system trained on undocumented data. Data quality failures and bias in training data are sources of risk that must appear in the Article 9 risk analysis.
Article 13 (Transparency and provision of information): The instructions for use and technical documentation required by Article 13 must convey the residual risks identified under Article 9. Where providers have completed an Article 9 analysis, the Article 13 documentation requirements become concrete: the risks to document are the residual risks that survived the tier 1 and tier 2 mitigation process.
Article 14 (Human oversight): Article 14 requires high-risk AI systems to be designed to enable human oversight. The design choices that satisfy Article 14 (override capability, monitoring interfaces, output interpretation tools) must be informed by the Article 9 risk analysis. If the risk analysis identifies a high-severity failure mode, the human oversight design must include a mechanism to detect and intervene in that specific failure mode, not just generic override capability.
Article 72 (Post-market monitoring): The connection to post-market monitoring under Article 72 creates the lifecycle feedback loop that makes Article 9 genuinely continuous. Post-market monitoring data must be evaluated and, where it reveals new risk patterns, fed back into the Article 9 risk assessment cycle. This means providers need a defined process for reviewing post-market monitoring outputs against the current risk assessment and triggering updates when thresholds are crossed.
What to Produce: A Minimum Viable Risk Management System
For organizations building their Article 9 compliance documentation, the following structure represents the minimum viable system that satisfies the legislative requirements:
| Document/Process | Required Content | Article 9 Basis |
|---|---|---|
| Hazard map | Known and reasonably foreseeable risks to health, safety, fundamental rights — intended use and foreseeable misuse scenarios | Art. 9(2)(a)-(b) |
| Risk estimation record | Severity and probability assessment per hazard; vulnerable group impact assessment | Art. 9(2)(b); Art. 9(9) |
| Mitigation log | Tier 1 (design decisions), Tier 2 (operational controls), Tier 3 (documentation) — mapped to hazards | Art. 9(5) |
| Residual risk acceptability record | Documented judgment per residual risk with decision-maker, basis, and re-evaluation trigger | Art. 9(5) |
| Testing protocol and results | Pre-defined metrics and probabilistic thresholds; fairness and robustness test results | Art. 9(6)-(8) |
| Post-market monitoring integration | Process for reviewing Article 72 data against current risk assessment; update trigger criteria | Art. 9(2)(c) |
| Annex IV Section 5 | Risk management system description in the technical file | Annex IV, Section 5 |
Illustrative Hazard Map Entry
A hazard map entry for a recruitment screening AI might look like this:
| Field | Content |
|---|---|
| Hazard ID | RM-003 |
| Hazard description | System assigns lower suitability scores to candidates from underrepresented demographic groups due to historical hiring data bias in training set |
| Risk type | Fundamental rights (non-discrimination, Article 21 EU Charter) |
| Scenario | Intended use: screening applicants for shortlisting. Foreseeable misuse: use as definitive hiring decision without human review |
| Severity | High (irreversible employment exclusion) |
| Probability | Medium (validated on test set but training data documented as non-representative across three demographic dimensions) |
| Mitigation tier | Tier 1: Rebalance training dataset and re-train before deployment. Tier 2: Flag low-confidence outputs for mandatory human review. Tier 3: Document known limitations in technical file and deployer instructions |
| Residual risk | Low — documented and judged acceptable subject to quarterly fairness audit |
| Re-evaluation trigger | Any training data update; significant shift in applicant demographic profile; any DPA investigation involving discrimination |
Every hazard identified in the Article 9 analysis should produce an entry at this level of specificity. Generic risk descriptions ("potential bias") without source identification and mitigation mapping do not satisfy Article 9(2).
Alignment with ISO 42001
Organizations that have implemented or are implementing ISO 42001 will find that Article 9's requirements map significantly onto ISO 42001's Clause 6 (Planning) and Clause 8 (Operation) risk management controls, and Clause 10 (Improvement) for the feedback cycle. ISO 42001 implementation does not automatically satisfy Article 9 — the EU AI Act's specific requirements around foreseeable misuse, the three-tier mitigation hierarchy, and Annex IV integration go beyond ISO 42001's general framework — but the two frameworks are structurally compatible, and organizations with mature ISO 42001 programs are well-positioned to satisfy Article 9 with targeted additions.
Article 9(10) explicitly permits providers to integrate the EU AI Act requirements with existing risk management obligations under Union law, which includes sector-specific frameworks in financial services, medical technology, and critical infrastructure. Integration is permitted but not automatic: the provider must demonstrate that the integrated process actually addresses the specific Article 9 requirements, not just that it addresses risk in general.
Common Implementation Mistakes to Avoid
Treating the risk register as the risk management system. A spreadsheet of identified risks is an input to the Article 9 system, not the system itself. The system is the documented process for identifying, evaluating, mitigating, and continuously reviewing those risks. The register is one artifact within that process.
Limiting risk analysis to technical failure. Article 9 covers risks to fundamental rights — discrimination, privacy harm, erosion of autonomy, and due process failures. These are not engineering failures in the conventional sense. Providers whose risk analysis focuses exclusively on system accuracy, uptime, and data quality have missed a substantial portion of the Article 9 scope.
Retrofitting risk management post-launch. Article 9 requires the system to be established from the development phase, not completed before a conformity assessment and then maintained only nominally. Testing requirements under Article 9(6)-(8) apply throughout development, which means the risk management process must begin before the system is complete.
Over-relying on user warnings. Documentation and user training occupy the third tier of the mitigation hierarchy for a reason. Providers that respond to identified risks by adding a disclaimer to the technical documentation without first genuinely assessing whether design changes could eliminate or reduce the risk are not satisfying Article 9(5)'s sequencing requirement.
Enforcement Context: Why This Matters Now
The August 2, 2026 enforcement date is not a target to prepare toward — it is the date on which national market surveillance authorities under Article 74 can open investigations and impose sanctions under Article 99. The fine exposure for providers who fail to meet Article 9 requirements is up to €15 million or 3% of total worldwide annual turnover, whichever is higher.
EU AI Act compliance across the high-risk AI system requirements (Articles 8 through 15) is a unified obligation. A provider whose system passes conformity assessment without a genuine Article 9 risk management system in place has not completed compliance — they have passed a documentation check that will not hold up under investigation.
Frequently Asked Questions
Does Article 9 apply to deployers of high-risk AI systems, or only to providers?
Article 9 is a provider obligation. Providers are the entities that develop and place high-risk AI systems on the market or put them into service. Deployers (organizations using AI systems supplied by others) have their own obligations under Article 26, which includes implementing the risk management measures specified in the provider's technical documentation. The deployer's Article 26 obligations are distinct from and do not substitute for the provider's Article 9 obligations.
What counts as a "material change" that triggers an Article 9 update?
The EU AI Act does not define "substantial modification" at the level of granularity that answers this question definitively, but Article 6(3) and Recital 66 together indicate that changes altering the system's intended purpose, risk level, or performance metrics in a way that affects compliance are substantial. In practice, this covers retraining that changes model behavior, deployment to a new use case not covered in the original documentation, and significant changes to the system's data inputs. Providers should define their own internal update triggers in the Article 9 documentation — this demonstrates proactive compliance and creates a documented basis for claims that a given change did not require re-assessment.
How does Article 9 interact with GDPR data protection impact assessments?
They are parallel requirements with overlapping scope, not substitutes for each other. Where a high-risk AI system processes personal data, the GDPR Article 35 DPIA requirement applies independently of Article 9. The DPIA covers risks to data subjects' rights and freedoms; the Article 9 risk management system covers risks to health, safety, and fundamental rights broadly. A DPIA that documents privacy risks in an AI system does not satisfy Article 9, and vice versa. Both must be completed. The practical advice is to run the DPIA and the Article 9 risk analysis concurrently, using the findings from each to inform the other.
Can we use an AI governance tool to manage Article 9 compliance documentation?
Yes, and given the volume and lifecycle nature of the documentation required — risk assessments per hazard, mitigation decisions with version histories, testing protocols and results, post-market monitoring integration — tooling is effectively necessary for anything beyond a single low-complexity system. The tool must support version control of the risk assessment documentation, audit trails for decisions, and process hooks for triggering reviews when system updates or post-market data require it.
What is the relationship between Article 9 and conformity assessment?
Article 43 governs conformity assessment for high-risk AI systems. For most high-risk AI systems, providers can self-assess conformity against the applicable harmonized standards. The Article 9 risk management system is one of the core elements assessed during conformity assessment (by a notified body or self-assessment). A system that has not completed a genuine Article 9 process cannot issue the EU declaration of conformity under Article 47 or affix the CE marking. Providers who attempt conformity assessment before their Article 9 system is documented and operational will need to complete it before the declaration can be issued.
Does Article 9 require us to test for adversarial attacks?
Article 9(6) requires testing for the "most appropriate and targeted risk management measures." If an adversarial attack is a reasonably foreseeable risk for the specific system in its intended deployment context — which it typically is for high-value decision-making systems, security applications, and systems in regulated sectors — then adversarial robustness testing falls within the Article 9 testing obligation. Providers should document whether adversarial attack scenarios are in scope for their system's risk profile and explain the assessment either way.
Secure Privacy's Privacy & AI Governance Platform provides structured workflows for building and maintaining EU AI Act documentation, including Article 9 risk management system records, Annex IV technical file sections, and post-market monitoring integration. The platform is designed for governance and compliance teams managing multiple AI systems, with audit trails, version control, and reporting built in from the ground up.
