Healthcare AI in Europe doesn't sit within a single regulatory framework. It sits within three simultaneously, each with its own authority, its own compliance obligations, and its own enforcement mechanisms. A clinical AI tool that supports diagnostic decisions may need CE marking as a medical device, must handle patient data in accordance with the General Data Protection Regulation (GDPR), and is likely to be classified as high-risk under the EU AI Act. These frameworks don't apply sequentially. They apply in parallel, and they interact in ways that aren't always straightforward. For healthcare organisations evaluating or deploying AI, understanding this regulatory landscape is a prerequisite for responsible procurement and safe clinical use.

The three regulatory pillars every healthcare AI company must understand

Three distinct EU frameworks govern clinical AI deployment, each with a different primary concern.

The EU Medical Device Regulation (MDR) 2017/745 governs safety and performance. Its focus is on whether a product, including software, is safe for its intended clinical purpose and whether it has been validated to perform as claimed.

GDPR governs privacy. Its focus is on how personal data, particularly health data, is collected, processed, stored, and shared, and on ensuring individuals retain meaningful rights over their information.

The EU AI Act (Regulation (EU) 2024/1689, in force since 1 August 2024) governs systemic risk. Its focus is on whether AI systems are transparent, accountable, and subject to adequate human oversight, particularly where those systems affect fundamental rights or safety-critical decisions.

As a joint FAQ from the Medical Device Coordination Group (MDCG) and the EU AI Board (MDCG 2025-6) confirmed in 2025, AI systems qualifying as medical devices must comply with both MDR/IVDR and the AI Act simultaneously. Compliance with one framework doesn't substitute for compliance with another.

When healthcare AI qualifies as a medical device under MDR

Under MDR 2017/745, the central question is whether a software tool has a medical intended purpose. That is, whether its manufacturer intends it for use in diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. Software meeting this definition is classified as Software as a Medical Device (SaMD) and must comply with the full MDR regime.

Intended purpose is the determining factor. A documentation tool that transcribes clinical notes without interpreting or influencing clinical decisions sits in a different regulatory position from an AI system that flags abnormal findings, suggests diagnoses, or prioritises patient triage. The latter is far more likely to be classified as SaMD.

Where a tool is classified as a medical device, the manufacturer must:

• Conduct a conformity assessment appropriate to the device's risk classification (Class I through III)

• Produce and maintain comprehensive technical documentation

• Implement a quality management system (QMS)

• Obtain CE marking before placing the device on the EU market

• Maintain post-market surveillance and report serious incidents

Analysis from King & Spalding of the MDCG 2025-6 guidance identifies five key operational areas where MDR and AI Act obligations converge: management systems, data governance, technical documentation, transparency and human oversight, and cybersecurity and accuracy. Manufacturers should treat these as integrated requirements rather than parallel checklists.

One practical complication is the shortage of designated Notified Bodies, the independent conformity assessment organisations required for higher-risk device classifications. Baker McKenzie has noted that this bottleneck, combined with a significant gap in harmonised standards for AI-specific risks such as algorithmic bias and model drift, creates real delays for manufacturers seeking market access.

GDPR and clinical AI: what counts as special category data and why it matters

Health data processed by AI systems is classified as special category data under Article 9 of GDPR, attracting the highest level of protection available under EU data protection law. This classification applies regardless of whether the AI system is the primary data controller or a downstream processor. The nature of the data, not the role of the processor, determines the classification.

For clinical AI deployments, this has several direct implications.

Lawful basis. Processing special category health data requires both a lawful basis under Article 6 and an additional condition under Article 9. In clinical contexts, the most commonly applicable Article 9 conditions are: processing necessary for medical diagnosis or the provision of healthcare (Article 9(2)(h)), processing for reasons of public interest in public health (Article 9(2)(i)), and, where neither applies, explicit consent (Article 9(2)(a)). Consent is rarely the most appropriate basis in clinical settings, given the inherent power imbalance between patients and healthcare providers.

Data minimisation and purpose limitation. AI systems must process only the data necessary for their specified purpose, and that data can't be repurposed without a fresh lawful basis. This creates particular tension where vendors wish to use clinical data for model training or improvement, a use that is typically distinct from the original clinical purpose.

Data subject rights. Patients retain rights of access, rectification, and in certain circumstances erasure, even where their data has been processed by AI systems. Healthcare organisations must be able to respond to these requests in relation to data held or processed by third-party AI vendors.

A review of privacy and governance frameworks for AI-powered healthcare devices highlighted that GDPR compliance in AI-enabled clinical settings requires not only technical controls but ongoing governance structures, including data protection impact assessments (DPIAs), records of processing activities, and clearly defined data processor agreements.

Data residency and cross-border data flows in EU healthcare AI

GDPR imposes strict restrictions on the transfer of personal data outside the European Economic Area (EEA). For clinical AI vendors, this means that where patient data is processed or stored on infrastructure located outside the EEA, including on cloud platforms hosted in the US or elsewhere, specific transfer mechanisms must be in place.

The primary mechanisms are:

• Adequacy decisions, where the European Commission has determined that a third country provides an equivalent level of data protection (currently covering a limited number of jurisdictions)

• Standard Contractual Clauses (SCCs), which impose contractual obligations on both the data exporter and importer

• Binding Corporate Rules (BCRs), used primarily within multinational corporate groups

For healthcare organisations, the practical question is not simply whether a vendor has signed SCCs, but where data is actually processed and stored. Data residency within the EU means that patient data is processed and stored on infrastructure physically located within the EEA. This eliminates the need for cross-border transfer mechanisms and simplifies GDPR compliance considerably. Healthcare organisations should require vendors to specify this in contractual documentation.

A comparative policy analysis of cybersecurity regulation in digital health across the US, EU, and India noted that the EU's approach to data sovereignty in healthcare is significantly more prescriptive than other jurisdictions, a factor that affects how global AI vendors architect their products for European markets.

How the EU AI Act classifies healthcare AI and what high-risk means in practice

The EU AI Act establishes a risk-based classification system with four tiers: unacceptable risk (prohibited), high-risk, limited risk, and minimal risk. Most clinical AI tools, including diagnostic support systems, triage tools, and clinical documentation assistants that influence care pathways, are likely to fall within the high-risk category.

Under Article 6(1) and Annex I of the AI Act, AI systems that are themselves regulated as medical devices under MDR or IVDR are automatically classified as high-risk AI systems. CE-marked SaMD is therefore subject to both MDR conformity requirements and the full high-risk AI Act compliance regime.

Hunton Andrews Kurth's analysis of the AI Act's application to medical devices sets out the key obligations for high-risk AI systems:

• Technical documentation: Detailed records of system design, training data, validation methodology, and known limitations

• Risk management: An ongoing risk management system covering AI-specific risks, including algorithmic bias and model drift

• Data governance: Requirements around training, validation, and testing datasets, including bias detection and data quality controls

• Transparency and instructions for use: Clear documentation so deployers and users can understand the system's capabilities and limitations

• Human oversight: Technical and organisational measures ensuring that humans can effectively monitor, override, and intervene in AI outputs

• Conformity assessment: Formal assessment before market placement, with ongoing post-market monitoring

• Registration: High-risk AI systems must be registered in the EU database for AI systems

The AI Act also introduces AI literacy obligations, effective from February 2025, requiring providers and deployers to ensure that staff working with AI systems have sufficient understanding of the technology's capabilities and limitations. Taylor Wessing notes that this obligation applies to healthcare organisations deploying AI tools, not only to the vendors supplying them.

Where MDR, GDPR, and the AI Act overlap and where they conflict

The three frameworks share several common threads. All require transparency about how a system works, what data it uses, and what its limitations are. All require documented risk management. All impose post-market or ongoing monitoring obligations. Where MDR requires post-market surveillance and the AI Act requires post-market monitoring, these obligations can, in principle, be addressed through a unified process.

A peer-reviewed analysis published in 2025 examining the regulatory nexus between the AI Act and MDR/IVDR confirmed that the QMS required under MDR can serve as a foundation for AI Act compliance, and that technical documentation requirements under both frameworks can be integrated rather than duplicated. Article 8 of the AI Act explicitly contemplates this integration for AI medical devices.

Genuine tensions exist, however.

Data retention vs. data minimisation. The AI Act encourages, and in some cases requires, retention of training data, validation datasets, and logs for audit and accountability purposes. GDPR's data minimisation and storage limitation principles push in the opposite direction. Vendors must navigate this tension explicitly, typically through purpose-specific retention schedules and anonymisation where feasible.

Transparency vs. commercial confidentiality. Both the AI Act and GDPR require meaningful transparency about how AI systems process data and reach outputs. In practice, vendors may resist disclosing proprietary model architectures. The frameworks don't fully resolve this tension.

Algorithmic bias and GDPR's fairness principle. GDPR requires that automated processing be fair, but doesn't specify how fairness should be measured in AI systems. The AI Act introduces more specific data governance requirements around bias detection, but academic commentary has noted that neither framework provides definitive methodological guidance for healthcare AI developers.

The regulatory landscape is itself in flux. Two competing EU legislative proposals, the Digital Omnibus (led by DG CONNECT) and the DG SANTE MDR/IVDR amendment, are both seeking to simplify the AI Act/MDR overlap. Analysis from the Petrie-Flom Center at Harvard Law School raises concerns that simplification efforts could inadvertently weaken human oversight safeguards, particularly for clinicians and patients. The outcome of these proposals remains uncertain as of mid-2026.

Who is accountable under each framework: the vendor, the hospital, or both?

Regulatory responsibility under the three frameworks is distributed rather than singular, and the allocation differs depending on which framework applies.

Under MDR, the primary obligation falls on the manufacturer, typically the AI vendor. The manufacturer is responsible for conformity assessment, CE marking, technical documentation, and post-market surveillance. A healthcare organisation that deploys a CE-marked SaMD without modification is generally acting as an operator rather than a manufacturer, with more limited obligations.

Under GDPR, the allocation depends on who determines the purposes and means of processing. A healthcare organisation that deploys an AI system to process patient records is typically the data controller, bearing primary responsibility for lawful basis, patient rights, and DPIA obligations. The AI vendor, processing data on the organisation's behalf, is typically the data processor, bound by a data processing agreement (DPA) specifying the scope and conditions of processing.

Under the EU AI Act, a distinction is drawn between providers (those who develop or place AI systems on the market) and deployers (those who use AI systems in a professional context). Providers bear the primary compliance burden for high-risk AI systems, covering technical documentation, conformity assessment, and registration. Deployers carry their own obligations: implementing human oversight measures, ensuring AI literacy among staff, monitoring system performance in use, and suspending use where safety concerns arise.

White & Case's analysis of the post-AI Liability Directive landscape, following the withdrawal of that directive in February 2025, confirms that the revised Product Liability Directive now forms part of the liability framework for AI-powered medical devices, with implications for both manufacturers and deployers where harm results from a defective AI system.

A hospital deploying a clinical AI tool can't assume that regulatory compliance is entirely the vendor's responsibility. Contractual clarity about roles, obligations, and liability allocation is essential before deployment.

What healthcare organisations should ask AI vendors before deployment

Procurement teams and clinical leads evaluating AI tools for clinical deployment should seek clear, documented answers to the following questions.

On MDR and medical device status:

• Is this product classified as a medical device under EU MDR 2017/745?

• If yes, what is its risk classification, and has CE marking been obtained?

• Can you provide the Declaration of Conformity and summary of safety and clinical performance?

• How is post-market surveillance conducted, and how are incidents reported?

On GDPR and data processing:

• Where is patient data processed and stored? Is EU data residency guaranteed?

• Will you sign a Data Processing Agreement compliant with GDPR Article 28?

• Is a Data Protection Impact Assessment available for review?

• Is patient data used for model training or improvement? If so, on what lawful basis?

• How are data subject rights (access, erasure, rectification) handled?

On the EU AI Act:

• Is this system classified as a high-risk AI system under the EU AI Act?

• What conformity assessment has been completed, or is planned, under the AI Act?

• What technical documentation is available covering training data, validation, and known limitations?

• What human oversight mechanisms are built into the system?

• Is the system registered in the EU AI systems database?

On security and audit:

• Does the organisation hold ISO 27001 certification, and is it current?

• What audit trail capabilities does the system provide?

• How are cybersecurity vulnerabilities identified and addressed post-deployment?

On AI literacy:

• What training or documentation is provided to support AI literacy obligations under the AI Act?

Incomplete or evasive answers to these questions should be treated as a significant procurement risk signal.

How the regulatory landscape is evolving: what to watch through 2026 and beyond

The EU AI Act entered into force in August 2024, but its obligations apply on a phased timeline. Key milestones include:

• February 2025: Prohibitions on unacceptable-risk AI systems apply; AI literacy obligations for providers and deployers take effect

• August 2026: High-risk AI system obligations under Chapter III apply in full, including those for AI medical devices under Annex I

• August 2027: Full applicability across all remaining provisions

The MDX CRO compliance guide notes that transitional provisions exist for AI systems already lawfully on the market before August 2026, but these provisions are time-limited and don't exempt manufacturers from eventual full compliance.

Two further developments warrant close attention.

The European Health Data Space (EHDS) Regulation entered into force on 26 March 2025. The EHDS creates a framework for the secondary use of health data, including for AI development and research, across EU member states. The European Commission's official guidance on AI in healthcare identifies the EHDS as a key enabler of responsible clinical AI development, but its interaction with GDPR's purpose limitation principle will require ongoing clarification as implementation proceeds.

Competing simplification proposals, the Digital Omnibus and the DG SANTE MDR/IVDR amendment, are both seeking to reduce the compliance burden at the MDR/AI Act intersection. As Harvard Law School's Petrie-Flom Center has observed, the outcome of these proposals could significantly alter the compliance landscape for clinical AI, either by streamlining dual conformity requirements or, if human oversight provisions are weakened, by creating new patient safety risks.

Uncertainty about the legality of AI use in specific clinical contexts remains a genuine challenge for healthcare providers, even where frameworks exist. Regulatory compliance in clinical AI isn't a one-time procurement checkbox. It requires ongoing monitoring of a regulatory environment that continues to develop, and a governance structure capable of responding as obligations evolve.

Frequently asked questions

▶ Which regulatory frameworks apply to clinical AI in Europe?

Three EU frameworks apply simultaneously to clinical AI. The Medical Device Regulation (MDR) 2017/745 governs safety and performance. The General Data Protection Regulation (GDPR) governs how patient data is collected, processed, and stored. The EU AI Act (Regulation (EU) 2024/1689), in force since 1 August 2024, governs transparency, accountability, and human oversight. A joint FAQ from the Medical Device Coordination Group and the EU AI Board confirmed in 2025 that compliance with one framework doesn't substitute for compliance with another.

▶ When does a clinical AI tool qualify as a medical device under EU MDR?

A clinical AI tool qualifies as a medical device when its manufacturer intends it for use in diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. Software meeting this definition is classified as Software as a Medical Device (SaMD). A documentation tool that transcribes clinical notes without influencing clinical decisions sits in a different regulatory position from an AI system that flags abnormal findings or prioritises patient triage. The latter is far more likely to be classified as SaMD and must obtain CE marking before being placed on the EU market.

▶ How does GDPR apply to health data processed by AI systems?

Health data processed by AI systems is classified as special category data under Article 9 of GDPR, attracting the highest level of protection available under EU data protection law. Processing it requires both a lawful basis under Article 6 and an additional condition under Article 9. In clinical contexts, the most commonly applicable conditions are processing necessary for medical diagnosis or the provision of healthcare, and processing for reasons of public interest in public health. AI systems must also apply data minimisation, meaning they can only process data necessary for their specified purpose, and that data can't be repurposed without a fresh lawful basis.

▶ What does EU data residency mean for clinical AI vendors?

Data residency within the EU means that patient data is processed and stored on infrastructure physically located within the European Economic Area (EEA). GDPR imposes strict restrictions on transferring personal data outside the EEA, so where a vendor processes data on infrastructure located in the US or elsewhere, specific transfer mechanisms must be in place, such as Standard Contractual Clauses. EU data residency eliminates the need for these mechanisms and simplifies GDPR compliance considerably. Healthcare organisations should require vendors to specify data residency arrangements in contractual documentation.

▶ How does the EU AI Act classify healthcare AI tools?

The EU AI Act establishes a risk-based classification system with four tiers: unacceptable risk (prohibited), high-risk, limited risk, and minimal risk. Most clinical AI tools, including diagnostic support systems, triage tools, and clinical documentation assistants that influence care pathways, are likely to fall within the high-risk category. Under Article 6(1) and Annex I of the AI Act, AI systems regulated as medical devices under MDR are automatically classified as high-risk AI systems, making them subject to both MDR conformity requirements and the full high-risk AI Act compliance regime.

▶ Where do MDR, GDPR, and the EU AI Act overlap or conflict?

All three frameworks require transparency, documented risk management, and ongoing monitoring obligations. A peer-reviewed analysis published in 2025 confirmed that the quality management system required under MDR can serve as a foundation for AI Act compliance, and that technical documentation requirements under both frameworks can be integrated rather than duplicated. Genuine tensions exist, however. The AI Act encourages retention of training data and logs for audit purposes, while GDPR's data minimisation and storage limitation principles push in the opposite direction. Vendors must navigate this tension explicitly, typically through purpose-specific retention schedules and anonymisation where feasible.

▶ Who is responsible for regulatory compliance: the AI vendor or the healthcare organisation?

Responsibility is distributed across all three frameworks, and the allocation differs depending on which framework applies. Under MDR, the primary obligation falls on the manufacturer, typically the AI vendor, who is responsible for CE marking, technical documentation, and post-market surveillance. Under GDPR, the healthcare organisation deploying the AI system is typically the data controller, bearing primary responsibility for lawful basis and patient rights, while the vendor acts as a data processor. Under the EU AI Act, vendors as providers carry the main compliance burden for high-risk AI systems, but deploying organisations carry their own obligations, including implementing human oversight and ensuring staff AI literacy. A hospital deploying a clinical AI tool can't assume that regulatory compliance is entirely the vendor's responsibility.

▶ What questions should healthcare organisations ask AI vendors before deployment?

Procurement teams should ask vendors to confirm whether the product holds CE marking as a medical device and what its risk classification is. On data protection, they should ask where patient data is processed and stored, whether EU data residency is guaranteed, and whether patient data is used for model training and on what lawful basis. On the EU AI Act, they should ask whether the system is classified as high-risk, what conformity assessment has been completed, and what human oversight mechanisms are built in. On security, they should ask whether the vendor holds current ISO 27001 certification. Incomplete or evasive answers should be treated as a significant procurement risk signal.

▶ When do EU AI Act obligations for high-risk clinical AI systems take full effect?

The EU AI Act entered into force on 1 August 2024, but its obligations apply on a phased timeline. Prohibitions on unacceptable-risk AI systems and AI literacy obligations for providers and deployers took effect in February 2025. High-risk AI system obligations under Chapter III, including those for AI medical devices, apply in full from August 2026. Full applicability across all remaining provisions follows in August 2027. Transitional provisions exist for AI systems already lawfully on the market before August 2026, but these are time-limited and don't exempt manufacturers from eventual full compliance.

▶ What is the European Health Data Space and how does it affect clinical AI?

The European Health Data Space (EHDS) Regulation entered into force on 26 March 2025. It creates a framework for the secondary use of health data, including for AI development and research, across EU member states. The European Commission identifies the EHDS as a key enabler of responsible clinical AI development. Its interaction with GDPR's purpose limitation principle, which restricts data from being repurposed without a fresh lawful basis, will require ongoing clarification as implementation proceeds.