AI Act Article 9: Turning Risks into Verifiable Controls and Tests

What this guide covers—and what it does not

Article 9 of the European Union Artificial Intelligence Act (AI Act) requires providers of high-risk AI systems to establish, implement, document and maintain a risk management system. The practical idea behind this guide is straightforward: connect every identified risk to a measure, and define how to check whether that measure helps reduce the risk.

This guide is limited to Article 9. It is not a complete explanation of the Regulation, a legal assessment of a product, or a method for deciding on its own whether a system is high-risk. Nor does it make every AI tool subject to Article 9. First, you need to determine whether the system and its intended purpose fall within the relevant scope of the Regulation. Only then does it make sense to use this template as a working aid.

Article 9 sets out obligations for providers of high-risk AI systems. That does not mean that everyone who uses a system automatically has to create and maintain the risk management system required of providers. The duties of other actors, such as deployers, must be assessed separately. For broader orientation, consult our guides to safety, system comparisons and AI tool discovery; they do not replace checking which obligations apply to a specific case.

Throughout this article, we distinguish between two levels. “Regulatory requirement” identifies what Article 9 sets out. “Operational recommendation” describes a practical way to organize the work that may help demonstrate compliance, but should not be confused with a form or field expressly required by the law.

Preliminary check: Is the system in scope?

Before recording risks under Article 9, identify the specific system and its intended purpose. Classification does not depend only on whether the product uses an advanced model, whether the organization considers it sensitive, or whether its outputs have significant consequences. The Regulation determines which systems are considered high-risk through categories and conditions, and classification may depend on how the system is used and the role it plays.

As an initial check, describe the actual and intended use precisely enough to assess it: who operates the system, who receives or uses its outputs, what decision or process it supports, and the context in which it is integrated. Then compare that description with the relevant provisions of the Regulation, including applicable categories and any conditions or exceptions that could affect classification. If there is uncertainty about the category, the organization’s role or when an obligation applies, seek legal review before treating a provisional conclusion as fact.

Do not classify a system based only on marketing language, the technology it incorporates or the name of a category. A system may have different uses; the assessment should focus on the specific use being considered. The applicant-screening example later in this guide is hypothetical and illustrates how to document a risk. It does not claim that every applicant-screening system automatically receives the same legal classification.

Record what information supports the initial conclusion: product documentation, the stated purpose, a description of the process and deployment conditions. If the conclusion depends on assumptions that have not yet been confirmed, mark them as pending. This prevents the template from turning a classification hypothesis into an apparently definitive premise.

From context to an assessable risk

Article 9 describes a continuous, iterative process that must cover the system’s lifecycle. To begin usefully, describe the context of use before listing possible harms. The same system output may have different consequences depending on who interprets it, what other checks exist and whether a person can correct an error before it affects someone.

The Regulation refers to known and reasonably foreseeable risks to health, safety and fundamental rights when a system is used as intended. It also requires estimating and evaluating risks that may arise from that intended use and from reasonably foreseeable misuse. It is therefore useful to examine both intended use and foreseeable deviations, without treating every remote possibility as a proven risk.

For each scenario, distinguish three things: what you know, the hypothesis you want to test and the possible harm. For example, it may be a fact that the system produces a classification; a hypothesis that certain incomplete records increase the likelihood of an incorrect classification; and a plausible harm that someone is excluded from an assessment stage without an appropriate review. The test should establish whether the hypothesis holds and under what conditions.

Include the people who may be affected and the conditions that could change the outcome: data quality or missing data, language, the operating environment, human involvement, dependence on other components and changes in the process. There is no need to pretend to be certain when you only have a hypothesis. It is better to identify missing information and explain how you will investigate it than to present an unsupported estimate as though it were a measurement.

From each risk to a relevant measure

Once you have described the scenario, define what change could prevent or reduce the risk and why you expect it to work. Article 9 requires appropriate risk management measures that address the risks identified. It also provides that risks must be eliminated or reduced as far as technically possible through appropriate design and development; where they cannot be eliminated, appropriate mitigation and control measures must be implemented.

In practice, a measure may relate to the system’s design, its configuration, its instructions or how it is integrated into a process. The choice depends on the risk and the system. Do not assume that an interface warning or generic human review is enough: describe what the measure will do, when it applies, who can intervene and what its limitations are. If a person needs information or training to deploy the system appropriately, specify what they need to know and how it will be provided; the Article also addresses information and training for deployers where applicable.

A measure’s rationale should be connected to the mechanism behind the risk. If the concern is that incomplete data produces unreliable results, a control that only records the execution date may leave the cause untouched. By contrast, you could assess mechanisms that detect incomplete data, prevent an invalid result from being used without review, or alert the operator. These are options to investigate, not universal prescriptions: testing must show whether they are relevant and effective in the specific context.

Bear in mind that the Regulation relates risk management to the state of the art, as well as to the intended purpose and reasonably foreseeable misuse. The record should therefore explain why a measure was selected and what information supported that choice. When the measure does not eliminate the risk, document what remains and the conditions under which the control might fail.

Design tests before running them

Article 9 includes testing high-risk AI systems to identify the most appropriate risk management measures. It also provides that, where appropriate, testing must take place at different stages of development and, in any event, before the system is placed on the market or put into service. The Regulation states that tests must follow previously defined probabilistic metrics and thresholds that are appropriate to the intended purpose. The Article itself does not set one metric that works for every system.

For a test to support a decision, define in advance the scenario it covers, the data or conditions involved, the outcome you will observe and the criterion you will consider sufficient. Explain why that criterion is relevant to the intended use. If you determine it after seeing the results, you increase the risk of adapting the evaluation to what has already happened and failing to detect important problems.

Also test the conditions that matter to the risk, such as missing data, language changes, borderline cases, inputs outside usual conditions or the planned human intervention. Selection should have a documented rationale; there is no need to list scenarios unrelated to the use. If you use a sample, explain its limitations and which groups, situations or conditions it does not represent. A favorable result in a narrowly defined test does not, on its own, demonstrate that the system is safe in every environment.

A result may be favorable, insufficient or inconclusive. In the latter two cases, describe what failed or what prevents a conclusion, adjust the measure if appropriate and define a new test. Retain relevant results and decisions as evidence of how the risk was managed. Testing should not be reduced to saving a score: its purpose is to assess appropriate measures and check the system’s behavior in relation to its intended purpose.

Template: connect risk, control, test and decision

A useful record entry makes the full reasoning traceable without confusing a proposed control with a measure that has already been validated. In the hypothetical applicant-screening example, the point is not to claim that bias or harm has been proven. It is to show what information should be gathered before deciding whether a control reduces the risk in question.

The measure should address the scenario, and the test should evaluate that measure rather than the system in the abstract. In the example, if the scenario is that missing information influences a classification that is not subsequently reviewed, a relevant test might examine what happens when that information is absent and whether the planned review procedure is triggered. Specific criteria and results cannot be invented: they must be defined and measured for the actual system.

Record separately who prepared the assessment, who approved an internal decision and who should review legal questions. Assigning these functions may be good governance practice, but do not attribute a universal role to Article 9 if the text does not specify one. The person or entity with an obligation depends on their role under the Regulation and the circumstances of the case.

What to do with insufficient results and residual risks

A result that does not meet the planned criterion should not be fixed by retrospectively changing the threshold until it appears acceptable. Record the result as obtained, explain which condition was not met and assess whether the cause calls for a design change, an added or revised mitigation measure, a change to the deployment process or a restriction on the evaluated use. Then plan a new assessment where appropriate.

If the test does not support a conclusion, identify why: a lack of suitable data, a scenario that cannot be reproduced, a limited sample or an unobserved condition of use. That uncertainty is relevant information too. State what would be needed to resolve it and who should decide whether to investigate further, limit the use or escalate the issue.

Do not describe a risk as eliminated if all that has happened is that its likelihood has been reduced or its impact limited. The documentation should make visible the difference between the initial risk, the effect of the measures and what has not yet been tested. This distinction helps reviewers avoid interpreting a planned action as demonstrated effectiveness.

Article 9 requires documentation of the risk management system and relevant decisions. As an operational recommendation, retain test versions, execution conditions, results and the reasoning behind decisions alongside the record. Before setting retention periods, check the provisions applicable to the system and the organization: this guide does not establish a universal period.

Lifecycle review and links to other processes

Risk management under Article 9 is not framed as a one-off assessment that ends when a test is completed. The system must operate as a continuous, iterative process throughout the lifecycle, with regular and systematic review and updates. Information obtained after deployment may be relevant to risk assessment; the Article also addresses data gathered through the post-market monitoring referred to in the Regulation.

As an organizational recommendation, define which changes may trigger a review: significant system changes, changes to the intended purpose or context of use, detected problems, new information about risks or monitoring results. Specify who receives that information and how it is decided whether to update the analysis, measures or tests. These specific triggers are a recommendation for making review operational, not a list copied from Article 9.

If the system is already subject to risk management requirements under other Union legislation, Article 9 provides that the relevant risk management system may form part of, or contribute to, the processes required by that legislation, under the conditions set out in the Regulation. Do not assume that an existing procedure automatically satisfies every AI Act obligation: check which risks, evidence and requirements each process actually covers.

The date on which an obligation applies depends on the relevant transitional provisions and may require checking current amendments and transitional measures. The timeline cannot be inferred from Article 9 alone. Before planning a compliance date, check the current official text and the provisions applicable to the type of system and the organization’s role. If the date affects an immediate decision, seek up-to-date legal advice.

Practical checks before closing the assessment

Before treating the work as complete, check that every risk has a clear description and that observed facts are distinguished from hypotheses. Confirm that each measure addresses a specific risk, that its rationale can be reconstructed and that the test includes criteria defined before it is run. If a measure has not been tested, identify it as pending; if a test covers only certain conditions, do not extend its result to others.

Also verify that the analysis concerns the purpose and context actually assessed, considers reasonably foreseeable misuse where relevant and does not omit potentially affected people. Document the limitations of the work and the issues that require legal or technical review. When existing processes are involved, check what they cover, what evidence they provide and what gaps remain.

Article 9 is not an automatic certification that a system is safe or a guarantee that no harm will occur. It provides the basis for a risk management process that must be maintained and documented. The value of a matrix is not measured by its number of rows, but by whether it makes clear why a measure was selected, what test supports it, what result was observed and what remains unresolved.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.