EU AI Act Article 9: Building a Compliant Risk Management System

Ask a compliance team to show you their Article 9 risk management system, and what usually gets pulled up is a PDF: a risk assessment written sometime before launch, signed off, filed. That document might be genuinely good work. It's also not what Article 9 requires, because Article 9 doesn't ask for a risk assessment — it asks for a risk management system, defined in the statute itself as a continuous, iterative process that runs for as long as the AI system is on the market, not a one-time deliverable.

That distinction isn't pedantic. It's the difference between passing an audit and failing one, because auditors specifically check whether the process is still running, not just whether it once produced a correct-looking document. Most Annex III high-risk obligations, Article 9 included, reached applicability in August 2026 — if your system falls outside the small set of Annex I product-safety-linked categories still on a longer runway into 2027, this is no longer a future deadline.

What the process actually has to do

Article 9 attaches to any system that's cleared Article 5's prohibited-practices screen and been classified high-risk under Article 6. Once that's settled, the risk management system has to comprise four substantive steps, run on a cycle rather than once:

Identifying and analyzing risks — including misuse, not just intended use

The process has to identify and analyze the known and reasonably foreseeable risks the system can pose to health, safety, or fundamental rights — and it has to do this for both the system used as intended and the system under conditions of reasonably foreseeable misuse. A risk analysis that only models correct, in-scope usage and never asks "what happens when someone uses this the wrong way" is incomplete on its face.

Estimating and evaluating those risks

Once identified, risks get estimated and evaluated — not just listed. This is where severity and likelihood get assigned, forming the basis for deciding which risks actually need a mitigation and which are acceptable as-is.

Evaluating risks surfaced by post-market monitoring

This is the step generic explainers tend to skip, and it's the one that makes the "process, not document" distinction concrete: the risk management system has to evaluate risks that emerge from the data and results generated by the system's required post-market monitoring. In practice, that means whatever your deployed system's monitoring pipeline actually surfaces — drift, unexpected outputs, incident reports — has to feed back into the risk process on a real cadence. A risk register that isn't connected to your production monitoring isn't doing this step.

Adopting targeted risk management measures

Finally, the process has to result in appropriate, targeted measures that address the identified risks — elimination or design-level reduction where possible, mitigation and control measures where a risk can't be designed away entirely, and the transparency information and deployer training needed to handle whatever residual risk remains.

What this looks like on a real system

Take an AI-driven resume-screening tool used for hiring — a standard Annex III high-risk use case. The identification step has to cover the obvious risk (the model systematically down-ranks candidates from a protected group) and the less obvious misuse case (a hiring manager feeding the tool candidates for a role it was never validated against, then treating its output as authoritative anyway). The estimation step assigns real severity and likelihood to each — a biased-ranking risk affecting every candidate pool is a different order of problem than an edge case affecting a handful of unusual resumes. Post-market monitoring might surface that pass-through rates for a specific demographic dropped after a model update; that finding has to route back into the risk register, not just into an engineering bug tracker. And the resulting measure might be as concrete as a re-weighted feature set, a mandatory human review step for borderline scores, or updated deployer guidance restricting the tool to the roles it was actually validated for.

Testing isn't optional, and it isn't a one-time gate either

Article 9 also requires testing specifically for the purpose of identifying the most appropriate risk management measures — checking that the system performs consistently for its intended purpose and meets the Act's other requirements. That testing has to happen at appropriate points throughout development, and in any event before the system is placed on the market, measured against predefined metrics and thresholds appropriate to its intended purpose. Testing can include real-world testing under the Act's separate real-world-testing provisions, but the point that trips teams up is the same one as above: a single pre-launch test run satisfies the letter of "test before market placement" while missing the spirit of a system that's supposed to keep being evaluated as it operates.

Special considerations: vulnerable users and overlapping regimes

Two provisions inside Article 9 catch teams off guard because they're easy to skip past on a first read. First, where the system is likely to be accessed by or have an impact on children or other vulnerable groups, the risk management process has to specifically account for that — a general-population risk analysis isn't a substitute for one that actually considers who's realistically on the other end of the system. Second, providers already subject to risk management obligations under existing EU financial-services law — banks and other credit institutions, most notably — can integrate this process into their existing risk management procedures rather than standing up a fully separate one, provided the integration genuinely accounts for the specific risks the AI Act is concerned with, not just a relabeled version of an existing compliance file.

The gap auditors flag most

If there's one sentence to take from this page, it's this: a risk management system that only exists as a document from before launch is not compliant, regardless of how good that document was. Article 9 explicitly requires regular systematic review and updating across the system's entire lifecycle. In practice, that means:

• A named owner and a real recurring cadence — quarterly, tied to a release cycle, whatever fits the system — not "we'll revisit if something breaks."
• An actual pipeline connecting post-market monitoring outputs back into the risk register, not two workstreams that happen to share a Slack channel.
• Version history showing the risk management file has actually changed over time in response to real inputs, not just a "last reviewed" date that gets bumped without content changing.

Auditors have seen enough static, pre-launch-only risk files to recognize one on sight. A thin but genuinely live process beats a thorough document that stopped updating the day the system shipped.

How this connects to what comes next

Article 9 doesn't operate in isolation — it feeds directly into the data governance requirements of Article 10, the technical documentation requirements of Article 11, and the instructions for use required under Article 13, all of which draw on the same risk analysis this process produces. For systems already covered by existing EU product-safety risk management procedures (certain Annex I categories), the Act allows integrating this process into that existing framework rather than running a duplicate one from scratch — worth checking before building something parallel to a process that already exists.

For the classification step that determines whether a system needs any of this in the first place, see how Article 6 high-risk classification actually works. And if the system hasn't been screened against the categorically prohibited practices yet, that has to happen before Article 9 is even the right conversation to have.