EU AI Act Compliance for Healthcare AI: A Complete Guide

Healthcare AI Faces a Dual Regulatory Burden

If you build AI for clinical settings, you carry one of the heaviest regulatory loads under the EU AI Act. And honestly, that makes sense. When a system helps diagnose disease, recommend a treatment, triage a patient, or run a clinical workflow, it touches patient safety and fundamental rights directly. European legislators saw that plainly. So they classified most healthcare AI as high-risk and put the full weight of the regulation behind it.

Here is the part that catches teams off guard. The AI Act does not stand alone. You also have to comply with the Medical Devices Regulation (MDR, Regulation 2017/745) at the same time, and for some products the In Vitro Diagnostic Medical Devices Regulation (IVDR, Regulation 2017/746) as well. Two frameworks, one product, both live at once. That is a steeper climb than almost any other sector faces.

The full set of high-risk obligations switches on August 2, 2026. This guide walks you through exactly what your healthcare AI company needs to do, where the AI Act meets the MDR, and the practical steps that actually get you to compliance.

How Healthcare AI Is Classified Under the AI Act

There are two doors into high-risk classification for healthcare AI, and which one applies depends on what your system actually is. Most clinical systems walk through one of them. Some walk through both.

Pathway 1: Annex II: AI as a Safety Component of a Medical Device

Annex II, Section A of the AI Act lists EU harmonisation legislation that triggers high-risk classification when an AI system serves as a safety component of a product covered by that legislation, or when the AI system is itself such a product. The Medical Devices Regulation (2017/745) and the In Vitro Diagnostic Medical Devices Regulation (2017/746) are both explicitly listed in Annex II.

So here is the practical takeaway. Any AI system that is a medical device, or a safety component of one, lands in high-risk automatically under the AI Act, as long as it needs a third-party conformity assessment under the MDR or IVDR.

Examples include:

• AI-powered diagnostic imaging systems (radiology AI, pathology AI, dermatology screening)
• AI-driven clinical decision support software that qualifies as a medical device under the MDR
• AI systems embedded in medical devices (such as AI algorithms in patient monitors, ventilators, or surgical robots)
• AI-based in vitro diagnostic tools (genetic analysis, laboratory result interpretation)

Pathway 2: Annex III: Standalone High-Risk AI in Healthcare

Annex III, point 5(c) classifies AI systems intended to be used to evaluate the readiness of first responders as high-risk. More broadly, Annex III, point 5(a) classifies AI systems intended to be used as safety components in the management and operation of critical infrastructure, which can encompass healthcare infrastructure in certain interpretations.

Annex III has one more hook. Any AI system used to assess eligibility for public healthcare services or that influences access to healthcare falls under Annex III, point 5(b) (access to essential public services).

Put it all together and the result is blunt. Nearly every AI system running in a clinical setting, device or not, lands as high-risk under at least one of these pathways.

For a complete overview of how risk classification works, see our EU AI Act Risk Assessment Guide.

The MDR and AI Act Overlap: What You Need to Understand

Few parts of healthcare AI compliance trip teams up more than the overlap between the AI Act and the MDR. People assume they get to pick one. They do not. These are not alternative frameworks. They apply at the same time, to the same product.

Conformity Assessment Coordination

Under Article 43(3) of the AI Act, for high-risk AI systems that are medical devices or safety components of medical devices, the AI Act conformity assessment is integrated into the existing MDR conformity assessment procedure. This means:

• The notified body that conducts your MDR conformity assessment will also assess compliance with the AI Act requirements
• You do not conduct two separate conformity assessments; the AI Act requirements are evaluated as part of the MDR assessment
• Even so, you must still meet all the substantive requirements of both regulations

The point of folding the two together is to cut regulatory burden. In practice, though, it means your MDR notified body has to be competent to assess AI-specific requirements, and that is a capability gap some notified bodies are still working to close.

Where the Two Frameworks Diverge

The conformity assessment may be integrated, but several AI Act requirements reach past what the MDR asks for. This is where the extra work hides:

Requirement	MDR	AI Act
Risk management system	Required (ISO 14971)	Required (Article 9), with specific AI risks
Clinical evaluation	Required	Not specifically required, but performance testing is
Data governance	General requirements	Detailed requirements (Article 10): bias detection, representativeness
Transparency	Labelling and IFU	Extended transparency (Article 13): interpretability of AI outputs
Human oversight	Implied through IFU	Explicit requirement (Article 14): override capability
Post-market surveillance	Required (MDR Article 83)	Required (Article 72): AI-specific monitoring
Fundamental rights impact	Not required	Required for certain deployers (Article 27)

Quality Management Systems

Both the MDR and the AI Act require quality management systems (QMS). Under Article 17 of the AI Act, providers of high-risk AI systems must establish a QMS that includes policies and procedures for regulatory compliance, design and development processes, testing and validation, data management, and post-market monitoring. Good news if you already run an MDR-compliant QMS aligned with ISO 13485: you can extend it to take on the AI Act-specific elements instead of standing up a parallel system from scratch.

Provider Obligations for Healthcare AI

If you provide a healthcare AI system, you owe the full set of high-risk requirements in Chapter 2 of Title III (Articles 8-21). That list can read like abstract legalese. So here is what each obligation actually means once you put it in a clinical context.

Risk Management (Article 9)

Your risk management system must address AI-specific risks that the MDR's ISO 14971-based approach may not fully capture. These include:

• Algorithmic bias: Does your diagnostic AI perform differently across patient demographics (age, sex, ethnicity, body composition)? Clinical studies have documented significant performance disparities in dermatology AI, radiology AI, and other diagnostic tools
• Distribution shift: Medical imaging equipment varies across facilities. Lab values have different reference ranges across populations. Your risk management must account for performance degradation when the system encounters data that differs from its training distribution
• Automation bias: Clinicians may over-rely on AI recommendations, reducing their independent clinical judgement. Your risk management system must assess this risk and define mitigation measures
• Cascading errors: In clinical workflows, an erroneous AI recommendation can propagate through subsequent clinical decisions. Your risk assessment must map these dependency chains

Data Governance (Article 10)

This is where healthcare AI gets held to a higher bar than most. The Article 10 data governance requirements are demanding on purpose. You must ensure:

• Training data representativeness: Your training datasets must be sufficiently representative of the patient populations for whom the system is intended. A diagnostic AI trained predominantly on data from one ethnic group will not meet this standard if the system is marketed for use across diverse populations
• Bias examination: You must systematically examine training, validation, and testing data for biases that could affect patient safety or lead to discrimination. For healthcare AI, this includes examining performance across demographic subgroups
• Data quality controls: The data used to train clinical AI must meet standards of accuracy, completeness, and relevance. This includes ensuring that ground truth labels (e.g., pathology-confirmed diagnoses used to train imaging AI) are reliable
• Special categories of personal data: Under Article 10(5), providers of high-risk AI systems may process special categories of personal data (including health data) to the extent strictly necessary for bias detection and correction, subject to appropriate safeguards. This provision is critical for healthcare AI providers who need access to demographic data to conduct bias audits

Technical Documentation (Article 11)

Your technical documentation must cover all elements specified in Annex IV, including:

• A detailed description of the AI system's intended purpose and the clinical contexts in which it is designed to operate
• The design specifications of the system, including its architecture, computational resources, and development methodology
• A description of the training, validation, and testing processes, including the data used, the metrics applied, and the results achieved
• Information about the system's performance across relevant patient subgroups
• The risk management measures adopted and their rationale

If your system is also a medical device, this documentation has to line up with the MDR technical documentation requirements. Our advice: build one integrated technical file that answers both frameworks at once. It saves you maintaining two sets of paperwork that drift apart over time.

Transparency and Instructions for Use (Article 13)

Healthcare AI transparency obligations require you to provide deployers (hospitals, clinics, healthcare systems) with:

• Clear information about the system's intended clinical purpose and any limitations on its use
• The level of accuracy, sensitivity, specificity, and other relevant performance metrics, broken down by clinically relevant subgroups where appropriate
• Known circumstances that may adversely affect the system's performance (e.g., image quality requirements, patient populations for which the system has not been validated)
• Human oversight measures, including when and how a clinician should review or override the system's outputs
• Input data specifications, including image format requirements, minimum resolution, and data preprocessing steps

Human Oversight (Article 14)

A clinician has to stay in the loop, and the system has to make that possible by design. For clinical AI, that means:

• Clinicians must be able to understand the system's outputs well enough to make informed decisions about whether to follow or override them
• The system must include mechanisms that allow clinicians to override, reverse, or disregard the AI's outputs
• Where the AI system operates in a time-critical context (such as emergency triage), the human oversight design must balance the need for rapid decision-making with meaningful clinical review

Post-Market Monitoring (Article 72)

Providers must establish post-market monitoring systems that actively and systematically collect, document, and analyse relevant data about the performance of their AI systems throughout their lifetime. For healthcare AI, this includes:

• Monitoring clinical outcomes associated with the system's recommendations
• Tracking performance metrics across facilities and patient populations
• Detecting algorithmic drift, meaning gradual degradation in system performance as real-world data distributions shift over time
• Documenting and reporting serious incidents to national competent authorities under Article 62

This obligation lines up with the MDR's post-market surveillance requirements, with the AI-specific monitoring stacked on top.

Deployer Obligations for Healthcare Organisations

The obligations do not stop with the people who build the system. If you run a hospital, a clinic, or a wider healthcare system and you deploy AI tools, you carry your own set of duties under Article 26.

Appropriate Use and Oversight

Healthcare deployers must:

• Use AI systems in accordance with the provider's instructions for use
• Assign human oversight to clinicians with appropriate competence, training, and authority
• Ensure that input data is relevant and sufficiently representative of the patient population being served
• Monitor the AI system for risks and report any serious incidents to the provider and relevant authorities

Fundamental Rights Impact Assessment (Article 27)

Public healthcare bodies that deploy high-risk AI systems must conduct a fundamental rights impact assessment before putting the system into use. This assessment must evaluate:

• The impact on patients' rights to health, non-discrimination, and privacy
• The risks of the system producing biased or inequitable clinical recommendations across patient groups
• The measures in place to address identified risks, including clinical governance protocols and patient complaint mechanisms

Informing Patients (Article 50)

Under the AI Act's transparency obligations, patients must be informed when they are subject to decisions made or significantly influenced by an AI system. For healthcare deployers, this means implementing clear communication processes (in intake forms, patient portals, and clinical consultations) that disclose the role of AI in their care.

Practical Compliance Roadmap for Healthcare AI

Enough theory. Here is the sequence we would run if this were our product on the line, broken into four phases that build on each other.

Phase 1: Inventory and Classification (Now)

1. Map all AI systems in use or under development across your clinical and operational workflows
2. Determine classification under both the AI Act (Annex II vs. Annex III) and the MDR (device class)
3. Identify your role (provider, deployer, or both) for each system
4. Assess notified body readiness: confirm that your MDR notified body has the competence to assess AI Act requirements

Use our EU AI Act Compliance Checklist to structure this initial assessment.

Phase 2: Gap Analysis and Planning (Q1-Q2 2026)

5. Conduct gap analysis comparing current MDR compliance artefacts against AI Act requirements
6. Extend your QMS to incorporate AI Act-specific elements (data governance, bias monitoring, human oversight protocols)
7. Audit training data for representativeness, bias, and quality
8. Plan conformity assessment updates with your notified body

Phase 3: Implementation (Q2-Q3 2026)

9. Update technical documentation to address all Annex IV requirements
10. Implement or enhance bias detection and monitoring across patient demographics
11. Develop transparency materials for both deployers and patients
12. Train clinical staff on human oversight responsibilities and AI system limitations
13. Establish post-market monitoring systems with AI-specific performance metrics

Phase 4: Validation and Deployment (Before August 2, 2026)

14. Complete conformity assessment through your MDR notified body, incorporating AI Act requirements
15. Conduct fundamental rights impact assessments for public healthcare deployments
16. Test incident reporting procedures to ensure readiness for Article 62 obligations
17. Document everything. Thorough documentation is your primary defence in any regulatory inquiry

Penalties and Market Access Risks

Get the high-risk requirements wrong and the AI Act allows administrative fines of up to 15 million EUR or 3% of worldwide annual turnover, whichever is higher. For healthcare AI companies, though, the market access fallout can hurt more than the fine. A non-compliant system can be pulled from the EU market, and a provider can be barred from placing new products until it proves compliance.

The EU is one of the largest healthcare markets on earth. Losing access to it is a strategic risk that dwarfs the cheque you would write for a penalty. For more on how enforcement actually works, see our guide on EU AI Act Fines and Enforcement.

The Strategic Opportunity in Compliance

Yes, healthcare AI compliance is expensive and demanding. We will not pretend otherwise. But flip it around and it becomes an edge. Hospitals and health systems are increasingly buying on the strength of regulatory compliance and proof that the AI can be trusted. Get to full AI Act compliance early and you are the easy yes in a procurement meeting: better placed to win contracts, earn clinical trust, and scale across the EU.

The companies that treat compliance as a core product quality, not a box to tick under protest, are the ones that will lead the next generation of healthcare AI.

To understand which AI practices are banned outright under the AI Act (including certain biometric categorisation systems that may be relevant in healthcare contexts), see our guide on EU AI Act Prohibited Practices.

For a comparative review of compliance management tools, see Best EU AI Act Compliance Tools Compared.

Start Your Free Compliance Assessment

Healthcare AI regulation is a lot, but the route through it is clear. Start now, work the phases in order, and build the processes and documentation that hold up long after August 2026. We built AI Comply HQ to walk you through every one of those requirements, so you are not piecing the map together alone.

Update: Where the Digital Omnibus Stands (June 12, 2026)

A quick note before you act on any date in this article. The Digital Omnibus is a simplification package the European Commission proposed on November 19, 2025. It would amend several EU digital laws at once, and for the AI Act it proposes two big changes: the high-risk obligations would apply later (December 2, 2027 for the stand-alone high-risk systems listed in Annex III, and August 2, 2028 for high-risk AI embedded in regulated products), and a number of requirements would be simplified along the way.

Here is the part that matters: none of this is law yet. The European Parliament and the Council reached a provisional agreement on May 7, 2026, and formal adoption is expected, but until the final text is adopted and published, nothing changes. The dates and obligations described in this article are the ones in force today. And the rules that already apply, like the prohibited practices and the AI literacy duty, stay exactly where they are no matter what happens to the Omnibus.

We are watching this closely. The moment the Omnibus is adopted, amended, or rejected, we will update this article to reflect the new EU AI compliance dates. Check back, or run the free 90-second risk check to see your obligations under the rules as they stand right now.