EU AI Act Article 9 Risk Management Systems: A Technology Function’s Reading

A reading of what Article 9’s risk management system requirement actually demands of a high-risk AI system — and where it overlaps with the ICT risk framework you’ve probably already built for DORA.

Most of what is written about the AI Act is written by people selling a GRC platform or a bias-audit service. This is a reading by someone who has had to commission and own ICT risk frameworks for a living. Article 9 sits in Chapter III, Section 2 of the Act — the section that applies once a system is classified high-risk under Article 6 and Annex III. Most of its obligations become enforceable on 2 August 2026. This is what it substantively requires of the people who have to build and run it.

The four verbs

Article 9 opens with a short, uncompromising instruction: a risk management system must be established, implemented, documented, and maintained for every high-risk AI system. Four separate obligations, not one. A risk assessment performed once and filed away satisfies “documented” and arguably “established,” and fails the other two. Regulators reading this article are going to ask about all four, not just the one that produces a PDF.

A continuous process, not a document

Article 9(2) is explicit that this is not a one-off checkpoint. The system must be a continuous, iterative process, planned and run across the entire lifecycle of the AI system, with regular and systematic review. In practice it comprises four steps, repeated: identify and analyse the known and reasonably foreseeable risks to health, safety, and fundamental rights that the system could pose given its intended purpose; estimate and evaluate those risks, including from reasonably foreseeable misuse; evaluate further risks surfaced by post-market monitoring; and adopt risk management measures in response. The loop doesn’t close when the system ships — it runs for as long as the system is in use.

What the risk management measures actually have to do

The Act sets a preference order. First, eliminate or reduce risk through design and development, as far as technically feasible. Where a risk can’t be eliminated that way, apply mitigation and control measures. Where residual risk remains, provide the information required under Article 13 and, where appropriate, train the deployer. The bar for “done” is specific: the residual risk associated with each individual hazard, and the overall residual risk of the system, must be judged acceptable — not zero, but consciously and defensibly acceptable.

Testing, and when it has to happen

High-risk systems must be tested specifically to identify the most appropriate and targeted risk management measures, and to confirm the system performs consistently for its intended purpose. Testing can happen at any point through development, including in real-world conditions, but it must happen — in every case — before the system is placed on the market or put into service, and against metrics and thresholds defined in advance. A system that has only ever been evaluated against generic model-performance benchmarks has not been tested for the purposes of Article 9.

The line most technology functions miss

Article 9(9) requires providers to specifically consider, given the system’s intended purpose, whether it is likely to adversely affect persons under 18 or other vulnerable groups. It’s a single provision, easy to skip past in a first read, and exactly the kind of thing a supervisory reviewer will ask about by name. If your risk register doesn’t have a line addressing it, that’s a gap worth closing before anyone else asks the question for you.

Who this is for

• The CTO or CISO at a financial services firm deploying or procuring AI for credit scoring, insurance risk pricing, or any other use that lands in Annex III’s high-risk categories.
• The compliance lead trying to work out whether Article 9 means building a second risk framework alongside the DORA one, or extending the one that already exists.
• The board member being asked to sign off an AI risk management system before the 2 August 2026 deadline, who wants to know what “signed off” is actually supposed to mean.

The paragraph that matters most if you’re already DORA-compliant

Article 9(10) is the one worth reading twice. Providers already subject to internal risk management requirements under other Union law may combine the Article 9 elements with the risk management procedures they’ve already established under that law. For a financial entity that has spent the last eighteen months building an ICT risk management framework under DORA Article 6, this is not licence to build a second, parallel structure. It’s licence to extend the one you have.

The caution is that “combine” is not “assume covered.” Your DORA framework was not built with AI systems in mind, and it will not naturally produce three things Article 9 specifically requires: testing evidence dated before the system went live, a residual-risk judgement recorded per hazard rather than at the framework level, and a documented answer to the under-18/vulnerable-groups question. Those need to be added as an AI-specific module inside the governance structure you already run — not asserted as already handled because the paperwork says “risk management framework” on the cover.

What actually counts as high-risk here

For financial services specifically, Annex III names two categories that capture a large share of what firms already do with AI: systems used for creditworthiness assessment and credit scoring of natural persons, and systems used for risk assessment and pricing in life and health insurance. If you haven’t yet built the inventory that classifies every AI system your firm uses against the Act’s risk bands, that’s the prerequisite step — covered in more detail here — before Article 9 can be applied to anything specific.

What the technology function needs to be able to show

Strip the article back to what a supervisory conversation will actually ask for, and it’s six things, per high-risk system:

1. A risk identification and analysis record, tied to the specific system in your AI inventory — not a generic AI-risk statement covering every system at once.
2. A residual-risk judgement, recorded per hazard and overall, with a named owner who signed off that it’s acceptable.
3. Testing evidence against metrics defined in advance, dated before the system was placed on the market or put into service.
4. A documented answer to the under-18 and vulnerable-groups question, specific to the system’s intended purpose.
5. A review log showing the process has actually run more than once — evidence of iteration, not just existence.
6. Where this is combined with an existing framework under Article 9(10) — a mapping showing which existing artefact satisfies which Article 9 element, and which elements needed a net-new addition.

If you have all six for every high-risk system in your inventory, you’re in a defensible position. If the inventory itself doesn’t exist yet, that’s the actual starting point — Article 9 has nothing to attach to until it does.

How we engage with this

We read risk management systems against what the regulation actually requires. That’s part of what happens in a Technology Control Review — including, where a firm is already DORA-regulated, an assessment of what genuinely extends from the existing ICT risk framework and what needs to be built fresh for AI-specific obligations. The output is a written assessment the board can act on, not a platform subscription.

We don’t build AI models. We don’t run bias audits. We don’t sell AI governance software. We read what’s there, identify what’s missing against Article 9 specifically, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If your board has asked for evidence of an Article 9 risk management system ahead of the 2 August deadline, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.