EU AI Act for Healthcare AI and Medical Devices

Healthcare AI sits at the intersection of two demanding EU regulatory frameworks, and the EU AI Act does not soften that. A diagnostic imaging system, an emergency-triage algorithm, a health-insurance underwriting tool — each triggers a different entry point into the high-risk regime under Regulation (EU) 2024/1689. Getting the classification right matters early, because the compliance work that follows — risk management, clinical validation, technical documentation, conformity assessment — takes months to build properly.

This guide covers how healthcare AI is classified under the Act, the two distinct routes to high-risk status, how obligations interact with the Medical Devices Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR), and what MedTech companies and hospitals need to do before the applicable deadlines.

---

Two Routes to High-Risk: Article 6(1) and Annex III

The EU AI Act reaches healthcare AI through two separate mechanisms. The route determines your deadline, your conformity assessment procedure, and how you interact with your notified body.

Route 1 — Article 6(1) and Annex I: AI Embedded in Regulated Medical Devices

Article 6(1) classifies an AI system as high-risk if it is a medical device, or a safety component of a medical device, regulated under MDR (Regulation (EU) 2017/745) or IVDR (Regulation (EU) 2017/746), and the device already requires a third-party conformity assessment under those instruments.

That last condition is the hinge. Not every medical device needs a notified body — Class I devices under MDR can largely self-certify. It is when a notified body is already involved — Class IIa, IIb, and III devices under MDR; Class B, C, and D devices under IVDR — that Article 6(1) activates automatically.

The practical effect is significant: the EU AI Act requirements are integrated into the existing MDR/IVDR conformity assessment. There is no separate AI Act certification process running in parallel. The notified body that already assesses your device also assesses the AI Act obligations, a "one-stop shop" designed to avoid double assessment. Recital 53 of the Act acknowledges the burden that duplicated procedures would place on MedTech companies, and Article 6(1) is the structural answer.

Deadline: 2 August 2028. Under the Digital Omnibus agreed in May 2026, the Annex I product-embedded systems deadline was moved from the original 2 August 2026 to 2 August 2028.

Examples of Article 6(1) systems:

• An AI model that automatically segments tumours in CT images, integrated into a Class IIb imaging device — the AI is a safety component; the device requires notified-body assessment under MDR; Article 6(1) applies.
• A software-as-a-medical-device (SaMD) product that analyses retinal scans to detect diabetic retinopathy, CE-marked under MDR Class IIa — same logic applies if the classification requires notified-body involvement.
• An algorithm embedded in an in-vitro diagnostic analyser (Class C under IVDR) that interprets assay results — IVDR notified-body assessment is required; Article 6(1) activates.

Route 2 — Annex III: Stand-Alone AI Systems in Health-Related Use Cases

The second route runs through Annex III, the list of eight high-risk use-case categories that the Act designates directly. Two are relevant to healthcare:

Annex III, point 5 — Access to essential private and public services. This includes AI used in emergency-care dispatch and triage, and AI used to determine eligibility for health insurance or set health/life insurance risk and pricing. An AI system that routes emergency calls, decides which ambulance unit responds, or helps determine whether a patient is prioritised for urgent admission at a hospital falls here. So does software that processes patient health data to score insurability or calculate premium risk.

Annex III, point 1 — Biometrics. Emotion-recognition AI used in healthcare contexts — for example, systems that analyse patient facial expressions to assess pain levels or mental state — falls under this category where permitted by Article 50.

The standard high-risk regime applies for Annex III systems: providers must run their own conformity assessment (Article 43 — either internal control under Annex VI or notified-body audit under Annex VII), and the full Article 9–15 obligation stack applies.

Deadline: 2 December 2027. Stand-alone high-risk Annex III systems must comply from 2 December 2027 under the Digital Omnibus.

Note that Article 6(3) provides a filter: an Annex III system is not high-risk if it poses no significant risk of harm to health, safety, or fundamental rights — for instance, a tool that performs a narrow preparatory task or improves a result of an already-completed human activity without replacing human judgment. In healthcare, the scope for invoking Article 6(3) is narrow. Any system that profiles natural persons is always high-risk regardless of this filter.

---

The MDR/IVDR Integration in Practice

For Article 6(1) systems, the integration of AI Act requirements into MDR/IVDR conformity assessment has concrete implications for how you plan the work.

Your notified body will assess AI Act compliance alongside MDR/IVDR. That means the technical file you build for your notified body — structured under Annex II MDR or equivalent IVDR provisions — must now also address the EU AI Act requirements. Think of it as one technical file, two regulatory lenses.

Specifically, the AI Act's Article 11 and Annex IV technical documentation requirements map onto (but do not replace) the MDR technical file. You will need to add:

• Description of the AI system's design logic, training data characteristics, and intended purpose as defined under the EU AI Act (Article 3(12))
• The risk management system documentation required by Article 9 — distinct from the MDR risk management process under ISO 14971, but capable of being run alongside it
• Data governance documentation under Article 10: where training data originated, how representativeness across patient subgroups was assessed, what bias testing was performed
• Human oversight measures under Article 14 and how they are implemented in the clinical workflow
• Post-market monitoring plan under Article 72, coordinated with the MDR post-market surveillance plan already required under MDR Article 83

MDR post-market surveillance and EU AI Act Article 72 monitoring are complementary, not duplicative. Both require tracking real-world performance, adverse events, and performance drift. In practice, you can build a single monitoring framework that satisfies both, provided the AI-specific triggers — model drift, training distribution shift, fairness degradation — are explicitly addressed alongside the conventional device vigilance requirements under MDR Articles 87–92 and Article 73 of the EU AI Act.

---

The Obligation Stack for High-Risk Healthcare AI

Whether you arrive through Article 6(1) or Annex III, the core high-risk obligations under Articles 9–15 apply. Here is what each requires, and how it lands in a clinical context.

Risk Management System — Article 9

A documented, ongoing risk management system that runs throughout the system's lifecycle. Not a one-time assessment: the regulation explicitly requires continuous review as the system operates in deployment.

For healthcare AI, the risk management process must address AI-specific failure modes that differ from conventional software risks: training distribution shift (the model was validated on data from academic hospitals but is deployed in community clinics), algorithmic bias (performance degrades for older patients or minority ethnic groups), and adversarial fragility (subtle image modifications that fool the model while appearing normal to a radiologist). Standard ISO 14971 risk management covers device hazards; Article 9 adds the AI layer on top.

Data and Data Governance — Article 10

Training, validation, and testing datasets must be relevant, representative, and sufficiently large to avoid bias. For healthcare AI, this directly implicates GDPR Article 9 — health data is special-category personal data, requiring a lawful basis (typically Article 9(2)(j) for scientific research, or explicit consent under Article 9(2)(a)) and appropriate technical and organisational safeguards.

Article 10 requires you to document representativeness across patient populations. A diagnostic imaging model validated exclusively on data from one country's hospital network may perform poorly on patients from different ethnic backgrounds, age groups, or equipment configurations. Article 10(3) explicitly requires that datasets cover characteristics relevant to the intended geographic, contextual, and behavioural population. For medical devices, this intersects with clinical validation under MDR Annex XIV — the clinical evidence must demonstrate performance across the intended population, which means the training and validation datasets must reflect that population.

Technical Documentation — Article 11 and Annex IV

The Article 11 technical file must describe the system's intended purpose, design logic, training data, validation results, known limitations, risk management report, and post-market monitoring plan. For Article 6(1) systems, this file is incorporated into the notified body's review.

Human Oversight — Article 14

Providers must design AI systems to allow qualified persons to understand outputs, monitor performance, and intervene when necessary. Deployers — hospitals and clinics — must implement the oversight measures the provider specifies, and must assign specific individuals with the necessary competence to do so.

In practice, Article 14 means that a radiologist reviewing AI-flagged findings cannot be placed in a workflow where the AI's output is structurally difficult to question. The system must indicate its confidence level, flag anomalous or out-of-distribution inputs, and enable the clinician to override without friction. Human oversight is the clinician's right as a matter of regulation, not merely good practice.

Deployers bear real obligations here. A hospital that purchases a diagnostic imaging AI from a vendor (the provider) is a deployer under Article 26. The hospital must implement the human oversight measures the vendor specifies in the instructions, train staff accordingly, monitor for unexpected outcomes, and report serious incidents under Article 73.

Accuracy, Robustness, and Cybersecurity — Article 15

The system must achieve the accuracy levels declared in the technical documentation across relevant patient groups, be resilient to errors and inconsistencies in input data, and be protected against adversarial manipulation. For medical devices, this overlaps substantially with MDR Annex I's general safety and performance requirements — but Article 15 adds cybersecurity expectations that MDR does not fully address, especially for AI systems that communicate over networks or receive model updates remotely.

Post-Market Monitoring — Article 72

Providers must establish and maintain a post-market monitoring plan, collect and analyse data from deployment, and take corrective action if performance degrades. Serious incidents — in healthcare, this may mean a missed diagnosis that contributed to patient harm — must be reported under Article 73 to the market surveillance authority of the relevant member state.

Article 72 monitoring runs alongside MDR vigilance. A vendor of an MDR-regulated AI system will already have a Post-Market Surveillance (PMS) plan and Periodic Safety Update Report (PSUR) obligations under MDR Articles 83–86. The AI Act adds AI-specific performance tracking: per-demographic accuracy reporting, drift detection thresholds, and documentation of any retraining or model updates. Coordinating these two monitoring streams from the outset saves considerable rework.

---

Provider and Deployer Obligations: A Diagnostic Imaging Example

Take a Berlin-based MedTech company — the provider — that develops a CE-marked AI system for mammography screening, classified as a Class IIb device under MDR. The system flags potential malignancies and assigns a probability score that radiologists review before issuing a report.

The system is an AI safety component of a regulated device requiring notified-body assessment: Article 6(1) applies, deadline 2 August 2028.

The provider's obligations include: building the Article 9 risk management system; compiling the Article 11 / Annex IV technical documentation for notified-body review; ensuring training data under Article 10 covers diverse patient populations, imaging equipment types, and screening protocols across the EU; designing human oversight measures (Article 14) — confidence indicators, out-of-distribution flags, clear override pathways; and maintaining post-market monitoring under Article 72 alongside the MDR PMS.

The hospitals that purchase and deploy the system are deployers under Article 26. Each hospital must: implement the human oversight measures in the vendor's instructions of use; ensure radiologists receive adequate training on the system's capabilities and documented limitations; monitor performance in their specific patient population and imaging environment; and report any serious incident under Article 73 where the system's output may have contributed to patient harm.

If a hospital significantly modifies the system — for example, retraining it on local data without the vendor's involvement — Article 25 may shift provider obligations onto the hospital. That is a risk few clinical institutions are prepared for.

---

What MedTech Companies Should Do Now

Both deadlines are reachable, but neither is generous when you factor in the work involved.

For Article 6(1) systems (deadline 2 August 2028): Start with your MDR notified body. Confirm they are prepared to assess AI Act compliance as part of the Article 43 conformity assessment. Some notified bodies are further along in developing AI Act assessment competence than others — this is worth investigating now rather than in 2027. Audit your existing technical file against Annex IV of the EU AI Act and identify the gaps: AI-specific risk management documentation, training data representativeness evidence, Article 10 data governance records. Begin aligning your MDR PMS plan with Article 72 requirements.

For Annex III systems (deadline 2 December 2027): The conformity assessment is your responsibility to run (Article 43), without the MDR/IVDR integration mechanism. Build the Article 9 risk management system first — it is the foundation everything else rests on. Assess your training data for Article 10 representativeness. Design Article 14 human oversight measures and confirm they are implemented in clinical workflows, not just documented in a manual. Register the system in the EU database under Article 49 once the EU database is operational.

For both: GDPR Article 9 health-data compliance is not optional infrastructure — it is a prerequisite. Confirm your lawful basis for using health data in training and validation, and ensure your data processing agreements with hospitals and data suppliers cover the Article 10 data governance requirements.

The fine for non-compliance with high-risk obligations is up to €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). For SMEs and start-ups, Article 99(6) caps the fine at the lower of the two figures. That is meaningful protection, but it does not make non-compliance cheap — and market access restrictions are the more immediate commercial risk.

---

How Confir Helps

Classifying a healthcare AI system under the EU AI Act involves layered questions: Is it a medical device? Does it require a notified body under MDR/IVDR? Which Annex III category applies? Does the Article 6(3) filter apply? Confir's rule-based classification engine runs through these questions systematically — same intake, same deterministic finding, with the applicable article cited for every conclusion.

Once classification is confirmed, Confir structures the assessment across the four compliance areas: AIRC (risk classification under Articles 5, 6, 43), AITR (data and technical robustness under Articles 10, 11, 15), AITO (transparency and human oversight under Articles 13, 14, 27), and AIGM (governance and post-market monitoring under Articles 9, 72, 73). The cross-map to MDR's corresponding obligations is surfaced where relevant, so you can see which AI Act requirement is already partially addressed by your MDR documentation and where the genuine gaps are.

The output is a print-ready Article 11 / Annex IV technical documentation pack and the Article 47 EU Declaration of Conformity — structured for submission to your notified body or retained for internal control.

---

Frequently Asked Questions

Does a clinical decision support tool always qualify as high-risk under the EU AI Act?

Not automatically. The classification depends on the tool's function and the Article 6(3) filter. An AI that provides reference ranges to a clinician but does not influence a diagnosis or treatment decision, and does not profile patients, may not be high-risk. An AI that flags urgency levels in an emergency triage workflow — directly influencing which patients receive faster care — almost certainly falls under Annex III, point 5. The honest answer is that "clinical decision support" is a broad category, and classification requires case-by-case analysis against Annex III and the Article 6(3) criteria.

How does the EU AI Act interact with GDPR for healthcare AI?

They interact at Article 10 of the EU AI Act (data governance) and Article 9 of GDPR (special-category data). Health data is special-category; you need a lawful basis under GDPR Article 9(2) to use it for training and validation — typically scientific or public-interest grounds, or explicit consent. The EU AI Act does not override GDPR; it adds a separate layer requiring representativeness and bias documentation. Your data processing agreements must address both frameworks.

Who is the "provider" for a hospital-built AI diagnostic tool used only internally?

If a hospital develops an AI system and puts it into service under its own name — even for internal use — it is a provider under Article 3(3) and bears the full provider obligations under Article 16. The Act does not limit provider status to companies that sell to third parties. A large academic hospital building its own sepsis-prediction model and running it in the ICU is a provider. Article 25 may also be relevant if the hospital significantly modifies a third-party system.

What does "representative training data" mean under Article 10 for a medical AI?

Article 10(3) requires that datasets cover characteristics relevant to the intended geographic, contextual, and behavioural population, with attention to known biases. For a diagnostic AI intended for EU-wide deployment, training data should reflect demographic diversity (age, sex, ethnicity), clinical diversity (disease severity, comorbidities), and equipment diversity (different scanner manufacturers and configurations). A model trained exclusively on data from one reference hospital in one country and deployed across a pan-EU hospital network has a documented Article 10 problem.

Can a hospital invoke Article 6(3) to avoid high-risk classification for an AI triage tool?

Rarely, and it requires rigorous documentation. Article 6(3) requires the provider (or deployer acting as provider) to demonstrate that the system poses no significant risk of harm to health, safety, or fundamental rights. A triage tool that allocates limited emergency resources influences patient outcomes in a direct and material way; regulators will scrutinise any Article 6(3) claim carefully. If the system profiles natural persons — ranking patients by urgency level — it is always high-risk and the filter does not apply.

What is the difference between Article 72 post-market monitoring and MDR post-market surveillance?

Article 72 of the EU AI Act and Articles 83–86 of MDR both require ongoing performance monitoring after deployment, but they focus on different failure modes. MDR surveillance addresses conventional device safety: adverse events, device malfunctions, material failures. Article 72 adds AI-specific monitoring: model performance drift, demographic bias emergence, training-distribution shift, and any deterioration in accuracy not captured by conventional device safety criteria. For Article 6(1) systems, both apply and can be run through a single coordinated monitoring programme.

What are the penalties for non-compliance in healthcare AI?

Article 99(4) sets the ceiling at €15 million or 3% of total worldwide annual turnover, whichever is higher, for non-compliance with high-risk obligations. For SMEs and start-ups, Article 99(6) caps the fine at the lower of the two figures. National market surveillance authorities can also restrict or prohibit deployment of non-compliant systems — for a MedTech company with a CE-marked product, that is a more immediate risk than the fine ceiling.

---

Related guides

• Article 6 high-risk classification
• risk classification levels guide
• 2026 compliance checklist
• Article 9 risk management system
• AI risk assessment methodology
• EU AI Act explained