TL;DR. Article 9 of the AI Act requires risk management across the entire life cycle for every high-risk AI system, not a one-off document. The Digital Omnibus moved the deadlines in summer 2026: for stand-alone high-risk systems under Annex III, Article 9 applies from December 2, 2027; for AI in regulated products such as medical devices or machinery, from August 2, 2028. Breaches of the high-risk duties cost up to €15 million or 3% of worldwide annual turnover. Mid-sized companies are affected too: with AI in recruiting, credit scoring, medical devices or safety functions.
What Article 9 actually requires
Article 9 prescribes a continuous, iterative risk management system. It is not a one-off document but a process maintained throughout the entire period of use. Anyone who treats it as a one-off audit will fail in the conformity assessment. The system records foreseeable risks to health, safety and fundamental rights, and its effort has to fit the application. The life cycle breaks down into four phases, each with its own evidence:
| Phase | What happens | Evidence |
|---|---|---|
| 1 · Identify risks | Record foreseeable risks and foreseeable misuse, map fundamental rights | Risk register, hazard list |
| 2 · Mitigate risks | Design measures, assess residual risk | Mitigation plan, architecture documentation |
| 3 · Test and validate | Tests before placing on the market, checks for bias, robustness | Test reports, validation records |
| 4 · Monitor in operation | Analyse usage data, log incidents | Post-market monitoring plan, incident reports |
Phase 4 is not an extra. It is where many fail. Without clean telemetry there is no post-market monitoring under Article 72, and without it no valid risk management.
Which AI is high-risk
An AI system becomes high-risk in two ways. Either it is a safety component of a product already covered by EU product law, such as medical devices or machinery (Article 6(1) with Annex I). Or it falls into one of the eight areas of Annex III. Four cases regularly hit German mid-sized companies, often without management knowing:
- Recruiting and HR (Annex III point 4). Any system that screens CVs, ranks applicants or automates performance reviews. If you use such a tool, you are in the chain as a deployer with duties of your own under Article 26, even if the system comes from a software vendor.
- Credit scoring and lending decisions (Annex III point 5(b)). AI scoring models for the creditworthiness of natural persons. If you score private customers with AI, for example in leasing or instalment payments, check whether you fall under it.
- Medical device software (Annex I). Software as a medical device is high-risk as soon as it needs a conformity assessment by a notified body under the MDR or IVDR, for example diagnostic algorithms, triage tools or imaging AI. Article 9 applies in addition to ISO 14971, not instead of it.
- Safety functions. AI as a safety component in machinery falls under the high-risk rules via Annex I. AI in the operation of critical infrastructure, for example in electricity, gas or water supply, falls under Annex III point 2.
When Article 9 applies: the deadlines after the Digital Omnibus
Originally, the high-risk duties for Annex III were to apply from August 2, 2026. With the Digital Omnibus, the EU postponed that. For stand-alone systems under Annex III, Article 9 applies from December 2, 2027; for AI in regulated products under Annex I, from August 2, 2028. Other parts have long applied: AI literacy of staff since February 2025, the duties for providers of general-purpose AI models since August 2025, and the disclosure duties of Article 50 since August 2, 2026.
Days until Article 9 applies, counted from November 3, 2026
That sounds like plenty of time. But a risk management system is not built in a quarter, because phase 4 needs data from real operation. If you start now, you can build telemetry and registers calmly instead of documenting retroactively under pressure in autumn 2027.
What a risk management system looks like
A compliant system follows an iterative sequence with clear gates: define the intended purpose, identify foreseeable misuse, estimate risks (severity times probability), design controls, assess the residual risk, test against the controls, set up monitoring in operation and update everything continuously. The evidence must be auditable at any time. Notified bodies expect a version, a date and a responsible person on every document.
The fines make clear why this is worth it. The AI Act grades them in Article 99 by the severity of the breach. The highest range applies to prohibited practices, not to Article 9:
Fine ranges under Article 99 of the AI Act
Medical technology specifics: Article 9 vs. ISO 14971
The most common confusion in medical technology: “We have ISO 14971, so we comply with the AI Act.” That is not true. The requirements complement each other; they do not replace each other.
| Dimension | ISO 14971 | Article 9 AI Act |
|---|---|---|
| Scope | Medical devices (MDR, IVDR) | All high-risk AI systems |
| Protected interest | Patient safety, clinical benefit | Health, safety and fundamental rights |
| Bias in data | not explicitly required | Required via Art. 10 (data) and Art. 15 (accuracy, robustness) |
| Monitoring in operation | Post-market surveillance under MDR Art. 83 et seq. | Plan under Art. 72 AI Act |
If you run both worlds together, you can keep much of the evidence jointly, such as the risk register and monitoring in operation. Bias checks and the mapping to fundamental rights, however, are duties of the AI Act in their own right and have to be added. For medical devices, Article 9 applies from August 2, 2028.
A typical path for a medical technology manufacturer
Take a mid-sized manufacturer with three software medical devices: two imaging algorithms and a triage score. ISO 14971 is fully implemented; evidence under Article 9 and bias checks are missing. A sensible path looks like this:
- Fix the purpose and misuse for each product, based on the existing intended purpose under the MDR.
- Extend the existing risk register with fundamental rights, for example unequal error rates across patient groups.
- Set up bias checks, with training and test data under Article 10.
- Build in telemetry for operation, so that deviations in real use become visible.
- Version everything, with a date and a responsible person, so that a notified body can trace every state.
How much effort this is in a given case depends on the data situation and the number of products. Serious figures only exist after an inventory.
What is often done wrong
Three patterns come up again and again. All can be corrected with reasonable effort if you start early enough.
- “We are not an AI provider.” As a deployer you have duties of your own under Article 26, even if the system comes from a software vendor. If you use an AI tool in HR, you share responsibility for it being used according to its intended purpose.
- ISO 14971 as a complete substitute. Bias and fundamental rights are missing there. Discovering that only in the conformity assessment costs time.
- No monitoring in operation. Without telemetry, risk management remains a dead document. Deviations in real use and edge cases stay invisible, and evidence of ongoing maintenance is missing.
Article 9 is not a one-off compliance act but a way of working in development. If you treat risk management as a paperwork exercise, you build yourself a delayed breach of duty. If you understand it as an architectural principle, you gain a head start.
What you should do now
- Clarify your role: provider, deployer or both?
- Assign your AI systems to the annexes. Annex III applies from December 2027, Annex I from August 2028.
- Start with telemetry, because phase 4 needs data from operation, and that does not appear overnight.
- Use existing standards. ISO 14971 or an existing ISMS carry a lot, but not everything.
As of November 3, 2026, based on Regulation (EU) 2024/1689 as amended by the Digital Omnibus. How a management system with evidence is prepared in practice is shown in our post on the TISAX audit. If you want to clarify which of your systems are affected, we are happy to talk.
