EU AI Act Article 9 risk management — what evidence is required

Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. The regulation specifies that this system must:

• Be a continuous iterative process — not a one-time assessment.
• Cover the entire lifecycle of the system, from design through decommissioning.
• Be proportionate to the nature, severity, and probability of the risks.
• Address risks to health, safety, and fundamental rights, including the environment.
• Consider reasonably foreseeable misuse, not just intended use.
• Give specific attention to vulnerable groups: children, elderly, people with disabilities.

What Article 9 does not specify is the format. There is no required template, no mandated scoring methodology, no prescribed document structure. This is deliberate — the regulation is technology-neutral and sector-neutral. The consequence is that organisations have to decide what their risk management system looks like, and then demonstrate that it satisfies the six requirements.

Article 9 contains six substantive requirements. They are not numbered as such in the regulation — they are spread across paragraphs 2 through 9 — but they map cleanly to six distinct obligations. Each one has a specific evidence implication.

Article 9(2)(a) requires identification of the known and reasonably foreseeable risks that the AI system can pose to health, safety, or fundamental rights when used as intended and when subject to reasonably foreseeable misuse.

The key word is reasonably foreseeable misuse. This is not a theoretical exercise. It requires the provider to think through how the system will actually be used by real people in real contexts — including people who are not the intended users, people who are under pressure, and people who are trying to game the system.

Article 9(2)(b) requires evaluation of the risks identified — specifically, assessment of their likelihood and severity, taking into account the intended purpose and the state of the art.

Article 9(9) adds a specific requirement to consider the impact on vulnerable groups. This is not optional for high-risk systems — if your system could be used by or affect children, elderly people, or people with disabilities, the risk evaluation must address their specific exposure.

Likelihood and severity without a methodology is an opinion. Likelihood and severity with a defined scale, applied consistently across all identified risks, is evidence.

The regulation does not mandate a specific scoring methodology. What it requires is that the evaluation is documented, consistent, and proportionate. A 3×3 likelihood × severity matrix with defined criteria for each level is sufficient. A spreadsheet column that says “High” without a definition is not.

Article 9(2)(c) and 9(4) require that risks are addressed through appropriate measures. The regulation specifies a hierarchy: eliminate the risk if possible; if not, reduce it to an acceptable level; if residual risk remains, accept it explicitly.

Article 9(4) is specific about what “appropriate measures” means for AI systems: technical measures built into the system design, and information and training measures for deployers and users. Both categories must be documented.

Article 9(4) requires that residual risks — risks that remain after treatment measures have been applied — are communicated to deployers and users. Article 9(2)(d) requires that the overall residual risk is judged acceptable.

“Judged acceptable” is the operative phrase. The regulation requires a judgment, not just a statement. That judgment must be made by someone with the authority to make it, documented, and tied to the conditions under which it holds.

Article 9(5) and 9(6) require testing of the AI system to verify that it performs as intended and that the risk management measures work. Testing must be done before the system is placed on the market and must be repeated when the system changes materially.

Article 9(6) specifically requires testing against the intended purpose and against reasonably foreseeable misuse scenarios. For agentic systems, this means adversarial testing — not just functional testing.

The regulation does not specify what testing methods to use. What it requires is that testing is documented, that the results are recorded, and that the testing covers both the intended use case and the foreseeable misuse scenarios identified in the risk assessment.

Articles 9(7) through 9(9) require that the risk management system is updated throughout the lifecycle of the system. This means monitoring the system in production, collecting data on its performance and any incidents, and updating the risk management record when issues are found or the system changes.

Article 9(9) requires that the risk management system is reviewed and updated when the AI system is modified in a way that could affect its compliance with the regulation. For agentic systems, this includes changes to the model, the tool manifest, the data sources, the user population, or the autonomy level.

The table below maps each Article 9 requirement to the specific evidence an auditor or notified body will ask for, and the gap that appears most often when organisations try to produce it.

ISO/IEC 42001 is the AI management system standard. It was published in December 2023 and is the closest thing to a structured implementation guide for Article 9. An organisation that implements ISO 42001 correctly will produce most of the evidence Article 9 requires as a side effect of running the management system.

The alignment is not perfect. The two gaps are:

• Residual risk acceptance specificity. ISO 42001 requires a risk treatment decision but does not mandate the four-element acceptance statement that Article 9 implies. Organisations implementing ISO 42001 need to add this explicitly.
• Post-market monitoring cadence. ISO 42001 §9.1 requires monitoring but does not specify frequency. Article 9(7) implies continuous monitoring for high-risk systems. The monitoring plan needs to be explicit about cadence.

The practical implication: if you are implementing ISO 42001 and need to demonstrate Article 9 compliance, you are most of the way there. The additional work is in the specificity of the residual risk acceptance statement and the explicitness of the post-market monitoring cadence.

The ISO 42001 controls map spreadsheet maps all 28 controls to their Article 9 equivalents with the evidence required for each.

Article 9 applies to high-risk AI systems as defined in Annex III. If your system is not in Annex III, you are not legally required to comply with Article 9.

You are, however, likely to face the same questions from procurement teams, internal audit, and enterprise customers — particularly if you are a B2B SaaS vendor selling AI features into regulated industries. The evidence framework Article 9 describes is the most widely understood template for AI risk documentation. Using it for non-high-risk systems is not over-engineering — it is speaking the language your buyers already know.

Article 9 does not specify what the risk management system looks like. It specifies what it must contain. The AI Risk Disposition memo — as described in the first piece in this series — is designed to be that artefact.

The seven sections of the disposition map directly to Article 9's requirements:

• Decision → the overall risk judgment (Art. 9.4)
• Rationale → the reasoning behind the judgment
• Required controls → the risk treatment measures (Art. 9.3–9.4)
• Residual risk → the explicit residual risk acceptance (Art. 9.4)
• Evidence gaps → what is not yet known (Art. 9.2)
• Re-assessment triggers → the post-market monitoring mechanism (Art. 9.7–9.9)
• Sign-off log → the record of who accepted the risk and when

A disposition memo that contains all seven sections, with the evidence fields filled in, is a defensible Article 9 risk management record. It is not the only valid format — but it is a format that a notified body, a market surveillance authority, and an enterprise procurement team can all read.