Most of what's been written about the EU AI Act and healthcare treats "medical" as a synonym for "pharma." Search the term and you'll find clinical trial software, drug discovery algorithms, and pharmacovigilance tools. What you won't find much of is a straight answer to the question a device manufacturer actually has: does my AI-enabled software or hardware just become high-risk under a second EU regulation, on top of the one I already comply with?
The answer is yes, for most of you, and the mechanism is more specific than most summaries let on. I want to walk through exactly how Regulation (EU) 2024/1689 — the AI Act — reaches into a Medical Device Regulation (MDR) or In Vitro Diagnostic Regulation (IVDR) file you may have spent years building, what it adds, what it doesn't touch, and when each piece actually becomes enforceable.
The AI Act Doesn't Replace the MDR. It Sits on Top of It
The AI Act entered into force on 1 August 2024. It does not create a new CE mark, a new notified body category, or a new regulatory pathway for medical devices. It adds a second layer of obligations on top of the CE marking you already pursue under the MDR or IVDR, triggered specifically because your product uses AI.
That layering is deliberate. The Act's drafters built it around a category of "Annex I" products: things already regulated under other EU harmonisation law — machinery, toys, lifts, pressure equipment, and, critically, medical devices. Annex I, Section A names Regulation (EU) 2017/745 (the MDR) at item 11 and Regulation (EU) 2017/746 (the IVDR) at item 12. That placement was contested through most of 2026: the Commission's Digital Omnibus on AI proposal (16 December 2025) would have moved the MDR and IVDR out of Section A and into Section B, exempting most AI-enabled devices from the high-risk track entirely. Member states and Parliament rejected that move on 7 May 2026, so the MDR and IVDR stay in Section A as described here. As a compromise, the final text, Regulation (EU) 2026/1744, gave the Commission power to limit the AI Act's applicability to a given Annex I product category by implementing act wherever the underlying sectoral law already provides equivalent protection — a standing lever on this question, not a closed one. That listing is the hook the whole framework hangs on. If your AI system is a safety component of, or is itself, a product covered by that Annex I legislation, it gets pulled into the AI Act's high-risk category through a specific test — not a general "AI in healthcare is risky" judgment call.
Why Nearly Every AI-Enabled Device Lands in the High-Risk Tier
Article 6(1) sets that test in two parts. An AI system is high-risk when it is intended to be used as a safety component of an Annex I product, or is itself such a product, and that product is required to undergo third-party conformity assessment before it can be placed on the market.
Read that second condition against how the MDR actually classifies software. Under MDCG 2019-11 — the Medical Device Coordination Group's guidance on qualifying and classifying medical device software, first issued in 2019 and revised in June 2025 — software that drives or influences a diagnostic or therapeutic decision typically lands in Class IIa or higher under MDR Annex VIII Rule 11. Class IIa and above require notified body involvement. Put those two facts together and the practical result is this: if your AI system informs a diagnosis or a treatment decision and your device needed a notified body before the AI Act existed, it is now, separately, a high-risk AI system too. A handful of Class I, self-certified products escape the trigger. Almost nothing above that does.
I'll say the quiet part directly: this isn't really a new risk tier for AI in medicine. It's a formal label attached to work you were already doing, with a new set of documentation and process requirements stapled to it.
When Each Obligation Actually Bites
The Act phases in on a schedule set out in Article 113, and the dates that matter for device makers aren't all the same date.
| Date | What applies | What it means for you |
|---|---|---|
| 1 August 2024 | Regulation enters into force | Clock starts; no obligations yet |
| 2 February 2025 | Chapters I and II (prohibited practices, Article 5) | Already binding — no AI system, medical device or not, may use manipulative or subliminal techniques; emotion-recognition AI is banned in workplace/education contexts, but Recital 44 carves out AI systems placed on the market strictly for medical or safety reasons, such as therapeutic use |
| 2 August 2025 | Chapter V (general-purpose AI models), governance, penalties | Relevant if your device is built on top of a foundation model you didn't train yourself |
| 2 August 2026 | General application date; transparency duties (Chapter IV) | Applies to limited-risk features like AI-driven chat interfaces or patient-facing assistants inside your device |
| 2 August 2028 | Article 6(1) and its corresponding obligations | The high-risk obligations for Annex I products — including MDR/IVDR devices — become enforceable. (Originally 2 August 2027; deferred a year by the Digital Omnibus on AI, Regulation (EU) 2026/1744.) |
That last row is the one worth sitting with. Article 6(1) and the obligations tied to it apply from 2 August 2028, not the 2 August 2027 date the Act originally set — the Digital Omnibus on AI (Regulation (EU) 2026/1744), politically agreed 7 May 2026 and in force 27 July 2026, pushed the deadline back a year. Even before that change, a full year separated the Act's general application date of 2 August 2026 from the original high-risk deadline; the extra time exists because the Commission recognized that folding AI Act compliance into an existing sectoral conformity assessment, rather than building a parallel one, takes device manufacturers and their notified bodies longer to work out. That's not a reason to wait until 2028 to start. It's a reason to start now, because the mechanism that makes this manageable depends on work you do inside your existing QMS, not a system built from scratch under time pressure.
The Conformity Assessment Doesn't Duplicate. It Merges
This is the part I get asked about most, and it's good news. Article 43(3) directs providers of high-risk AI systems covered by Annex I, Section A legislation to follow the conformity assessment procedure already required under that sectoral law, rather than a separate AI Act procedure. For a device maker, that means the same MDR or IVDR notified body audit that already reviews your technical file also picks up the AI Act's Chapter III, Section 2 requirements — and Article 43(3) specifically calls out that the quality management system assessment under Article 17 gets undertaken as part of that same review.
There's a real bottleneck hiding inside that convenience, though. Notified bodies designated under the MDR or IVDR can assess the AI Act's requirements only if their own competence against Article 31 was assessed during their original notification procedure. Not every notified body has done that yet. If yours hasn't, you're not looking at a second audit body from scratch, but you are looking at a scope extension that takes time your notified body doesn't control alone. Ask your notified body directly, this quarter, whether its designation covers Article 31 competence. Don't assume it does because it's competent under the MDR.
Where the New Requirements Overlap What You Already Have
Nearly every substantive requirement in the AI Act's Chapter III, Section 2 has a direct analog in a QMS built to ISO 13485 and a risk file built to ISO 14971. That overlap is the whole reason the merged conformity assessment works.
| AI Act requirement | Article | Closest existing analog |
|---|---|---|
| Risk management system | Article 9 | ISO 14971 risk management file |
| Data and data governance | Article 10 | Design controls, verification/validation records |
| Technical documentation | Article 11 | MDR/IVDR technical file, Annex IV |
| Record-keeping / logging | Article 12 | Device history record, audit trail |
| Transparency / instructions for use | Article 13 | IFU, labeling requirements |
| Human oversight | Article 14 | Usability engineering, IEC 62366 |
| Quality management system | Article 17 | ISO 13485 QMS |
| Post-market monitoring | Article 72 | MDR/IVDR post-market surveillance |
| Serious incident reporting | Article 73 | MDR/IVDR vigilance reporting |
None of that overlap means the new work is trivial. Annex IV's technical documentation requirements go further than a typical MDR technical file on questions like training data provenance, known limitations, and foreseeable misuse. But it does mean the honest starting point isn't a blank page. It's your existing risk management file and QMS, read against a new checklist to see what's missing. If your risk management process for AI-enabled features isn't already talking to your ISO 14971 file in a structured way, that's the gap to close first — our guide to integrating ISO 14971 with an ISO 13485 QMS is a reasonable place to start regardless of the AI Act, because the discipline transfers directly.
If You're Building On Someone Else's Model
A growing number of device makers aren't training their own AI. They're fine-tuning or wrapping a general-purpose model, an imaging foundation model, or a large language model for clinical documentation, inside a device that carries their own name.
The Act's value-chain provisions matter here in a way that's easy to miss. Under Article 25(1), if you substantially modify a high-risk AI system that someone else placed on the market, or you put your own name on it, the Act treats you as having taken on provider obligations for that system, not just the lighter obligations of a deployer. That shift can happen quietly, through a fine-tuning decision that felt routine on the engineering side. If your device's AI component depends on a model you didn't build end to end, get clear early on which party is holding provider obligations under the Act, and document that determination the same way you'd document any other design input decision.
This is exactly the kind of question that comes up constantly in radiology and imaging AI, where a device often layers proprietary logic on top of a broader machine-learning backbone. Our classification guide for radiology and imaging AI devices walks through how MDR classification treats that kind of layered software, and the same layering question is exactly what determines your AI Act role.
What to Do Between Now and August 2028
In my view, the mistake I'd watch for isn't underestimating the AI Act. It's treating 2028 as a start date instead of a deadline. Four things are worth doing now, while there's still runway:
- Confirm your Article 6(1) status in writing. For each AI-enabled device, document whether it's a safety component of, or itself, an Annex I product requiring notified body assessment. Don't leave this as an assumption.
- Ask your notified body about its Article 31 scope. If it hasn't extended its designation to cover AI Act competence, you need to know that now, not in month eleven of a 2028 submission.
- Map your existing risk and quality files against Chapter III, Section 2. Use the overlap table above as a starting checklist, then go deeper into where your documentation actually falls short of Annex IV.
- Settle your value-chain role for any device built on a third-party model. Provider or deployer, decide it deliberately and write down why.
None of this requires abandoning what you've already built. It requires reading it against a new list, honestly, before a notified body does it for you.
FAQ
Does the EU AI Act replace the MDR or IVDR for medical devices?
No. It adds a second, parallel set of obligations that apply specifically because a device uses AI. CE marking under the MDR or IVDR is still the primary pathway; the AI Act's high-risk requirements are assessed as part of that same conformity assessment procedure under Article 43(3), not as a separate certification.
Which medical devices count as "high-risk" under the AI Act?
Under Article 6(1), an AI system is high-risk if it is a safety component of, or is itself, a product covered by Annex I, Section A legislation, and that product requires third-party conformity assessment. Annex I, Section A lists the MDR at item 11 and the IVDR at item 12, so any AI-enabled device that already needs notified body involvement under one of those regulations is generally caught. A concrete edge case: an AI-enabled wellness app that stays Class I and self-certified never trips the test, while that same AI feature built into a Class IIa diagnostic-support device — the more typical case under MDCG 2019-11's Rule 11 — is caught the moment a notified body is required. The list itself isn't frozen, either: under the Digital Omnibus compromise described above, the Commission can now narrow it for a given product category by implementing act, so it's worth re-checking Annex I, Section A rather than treating today's answer as permanent.
When do medical device manufacturers actually have to comply?
Article 113 phases the Act in. Article 6(1) and the obligations tied to it apply from 2 August 2028 — the Digital Omnibus on AI (Regulation (EU) 2026/1744) pushed that date back a year from the Act's original 2 August 2027 deadline. Some obligations are already live, though: prohibited practices under Article 5 have applied since 2 February 2025, and general-purpose AI model obligations have applied since 2 August 2025.
Do we need a separate AI Act audit from a different notified body?
Not if your existing MDR or IVDR notified body has extended its designation to cover the AI Act's Article 31 competence requirements. Article 43(3) allows that same notified body to assess AI Act compliance, including the quality management system check under Article 17, as part of your regular conformity assessment. Confirm your notified body's scope directly rather than assuming it.
Does the AI Act apply if we build our device on top of a third-party AI model?
Likely yes, and possibly with more obligation than you'd expect. If you substantially modify a high-risk AI system built by someone else, or put your own branding on it, the Act's value-chain provisions can shift you from a lighter "deployer" role into full "provider" obligations for that system. This determination should be documented, not assumed, especially for devices layered on general-purpose or imaging foundation models.
Last updated: 2026-09-20
Jared Clark
Principal Consultant, Certify Consulting
Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.