8
min read
EU healthcare AI regulations: MDR, GDPR and AI Act
Navigate EU regulations for clinical AI. Understand MDR medical device requirements, GDPR data protection, and AI Act compliance obligations for healthcare organisations

Healthcare AI in Europe doesn't sit within a single regulatory framework. It sits within three simultaneously, each with its own authority, compliance obligations, and enforcement mechanism. A clinical AI tool that supports diagnostic decisions may need CE marking as a medical device, must handle patient data under the General Data Protection Regulation (GDPR), and is likely to be classified as high-risk under the EU AI Act.
These frameworks apply in parallel, not sequentially, and they interact in ways that aren't always straightforward. For healthcare organisations evaluating or deploying AI, understanding this landscape is a prerequisite for responsible procurement, as we've covered in more depth on the EU AI Act specifically.
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 Medical Device Regulation (MDR) 2017/745 governs safety and performance: whether a product, including software, is safe for its intended clinical purpose and validated to perform as claimed. GDPR governs privacy: how personal data, particularly health data, is collected, processed, and shared, and how individuals retain rights over it. The EU AI Act (Regulation (EU) 2024/1689, in force since 1 August 2024) governs systemic risk: whether AI systems are transparent, accountable, and subject to adequate human oversight.
The Medical Device Coordination Group and the European AI Board's joint MDCG 2025-6 guidance, published by the European Commission in June 2025, confirmed that AI systems qualifying as medical devices must comply with both the MDR/IVDR and the AI Act simultaneously. Compliance with one doesn't substitute for the other.
When healthcare AI qualifies as a medical device under MDR
The central question under MDR is whether a software tool has a medical intended purpose: diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. Software meeting this definition is 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 decisions sits in a different position from one that flags abnormal findings or prioritises triage, which 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
The MDCG 2025-6 guidance itself identifies five 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 a shortage of Notified Bodies competent to assess AI systems under both frameworks at once. Osborne Clarke's analysis of the Commission's Digital Omnibus proposal notes this bottleneck directly, and that the proposal responds to it by letting conformity assessment bodies apply once for designation under both the AI Act and the MDR or IVDR, rather than through two separate processes.
GDPR and clinical AI: what counts as special category data
Health data processed by AI systems is special category data under GDPR Article 9, attracting the highest level of protection available. This applies regardless of whether the AI system is the primary controller or a downstream processor.
Processing special category health data requires both a lawful basis under Article 6 and an additional condition under Article 9, most commonly processing necessary for medical diagnosis or healthcare provision, or public interest in public health. Consent is rarely the most appropriate basis in clinical settings, given the inherent power imbalance between patients and providers.
AI systems must also process only the data necessary for their specified purpose, which creates tension where vendors want to reuse clinical data for model training, a use distinct from the original clinical purpose. Patients retain rights of access, rectification, and in some cases erasure, and healthcare organisations must be able to respond to these requests even where a third-party AI vendor is processing the data. The Information Commissioner's Office publishes detailed guidance on applying data protection law to AI systems, including when a data protection impact assessment is required.
Data residency and cross-border data flows in EU healthcare AI
GDPR restricts transferring personal data outside the European Economic Area. Where patient data is processed on infrastructure outside the EEA, transfer mechanisms such as an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules must be in place.
For healthcare organisations, the practical question isn't just whether a vendor has signed SCCs, but where data is actually processed. EU data residency removes the need for cross-border transfer mechanisms entirely and simplifies compliance considerably. Healthcare organisations should require vendors to specify this in contractual documentation.
How the EU AI Act classifies healthcare AI and what high-risk means in practice
The AI Act sets four risk tiers: unacceptable (prohibited), high, limited, and minimal. Most clinical AI tools, including diagnostic support, triage tools, and documentation assistants that influence care pathways, fall into the high-risk category. Under Article 6(1) and Annex I, AI systems already regulated as medical devices under MDR or IVDR are automatically high-risk AI systems, so CE-marked SaMD faces both regimes at once.
Bird & Bird's analysis of the Commission's draft high-risk AI guidelines sets out the practical obligations this triggers: detailed technical documentation covering design, training data, and known limitations; an ongoing risk management system addressing AI-specific risks such as bias and model drift; data governance controls over training and validation datasets; clear instructions for use; human oversight mechanisms; formal conformity assessment; and registration in the EU database for AI systems.
The Act also introduces an AI literacy obligation, effective since February 2025. Taylor Wessing's analysis is clear that this applies to deployers, meaning healthcare organisations using AI tools, not only the vendors supplying them, and that organisations should ensure staff have the training and authorisation to supervise high-risk AI in practice, not just on paper.
Where MDR, GDPR, and the AI Act overlap and where they conflict
All three frameworks require transparency about how a system works, documented risk management, and ongoing monitoring.
A peer-reviewed compliance-by-design framework published in Frontiers in Digital Health confirms that a quality management system built for MDR can serve as a foundation for AI Act compliance, and that technical documentation under both frameworks can be integrated rather than duplicated. Article 8 of the AI Act explicitly contemplates this.
Genuine tensions remain, though. The AI Act encourages retaining training data, validation datasets, and logs for audit purposes, while GDPR's data minimisation principle pushes the other way; vendors typically navigate this through purpose-specific retention schedules and anonymisation. Both frameworks also require meaningful transparency about how systems reach outputs, while vendors may resist disclosing proprietary architecture, and neither framework fully resolves that tension.
The regulatory landscape is also in flux. Two proposals, the Digital Omnibus (DG CONNECT) and a parallel MDR/IVDR amendment (DG SANTE), both aim to simplify the AI Act/MDR overlap, but not without controversy. The Jacques Delors Centre has warned that because these changes are being advanced through a fast-track "omnibus" process, they lack the comprehensive impact assessment normally expected, which is particularly risky where they could weaken fundamental rights safeguards.
In healthcare specifically, the Standing Committee of European Doctors has called for a cautious approach, arguing some proposed changes could weaken privacy protections and make it easier to process sensitive patient data for AI development. The outcome remains uncertain.
Who is accountable under each framework: the vendor, the hospital, or both?
Responsibility is distributed, and the allocation differs by framework. Under MDR, the primary obligation falls on the manufacturer, typically the AI vendor, for conformity assessment, CE marking, and post-market surveillance. A healthcare organisation deploying a CE-marked SaMD unmodified is generally an operator with more limited obligations.
Under GDPR, whoever determines the purposes and means of processing is the controller, which for a healthcare organisation deploying an AI system to process patient records is usually itself, bearing primary responsibility for lawful basis and patient rights. The vendor, processing data on the organisation's behalf, is typically the processor, bound by a data processing agreement.
Under the AI Act, providers bear the primary compliance burden for high-risk systems, while deployers carry their own obligations: human oversight, AI literacy, performance monitoring, and suspending use where safety concerns arise. Bird & Bird's analysis of healthcare AI liability notes that, following the European Commission's 2025 withdrawal of the proposed AI Liability Directive, the revised Product Liability Directive now carries much of the liability weight for AI-powered medical devices, and it applies to both manufacturers and, in some cases, deployers where harm results from a defective system.
A hospital can't assume compliance is entirely the vendor's responsibility; contractual clarity about roles and liability 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.
High-risk AI system obligations apply in full from August 2026, with AI medical devices getting until August 2027. The European Health Data Space, in force since March 2025, creates a framework for the secondary use of health data, including for AI development, and the European Commission identifies it as a key enabler of responsible clinical AI, though its interaction with GDPR's purpose limitation principle will need ongoing clarification.
Regulatory compliance in clinical AI isn't a one-time procurement checkbox, as we've noted when covering Tandem's own AI Scribe certification. It requires ongoing monitoring of a regulatory environment that's still developing, and a governance structure capable of responding as the rules themselves change.
Frequently asked questions
▶ Which regulatory frameworks apply to clinical AI in Europe?
Three, simultaneously: the MDR for safety and performance, GDPR for patient data, and the EU AI Act for transparency and human oversight. The European Commission's MDCG 2025-6 guidance confirms compliance with one doesn't substitute for another.
▶ When does a clinical AI tool qualify as a medical device under EU MDR?
When its manufacturer intends it for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or disease management. A transcription tool that doesn't influence decisions sits differently from one that flags abnormal findings or prioritises triage, which is far more likely to need CE marking as Software as a Medical Device.
▶ How does GDPR apply to health data processed by AI systems?
Health data is special category data under Article 9, requiring both a lawful basis and an additional condition, most often necessity for healthcare provision or public health. AI systems must also apply data minimisation: only the data needed for the stated purpose, with no repurposing without a fresh lawful basis.
▶ What does EU data residency mean for clinical AI vendors?
Data processed and stored on infrastructure physically inside the EEA. This removes the need for transfer mechanisms like Standard Contractual Clauses that apply when data sits outside it, so it's worth requiring vendors to specify this in contracts rather than just asking whether SCCs are in place.
▶ How does the EU AI Act classify healthcare AI tools?
Four tiers, from unacceptable to minimal risk. Most clinical AI, including diagnostic support and triage tools, falls into high-risk. Under Article 6(1) and Annex I, any AI system already regulated as a medical device under MDR is automatically high-risk too, so CE-marked SaMD faces both regimes at once.
▶ Where do MDR, GDPR, and the EU AI Act overlap or conflict?
They share transparency and monitoring requirements, and research published in Frontiers in Digital Health confirms an MDR quality management system can underpin AI Act compliance rather than duplicate it. But genuine tension remains: the AI Act pushes toward retaining data and logs for audit purposes, while GDPR's minimisation principle pushes the other way. Vendors typically resolve this with purpose-specific retention schedules and anonymisation.
▶ Who is responsible for regulatory compliance: the AI vendor or the healthcare organisation?
Both, depending on the framework. The vendor is usually the MDR manufacturer and the GDPR processor; the healthcare organisation is usually the GDPR controller. Under the AI Act, vendors carry the main burden as providers, but deploying organisations have their own obligations too, including human oversight and staff AI literacy. No hospital can treat compliance as entirely the vendor's problem.
▶ What questions should healthcare organisations ask AI vendors before deployment?
Whether the product holds CE marking and what risk class it's in; where patient data is processed and stored, and whether EU residency is guaranteed; whether patient data trains the model and on what legal basis; whether the AI Act classifies it as high-risk and what conformity assessment exists; what human oversight is built in; and whether ISO 27001 certification is current. Vague or evasive answers are a procurement red flag in themselves.
▶ When do EU AI Act obligations for high-risk clinical AI systems take full effect?
Prohibitions and AI literacy obligations applied from February 2025. Chapter III high-risk obligations, including for AI medical devices, apply in full from August 2026, with full applicability across all remaining provisions by August 2027. Transitional provisions for systems already on the market are time-limited, not exemptions.
▶ What is the European Health Data Space and how does it affect clinical AI?
In force since March 2025, it creates an EU-wide framework for the secondary use of health data, including for AI development. The European Commission treats it as a key enabler of responsible clinical AI, though how it interacts with GDPR's purpose limitation principle is still being worked out.