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; publication in the Official Journal is expected before 2 August 2026. Until OJ publication, the original 2 August 2026 deadline remains technically in force.

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
============================================================

  Verdict: HIGH-RISK
  Your project is classified as high-risk under EU AI Act Annex III.
  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 appropriate times throughout the development process, and, in any event, prior to the placing on the market." 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 scores your project against each applicable article, including Article 9. Run it against your project root:

$ regula gap --project .

EU AI Act Compliance Gap Assessment: myproject
Overall score:     29%

Article 9   Risk Management                     [ 60%] MODERATE
  Evidence: Risk management content in: README.md
  Gap:      Risk documentation lacks structured mitigations

Article 10  Data Governance                     [ 30%] PARTIAL
Article 11  Technical Documentation             [  0%] NOT FOUND
Article 13  Transparency                        [  0%] NOT FOUND
Article 14  Human Oversight                     [ 45%] PARTIAL

Scores reflect only the technical components Regula can measure.

The Article 9 score reflects only the technical components Regula can measure. A moderate score means your codebase has some evidence of risk management artefacts but significant gaps remain. It does not mean your overall Article 9 compliance is at that level, because the organisational components (which Regula cannot assess) also matter. A project could score highly on the code scan and still fail Article 9 if no risk management process exists.

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 caveat

All dates referencing the Digital Omnibus are based on the provisional political agreement of 7 May 2026, approved by the European Parliament on 16 June 2026. The Council approved it on 29 June 2026; publication in the Official Journal is expected before 2 August 2026. Until OJ publication, the original EU AI Act deadlines technically remain in force. We will update this page when the Omnibus is formally adopted.

Last verified: 25 June 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.