The Article 9 Risk Management System as a Continuous Process

A lender signs off an AI-assisted creditworthiness system in the spring: technical file complete, conformity assessment done, risk assessment filed. Six months later the model is retrained on fresher data, an upstream feature provider changes its schema, and the decline rate for one applicant segment shifts. Nobody reopens the risk file, because in that organisation risk assessment was a gate the system passed, not a process it runs.

Article 9 of the EU AI Act makes that indefensible. It does not ask for a risk assessment. It requires a risk management system that is established, implemented, documented and maintained, and defines it as a continuous iterative process planned and run throughout the entire lifecycle of the system, requiring regular systematic review and updating.

What Article 9 actually requires

The Article sets out four steps. Each is an obligation in its own right and each generates evidence.

Identify and analyse the known and reasonably foreseeable risks the system can pose to health, safety or fundamental rights when used in accordance with its intended purpose.
Estimate and evaluate the risks that may emerge in use according to the intended purpose and under conditions of reasonably foreseeable misuse. The misuse limb is most often skipped, and it is where rights harm appears.
Evaluate other risks arising from analysis of post-market monitoring data gathered under Article 72. This closes the loop: field data must re-enter the risk analysis.
Adopt appropriate and targeted measures to address the risks identified.

Note the scope limit. Article 9 covers only risks that may reasonably be mitigated or eliminated through the design or development of the system, or through adequate technical information — a real defence, but only where your reasoning for the exclusions was written down at the time.

Who the duty falls on

Article 9 falls on the provider of a high-risk AI system: the party that develops it, or has it developed, and places it on the market or puts it into service under its own name or trade mark. Deployers owe no Article 9 duty as such. This is the most commonly confused point in high-risk compliance.

A deployer becomes a provider — inheriting Article 9 in full — in the Article 25 situations: putting its own name or trade mark on a high-risk system already placed on the market; making a substantial modification to a high-risk system such that it remains high-risk; or modifying the intended purpose of a system that was not classified as high-risk — including a general-purpose AI system — so that it becomes high-risk. The original provider then ceases to be the provider of that system and must supply the information and access needed. The white-labelled procurement deal and the "we only fine-tuned it on our own data" project are how in-house teams acquire a duty they never budgeted for.

Deployers that remain deployers owe Article 26 duties instead: use per the instructions for use, competent human oversight, input data that is relevant and sufficiently representative where they control it, monitoring, suspension and notification where a risk emerges, and log retention. They are the practical feed for the provider's Article 9 loop; the contract should say so.

Why "continuous" is the operative word

A file reviewed annually because the calendar says so is not what the Article describes. Name, in writing, the events that force a review and who runs it. At minimum:

Retraining, version changes, or a change in a foundation model or third-party component the system depends on.
Any change to the intended purpose, or a materially new deployment context, user population or jurisdiction.
Drift beyond your declared thresholds, including subgroup drift rather than only aggregate accuracy.
Serious incidents, near misses, complaints, and human-oversight overrides clustering in one case type.
Changes in the datasets or data sources feeding the system, including quality degradation upstream.

Residual risk and the order measures come in

Measures must give due consideration to the effects and interactions of applying the other high-risk requirements together — data governance, documentation, logging, transparency, human oversight, accuracy and robustness. Tightening one often loosens another. The measures must leave the residual risk of each hazard, and the overall residual risk, judged acceptable; that judgement is the provider's to make and to justify.

The Article sets an order: eliminate or reduce risks so far as technically feasible through design and development; then mitigation and control measures for what cannot be eliminated; then information under Article 13 and, where appropriate, deployer training. You cannot jump to the third because the first two are inconvenient. Due regard must also go to the deployer's expected technical knowledge and to adverse impact on persons under 18 and other vulnerable groups.

Testing, metrics and thresholds

Systems must be tested to identify the most appropriate measures and to establish consistent performance for the intended purpose, against prior defined metrics and probabilistic thresholds, at points during development and in any event before the system is placed on the market or put into service. Real-world testing falls under Article 60. "Prior defined" does real work there: setting a threshold after seeing the result is not testing, and an assessor comparing test report dates against metric definition dates will see it.

What evidence satisfies it

Required step	Evidence that stands up	Common weakness
Identification and analysis	Dated hazard log tied to a written intended purpose, rights impacts logged separately	Only technical failure modes logged
Foreseeable misuse	Misuse scenarios with reasoning for what was excluded	Dismissed as not the intended use
Post-market feedback	Monitoring outputs traceably linked to a risk file revision	Monitoring never changes the risk file
Measures and residual risk	Record showing design-first ordering and a signed acceptability judgement	Residual risk called acceptable with no author

The system must also sit inside the provider's quality management system under Article 17, and the Annex IV technical documentation must describe it in detail. A risk file that cannot be produced from the quality system on request is not yet an Article 9 system. Breaching provider obligations carries fines of up to 3% of total worldwide annual turnover — the 7% ceiling applies only to prohibited practices — and where personal data is involved the same facts can engage UK or EU GDPR, with fines up to 4%.

Where the detail is genuinely unsettled

Be honest with your board about what is not fixed. The harmonised standards meant to give a presumption of conformity for risk management have been under development through CEN-CENELEC and, at the time of writing, are not all cited in the Official Journal. Until they are, ISO/IEC 23894 and ISO/IEC 42001 are useful scaffolding but confer no legal presumption. The Commission must also set a post-market monitoring plan template by implementing act; check its status before freezing your format. Application dates for high-risk obligations have also faced amendment proposals — verify the position as it stands when you read this.

Limits of this guidance

This describes the Article 9 duty's structure and the evidence that satisfies it. It is not legal advice and cannot settle the questions that decide outcomes in a given organisation: whether a system is high-risk at all, whether a modification is "substantial", whether your residual risk judgement would survive challenge, and how the Act meets sectoral regimes.

Take specialist advice where you sit close to the provider boundary, where a system touches safety or vulnerable groups, where a sectoral risk regime must be reconciled rather than duplicated, or where you are a UK organisation whose systems reach the EU market. The absence of an equivalent UK statute removes none of your exposure under the Equality Act 2010, UK GDPR or sector regulators' expectations, all of which apply now.