Safeguard
Compliance•

EU AI Act risk management (Article 9) step by step

Article 9 asks for a continuous, lifecycle risk management process for high-risk AI. Four steps, what to record and how to test against metrics.

Safeguard Security Team
3 min read

Article 9 requires a continuous, iterative risk management system for high-risk AI across the whole lifecycle. In practice: identify risks to health, safety and fundamental rights, estimate them for intended use and foreseeable misuse, use post-market data to find more, then adopt measures until residual risk is acceptable. Test against defined metrics before release.

The four steps

  1. Identify and analyse known and reasonably foreseeable risks to health, safety or fundamental rights, given intended purpose and context.
  2. Estimate and evaluate risks from intended use and from reasonably foreseeable misuse, including misuse that comes from human behaviour or interaction with other systems.
  3. Evaluate further risks using data from post-market monitoring.
  4. Adopt targeted risk management measures.

Only risks that can reasonably be reduced or removed through design, development or adequate technical information are in scope.

Choosing measures

The order of preference in the article is: remove or reduce risk through design and development where technically feasible, mitigate what remains, and give information and training to deployers. Measures should be balanced so they work together. The residual risk of each hazard and the overall residual risk must be judged acceptable.

Providers should also consider likely adverse impacts on people under 18 and other vulnerable groups.

Testing

Systems must be tested against predefined metrics and probabilistic thresholds appropriate to the intended purpose, during development and before market placement. Write the thresholds before you see results. Otherwise they drift to whatever the model achieved.

A usable risk record

For each risk keep:

  • Description and affected group.
  • Cause: data, model, interface, misuse or interaction.
  • Likelihood and severity rating with rationale.
  • Control and owner.
  • Residual risk and who accepted it.
  • Test evidence.
  • Review date and trigger.

Misuse is part of the job

Foreseeable misuse is explicitly included. If users can paste anything into the tool, someone will. If outputs are easy to over-trust, they will be. Threat model the human workflow, not only the model. Security failure modes, such as the attacks listed in Article 15, belong on the register too.

Keep it continuous

Treat the register as a living document linked to change management. A new data source, model version or customer use case should trigger a review. Post-market findings feed step three. See the posts on the quality management system and documentation and monitoring.

Providers already under other EU risk rules may combine the elements with those procedures.

For a small team, start with a one hour workshop per system: list who is affected, how it could go wrong, and what would tell you early. Capture the output in the register, assign owners, then schedule the first review. A rough register that is maintained beats a perfect one that is not.

Quick check

Is risk management a one time exercise?

No. The article calls it continuous and iterative, with regular review across the lifecycle.

Does it cover misuse?

Yes, reasonably foreseeable misuse must be estimated and evaluated.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.