Why Article 9 matters
Most compliance attention paid to the EU AI Act has gone to scope and classification: is this an AI system, is it high-risk, are we the provider or the deployer. Those are gateway questions. Once a business finds itself inside Chapter III of the Regulation, the substantive work begins, and it begins with Article 9. Data governance under Article 10, human oversight under Article 14, accuracy and robustness under Article 15 and the technical documentation under Article 11 all describe measures taken in response to identified risks. If the risk identification is thin, everything downstream is thin.
The timetable has moved, but not in a way that justifies waiting. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and postponed the application of Chapter III, Sections 1, 2 and 3 to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I. Article 9 sits in Section 2 and is caught by that postponement. What did not change is Article 9 itself. The Omnibus amended Articles 10, 11 and 17 in the same neighbourhood and left Article 9 untouched, so the text businesses were reading in 2024 is still the text that will be enforced.
Who Article 9 binds, and what it actually says
Article 9 is drafted as a requirement of the system rather than a duty of a named person. Paragraph 1 provides that a risk management system “shall be established, implemented, documented and maintained in relation to high-risk AI systems”. The obligation attaches to the provider through Article 16, which lists compliance with the Section 2 requirements as the first of the provider’s obligations.
The four verbs repay attention. Implementing means the system operates in the business rather than in a policy document. Documenting is what makes it auditable by a notified body, a market surveillance authority or a customer’s procurement team. Maintaining rules out a one-off assessment filed and forgotten. Paragraph 2 makes that explicit: the system “shall be understood as a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating”.
The four steps the Regulation requires
Article 9(2) sets out a four-step cycle. Read alongside paragraphs 3 to 8, it describes a product safety discipline rather than the enterprise risk register most companies already maintain.
Identifying risks, including foreseeable misuse
The first step is the identification and analysis of 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. The reference to fundamental rights takes the analysis well beyond safety engineering into discrimination, privacy and effective remedy, and the anchoring to intended purpose means it cannot be generic. The second step then requires estimation and evaluation of risks arising both in intended use and under conditions of reasonably foreseeable misuse. A tool marketed as decision support will be treated by someone as a decision-maker; that is foreseeable, and it belongs in the file.
Feeding in what happens after launch
The third step is the evaluation of other risks arising from data gathered through the post-market monitoring system under Article 72. This is the hinge between Article 9 and the rest of the Regulation, and it explains why the logging capability required by Article 12 exists at all. The Omnibus removed the Commission’s power to adopt a binding harmonised template for the post-market monitoring plan, and instead requires the Commission to publish guidance, including a voluntary template, by 2 September 2027. Providers have flexibility in how they design post-market monitoring, and no template to wait for.
Choosing measures and judging residual risk
The fourth step is the adoption of appropriate and targeted risk management measures. Article 9(5) then imposes the test that decides whether a system may be placed on the market at all: measures must be such that the relevant residual risk associated with each hazard, as well as the overall residual risk, is judged to be acceptable. The Regulation also fixes the order in which measures are considered. Risks are eliminated or reduced through design in so far as technically feasible; where they cannot be eliminated, adequate mitigation and control measures are implemented; and only then does the provider fall back on the information required under Article 13 and training for deployers. A warning in the instructions for use is the last resort, not the first.
Testing against metrics fixed in advance
Article 9(6) requires high-risk systems to be tested to identify the most appropriate risk management measures and to ensure they perform consistently for their intended purpose. Paragraph 8 adds the timing and the discipline: testing is performed as appropriate throughout development and, in any event, before the system is placed on the market or put into service, and it is carried out against prior defined metrics and probabilistic thresholds appropriate to the intended purpose. The words “prior defined” are the operative ones. A threshold chosen after the results are in is not a threshold.
Where Article 9 stops, and where Article 17 begins
Two boundaries are commonly missed. The first is internal to Article 9. Paragraph 3 limits the risks in scope to those that may reasonably be mitigated or eliminated through the development or design of the system, or through the provision of adequate technical information. Article 9 is not a general societal impact assessment; risks that cannot be addressed by design or by information belong elsewhere, including in the fundamental rights impact assessment under Article 27.
The second boundary separates Article 9 from Article 17. Article 9 is a requirement about the product; Article 17 is an obligation about the organisation, a quality management system ensuring that the provider as a business complies with the Regulation. The risk management system sits inside it, but the two are separately enforceable, and there is now an asymmetry worth knowing about. The Omnibus amended Article 17(2) to extend proportionality to small and medium-sized enterprises and to small mid-cap enterprises, while retaining the requirement to respect the degree of rigour and level of protection required. It made no equivalent change to Article 9. A small provider gets a lighter organisational system; it does not get a lighter risk analysis. Article 9(10) does allow providers already subject to internal risk management requirements under other Union law to combine the Article 9 elements with those procedures rather than run a parallel process, and Article 9(9) requires providers to consider whether the system is likely to have an adverse impact on persons under the age of 18 and, as appropriate, other vulnerable groups.
Praktiskt exempel
A Stockholm software company sells a candidate screening tool to Nordic employers. It ranks applicants against a role profile and produces a shortlist. Recruitment systems of this kind fall under Annex III point 4, so the company is a provider of a high-risk AI system and Article 9 bites on 2 December 2027. Its current risk register is a spreadsheet reviewed annually, listing commercial and information security risks.
What Article 9 asks for is different in kind. The company has to analyse how the tool could produce discriminatory outcomes for candidates with career breaks or qualifications obtained outside the EU, for the intended purpose it actually markets. It has to assume some customers will treat the ranking as a decision rather than a recommendation, and either design against that or address it through the instructions for use and customer training. It has to define, before testing, what error rates and selection rate differences across groups it will accept, and record results against those thresholds. It has to decide what residual risk is acceptable and be able to explain that judgement to Post- och telestyrelsen, which supervises this part of Annex III in Sweden. None of that is impossible, but none of it happens in a spreadsheet reviewed once a year.
Vanliga misstag som företag gör
The first is treating Article 9 as a document rather than a process. A risk assessment produced for a funding round or a customer questionnaire, signed and archived, fails paragraph 2 on its face because it is neither maintained nor iterative. The second is conflating Article 9 with Article 17, usually by pointing to an existing management system certification and assuming it covers both. It does not, and the proportionality relief the Omnibus introduced applies only to one of them. The third is confining the analysis to safety and security and omitting fundamental rights, when for most Annex III systems that exposure is the whole point of the classification. The fourth is ignoring foreseeable misuse because the contract requires the customer to follow instructions; contractual allocation does not remove the design duty. The fifth is choosing evaluation metrics after seeing the test results, which paragraph 8 rules out.
Rekommenderade åtgärder
Start by establishing in writing whether your business is a provider of a high-risk AI system and under which limb of Article 6, because that determines both the substance and the date. If it is, map what you already have against the four steps in Article 9(2) and be honest about the gaps. Most companies find they have some identification step, no post-market feedback step at all, and testing that is real but undocumented against pre-defined thresholds. Fix the documentation discipline first: it is cheap now, expensive to reconstruct later, and it is what an authority will inspect.
Then decide the governance question. Someone has to own the residual risk judgement under Article 9(5), and it should not be the engineering team alone, because that judgement is about acceptability rather than feasibility. If you already run a risk management process under medical device, machinery or financial services legislation, use Article 9(10) and integrate rather than duplicate, taking care that the integrated process covers fundamental rights and not only safety. Finally, resist the temptation to wait for standards. A provider that has done the analysis properly will be able to map it onto a standard later far more easily than one starting from nothing eighteen months before the deadline.
Vanliga frågor
Does Article 9 apply to us if we only use AI bought from a vendor?
Not directly. Article 9 binds providers, and a business that deploys a high-risk system under the provider’s name and in accordance with its instructions has obligations under Article 26 instead. But the line moves. Under Article 25 a deployer that puts its own name or trade mark on a high-risk system, substantially modifies it, or changes its intended purpose so that it becomes high-risk takes on the provider’s obligations, including Article 9. Businesses that heavily configure or fine-tune purchased AI should check that line carefully.
Can we reuse the risk management framework we already have?
In part, and the Regulation encourages it. Article 9(10) allows providers subject to internal risk management requirements under other Union law to make the Article 9 elements part of, or combine them with, those existing procedures. A medical device manufacturer running a risk management file, or a financial institution with an established internal framework, should build on it rather than create a parallel system. The caution is scope: existing frameworks are usually built around safety, financial or operational risk, while Article 9 requires fundamental rights to be analysed alongside them.
Is there a standard we can certify against to show compliance?
Not yet, in the sense that matters legally. European standardisation work covering AI risk management is in progress at CEN-CENELEC, and a quality management standard for AI Act purposes, EN 18286, was published by CEN-CENELEC at the end of July 2026. But presumption of conformity under Article 40 arises only once a harmonised standard has been cited in the Official Journal of the European Union, and no AI Act standard has been cited. Publication by a standards body and citation in the Official Journal are different steps.
Slutsats
Article 9 is short, unamended and more demanding than it looks. It asks for a continuous, documented process that identifies risks to health, safety and fundamental rights across the whole lifecycle, tests against thresholds fixed in advance, and reaches a defensible judgement that what remains is acceptable. The deadlines of 2 December 2027 and 2 August 2028 sound distant, but the work is cumulative and the documentation cannot be back-filled convincingly. Businesses that begin now will find most of the rest of Chapter III follows from it. Lawgent helps businesses design and document AI Act risk management systems for high-risk AI.
