What does Article 9 of the EU AI Act require?

Article 9 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. This system must be a continuous iterative process that runs throughout the entire lifecycle of the AI system. It covers risk identification, risk estimation and evaluation, adoption of risk management measures, and testing to confirm residual risks are acceptable.

Can a code scanner fulfil Article 9 obligations?

No. Article 9 is an organisational obligation that requires an ongoing risk management process, stakeholder engagement, and documented risk assessments across the AI lifecycle. A code scanner can detect some technical indicators relevant to Article 9 — such as error handling, input validation, logging, and the presence of risk documentation files — but it cannot verify that a risk management system is actually being operated, that risk assessments involve the right stakeholders, or that identified risks have been communicated to deployers.

When do Article 9 obligations apply?

Article 9 applies to providers of high-risk AI systems. Under the Digital Omnibus provisional agreement of 7 May 2026, approved by European Parliament on 16 June 2026, Annex III (use-based) high-risk obligations are postponed to 2 December 2027. Annex I (product-embedded) obligations apply from 2 August 2028. The Council approved it on 29 June 2026, and the regulation was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744, in force from 27 July 2026. The deferred dates are enacted law.

25 June 2026 · Kuziva Muzondo

EU AI Act Article 9: Risk Management System Requirements

Article 9 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. This is an organisational obligation. A code scanner cannot verify it. But code scanning can detect some of the technical components that Article 9 refers to, and flag where they are missing.

What Article 9 actually requires

Article 9 defines four core requirements for the risk management system. All four apply throughout the entire lifecycle of the AI system, not just at the point of deployment.

1. A continuous iterative process

The risk management system must run throughout the AI system's lifecycle (Article 9(1)). It is not a one-off assessment. You update it when the system changes, when new risks emerge, or when post-market monitoring reveals something unexpected. The emphasis on "continuous" and "iterative" means a static document filed at launch does not satisfy this requirement.

2. Identification and analysis of known and foreseeable risks

Article 9(2)(a) requires identifying and analysing "known and reasonably foreseeable risks" that the high-risk AI system can pose to health, safety, or fundamental rights. This includes risks from intended use and from conditions of reasonably foreseeable misuse.

3. Estimation and evaluation of risks

Once identified, risks must be estimated and evaluated, considering both the probability of harm and its severity (Article 9(2)(b)). This includes risks that may emerge from the interaction between the AI system and the environment in which it operates.

4. Adoption of risk management measures

Article 9(2)(d) requires "appropriate and targeted risk management measures" to address identified risks. Article 9(5) adds that residual risks must be judged acceptable, and that deployers must receive the information required under Article 13, along with appropriate training where needed. Testing under Article 9(6)-(8) must confirm that the system performs consistently and that risk management measures are effective.

What code scanning can detect

A code scanner operates on source files. It cannot observe processes, interview stakeholders, or verify that a risk register is actually maintained. But it can check for technical artefacts that map to Article 9 requirements.

Risk assessment documentation. Regula looks for files matching patterns like risk_assessment.*, risk_register.*, or RISK_MANAGEMENT.* in your project. If none exist, that is a gap signal. If they exist, their content still needs human review.

Error handling around model calls. Article 9(5) requires that residual risks be acceptable. Unhandled exceptions in model inference code mean a failure mode exists with no mitigation. Regula flags model calls (e.g. calls to OpenAI, Anthropic, HuggingFace APIs) that lack try/except or equivalent error handling.

Input validation and sanitisation. Validating inputs before they reach the model is a basic risk management measure. Regula checks whether input data passes through validation logic before model consumption.

Logging of model decisions. An audit trail supports the "continuous iterative" requirement: you cannot review and update risk assessments without records of what the system actually did. Regula checks for logging around model inference calls.

Example: scanning a healthcare project for high-risk indicators.

$ regula check --domain healthcare .

Regula Scan: /home/dev/myproject
============================================================

Decision: insufficient_information
Jurisdiction: eu
Rule resolution: unresolved
Facts needed to resolve the next decision: 2
  - is_ai_system: Does the subject meet the governing law's definition of an AI system or regulated automated technology?
  - jurisdiction_in_scope: Does this jurisdiction's territorial and operator scope apply?

Detector observations (not legal facts):

  Detector summary: ANNEX III OR SECURITY PATTERNS
  The scanner found patterns relevant to Annex III or security review.
  Resolve the facts listed above before attaching Article 9 to 15 duties.
  Files scanned:      34
  High-risk:          2

  HIGH-RISK INDICATORS:
    [INFO] [ 43] predict.py — Healthcare services [plan]
    [INFO] [ 38] routes.py — Healthcare services [plan]

============================================================

The exact output depends on your codebase. The format above is illustrative.

Each finding maps to a specific Article 9 concern. High-risk indicators flag where the codebase touches domains that trigger Annex III obligations. The scan is a starting point, not a determination.

What code scanning cannot detect

Be clear about the limits. Code scanning does not cover:

Whether the risk management system is actually operated. A risk register file can exist but never be updated. Regula sees the file. It cannot verify that someone reviews it quarterly.
Whether risk assessments involve the right stakeholders. Article 9 expects input from domain experts, affected communities, and deployers. A code scanner has no visibility into your process.
Whether the RMS covers the full AI lifecycle. Article 9(1) requires coverage from design through post-market monitoring. Code scanning sees a snapshot of the current codebase. It does not know what happened during training or what your post-deployment monitoring looks like.
Whether identified risks have been communicated to deployers. Article 9(5) requires that residual risks be communicated to deployers with information per Article 13 and appropriate training. This is a documentation and process requirement, not a code pattern.
Whether testing is sufficient. Article 9(5) requires testing "at any time throughout the development process, and, in any event, prior to their being placed on the market or put into service". Regula can check for test files but cannot evaluate whether the testing regime is adequate.

The gap between what code scanning covers and what Article 9 requires is large. Code scanning is a partial input into a broader compliance process.

Gap analysis with Regula

The regula gap command reports which article obligations it can attach evidence to, and which it is holding back. Run it against your project root:

$ regula gap --project .

Decision: insufficient_information
Jurisdiction: eu
Rule resolution: unresolved
Facts needed to resolve the next decision: 2
  - is_ai_system: Does the subject meet the governing law's definition of an AI system or regulated automated technology?
  - jurisdiction_in_scope: Does this jurisdiction's territorial and operator scope apply?

Evidence scan:
Article evidence is attached only where the decision kernel resolved the corresponding obligation.
Article observations emitted: 0; held pending applicability: 8

Output is illustrative. Counts depend on your codebase.

Until the two facts above are settled by a person, Regula holds the article observations rather than emitting them. Earlier versions of this page showed a percentage beside each article. That output has been removed from the tool: a percentage against Article 9 reads as a measure of Article 9 compliance, and it is not one. The organisational components of Article 9, which are where a risk management process actually lives, are not visible to a code scan at all, so a codebase can look well covered and still have no risk management process behind it.

To focus on Article 9 specifically:

$ regula gap --project . --article 9

Practical next steps

If your system is high-risk (or likely to be classified as such), here is a concrete starting point for Article 9 compliance.

Create a risk register

A plain text or markdown file in your repository is fine to start. List each known risk, its severity, its probability, and what you are doing about it. Update it when the system changes. The format matters less than the habit of maintaining it.

Map risks to mitigation measures

For each risk in your register, document what technical or organisational measure addresses it. "We validate inputs before model inference" is a measure. "We will think about it later" is not. Article 9(2)(d) requires that measures be "appropriate and targeted."

Set up periodic review

The "continuous iterative process" requirement means scheduling reviews. Monthly or quarterly, depending on how fast your system changes. Record what was reviewed and what changed. A git commit log showing updates to your risk register is simple evidence that the process is active.

Use the organisational questionnaire

Regula includes a questionnaire mode that covers the organisational components a code scanner cannot detect:

$ regula conform --organisational

Organisational compliance questionnaire
========================================

Article 9 - Risk Management System
Q1: Do you maintain a risk register? [y/n]
Q2: Is the risk register reviewed at defined intervals? [y/n]
Q3: Have residual risks been communicated to deployers? [y/n]
...

This produces a structured record of your self-assessment. It is not a substitute for legal review, but it gives you a documented baseline and highlights areas that need attention.

Combine code scan and questionnaire

The code scan covers technical implementation. The questionnaire covers organisational process. Together, they give you a more complete picture of where you stand against Article 9. Neither alone is sufficient.

Omnibus status

The dates stated here come from Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026. The provisional agreement of 7 May 2026 is legislative history, not the current legal basis.

Last reviewed: 14 August 2026 · Author: Kuziva Muzondo · Sources: Regulation (EU) 2024/1689, Article 9, Digital Omnibus provisional agreement (7 May 2026) · Not legal advice. Regula identifies risk indicators for developer review.