Is My Medical AI High-Risk Under the EU AI Act?

Your medical AI is high-risk under the EU AI Act if it is, or is a safety component of, a medical device that needs a notified body under the MDR (Regulation (EU) 2017/745) or IVDR (Regulation (EU) 2017/746). In practice:

• MDR Class IIa, IIb, III → high-risk AI (a notified body is required).
• MDR Class I that is sterile (Is), has a measuring function (Im), or is reusable surgical (Ir) → high-risk AI, because those need a notified body for that aspect.
• Basic self-certified MDR Class I → not high-risk via this route.
• IVDR Class B, C, D, and sterile Class A → high-risk AI. Basic IVDR Class A → not via this route.

If a notified body has to touch your device, the AI Act treats the AI as high-risk. And the relief most summaries miss: you do not run a separate AI Act audit. Under Article 43(3), the AI Act check is integrated into the MDR/IVDR conformity assessment you already do, one coherent pathway, not two.

This guide walks the full path: scope, class mapping, worked examples, why the Article 6(3) exceptions do not help medical devices, the obligation delta, what it costs, and the common mistakes. Every legal claim is cited to the official regulation or Commission guidance. See Sources.

Key terms in 30 seconds

• AI system: software that infers, from inputs, outputs such as predictions, recommendations or decisions (AI Act Article 3).
• Medical device / IVD: a product with a medical intended purpose under the MDR or IVDR. Software can be the device.
• SaMD (Software as a Medical Device): software that is itself a medical device, not part of a hardware device.
• Safety component: a component whose failure endangers health or safety. AI can be a safety component of a device.
• Notified body: an independent organisation that assesses conformity for higher-risk devices. Its involvement is the AI Act's high-risk trigger for medical AI.
• Provider vs deployer: the provider makes the AI (the MDR manufacturer); the deployer uses it (for example a clinic). Most obligations sit on the provider. See provider vs deployer.
• Conformity assessment: the procedure that leads to CE marking. For high-risk medical AI, the AI Act check happens inside it.

Why this question is so confusing

Medical-device teams already live under the MDR or IVDR: technical documentation, clinical or performance evaluation, a notified body, ISO 13485, ISO 14971, post-market surveillance. Then the AI Act arrives and it looks like a second, parallel regime bolted on top, another risk classification, another set of obligations, another assessment.

The industry has said this out loud. In a joint statement, MedTech Europe, COCIR and DIGITALEUROPE called for AI Act requirements for medical technologies to be implemented through the existing MDR and IVDR rather than as parallel obligations, arguing that layering the AI Act on top "adds complexity, increases administrative burden, and risks slowing patient access." So the honest starting point is: yes, there is overlap.

The good news is structural, and it is the point of this guide: the AI Act was written to plug into the medical-device framework, not to sit beside it. The Commission's own MDCG 2025-6 guidance on the interplay between the MDR/IVDR and the AI Act confirms this direction. Once you see how the trigger and the assessment connect, "two regimes" collapses into one integrated pathway.

Step 1: Is your AI in scope as a medical device?

The AI Act's high-risk trigger for medical AI runs through Article 6(1). An AI system is high-risk when both are true:

1. The AI system is itself a product, or a safety component of a product, covered by the EU harmonisation legislation listed in Annex I (Article 6(1)(a)); the MDR and IVDR are both listed in Annex I, Section A (items 11 and 12); and
2. That product (or the AI safety component) is required to undergo a third-party conformity assessment, that is, a notified body, under that same legislation (Article 6(1)(b)).

So the single load-bearing question is: does your device need a notified body? That is decided by your MDR/IVDR risk class, not by how "AI-heavy" or autonomous the product feels.

Two things decide whether you are even in scope:

• Is it a medical device at all? That turns on intended purpose. A tool intended to diagnose, prevent, monitor, predict, treat or alleviate disease is a medical device. A general wellness or lifestyle tool, with no medical claim, usually is not, and therefore is not caught by this route. The moment you make a medical claim, the qualification (and this whole analysis) changes.
• Is your software the device, or a safety component? Your software can be the medical device itself (Software as a Medical Device), or it can be a safety component of a hardware device. Article 6(1) confirms both routes: "a safety component of a product, or the AI system is itself a product." Both land you in the high-risk trigger.

Two related questions decide who actually owns these obligations: are you the provider or the deployer of the system? And if you built it on a general-purpose model, see what the AI Act requires when you build medical AI on an LLM. If you are still working out whether you are in scope at all, start with the general high-risk classification guide.

Step 2: Map your MDR / IVDR class to an AI Act outcome

If you fall under the MDR (2017/745)

Whether a notified body is involved follows from MDR Article 52 and, for the special Class I subtypes, Article 52(7).

Most medical AI is software, and software classification runs through MDR Annex VIII, Rule 11. Rule 11 is worth understanding because it is where most medical AI lands:

• Software that provides information used to take decisions with diagnostic or therapeutic purposes is Class IIa.
• It escalates to Class IIb where those decisions could cause a serious deterioration of health or a surgical intervention.
• It escalates to Class III where those decisions could cause death or an irreversible deterioration of health.
• Software intended to monitor physiological processes is Class IIa, rising to IIb where the parameters are vital and variation could cause immediate danger.

Because almost any diagnostic or therapy-driving function lands at Class IIa or above, most clinical medical AI is high-risk. But "most" is not "all", a genuinely basic Class I tool (for example, software that only stores or communicates data without a diagnostic or therapeutic function) is not caught by this trigger.

If you fall under the IVDR (2017/746)

Notified-body involvement follows from IVDR Article 48: only non-sterile Class A is self-certified; Class A sterile, B, C and D all involve a notified body.

The one-line rule

Notified body involved → high-risk AI. Self-certified only → not high-risk via this route.

One caveat worth stating plainly: "not high-risk via Article 6(1)" is not the same as "no AI Act obligations at all." Transparency duties under Article 50 can still apply, and a small number of systems could be caught by other routes. But the high-risk classification for medical AI is the notified-body test above. Note too that being high-risk under the AI Act does not push your device into a higher MDR/IVDR class; the two classifications are separate, as MDCG 2025-6 confirms.

Worked examples

The logic is easier to trust when you see it run. These are illustrative (your exact classification depends on your intended purpose and claims), but they show how the trigger resolves:

Two lessons from the table. First, intended purpose decides everything: the wellness app and the scribe are usually out because they do not make a medical claim, but the instant either starts driving a diagnosis or treatment decision, it re-qualifies and the analysis flips. Second, the base technology does not matter, an LLM-powered triage tool and a classical-ML detector reach the same high-risk outcome if they share the same clinical intended purpose.

Why Article 6(3) does not rescue medical AI

Teams often hear about the AI Act's "narrow task" exceptions and hope they apply. They do not, for medical devices. Article 6(3) opens with "By derogation from paragraph 2, an AI system referred to in Annex III shall not be considered to be high-risk" where it performs a narrow procedural task, improves a completed human activity, and so on.

The key word is paragraph 2. Article 6(2) is the Annex III route (the list of high-risk use cases like employment or credit scoring). The exceptions in 6(3) derogate from that route only. Medical devices are caught under Article 6(1), the Annex I product route, which 6(3) does not touch. So a medical AI that needs a notified body cannot argue its way out of high-risk by claiming it performs a narrow task. The notified-body test governs.

Step 3: The relief, one integrated assessment, not two (Article 43(3))

Here is the part most summaries get wrong. When your device already goes through a notified-body conformity assessment under the MDR/IVDR, the AI Act does not bolt on a separate procedure. Under Article 43(3), the AI Act's high-risk requirements are assessed as part of that existing MDR/IVDR conformity assessment, and notified bodies already notified under the MDR/IVDR may control conformity with the AI Act requirements. One procedure, one notified body, one technical documentation set that has to satisfy both.

In practice that means:

• You extend your existing MDR/IVDR technical documentation to also cover the AI Act's high-risk requirements, rather than producing a standalone AI Act file. Our Annex IV technical-documentation guide shows what those elements look like.
• Your notified body, once it has been assessed for AI Act scope under the notification procedure (Article 43(3)), checks AI Act conformity inside the assessment it already runs on you. See notified bodies and AI medical devices for what to confirm with yours.
• Your quality system (ISO 13485) and risk management (ISO 14971) are the backbone you build the AI Act obligations onto, alongside the AI-specific ISO/IEC 42001. MDCG 2025-6 explicitly encourages integrating the AI-Act-specific elements into your existing MDR/IVDR quality management system.

Be precise about the wording: it is an integrated procedure, not "one merged certificate with nothing extra." You still have to satisfy the AI Act's substantive requirements, they are checked within your MDR/IVDR route instead of beside it. Integrated, not free.

Step 4: What the AI Act adds on top of MDR/IVDR

Most of the AI Act's high-risk requirements have a cousin in the MDR/IVDR world. The work is mapping what you already do to what the AI Act names, then closing the genuine gaps. Obligation by obligation:

• Risk management (Art 9): your ISO 14971 file is the backbone; extend it to AI-specific risks (data drift, feedback loops, foreseeable model misuse).
• Data and data governance (Art 10): training, validation and test data quality, representativeness, and bias examination, beyond typical clinical-evaluation framing. This is often the biggest genuine gap. Article 10(5) even carves a narrow, safeguard-heavy route to process special-category data for bias correction, see GDPR × AI Act × MDR for health data.
• Technical documentation (Art 11 and Annex IV): folded into your existing MDR/IVDR file, adding model architecture, training methodology, performance metrics and limitations.
• Logging and record-keeping (Art 12): automatic event logging over the lifecycle.
• Transparency and instructions for use (Art 13): AI-specific information to the deployer (capabilities, limitations, expected accuracy).
• Human oversight (Art 14): designed-in oversight, supported by your IEC 62366 usability work.
• Accuracy, robustness, cybersecurity (Art 15): declared performance and resilience, supported by IEC 62304.
• Quality management system (Art 17): largely satisfiable through ISO 13485 extended for AI, plus ISO/IEC 42001.

These sit alongside post-market monitoring (Art 72) and the declaration of conformity, CE marking and registration steps (Arts 47, 48, 49).

The point of a crosswalk is to show, obligation by obligation, what your MDR/IVDR plus ISO 13485/14971 evidence already covers and what is genuinely new, so you close the delta instead of rebuilding from zero. We built exactly that: the AI Act × MDR/IVDR crosswalk, a free obligation-by-obligation map with a printable Have / Partial / Gap column.

What being high-risk actually costs you

Two kinds of stakes. First, effort: the work above, done inside your MDR/IVDR route, not as a second system. Second, penalties. Under Article 99, non-compliance with the high-risk obligations (Articles 16, 26 and others) can draw fines of up to 15 million euro or 3% of worldwide annual turnover, whichever is higher. For comparison, prohibited practices carry up to 35 million euro or 7%, and supplying incorrect information to authorities up to 7.5 million euro or 1%. There is relief for smaller companies: for SMEs and start-ups, the fine is the lower of the euro amount or the percentage, not the higher. The point is not to alarm, it is that the high-risk classification is the difference between a bounded, integrated workstream and an open liability.

Common mistakes teams make

• "We use an LLM, so the model provider handles compliance." No. You are the provider of the high-risk system; the model provider only owes you documentation. See building medical AI on LLMs.
• "We will do the AI Act after CE marking." The AI Act check is part of the same conformity assessment (Article 43(3)); it is not a later, separate step.
• "Our tool performs a narrow task, so Article 6(3) exempts us." Article 6(3) only applies to the Annex III route, not to medical devices under 6(1).
• "High-risk under the AI Act means our MDR class goes up." It does not; the classifications are separate (MDCG 2025-6).
• "We are GDPR-compliant, so we are covered." The AI Act's data governance is a separate duty from GDPR lawfulness. Both apply.
• "Being classified high-risk is a failure." It is the expected outcome for most clinical AI, and it is a bounded, integrated workstream, not a catastrophe.

A note on timing (this part is moving)

The AI Act's high-risk obligations for products covered by Annex I, which includes medical devices, phase in on a longer timeline than the rest of the Act, and that timeline is currently in flux. The Digital Omnibus, presented by the European Commission on 19 November 2025, would move the application date for AI embedded in Annex I products (medical devices included) to 2 August 2028, narrow the "safety component" definition, and empower the Commission to limit AI Act requirements where the MDR/IVDR already imposes equivalent obligations, reducing duplication.

Because these dates and scope details are still moving through the legislative process, treat any specific deadline you read as provisional. The classification logic in this guide, Article 6(1) and 43(3), is the durable part; the exact application dates are the volatile part. We keep a continuously updated view in our AI Act deadlines after the Digital Omnibus tracker.

So, is my medical AI high-risk? Decision recap

1. Are you a medical device under the MDR or IVDR? (Turns on intended purpose.) If yes:
2. Does your risk class require a notified body? (MDR IIa+, or Is/Im/Ir; IVDR B/C/D or sterile A.) If yes → high-risk AI under Article 6(1). And no, Article 6(3) will not save you, it applies only to the Annex III route.
3. If high-risk, you do not run a separate AI Act audit, you extend your existing MDR/IVDR conformity assessment under Article 43(3).
4. Map obligation by obligation what you already have versus what the AI Act adds. Close the delta.

Want the fast version? Answer three questions with the interactive medical AI risk check and get your verdict plus the crosswalk. Or download the AI Act × MDR/IVDR crosswalk directly, or run the free assessment to classify your specific system and get a dated, cited compliance record. For the wider healthcare picture, see our AI Act for healthcare and medical devices guide.

Is all medical AI high-risk under the EU AI Act?

No. Medical AI is high-risk under Article 6(1) only when the device is, or is a safety component of, an MDR or IVDR device that requires a notified body. MDR Class IIa and above (and Class I sterile, measuring, or reusable surgical) and IVDR Class B, C, D and sterile Class A are caught. Basic self-certified MDR Class I and IVDR Class A are not high-risk via this route, though transparency duties under Article 50 may still apply.

Do I have to do a separate AI Act conformity assessment on top of the MDR?

No. Under Article 43(3), the AI Act's high-risk requirements are assessed inside your existing MDR or IVDR conformity assessment, one integrated procedure with one notified body. You extend your existing technical documentation to cover the AI Act requirements rather than running a second, standalone audit. You still have to satisfy the AI Act's substantive requirements; they are just checked within the MDR/IVDR route.

Does Software as a Medical Device (SaMD) count?

Yes. Your software can be the medical device itself, not just a component of hardware. If that SaMD is classified MDR Class IIa or higher (most diagnostic or therapy-driving SaMD is, under MDR Annex VIII Rule 11), or the IVDR equivalent, it triggers the notified-body requirement and is high-risk AI.

Can Article 6(3) exempt my medical AI as a "narrow task"?

No. Article 6(3) derogates only from Article 6(2), the Annex III use-case route. Medical devices are caught under Article 6(1), the product route, which the Article 6(3) exceptions do not touch. If a notified body is required, your medical AI is high-risk.

Is a general wellness or mindfulness app high-risk?

Usually not, because it typically has no medical intended purpose and so is not a medical device. But intended purpose governs: the moment the product makes a medical claim (to diagnose, treat or monitor a condition), it can re-qualify as a medical device and this whole analysis applies.

What does the AI Act add that the MDR and ISO 13485 do not already cover?

Mostly data governance (Article 10 training, validation and test data quality and bias examination), automatic lifecycle logging (Article 12), AI-specific transparency and human-oversight design (Articles 13 and 14), and declared accuracy and robustness (Article 15). Much of the quality-system requirement (Article 17) is satisfiable by extending ISO 13485, with ISO/IEC 42001 layered on top. MDCG 2025-6 encourages folding these into your existing MDR/IVDR quality management system.

What are the penalties for non-compliance?

Under Article 99, breaching the high-risk obligations can draw up to 15 million euro or 3% of worldwide annual turnover, whichever is higher. Prohibited practices carry up to 35 million euro or 7%, and incorrect information to authorities up to 7.5 million euro or 1%. For SMEs and start-ups, the fine is the lower of the euro amount or the percentage.

When do these obligations actually apply?

The high-risk obligations for medical devices phase in on a longer timeline than the rest of the Act, and the dates are being revised through the Digital Omnibus (which would move the application date for AI in Annex I products to 2 August 2028). Treat any specific deadline as provisional and build to the classification logic, which is stable, rather than to a fixed date, which is not.

Sources (official)

All legal claims above are drawn from the official texts and Commission guidance:

• EU AI Act, Regulation (EU) 2024/1689: official text on EUR-Lex; per-article on the European Commission AI Act Service Desk. Cited: Article 3 (definitions), Article 6 (classification, including 6(1) product route and 6(3) derogation from 6(2)), Article 43 (conformity assessment), Articles 10 to 17 (high-risk requirements), Articles 47 to 49 (declaration of conformity, CE marking, registration), Article 50 (transparency), Article 72 (post-market monitoring), Article 99 (penalties), Annex I, Annex IV.
• MDR, Regulation (EU) 2017/745 on medical devices: official text on EUR-Lex. Cited: Article 52 and 52(7) (conformity assessment; Class I sterile, measuring, reusable surgical), Annex VIII Rule 11 (software classification).
• IVDR, Regulation (EU) 2017/746 on in vitro diagnostic medical devices: official text on EUR-Lex. Cited: Article 48 (conformity assessment by class).
• MDCG 2025-6, Medical Device Coordination Group and European Artificial Intelligence Board, FAQ on the interplay between the MDR/IVDR and the AI Act (19 June 2025): Commission page · PDF.
• Digital Omnibus, European Commission proposal of 19 November 2025; Council and Parliament provisional agreement: Council press release, 7 May 2026. Provisional and not yet final.
• Industry position, MedTech Europe, with COCIR and DIGITALEUROPE, joint statement on one coherent framework for AI-enabled medical technologies (7 May 2026): MedTech Europe.

Legalithm provides compliance information and tooling, not legal advice. Classification depends on your specific intended purpose and device qualification; confirm with your notified body and qualified regulatory counsel. Article references are to Regulation (EU) 2024/1689 (the AI Act); device rules are the MDR (EU) 2017/745 and IVDR (EU) 2017/746.