EU AI Act Risk Management System Design: Article 9 Requirements (2026) | MmowW

Understanding Article 9: The Foundation of AI Risk Management

The EU AI Act, formally Regulation (EU) 2024/1689, places risk management at the centre of its regulatory framework for high-risk AI systems. Article 9 establishes that providers must design, implement, and maintain a risk management system that is not a one-time exercise but a continuous iterative process running throughout the entire lifecycle of the AI system. This requirement reflects the understanding that AI risks evolve as systems are deployed, updated, and used in ways that may not have been anticipated during initial development.

The risk management system described in Article 9(1) must be established, implemented, documented, and maintained. Each of these verbs carries distinct obligations. Establishing the system means creating a structured methodology. Implementing means putting it into practice. Documenting means creating records that can be reviewed by authorities. Maintaining means ensuring the system remains current as the AI system and its operating environment change.

The Four Core Requirements

Article 9(2) sets out four essential activities that together constitute the risk management process. These are not sequential steps to be completed once but ongoing obligations that feed into each other throughout the AI system's lifecycle.

The first requirement is the identification and analysis of known and reasonably foreseeable risks that the high-risk AI system can pose to health, safety, or fundamental rights. This goes beyond technical failure modes. Providers must consider how the system might affect people in practice, including vulnerable populations and those who may be disproportionately impacted by automated decisions. The scope of foreseeable risks includes those arising from the intended purpose of the system as well as conditions of reasonably foreseeable misuse.

The second requirement is the estimation and evaluation of the 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. Article 9(2)(b) requires providers to assess both the likelihood and severity of potential harms. This evaluation must be grounded in available data and evidence rather than speculative assumptions.

The third requirement addresses the evaluation of other risks that may arise based on the analysis of data gathered from the post-market monitoring system referred to in Article 72. This creates a feedback loop where real-world deployment data informs ongoing risk assessment. As the AI system operates in production environments, new risk patterns may emerge that were not identifiable during development and testing phases.

The fourth requirement is the adoption of appropriate and targeted risk management measures designed to address the identified risks. Article 9(2)(d) specifies that these measures must give due consideration to the effects and possible interactions resulting from the combined application of the requirements set out in Section 2 of the Act. Risk treatment is not merely about mitigating individual risks in isolation but understanding how different measures interact with each other and with the overall system.

Residual Risk Communication

Article 9(3) addresses a reality that every risk management professional understands: not all risks can be eliminated. The provision requires that when risk management measures are implemented, the remaining residual risks associated with each hazard must be judged to be acceptable. The determination of what constitutes acceptable residual risk must consider the cumulative effect of all residual risks together, not each one in isolation.

Article 9(4) establishes an important obligation regarding transparency about residual risks. Providers must communicate residual risks to deployers through the instructions for use referred to in Article 13. Where residual risks remain after all reasonable mitigation measures have been applied, the deployer must be informed so they can make appropriate decisions about how to manage those risks in their specific deployment context. This creates a chain of responsibility from provider to deployer to end user.

Testing Throughout the Development Process

Article 9(5) through 9(7) address testing requirements. High-risk AI systems must be tested for the purpose of identifying the most appropriate and targeted risk management measures. Testing must ensure that high-risk AI systems perform consistently for their intended purpose and are in compliance with the requirements of the Act.

Article 9(6) specifies that testing procedures may include testing in real-world conditions in accordance with Article 60. This provision acknowledges that laboratory testing alone may not capture the full range of risks that emerge in actual deployment environments. Real-world testing must be conducted with appropriate safeguards and in compliance with the conditions set out in the Act.

Article 9(7) requires that testing be performed at appropriate points during the development process and, in any event, prior to the placing on the market or putting into service of the AI system. Testing benchmarks and methodologies must be established with due regard to the intended purpose of the high-risk AI system and the state of the art.

The Continuous Iterative Nature

What distinguishes the Article 9 risk management system from traditional product safety assessments is its explicitly iterative character. Article 9(8) requires that the risk management system be designed to ensure that any significant change to the high-risk AI system triggers a new risk assessment. This prevents providers from treating their initial risk assessment as a permanent document that never requires revision.

The iterative process means that risk identification feeds into risk evaluation, which feeds into risk treatment, which feeds back into risk monitoring. Post-market monitoring data, as referenced in Article 9(2)(c), creates an additional feedback loop that connects real-world performance to the risk management process. This continuous cycle ensures that the risk management system remains a living process rather than a static compliance document.

Practical Implementation Considerations

Implementing an Article 9-compliant risk management system requires organisational commitment beyond the technical team. Risk identification should involve domain experts who understand the contexts in which the AI system will be deployed. Risk evaluation requires methodologies that can assess both quantitative metrics and qualitative impacts on fundamental rights. Risk treatment decisions must balance effectiveness against feasibility and proportionality.

Documentation is a critical element throughout. The risk management system must produce records that demonstrate not only what risks were identified and how they were addressed, but also the reasoning behind decisions about acceptable residual risk levels. These records form part of the technical documentation required under Article 11 and Annex IV, and must be available for review by national competent authorities and notified bodies.

Organisations seeking to operationalise these requirements may benefit from structured daily practices that embed risk awareness into their AI operations. The WnowW Trust OS at mmoww.net/ai/app/ provides a framework for tracking AI system risks, maintaining documentation, and building the kind of continuous monitoring culture that Article 9 demands. Rather than treating compliance as a periodic audit exercise, the most effective approach treats risk management as part of the daily operational rhythm.

The risk management system required by Article 9 is not merely a regulatory burden. It is a structured approach to understanding and managing the real-world impacts of AI systems. Organisations that invest in robust risk management processes will be better positioned not only for regulatory compliance but for building AI systems that genuinely serve their intended purpose while respecting fundamental rights. Content verified against current regulations by Sawai Gyoseishoshi Office.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.