AI Risk Management Under the EU AI Act: Building Your Article 9 System

An AI risk management system (RMS) is a documented, continuous, iterative process — mandated by Article 9 of Regulation (EU) 2024/1689 — that identifies and analyses risks a high-risk AI system poses to health, safety and fundamental rights; estimates and evaluates those risks from intended use and reasonably foreseeable misuse; evaluates risks surfaced by post-market monitoring data under Article 72; and adopts targeted, proportionate measures to reduce risks to an acceptable residual level before and throughout market operation.

That definition is worth reading twice, because it contradicts how most compliance programmes actually run. The RMS is not a one-time pre-launch checklist, not a chapter in the technical file, and not something your legal team handles once and archives. Article 9(1) uses the phrase "continuous, iterative process" over "the entire lifecycle" of the system. Every time deployment conditions change, the model is retrained, new monitoring data arrives, or a serious incident surfaces, the RMS loop restarts.

Under the Digital Omnibus agreed in May 2026, obligations for stand-alone high-risk AI systems (the Annex III list) apply from 2 December 2027 — and from 2 August 2028 for high-risk AI embedded in regulated products under Annex I. That extends the window the original August 2026 date gave you, but the documentation and governance work needed to demonstrate an Article 9-compliant RMS to a notified body or market surveillance authority takes well over a year to build properly. The practical deadline is now, not late 2027.

Non-compliance with Article 9 falls under the middle penalty tier in Article 99: up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For SMBs with revenues under €5 million, the percentage threshold is the binding number — and Article 99(6) caps fines for SMEs at the lower of the two figures, which is a genuine proportionality protection but not a reason to take shortcuts.

---

Who Must Run a Formal Article 9 RMS

Article 9 applies to providers of high-risk AI systems — organisations that develop a high-risk system and place it on the EU market or put it into service under their own name or trademark (Article 16). If you are a SaaS company shipping a credit-scoring module, a CV-screening feature, or a biometric verification flow, you are a provider with the full Article 9 obligation.

Deployers — organisations that use a high-risk AI system in a professional context — have lighter obligations under Article 26, but those still include ensuring the human oversight measures specified in Article 14, monitoring operations, and reporting incidents. Deployers do not run the full Article 9 RMS, but they must integrate into it: the provider's risk documentation has to account for the deployment contexts the system will actually encounter.

An important practical point: Article 25 means a deployer can become a provider overnight. If you white-label a third-party model, integrate it into a new product under your name, or substantially modify its intended purpose, the full provider obligations — including Article 9 — fall on you from that moment.

For systems not classified as high-risk under Article 6 and Annex III, Article 9 is not legally mandatory. That said, running a scaled-down version of the Article 9 process is good governance and generates documentation that is immediately useful if a system's classification changes — which it can, either through regulatory amendment under Article 7 or because a deployment context shifts the risk profile.

One classification nuance worth flagging: Article 6(3) provides a filter. A system that falls within an Annex III category is not high-risk if it does not pose a significant risk of harm to health, safety or fundamental rights — for example, it performs a narrow procedural task, improves the result of a previously completed human activity, or detects decision patterns without influencing human assessment. The exception does not apply to any system that profiles natural persons, which remains high-risk regardless. Providers claiming the Article 6(3) exemption must document their assessment and register it in the EU database under Article 49. If you are considering this route, the documentation requirement for the exemption claim is almost as demanding as running the Article 9 process itself — factor that into your decision.

---

Setting Up RMS Governance Before the Loop Starts

Article 17(1)(b) lists risk management as one of the elements that the quality management system must cover. In practice this means the RMS needs a governance layer before you can run it: assigned ownership, defined review cadences, documented procedures, and a version-controlled record of every update.

For an SMB provider, this does not require a dedicated risk function. What it does require is: one named individual accountable for the RMS (typically the CTO or Head of Product), a cross-functional input process that pulls in technical, product, legal and deployment-context knowledge for risk identification, and a documented schedule for RMS review — quarterly as a minimum, and triggered immediately by any material change to the system, deployment context, or monitoring data.

The staffing question matters for proportionality. Article 9 does not demand the same governance depth from a 30-person start-up that it demands from a large enterprise. The Act's proportionality language runs through most of the provider obligations, and competent authorities are expected to take the scale and resources of an organisation into account when assessing compliance. That said, proportionality does not excuse a gap in the substance of the RMS outputs — a 30-person company still needs a risk register with specific identified risks, documented evaluations, and traceable mitigations. It just may not need a dedicated risk management committee.

One document that SMB providers consistently underinvest in is the RMS policy: a brief written statement, signed by the most senior responsible person, committing the organisation to the Article 9 obligations, assigning accountability, and defining the scope of the RMS (which systems it covers). This document carries disproportionate weight in a regulatory inspection because it signals that the risk management process is an organisational commitment, not a technical artefact assembled retroactively.

---

The Article 9 Lifecycle Loop, Step by Step

Article 9 structures the RMS as a loop with four operational phases. They are not sequential milestones; they run concurrently and feed each other throughout the system's life.

Phase 1: Identify and Analyse Known and Reasonably Foreseeable Risks

Article 9(2)(a) requires you to identify and analyse "known and reasonably foreseeable risks to health, safety or fundamental rights." The standard is not just the risks you have already observed — it includes risks a competent engineer would foresee given the technology, the deployment context, and the population affected.

"Known" risks are grounded in empirical evidence: academic literature on the failure modes of the underlying model class, vendor-disclosed limitations, internal testing results. "Reasonably foreseeable" risks require anticipating how the system will behave when users deviate from the intended use, when edge-case inputs arrive, or when deployment conditions drift from the training distribution.

This phase also requires explicit attention to impact on vulnerable groups, including minors. Article 9 recitals and the fundamental rights framing throughout the Act make this a substantive requirement, not a box to check. A recruitment AI assessed for a professional workforce that later gets deployed in contexts involving young workers or people with disabilities requires the risk identification to be reopened.

The output of this phase is a risk register — not a high-level list of categories, but specific, bounded risk descriptions tied to the system's actual technical characteristics, the deployment context, and the population at risk.

Phase 2: Estimate and Evaluate Risks from Intended Use and Reasonably Foreseeable Misuse

Article 9(2)(b) and (c) separate the analysis of intended use scenarios from misuse scenarios. Both are mandatory. Misuse does not mean deliberate sabotage — it means predictable operator error, context drift, and users applying the system to decisions it was not designed for.

For each identified risk, this phase produces an estimate of severity (the magnitude of potential harm) and probability (the likelihood the harm materialises under real-world conditions). Article 9 does not prescribe a specific methodology — you can use a qualitative severity/likelihood matrix, a semi-quantitative scoring model, or a formal FMEA approach — but the choice must be documented and defensible. Whatever method you use, it must be applied consistently across all identified risks, and the resulting acceptability judgement must be explicit.

Residual risk — the risk that remains after all mitigation measures have been applied — must be evaluated and judged acceptable. Article 9(4) is clear that systems can only be placed on the market when residual risks "are considered acceptable." This is not zero risk. It is the judgement that the benefit of the system in its intended application outweighs the remaining risk after proportionate controls have been applied. That judgement must be documented, signed off, and revisited whenever the system or its operating environment changes.

Phase 3: Adopt Targeted, Appropriate Risk Management Measures

Article 9(4) requires risk management measures that are "proportionate to the risks" and "taking into account the generally acknowledged state of the art." The measures must address risks at their source where technically feasible — which means working through a mitigation hierarchy before accepting a monitoring-only control.

The practical hierarchy for AI systems looks roughly like this:

1. Design-level controls: Modify the model architecture, training data, or output logic to reduce the risk mechanically. Fairness constraints on output distributions, adversarial training to improve robustness, input validation to block known attack vectors.
2. Safeguards built into the system: Confidence thresholds that suppress low-certainty outputs, output filters, automatic fallback to human review when the system operates outside its tested envelope.
3. Information and instructions for deployers: The Article 11 technical documentation and deployer guidance under Article 13, disclosing known limitations and specifying conditions of safe use.
4. Human oversight mechanisms: The Article 14 requirements — the ability to monitor, override, and stop the system. Designing for interpretability so that human reviewers can actually exercise meaningful oversight rather than rubber-stamp automated outputs.
5. Monitoring controls: Post-market monitoring under Article 72 as the residual control for risks that cannot be fully designed out.

Choosing monitoring as the primary control for a high-severity risk — rather than working up the hierarchy first — is exactly the kind of gap that draws scrutiny during conformity assessment.

Phase 4: Test Against Pre-Defined Metrics and Thresholds

Article 9(6) requires that the risk management system "include testing of the high-risk AI system in order to identify the most appropriate and targeted risk management measures." Article 9(7) is more specific: testing "shall be performed against prior-defined metrics and thresholds and shall be performed against prior-defined metrics and probabilistic thresholds."

That language matters. You cannot test after the fact against whatever metrics look favourable. The metrics, thresholds, and test datasets must be defined before testing begins and documented in the RMS. Testing must be representative of the intended deployment population — Article 9(8) explicitly requires that test data is appropriate and reflects "the natural variation in demographic groups" where relevant.

Testing is not a one-time activity. The obligation to test extends to retrained model versions, significant architectural changes, and where post-market monitoring data indicates performance degradation.

---

AI-Specific Risk Taxonomy

The EU AI Act does not specify a taxonomy of AI risk categories, but Article 9 practice has converged on a set of risk types that any RMS for a high-risk system should address systematically. Here is how experienced practitioners structure the risk identification phase.

Bias and discrimination: The most litigated AI risk category. Includes direct bias (the system uses a protected characteristic as an input feature), proxy bias (the system uses a feature that correlates with a protected characteristic — postcode as a proxy for ethnicity in a credit model), and feedback loop bias (a model trained on historically biased decisions replicates and amplifies those decisions). Assessment requires disaggregated performance analysis across demographic subgroups, documented in the technical file.

Accuracy and performance failures: A high-risk system that produces systematically incorrect outputs causes concrete harm — a medical device that fails to detect a condition, a fraud-detection system that generates excessive false positives and freezes legitimate accounts. Accuracy must be specified at the level of the deployment task and population, not just reported as an aggregate headline figure.

Robustness and distributional shift: AI systems behave differently on data that differs from the training distribution. A model trained on pre-2020 lending data deployed in post-2023 economic conditions may have systematically degraded performance. Robustness testing must cover edge cases, adversarial inputs, and deployment contexts that differ from the training set.

Security: adversarial attacks, data poisoning, and prompt injection: Article 15 covers accuracy, robustness and cybersecurity together. For systems that use large language model components or that accept natural language inputs, prompt injection — manipulating model behaviour through crafted inputs — is a concrete, documented threat class, not a theoretical concern. The RMS must address it explicitly for any system in this category. Data poisoning risks are relevant wherever training data comes from sources the provider does not fully control.

Model drift and concept drift: The statistical relationship between inputs and the correct output can shift over time. A document-classification system trained on 2022 contract language may degrade as contract structures evolve. The RMS must specify monitoring indicators that would surface drift and thresholds that trigger retraining or review.

Data and privacy risks: Article 10 governs data governance for training datasets, requiring datasets that are relevant, representative, and free of errors. Privacy risks from the system's outputs — re-identification of individuals from supposedly anonymised outputs, unintended disclosure of training data through model inversion attacks — require assessment in the RMS and coordination with GDPR obligations.

Transparency failures and explainability gaps: If a system produces outputs that affected individuals or human overseers cannot interrogate, Article 14's meaningful human oversight requirement becomes unenforceable in practice. A risk that is often missed: deployers may be technically capable of overriding the system but practically unable to do so because they cannot interpret the system's output. The RMS must assess whether the information provided under Article 13 is genuinely sufficient for the oversight function to work.

Human-oversight failure: Article 14 requires that high-risk AI systems be designed so that natural persons can effectively oversee them, intervene, and override. A common RMS gap is treating human oversight as a procedural control ("we require a human to confirm the decision") without assessing whether the human in that role is realistically able to detect errors. The risk is not just that oversight is absent — it is that oversight is nominal and therefore provides false assurance.

Third-party and supply-chain risks: Many high-risk AI systems are built on top of foundation models, third-party data pipelines, or API services that the provider does not fully control. If a component in your system's technical stack introduces a vulnerability — a training dataset that contains undisclosed biases, a foundation model that behaves unpredictably in adversarial conditions — the provider's Article 9 obligation still applies. The risk identification phase must assess third-party dependencies explicitly, and the RMS must include contingency procedures for the failure or modification of those dependencies. This is not the same as shifting responsibility: Article 9 sits with the provider of the high-risk system, not with the provider of the underlying component.

Cascading and systemic risks across deployments: A provider whose system is deployed across dozens or hundreds of client organisations faces a risk the risk register must address: systemic failure. If a model degradation event, a discovered bias, or a security vulnerability affects all deployments simultaneously, the combined harm is far greater than the risk evaluated against any single deployment. The Article 72 post-market monitoring plan must be designed with this aggregated risk picture in mind — not just client-by-client monitoring, but cross-deployment pattern detection.

---

Risk Evaluation and Acceptability Judgement

The acceptability judgement — deciding that residual risk is low enough to proceed — is the most consequential output of the Article 9 process. It should be documented as an explicit decision, not implied by the absence of red flags.

In practice, a defensible acceptability judgement documents: the identified residual risks and their estimated severity and probability after controls; the rationale for treating the remaining risk as acceptable (often referencing the proportionality of the system's benefit against the residual harm); the conditions under which the acceptability judgement would be reopened (specific monitoring thresholds, changes to deployment context, new evidence from post-market data); and the identity and authority of the person or committee making the judgement.

For systems where residual risks to vulnerable groups or minors are elevated, a higher standard applies. Article 9's attention to "specific risks to specific groups" is not satisfied by a general acceptability judgement — it requires group-specific risk assessment and group-specific acceptability evaluation.

---

How the RMS Feeds into Related Obligations

Article 9 is not a standalone obligation. It is the process spine that connects to nearly every other high-risk requirement.

Article 11 — Technical documentation: The technical file under Annex IV must include a description of the risk management system and the measures adopted. Annex IV, point 1(e) specifically requires the RMS description; point 2(a)-(c) requires information about training methodology, training datasets, and validation and testing procedures — all of which are outputs of or inputs to the Article 9 process. In practice, the technical file is a structured snapshot of the RMS's current state, not a separate document written independently. The RMS is live; the technical file is the snapshot that a conformity assessment body reviews. Keep them structurally linked so that updating the RMS automatically surfaces what needs updating in the technical file.

One of the most common documentation failures in conformity assessments is that the technical file describes a risk management system that looks different from the one the engineering team is actually running. The gap usually opens up when the RMS is updated mid-cycle but the technical file is not. Version control — with dated entries and a change log — is the only reliable fix.

Article 10 — Data governance: The data management practices required under Article 10 (relevant, representative, error-free training datasets; monitoring for biases) should be directly informed by the data and bias risks identified in the RMS risk register. If your Article 9 process identifies training-data bias as a high-severity risk, your Article 10 controls must address that finding specifically.

Article 14 — Human oversight: The design of human oversight mechanisms must be shaped by the RMS findings. If the RMS finds that a specific risk category — say, incorrect outputs for a particular demographic subgroup — cannot be fully mitigated at the design level, Article 14 oversight must be designed to detect and intercept that specific risk. Generic oversight designs that are not connected to the RMS findings are harder to defend.

Article 15 — Accuracy, robustness and cybersecurity: Article 15 requires that high-risk AI systems achieve, and maintain throughout their lifecycle, appropriate levels of accuracy, robustness and cybersecurity. The thresholds for "appropriate" must be derived from the Article 9 risk evaluation — the acceptable performance floor is set by what the residual-risk analysis determined is needed to keep residual risk at an acceptable level.

Article 17 — Quality management system: The QMS under Article 17 is the organisational container that the RMS sits inside. The QMS must cover procedures for risk management (specifically listed in Article 17(1)(b)), change management, testing, incident handling, and documentation. If your organisation has an ISO 9001 or ISO/IEC 42001 QMS, Article 9 compliance requires mapping the RMS process into those frameworks — not treating them as substitutes for each other.

Article 72 — Post-market monitoring: This is the feedback channel that closes the Article 9 loop. Article 72 requires providers to establish a post-market monitoring plan that actively collects and analyses data on the system's performance in real-world deployment. Where that data surfaces risks that were not identified pre-deployment or that have worsened post-deployment, the Article 9 RMS must be updated. The two obligations are intentionally interdependent: Article 9 addresses foreseeable risk; Article 72 addresses the risk that emerges from actual operation.

---

Testing, Metrics and Thresholds

The Article 9 testing obligation (Article 9(6)–(9)) is one of the most specific, and most underimplemented, parts of the RMS requirement. Here is what operational compliance looks like.

Define your metrics before testing begins. For a classification system, relevant metrics might include accuracy, precision, recall, F1-score, and fairness metrics (demographic parity difference, equalised odds difference). For a regression system, mean absolute error, error variance across subgroups. For a natural-language system, output consistency, refusal rates on adversarial prompts. Which metrics are selected must be justified in the RMS based on the system's task and the risks identified.

Define your thresholds before testing begins. A threshold might be: overall accuracy ≥ 92%; demographic parity difference ≤ 5 percentage points; false negative rate ≤ 3% for the highest-consequence output class. Thresholds should be grounded in the acceptability judgement — they are the quantified expression of what "acceptable residual risk" means for this system.

Test on data that is representative of the actual deployment population. If your intended deployment includes users from multiple EU member states with different language and cultural contexts, your test set must reflect that. Article 9(8) requires testing to "include, to the extent possible, data reflecting the natural variation in demographic groups."

Where a system fails to meet a pre-defined threshold, the failure must be documented, the cause investigated, and either the system must be modified until it passes or the acceptability judgement must be reopened. Lowering the threshold after a test failure to make the result pass is exactly the kind of engineering manipulation that structured RMS documentation is designed to prevent.

---

Frameworks Crosswalk: Article 9 and the Voluntary Standards

Organisations that have already invested in voluntary risk management frameworks need to understand the gaps — and the overlaps — between those frameworks and the Article 9 legal obligation.

The practical takeaway: if your organisation has implemented the NIST AI RMF's Govern/Map/Measure/Manage cycle, you have built useful risk governance infrastructure — but you have not automatically satisfied Article 9. The Article 9 obligation is more specific on residual risk acceptability, testing standards, fundamental rights framing, and the Article 72 feedback loop. Similarly, ISO/IEC 42001 certification is valuable for QMS purposes and maps reasonably well to Article 17, but it does not substitute for the technical specificity Article 9 demands. ISO 31000 is a useful methodological reference for the risk identification and evaluation phases, but it operates at a level of generality that requires substantial AI-specific elaboration before it meets Article 9 standards.

The question practitioners often ask is: where should we start if we have already invested in NIST AI RMF? The most direct bridge is the Measure function. NIST AI RMF Measure 2.5 (AI risks to be managed are prioritised based on impact, likelihood, and available mitigations) maps closely to the Article 9(2)–(4) evaluation and mitigation phases. Measure 2.7 (AI system trustworthiness is evaluated based on test results aligned with risk or harms) is the closest analogue to the Article 9(6)–(9) testing obligation. Starting from those two Measure practices and layering in the specific Article 9 requirements — explicit residual-risk acceptability judgement, pre-defined thresholds, fundamental rights framing, vulnerable group attention — is faster than building from scratch.

For organisations with ISO/IEC 42001, the gap is narrower on governance and QMS structure (which maps to Article 17) and wider on the technical specificity of risk evaluation. ISO 42001's Annex A controls reference risk management without specifying the Article 9 level of detail on testing standards, acceptability criteria, or post-market feedback loops. Use the 42001 structure as the container; build the Article 9-specific content inside it.

---

Worked Example: A 45-Person HR-Tech Provider

Meridia is a 45-person HR-tech company. Its flagship product is an AI-assisted interview-scoring tool that analyses written responses to structured interview questions and provides ranked shortlists to HR teams at mid-market employers. The company's legal team has determined the tool falls under Annex III heading 4 (employment decisions affecting access to self-employment and workers management). Under Article 6, the tool is high-risk. Meridia is a provider. Article 9 applies in full. The compliance deadline is 2 December 2027.

RMS governance: Meridia appoints its CTO as the RMS owner and convenes a quarterly RMS review including the CTO, Head of Product, and a part-time data scientist. This satisfies Article 17's QMS requirement that risk management responsibilities be assigned to staff with the necessary competence.

Risk identification: The cross-functional team documents six material risks. The two highest-severity:

• Proxy discrimination: The model was trained on historical hiring data from clients who operated in industries with historically male-dominated hiring. The model may have learned to associate linguistic patterns correlated with male candidates with higher scores.
• Transparency/oversight failure: HR reviewers at client companies receive a numerical score and a ranking but no explanation of the factors driving the score. Meaningful override under Article 14 is not practically achievable because reviewers cannot assess what drove a low score.

Risk evaluation: The proxy discrimination risk is rated severe/high-probability and assessed as affecting female and ethnically diverse candidates disproportionately — a targeted, fundamental-rights-relevant impact. The oversight failure risk is rated severe/medium-probability. Both are marked "not yet acceptable."

Mitigation design:

• Proxy discrimination: Meridia retrains the model with demographic parity constraints; removes features with documented proxy-discrimination potential; commissions an independent fairness audit against the retrained model, with acceptance threshold of ≤4 percentage point demographic parity difference.
• Oversight failure: Adds a feature-importance explanation to each scoring output (the three response characteristics contributing most to the score), redesigns the UI to require the reviewer to acknowledge the explanation before confirming the shortlist.

Testing: Meridia runs fairness testing on a held-out dataset stratified by gender, age group and national origin. The pre-defined acceptance thresholds are documented in the RMS before testing begins. First pass fails for age-group parity (8 percentage point difference). Meridia modifies the training pipeline and retests. Second pass passes all thresholds.

Residual risk acceptability: Documented by the CTO and signed off by the CEO: demographic parity difference ≤4%, explanation provided for all scores, human review required before shortlist is finalised. Residual risk judged acceptable under these conditions.

Post-market monitoring: Monthly demographic performance reports to client HR teams; automated alert to Meridia's monitoring dashboard if any client deployment shows demographic parity difference exceeding 6 percentage points; quarterly review of monitoring data incorporated into the RMS review meeting.

This structure — governance, identification, evaluation, mitigation, testing, acceptability, monitoring — is what Article 9 compliance looks like for an SMB-scale provider. It does not require a 200-page document. It requires a disciplined, cross-functional process with traceable outputs at each stage.

---

How Confir Helps

Article 9 compliance generates a lot of documentation that has to remain coherent as the system evolves, the risk register updates, and post-market monitoring data feeds back in. Keeping that coherent in a spreadsheet is technically possible for one system; it becomes unmanageable quickly across multiple systems or team members.

Confir's AIGM compliance area — covering Article 9 and Article 72 — structures the Article 9 process as a series of guided assessments. The risk register is embedded in the workflow, controls are assessed against specific Article references using deterministic, rule-based logic rather than AI-generated suggestions, and the Compliance Health Score reflects the current state of your RMS at the organisation level across all registered systems. When the RMS feeds the technical documentation pack under Article 11, the link is maintained automatically — so an updated risk evaluation reflects in the documentation that goes to a conformity assessment body.

For organisations managing multiple high-risk systems — or organisations that have a mix of provider and deployer roles — the organisation-wide risk register is where Article 9 compliance becomes tractable rather than overwhelming.

Confir starts at €600/year with no consultants and no sales cycle. The documentation work is still yours; the structure and the Article-level accuracy are built in.

---

FAQ

What exactly is the Article 9 risk management system, and is it the same as a risk assessment?

A risk assessment is a single exercise — typically a point-in-time evaluation of identified risks. The Article 9 risk management system is the ongoing process that wraps around risk assessment: governance structure, documented procedures, risk identification methodology, testing protocols, mitigation tracking, post-market feedback loops, and the standing obligation to update the system whenever circumstances change. The risk assessment is one output of the RMS; the RMS is the living infrastructure that produces it continuously.

Does Article 9 apply to deployers, or only providers?

The full Article 9 obligation sits with providers (Article 16). Deployers have lighter obligations under Article 26 — primarily to follow the provider's instructions, ensure human oversight in line with Article 14, and monitor use. That said, deployers who substantially modify a system or change its intended purpose shift into the provider role under Article 25 and inherit the full Article 9 obligation from that point.

What does "residual risk must be acceptable" mean in practice?

It means that after all proportionate mitigation measures have been applied, the remaining risk — quantified in terms of the severity and probability of potential harms to health, safety and fundamental rights — must be judged acceptable relative to the system's benefit. The Act does not define a universal threshold. The acceptability judgement is yours to make and document, but it must be explicit, grounded in the risk evaluation findings, condition-specific, and reopened whenever deployment conditions change materially.

How does Article 9 interact with GDPR?

They operate under different legal bases but address overlapping risk categories. A training-data bias risk identified under Article 9 may overlap with GDPR principles of data accuracy and fairness in automated decision-making. A privacy risk from model inversion attacks sits at the intersection of Article 15 cybersecurity and GDPR security obligations. The two frameworks do not replace each other; they require coordinated compliance programmes, particularly where Article 27's Fundamental Rights Impact Assessment overlaps with a GDPR Data Protection Impact Assessment.

What is the penalty for failing to run an Article 9-compliant risk management system?

Non-compliance with Article 9 falls under the middle penalty tier in Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. For SMEs and start-ups, Article 99(6) caps fines at the lower of those two figures. Penalties aside, market surveillance authorities can also require corrective action, withdraw a system from the market, or suspend its deployment pending compliance.

Can ISO/IEC 42001 certification replace the Article 9 RMS?

No. ISO/IEC 42001 is a management system standard that maps well to the organisational and QMS requirements in Article 17. It does not substitute for the Article 9 RMS. The Act requires specific technical outputs — a documented risk register, pre-defined testing metrics and thresholds, an explicit residual-risk acceptability judgement, integration with post-market monitoring under Article 72 — that go beyond what an ISO 42001 certification addresses. Certification is useful evidence of governance maturity; it does not complete the Article 9 obligation.

When is the deadline for high-risk AI systems to have an Article 9-compliant RMS in place?

Under the Digital Omnibus agreed in May 2026, the application date for stand-alone high-risk AI systems listed in Annex III is 2 December 2027. For high-risk AI systems that are safety components of products regulated under Annex I (medical devices, machinery, etc.), the date is 2 August 2028. These dates extend the original August 2026 deadline. Given that a credible Article 9 RMS takes a year or more to build, document and test, organisations that have not started governance work are already behind the effective schedule.

---

Related guides

• compare EU AI Act compliance solutions
• Article 26 deployer obligations
• Article 17 quality management requirements