Module 3 — The Risk Register: Art. 9 as a Running System

Module 3 of AI Risk Management Pro: operating Art. 9 as a maintained register — identification, estimation, evaluation, mitigation and a residual risk judgement you can defend, with the testing under Art. 9(6)-(8) that demonstrates it.

Art. 9 is the obligation most often satisfied on paper and least often satisfied in fact. The reason is structural: the article describes a process, and processes are hard to evidence, so organisations produce the artefact a process would produce — a risk assessment document — and stop. Art. 9(2) closes that door explicitly by requiring a "continuous iterative process planned and run throughout the entire lifecycle... requiring regular systematic review and updating."

This module is about running it as a register.

The five movements of Art. 9(2)

Art. 9(2) sets out what the process must do. Read as operations rather than law:

(a) Identify and analyse the known and the reasonably foreseeable risks the system can pose to health, safety or fundamental rights when used in accordance with its intended purpose.

(b) Estimate and evaluate the risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse.

(c) Evaluate other risks that may arise, based on the analysis of data gathered from the post-market monitoring system under Art. 72.

(d) Adopt appropriate and targeted risk management measures addressing the risks identified under (a).

Then Art. 9(3) narrows the scope usefully: the article concerns only risks that may be reasonably mitigated or eliminated through development or design, or by providing adequate technical information. You are not required to solve the world.

Two things in that list are the ones programmes miss. Reasonably foreseeable misuse in (b) is not abuse by an attacker; it is the ordinary wrong use a real user will make — the recruiter who pastes a whole CV into a tool scoped for keyword extraction, the clinician who treats a triage score as a diagnosis. And (c) makes the register downstream of monitoring: a register that has never been changed by production data is not running.

Rows, not sections

A register is a table whose unit is the risk scenario. A scenario is concrete enough to test. "Bias" is not a scenario; "the model scores applicants from non-EU universities lower because degree classification is encoded inconsistently in training data" is.

The minimum viable row:

The AI Risk Register template included with this track ships with the Annex III categories pre-mapped and around eighteen scenarios already written, a 5×5 scoring matrix, and a review schedule aligned to Art. 9(4) — because the blank-page problem is the real reason registers do not get built.

Scoring, and the two honest things to say about it

Any ordinal scale is a convention. What matters is that it is declared, applied consistently, and not treated as arithmetic. Two rules keep it defensible:

Declare the scale in the register itself. A 5×5 likelihood-severity grid with written anchors for each level ("severity 4: a person is denied a service they were entitled to, and the error is not detectable by them") beats an undocumented 1-10 field, because two assessors converge.

Never let the product of two ordinals do the deciding. A 2×5 and a 5×2 both score 10 and are not the same risk. Severity should gate: anything at the top severity level goes to escalation regardless of likelihood. The tolerance band from the Module 1 mandate is what makes this mechanical rather than argumentative.

Residual risk is where registers fail a review

The commonest finding in a readiness review is a register whose "accepted" rows carry a name, a date and a score — and no measures and no test result. That is an acceptance, not a justification.

Art. 9(5) asks that the residual risk be judged acceptable. The judgement is only legible if three things sit beside it:

1. The measures actually adopted, specifically. "Human review added" is not a measure; "all scores below 0.4 are routed to a named reviewer with access to the full application and authority to overturn, logged" is.
2. The testing that demonstrates they work. Art. 9(6)-(8): testing against prior defined metrics and probabilistic thresholds appropriate to the intended purpose, performed throughout development and in any event before placing on the market or putting into service. A measure with no test result is an intention.
3. The reasoning against the intended purpose. Why this level of residual risk is acceptable for this use, which is a different question from whether it is within appetite.

A row that has all three can be challenged on its merits. A row that has none can only be challenged as a whole, and will be.

Wiring the register to the rest of the programme

Art. 9 does not stand alone, and a register that does not connect is a parallel universe:

• Into Art. 10 — data-related scenarios (representativeness, bias, provenance) should reference the data governance evidence from Module 4, not restate it.
• Into Annex IV — element 2 of the technical file covers the risk management system. The file should link the register, not duplicate it.
• Into Art. 14 — every row whose measure is "human oversight" creates an obligation in Module 6 to design that oversight for real.
• Into Art. 72 — the monitoring plan should name the metrics that would move the register's rows, which is what makes Art. 9(2)(c) operable.
• Into Art. 73 — a serious incident should always produce a register change. If an incident closes without one, either the register was already right or the review was not done.

The review cadence

Art. 9(4) requires regular systematic review and updating. What "regular" means is yours to define and then keep. A defensible pattern:

• Monthly — open rows with mitigation in flight.
• Quarterly — the full register for each high-risk system, against monitoring data.
• On trigger — incident, substantial modification, retraining, intended-purpose change, new monitoring signal, regulatory change.
• Annually — the scale and the tolerance band themselves, which drift as the system's context changes.

Record the review as an event with a date and a reviewer, even when nothing changed. "Reviewed, no change, 2027-03-14, J. Okonjo" is evidence. An unchanged register with no review log is indistinguishable from an abandoned one.

Check yourself

1. Our risk assessment was signed off before launch, so Art. 9 is satisfied. — No. Art. 9(2) requires a continuous iterative process across the lifecycle with regular systematic review and updating.
2. We score likelihood × severity and accept anything under 12. — Severity must gate independently. A 2×5 and a 5×2 both score 10 and are not the same risk.
3. Misuse is out of scope because users are trained. — Art. 9(2)(b) requires reasonably foreseeable misuse to be estimated and evaluated. Training is a measure, not a reason to omit the row.
4. The residual risk is accepted and signed. — By what reasoning, and against what test result? Art. 9(5) asks for a judgement; Art. 9(6)-(8) make testing the demonstration.

Next: Module 4 — Data governance you can evidence (Art. 10) →