NEWVenvera speaks your language: the full platform, in English, German, Spanish and Bulgarian.See what’s new →
EU AI Act for Healthcare: Which AI Must Comply
Learn

EU AI Act for Healthcare: Which AI Must Comply

·Alexander Sverdlov

What this article covers: How the EU AI Act applies to healthcare AI specifically, the two routes into high-risk classification for medical AI, which systems are high-risk and why, how the AI Act interacts with the Medical Device Regulation and IVDR, what the Digital Omnibus on AI changed about the deadlines, what hospitals must do as deployers, and the classification mistakes that recur in this sector.

Editorial illustration related to EU AI Act for healthcare: which medical and diagnostic AI systems must comply

Healthcare is one of the sectors where the EU AI Act lands hardest, and it is also where the most common compliance error shows up: assuming that a CE mark under the Medical Device Regulation already covers the AI Act. It does not. The MDR and IVDR assess the safety and clinical performance of a device. The EU AI Act imposes a separate set of obligations - data governance, transparency, human oversight, risk management, and technical documentation - that the medical device conformity process does not fully address. Passing one does not mean passing the other, and for most medical AI both apply at once.

Medical AI reaches high-risk status on two routes, and the route decides the deadline, the conformity assessment, and when a hospital's own duties start. The first route is the medical device route: AI that is, or is a safety component of, a product regulated under the MDR (2017/745) or IVDR (2017/746), which are listed in Annex I of the AI Act. The second is the standalone route: AI that is not a medical device but fits one of the specific high-risk use cases listed in Annex III. Diagnostic and imaging AI almost always travels the first route. The second route for healthcare is narrower than it is often described, and this article is precise about which systems actually fall inside it.

The deadlines moved - read this before you plan anything

The Digital Omnibus on AI, endorsed by the European Parliament on 16 June 2026 and adopted by the Council of the EU on 29 June 2026, postponed the high-risk deadlines. It takes legal effect once published in the Official Journal, which is expected shortly - so it is adopted but not yet in force, and it does not carry a regulation number until publication. Standalone high-risk systems under Annex III now apply from 2 December 2027 (moved from 2 August 2026). High-risk AI embedded in regulated products such as medical devices, under Annex I, now applies from 2 August 2028 (moved from 2 August 2027). The Article 50 transparency duties were not postponed and still start on 2 August 2026.

Jump to section

  1. The two routes for healthcare AI
  2. Route 1 - AI embedded in medical devices
  3. Route 2 - Standalone clinical AI under Annex III
  4. Which specific systems are high-risk
  5. How the AI Act and MDR interact
  6. What hospitals and clinics must do as deployers
  7. The compliance timeline for healthcare AI
  8. Classification mistakes specific to healthcare
TL;DR Most clinical AI is high-risk. Diagnostic, imaging and IVD AI is high-risk because it is a medical device regulated under the MDR or IVDR (Annex I, Article 6(1)) - deadline 2 August 2028 after the Digital Omnibus. A narrower set of standalone systems is high-risk under Annex III - public-authority eligibility decisions about healthcare services (point 5(a)) and emergency healthcare patient triage (point 5(d)) - deadline 2 December 2027. MDR conformity does not satisfy the AI Act, but for medical-device AI the two run through a single notified-body assessment. Article 50 transparency duties still start 2 August 2026. Hospitals have their own deployer duties on the same high-risk dates.

The Two Routes for Healthcare AI

Healthcare AI can reach high-risk status through either of the AI Act's two classification routes. Working out which route applies to a given system is the starting point for every other compliance decision, because the routes carry different conformity assessment procedures and different deadlines.

Route 1 - Article 6(1), Annex I

AI embedded in a CE-marked medical device

AI that is a safety component of, or is itself, a product regulated under the MDR (2017/745) or IVDR (2017/746) and required to undergo third-party conformity assessment. These regulations are listed in Annex I of the AI Act.

Deadline: 2 August 2028
Route 2 - Article 6(2), Annex III

Standalone clinical AI listed in Annex III

AI that is not a regulated medical device but fits a listed Annex III use case - for healthcare, public-authority decisions on eligibility for healthcare services (5(a)) or emergency healthcare patient triage (5(d)).

Deadline: 2 December 2027

After the Digital Omnibus, the two deadlines sit about eight months apart. Standalone Annex III clinical AI applies from 2 December 2027; AI embedded in CE-marked medical devices applies from 2 August 2028. Hospitals deploying either type carry deployer obligations from the same high-risk dates - not from an earlier one. The only healthcare AI duty that begins on 2 August 2026 is the Article 50 transparency obligation, which is separate from the high-risk regime.

Route 1 - AI Embedded in Medical Devices

Editorial pull quote for EU AI Act for healthcare: which medical and diagnostic AI systems must comply

Route 1 applies when an AI system is, or is a safety component of, a product regulated under EU medical device law and required to undergo third-party conformity assessment. In practice this covers almost all diagnostic, imaging and in-vitro diagnostic AI: it is CE-marked under the MDR or IVDR, and Article 6(1) of the AI Act makes it high-risk precisely because that third-party assessment is mandatory.

The MDR device classes - Class I through Class III - do not map onto the AI Act's high-risk test. The device class governs the conformity route under the MDR; the AI Act layers its own requirements on top and, for these systems, folds them into the same notified-body assessment (see the interaction section below). A Class I device whose AI performs a safety-relevant function can still be high-risk under Article 6(1) if that device is subject to third-party conformity assessment.

Medical AI example MDR/IVDR classification High-risk via Route 1?
AI analysing retinal images to detect diabetic retinopathy MDR Class IIa or IIb (diagnostic device) Yes
AI interpreting ECG signals to detect arrhythmias MDR Class IIa or III Yes
AI in an in-vitro diagnostic device interpreting blood test results IVDR Class B, C, or D Yes
AI controlling drug dosage in an infusion pump MDR Class IIb or III Yes
AI providing real-time navigation guidance during robotic surgery MDR Class III (active therapeutic device) Yes
AI generating a general-wellness exercise plan with no diagnostic claims Not a regulated medical device No (Route 1)
Software as a Medical Device (SaMD) Many clinical AI systems qualify as Software as a Medical Device under the MDR - standalone software intended for a medical purpose. SaMD with an AI component is regulated as a medical device and therefore takes Route 1 where it is subject to third-party conformity assessment. If your clinical AI software carries an MDR CE mark, it is a Route 1 system and its high-risk deadline is 2 August 2028.

Route 2 - Standalone Clinical AI Under Annex III

Diagram anchoring standalone healthcare AI to the specific Annex III high-risk use cases under the EU AI Act

Not all clinical AI is a regulated medical device, and the standalone route into high-risk is narrower than it is often presented. A system that is not a medical device becomes high-risk only if it fits one of the use cases explicitly listed in Annex III. For healthcare, two entries matter:

Annex III, point 5(a) - eligibility for healthcare services

AI used by, or on behalf of, public authorities to evaluate eligibility for essential public assistance benefits and services, including healthcare services, or to grant, reduce, revoke or reclaim them. This is a public-sector entitlement decision, not a clinical diagnosis.

Annex III, point 5(d) - emergency healthcare patient triage

AI used to evaluate and classify emergency calls, or to dispatch or set priority in dispatching emergency first response, and emergency healthcare patient triage systems.

There is no general "clinical AI", "diagnosis" or "clinical decision support" entry in Annex III. A standalone diagnostic or decision-support tool that is not a medical device, and that neither decides public-benefit eligibility nor performs emergency triage, may fall outside the high-risk tier entirely. That is exactly why the medical device route carries most diagnostic AI: if a tool influences a clinical decision to any material degree, it is almost always a medical device under the MDR, and it enters high-risk through Article 6(1) rather than Annex III.

Standalone Annex III health systems apply from 2 December 2027 and, unlike medical-device AI, they self-assess through the internal-control procedure under Article 43(2). Getting the route right therefore changes both the deadline and who signs off the conformity assessment.

Which Specific Healthcare AI Systems Are High-Risk

Compliance dashboard preview classifying healthcare AI systems by high-risk route under the EU AI Act

Working common healthcare AI use cases against the two routes produces the picture below. It is not exhaustive, but it covers the systems that generate the most classification questions in practice.

High-risk Diagnostic imaging AI

AI that analyses radiology images (X-ray, CT, MRI, PET), pathology slides, dermatology images or ophthalmology scans to detect or characterise disease. Almost always CE-marked as MDR SaMD - Route 1, high-risk under Article 6(1). Deadline 2 August 2028.

High-risk Clinical decision support (consequential)

AI that generates treatment recommendations, drug-dosing suggestions or differential diagnoses that a clinician acts on. Where the tool influences a clinical decision it is generally a medical device (SaMD), so it is high-risk via Route 1 - deadline 2 August 2028. A non-device tool is high-risk only if it fits an Annex III use case (public eligibility or emergency triage).

High-risk Emergency patient triage AI

AI used to score acuity and set treatment priority in emergency settings, or to triage emergency calls and dispatch first response. Named explicitly in Annex III point 5(d) - standalone high-risk, deadline 2 December 2027. Triage built into a CE-marked device instead follows Route 1 (2 August 2028).

High-risk Deterioration and readmission risk AI

Early-warning scores, sepsis prediction and readmission risk models. These are usually medical devices (SaMD) - Route 1, deadline 2 August 2028. A standalone risk model that is not a device is high-risk only where it fits a listed Annex III use case; general risk scoring is not automatically listed.

High-risk Surgical robot and intraoperative guidance AI

AI that controls, guides or provides real-time intraoperative assistance in surgical systems. MDR Class IIb or III device - Route 1, high-risk under Article 6(1). Deadline 2 August 2028.

High-risk In-vitro diagnostic AI

AI that is or is embedded in an in-vitro diagnostic device - interpreting genetic sequencing, analysing pathology samples, reading point-of-care results. Governed by the IVDR - Route 1, high-risk under Article 6(1). Deadline 2 August 2028.

The following use cases are more likely to fall outside the high-risk tier, though each case still needs its own assessment.

Likely not high-risk Administrative scheduling and capacity AI

AI that optimises appointment scheduling, bed management or staff rostering without influencing individual clinical decisions, and without deciding access to care at the individual patient level.

Likely not high-risk General wellness and fitness apps

AI in consumer apps making general health suggestions (step targets, sleep coaching, nutrition) that do not constitute medical advice and are not CE-marked medical devices.

Likely not high-risk Medical literature search and summarisation AI

AI that helps clinicians search or summarise literature without generating patient-specific recommendations - a research support tool, not a clinical decision system.

Likely not high-risk Clinical documentation AI

AI that transcribes, structures or summarises clinical notes without generating recommendations - though if the output feeds a system that does influence care, the chain of influence matters.

How the AI Act and MDR Interact

This is the question that trips up most medical device companies. The two regulations are complementary but not duplicative - compliance with one does not discharge the other, and the requirements do not fully overlap. Crucially, though, for medical-device AI the AI Act does not add a second, separate conformity assessment. Under Article 43(3) the AI Act requirements are folded into the existing MDR or IVDR notified-body assessment, so there is one assessment and one notified body, not two.

Venvera EU AI Act dashboard
An AI system inventory with risk classification under the EU AI Act.
Requirement area MDR/IVDR EU AI Act Overlap?
Clinical performance / safety Comprehensive Partial MDR is more comprehensive on clinical evidence; the AI Act adds accuracy and robustness requirements
Technical documentation Required Required Significant overlap, but the AI Act requires additional AI-specific content - training-data governance, model architecture, bias assessment
Risk management ISO 14971 Required ISO 14971 covers much of the AI Act requirement; AI-specific risks (bias, data drift) need additional work
Human oversight by design Partial (usability) Explicit requirement The AI Act oversight requirement is more specific than MDR usability - design must let a human understand, monitor and override the AI
Training data governance Limited Comprehensive The AI Act adds explicit requirements on training-data relevance, representativeness and bias that the MDR does not fully address
Post-market surveillance Required Required Strong overlap; MDR PMS can be extended to cover AI Act post-market monitoring with targeted additions
Registration database EUDAMED EU database Two separate registrations in two separate systems - EUDAMED for the MDR, the EU database for the AI Act. Not interchangeable.
Conformity assessment Notified Body (Class IIa+/IVD B+) Same Notified Body, via Art 43(3) Medical-device AI does NOT self-assess. The AI Act requirements are checked as part of the MDR/IVDR notified-body assessment - one integrated assessment. Only standalone Annex III health systems self-assess, under the internal-control procedure of Article 43(2).

The practical takeaway for medical device manufacturers: use existing MDR work as the foundation and identify what the AI Act adds. Training-data governance, the specific human-oversight design requirement, the EU database registration and the AI Act technical-documentation format are the areas most likely to need new work on top of MDR compliance - and they need to be ready for the same notified body that already handles your device.

What Hospitals and Clinics Must Do as Deployers

A hospital that buys and uses a clinical AI system is a deployer under the AI Act. The vendor being compliant as a provider does not remove the hospital's own obligations. Those deployer duties, set out in Article 26, apply from the system's high-risk application date - 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in medical devices. The one duty that starts earlier, on 2 August 2026, is the Article 50 transparency obligation to tell people when they are interacting with an AI system.

For healthcare deployers of high-risk systems, the obligations that apply from those dates include the following.

1

Implement genuine human oversight

Ensure that clinical staff who use AI outputs understand the system's limitations, know how to interpret and challenge its recommendations, and have the authority and practical ability to override them. This means a real governance framework, not just a sign-off policy - evidence that oversight is actually exercised.

2

Use the system only for its intended purpose

High-risk AI must be used in accordance with the provider's instructions. A hospital that applies a validated tool to an unvalidated context - for example, running a model on a patient population it was not tested on - may become a provider itself, acquiring the full provider obligation set.

3

Inform affected patients

Where a high-risk AI system is used to make or significantly assist a decision about an individual patient, that person must be informed. This Article 26 deployer duty tracks the high-risk application date for the system, and it sits alongside - not inside - the general Article 50 transparency duty that begins on 2 August 2026.

4

Monitor performance and report incidents

Deployers must monitor high-risk AI in operational use and report serious incidents to the provider and, where harm occurs, to market surveillance authorities. Healthcare deployers should fold AI incident reporting into their existing clinical incident management process.

5

Register in the EU database (public deployers)

Public authorities - including publicly funded hospitals - that deploy high-risk AI must register the deployment in the EU database before putting the system into service. Private providers are not subject to this specific duty but may need to cooperate with registration requests.

The Compliance Timeline for Healthcare AI

Date What applies Who is affected
1 Aug 2024 AI Act enters into force Start of the phased application timeline
2 Feb 2025 Prohibited AI practices and AI literacy obligations apply All healthcare organisations using any AI
2 Aug 2025 Rules for general-purpose AI models, the governance framework and penalties apply GPAI providers; national supervisory framework
2 Aug 2026 Article 50 transparency obligations apply - disclosing AI interaction and labelling AI-generated content. Not postponed by the Omnibus. All deployers and providers of in-scope AI
2 Dec 2027 High-risk obligations for standalone Annex III systems apply (moved from 2 Aug 2026 by the Digital Omnibus) Providers of standalone Annex III health AI; hospitals deploying it
2 Aug 2028 High-risk obligations for AI embedded in Annex I regulated products apply (moved from 2 Aug 2027) Medical device and IVD manufacturers with AI; hospitals deploying device-embedded AI
More time, but not a reason to wait The Digital Omnibus pushed the high-risk deadlines out by roughly a year each. That is real breathing room, but the underlying work has not shrunk. Building AI Act technical documentation, standing up training-data governance and coordinating a single conformity assessment across the MDR or IVDR and the AI Act is a substantial programme, and it has to be ready for the same notified body that certifies your device. The extra time reflects the practical state of standards and supervision, not a lighter obligation.

Classification Mistakes Specific to Healthcare

Assuming MDR CE-marking resolves AI Act compliance

CE-marking demonstrates MDR conformity. It is not, on its own, an AI Act conformity assessment. The AI Act requirements must still be met, though for medical-device AI they are assessed as part of the same notified-body process rather than in a separate exercise.

Planning against the pre-Omnibus dates

The Digital Omnibus moved the standalone high-risk deadline to 2 December 2027 and the device-embedded deadline to 2 August 2028. Plans and vendor contracts written against 2 August 2026 or 2 August 2027 now cite superseded dates. Prohibitions, GPAI rules and Article 50 transparency were not postponed.

Treating every standalone clinical tool as Annex III high-risk

Annex III does not list "diagnosis" or "clinical decision support" as such. A standalone, non-device tool is high-risk only if it decides public-benefit eligibility (5(a)) or performs emergency triage (5(d)). Over-classifying every clinical tool as Annex III creates burden without benefit - and usually the real trigger is the medical device route anyway.

Hospitals assuming the vendor handles all compliance

The vendor's compliance as a provider does not discharge the hospital's deployer obligations. Human oversight, patient notification, incident monitoring and - for public hospitals - EU database registration are deployer duties under Article 26 that cannot be contractually handed to the vendor.

Frequently Asked Questions

Did the Digital Omnibus change the deadlines for healthcare AI?

Yes. The Digital Omnibus on AI - endorsed by the European Parliament on 16 June 2026 and adopted by the Council of the EU on 29 June 2026 - postponed the high-risk deadlines. Standalone Annex III systems now apply from 2 December 2027 (was 2 August 2026) and AI embedded in regulated products such as medical devices from 2 August 2028 (was 2 August 2027). It takes effect once published in the Official Journal, expected shortly. Prohibited practices, general-purpose AI rules and the Article 50 transparency duties were not postponed; transparency still starts on 2 August 2026.

Does a Class I MDR device with an AI component fall under Route 1?

Only if it is subject to third-party conformity assessment. Article 6(1) makes AI high-risk when it is a safety component of, or is, an Annex I product that must undergo third-party conformity assessment. Many Class I devices self-certify under the MDR and so would not meet that second condition, whereas a Class I device that requires notified-body involvement, or whose AI performs a safety-relevant function bringing it into a higher class, can be Route 1 high-risk with a 2 August 2028 deadline.

Our hospital uses a US-developed clinical AI tool. Do we have AI Act obligations?

Yes. As an EU-established deployer of a high-risk AI system you have Article 26 deployer obligations regardless of where the vendor is based. The vendor should be compliant as a non-EU provider, including appointing an EU authorised representative for high-risk systems. If it is not, your procurement contract should address the gap, and you should assess whether continuing to use the system creates regulatory exposure for your organisation.

What does meaningful human oversight look like for diagnostic AI in practice?

It means the clinician reviewing an AI output genuinely understands what the system is telling them, can see its confidence level and known limitations, and makes an independent clinical judgement rather than rubber-stamping the output. Workflows where clinicians cannot realistically override the AI - due to time pressure, lack of training or institutional culture - do not amount to meaningful oversight even if a human step technically exists. Deployers are responsible for designing workflows that support genuine oversight, not just formal sign-off.

Can we reuse our MDR post-market surveillance for AI Act monitoring?

Yes, with targeted additions. Your MDR post-market surveillance already covers adverse-event reporting, systematic review of performance data and feedback integration. The gaps to close are AI-specific: monitoring for data drift (performance degrading as the input distribution shifts), bias monitoring across patient demographics, and the AI Act's serious-incident reporting channel to market surveillance authorities, which is distinct from MDR vigilance reporting to the medical device authority.

Managing EU AI Act compliance alongside the MDR and IVDR?

Venvera is purpose-built for European regulated entities navigating overlapping obligations - with EU data residency, structured gap assessment, and documentation tooling built for the regulatory environment you actually operate in.

Learn more at Venvera.com

Primary sources

Written by the Venvera compliance team. Venvera is a purpose-built compliance platform for European regulated entities. This article reflects the EU AI Act as amended by the Digital Omnibus on AI (adopted by the Council of the EU on 29 June 2026, entering into force on publication in the Official Journal) and the regulatory position as of July 2026. It is provided for information only and does not constitute legal advice. Last updated: July 2026.

Alexander Sverdlov

Alexander Sverdlov

CEO & Founder

Alexander is the founder of Venvera and a 20+ year veteran of European cybersecurity and compliance. He has led security and risk programmes for regulated financial institutions, fintechs and SaaS companies operating under DORA, NIS2, GDPR, ISO 27001 and the EU AI Act. Before Venvera, he founded Atlant Security, an offensive security consultancy that ran penetration tests, red-team exercises and ISO 27001 readiness programmes for clients across the EU and the Middle East. He writes on the cross-framework realities of running modern compliance: how to map one control to many obligations, where the spreadsheets fall apart, and what regulators are actually asking for once the auditor sits down.

More articles by Alexander

RELATED POSTS