Article 9 Risk Management Plan Template for High-Risk AI

If you provide a high-risk AI system, Article 9 of the EU AI Act requires you to establish, document, and maintain a risk management system across the whole life of the system. This template gives you the structure to do it: the fields to capture, the iterative loop the Article actually describes, and where the risk-management work hands off to the data, oversight, and accuracy requirements in Articles 10, 14, and 15.

Start with the single most misread point. Article 9 is not a one-off document you write before launch and file away. The text is explicit that the risk management system is a continuous, iterative process run throughout the entire lifecycle of the system, requiring regular and systematic review and updating. A plan that is current on launch day and stale six months later does not meet Article 9. The template below is built to be revisited, not archived.

---

The Article 9 Process in Four Movements

Article 9 describes a loop, not a checklist. The risk management system must:

1. Identify and analyse the known and reasonably foreseeable risks the high-risk system can pose to health, safety, or fundamental rights when used for its intended purpose.
2. Estimate and evaluate the risks that may emerge when the system is used as intended and under conditions of reasonably foreseeable misuse.
3. Evaluate other risks arising from analysis of post-market monitoring data (the feedback from Article 72 monitoring flows back in here).
4. Adopt appropriate and targeted risk-management measures to address the risks identified — and then test the system to confirm the measures work and that the system performs consistently for its intended purpose.

The loop closes and reopens: testing and post-market data surface new risks, which feed the next identification cycle. Residual risk that remains after mitigation must be judged acceptable, and the system communicated to deployers so they understand it.

A note on reasonably foreseeable misuse (defined in Article 3(13)): it is not every conceivable abuse, but the misuse a reasonable provider should anticipate given the system's purpose and context. A CV-screening tool being used to screen tenancy applications is foreseeable misuse worth documenting; deliberate criminal sabotage generally is not.

---

The Risk Management Plan Template

Capture each field below for the high-risk system. Treat it as a living record with a version history.

1. System identification

• System name, version, and intended purpose (Article 3(12))
• Provider and any authorised representative (Article 22 if outside the EU)
• Annex III category (or Annex I product route) and the Article 6 classification reasoning
• Deployer context(s) the system is sold into

2. Risk identification log

For each identified risk:

• Risk description (to health, safety, or fundamental rights)
• Source (intended use, foreseeable misuse, data, model behaviour, human-machine interaction)
• Affected persons or groups
• Whether the risk implicates a fundamental right (links to the Article 27 FRIA where a deployer must run one)

3. Risk estimation and evaluation

• Likelihood and severity, before mitigation
• Evaluation method and assumptions
• Acceptability threshold applied

4. Mitigation measures

• The targeted measure adopted for each risk
• Whether it eliminates, reduces, or controls the risk
• Residual risk after mitigation, and the judgment that it is acceptable
• Information passed to deployers about residual risk and conditions of use (links to Article 13 instructions for use)

5. Testing record

• Test objectives, metrics, and acceptance criteria
• Testing against intended purpose and foreseeable misuse
• Results, and any risks re-opened by testing
• Whether testing in real-world conditions was used and under what safeguards

6. Lifecycle review

• Review cadence and triggers (substantial modification, incident, post-market signal)
• Owner accountable for the review
• Change log: what changed, why, and when
• Feedback loop from Article 72 post-market monitoring and Article 73 serious-incident reporting

---

Where Article 9 Hands Off

Article 9 is the spine, but it pulls in the other high-risk requirements. The plan should cross-reference them explicitly:

Getting the article numbers right matters: risk management is Article 9, not Article 8 (which is the chapeau activating the requirements). Human oversight is Article 14, not Article 9 — but oversight measures are recorded in the risk plan as mitigations. Keep the boundary clean.

---

Worked Example: A High-Risk Provider

Take Helvetia HealthScreen B.V., a fictional Netherlands-based medtech SME — about 90 employees, ~€18 million turnover — that provides an AI triage tool which flags patients for follow-up based on symptom data. The tool is a high-risk system: it is intended as a safety component touching health, and it sits in the high-risk space whether routed through Annex III or the medical-device product path.

Its Article 9 plan, in practice:

• Identification logs risks including false negatives (a flagged-as-low-risk patient who needs urgent care), demographic performance gaps, and over-reliance by clinicians.
• Foreseeable misuse: clinicians treating the flag as a diagnosis rather than a triage aid — so the plan records a mitigation (Article 14 human oversight plus Article 13 instructions stating the tool does not diagnose).
• Estimation rates the false-negative risk high-severity, driving a conservative threshold and extra testing on under-represented patient groups (linking to Article 10 data governance).
• Testing runs against intended use and the misuse scenario; results re-open a residual demographic-gap risk that goes back into the next cycle.
• Lifecycle review is triggered every release and on any serious incident reported under Article 73.

Helvetia's deadline for the high-risk obligations is 2 December 2027 for the stand-alone Annex III route, or 2 August 2028 if the tool is regulated as a medical device under the product-safety path — both now settled dates under the formally adopted Digital Omnibus, pending only Official Journal publication, so Helvetia plans against them directly. Either way, building an Article 9 system properly takes most providers six to twelve months, so the plan starts now.

---

How Confir Helps

Confir's classification engine is rule-based and deterministic, so it first tells you — reproducibly, with the rule that fired shown — whether a system is actually high-risk and therefore in Article 9 scope at all. For systems that are, it structures the Article 9 risk-management record alongside the Annex IV technical documentation, the Article 27 FRIA where a deployer owes one, and the post-market monitoring plan, keeping the whole high-risk pack in one org-wide register with an audit trail of every revision.

---

Related guides

• Article 9 risk management system explained
• the risk management system in practice
• Article 10 data governance
• Article 14 human oversight
• Article 15 accuracy and robustness
• Annex IV technical documentation template
• the corrected enforcement timeline