The EU AI Act for Medical Devices: Intersections and Practical Compliance
By Vaclav Vlcek, MD
The AI Act rarely applies on its own. A medical device that falls under it is almost always under the MDR or IVDR already, it processes personal data governed by the GDPR, and if it sells into the United States it answers to the FDA as well.
[Part 2] covered the Act's own requirements. This part covers where those requirements meet the other regimes, and how a manufacturer runs one compliance effort across all of them.
Summary
For an AI-enabled medical device, the EU AI Act sits alongside the MDR or IVDR, the GDPR, and, for global products, the U.S. FDA framework. The GDPR governs whether data may be used; the Act governs whether it is good enough to use, so a dataset has to clear both bars.
A Fundamental Rights Impact Assessment under Article 27 can be required on top of a GDPR Data Protection Impact Assessment. The Act and the FDA framework share a risk-based structure but diverge on fundamental rights, registration, and change management. The practical path starts with classification and role, then a gap assessment against what the manufacturer already does.
How the AI Act and GDPR Intersect
When an AI-enabled medical device processes personal data, two regulations apply at once. The GDPR governs whether the data may be used; the AI Act governs whether the data is good enough to use. A manufacturer has to satisfy both, and the two do not always pull in the same direction.
Data Governance
The starting point is data quality. Article 10 of the AI Act requires that the data used to train, validate, and test a high-risk system be relevant, representative, and as free of errors and bias as possible.
The GDPR comes at the same data from a different angle: under Articles 5 and 6 it must be processed lawfully, fairly, and on a valid legal basis such as consent or public interest.
A dataset therefore has to clear two separate bars before it can be used. Take a tool that predicts type 2 diabetes risk from health records, lifestyle questionnaires, and genetic data.
The genetic and health data need a lawful basis under Article 6 and an exception under Article 9(2) before they can be touched at all; only then does Article 10 ask whether the data is representative enough to give a fair result.
Data can be lawful to hold and still fall short of what Article 10 needs.
Data Minimization
Here the two regimes pull against each other. The AI Act leans toward broad, representative datasets, because that is how a high-risk system avoids skewed results across different patient groups (Article 10). The GDPR leans the other way, limiting collection to what is necessary for the stated purpose under its data-minimization principle (Article 5(1)(c)).
A hospital-readmission model shows the squeeze: wider inputs such as social and economic factors can make the prediction fairer, yet each added field has to earn its place or be dropped.
The workable answer is a documented rationale for every variable, recording why each one is necessary rather than merely useful.
Transparency and User Rights
Transparency runs through both regimes, from opposite ends. The GDPR (Articles 12 to 15) gives a person the right to be told how their data is collected and used, and to act on that. The AI Act (Article 13) requires a high-risk system to tell its users what it is for, where its limits lie, and how human oversight works.
In a hospital triage system the two stack: the GDPR duties to inform patients about the processing, its purpose, legal basis, and retention, and their rights of access and rectification; and on top of them the Act's duty to make clear to staff that they are working with an AI system, to keep clinicians as the final authority, and, where appropriate, to tell patients that AI is part of the decision.
Meeting the GDPR bar does not discharge the Act's. The Act wants users to understand how the system reaches a result, so that they do not defer to it blindly.
Special Categories of Data
Health data gets special treatment under both regimes, and mental-health data most of all. Under Article 9 of the GDPR, categories such as mental-health status, mood, and biometric signals may be processed only under narrow conditions, such as explicit consent or a public-interest basis in health.
The AI Act adds a condition of its own through Article 10, requiring the same data to be representative and quality-assured, while also allowing limited processing of sensitive data specifically to detect and correct bias.
A depression-risk tool built on questionnaires and wearable data has to clear the GDPR's consent bar first, and only then does the AI Act's quality bar come into play. A high-quality dataset that lacks a lawful basis cannot be used at all.
Impact Assessments
Two impact assessments can apply to the same system. The GDPR's Data Protection Impact Assessment (Article 35) examines risk to personal data. The AI Act's Fundamental Rights Impact Assessment, required under Article 27 for certain high-risk deployments and particularly those by public bodies, examines risk to fundamental rights such as non-discrimination, autonomy, and equal access.
Both identify and mitigate risk, but they answer different questions: a DPIA can come back clean while an FRIA still finds a problem, because correct data handling does not guarantee a fair outcome.
Accountability
Both regimes put the burden of proof on the organisation. The GDPR's accountability principle (Articles 5(2) and 24) makes a controller responsible for compliance and for being able to demonstrate it. The Act carries the same idea into AI: a provider of a high-risk system runs a documented quality management system (Article 17) and keeps the documentation that lets a regulator verify compliance and trace the lifecycle (Articles 11 and 18).
How the Act Compares with the U.S. FDA Framework
A manufacturer selling into both markets meets two regulators with a shared instinct and different reach. Both are risk-based, and both care about transparency, monitoring, and quality.
The FDA works within the medical-device paradigm; the Act works across sectors and adds a fundamental-rights dimension the FDA does not carry.
The ground has also shifted on the U.S. side: since 2 February 2026 the FDA's Quality Management System Regulation (QMSR) has replaced the old QSR and incorporates ISO 13485:2016 by reference, so both markets now build on the same QMS standard.
The two tables below set the comparison out.
| Aspect | FDA | EU AI Act |
|---|---|---|
| Risk-based approach | Classifies by patient risk and intended use | Classifies systems as prohibited, high-risk, or lower-risk |
| Transparency and explainability | Emphasises labelling, user training, and system understanding | Legally mandates transparency (Article 13): capabilities, purpose, human oversight |
| Lifecycle management | Encourages real-world monitoring and change protocols such as the PCCP | Requires post-market monitoring (Articles 72–73) and a new conformity assessment for substantial changes (Article 43(4)) |
| Human oversight | Encouraged, especially in high-risk use | Mandatory for high-risk systems (Article 14) |
| Bias and fairness | Addressed in GMLP but not enforceable | Required under Article 10 (data governance) and Article 9 (risk management) |
| Quality management | QMSR (21 CFR Part 820), which incorporates ISO 13485:2016, effective 2 February 2026 | AI-specific QMS under Article 17, layered onto an ISO 13485 QMS for SaMD |
Table 4: Where the FDA and EU AI Act approaches align.
| Aspect | FDA | EU AI Act |
|---|---|---|
| Legal framework | Sector-specific, medical devices only | Cross-sectoral, with a fundamental-rights emphasis |
| Ethical governance | Not explicitly addressed | Central: prohibits manipulative or exploitative uses (Article 5), requires FRIAs |
| Change management | Predetermined Change Control Plans for adaptive AI | A substantial modification may require a new conformity assessment |
| Fundamental-rights impact | Not covered | Required for public-sector high-risk deployers (Article 27, FRIA) |
| Public registration | Device listing required | High-risk systems registered in an EU database (Article 49) |
Table 5: Where the FDA and EU AI Act approaches diverge.
The practical read for a global manufacturer: the FDA's Predetermined Change Control Plan and the Act's substantial-modification rule are solving the same problem from different directions.
The Act then asks for two things the FDA does not: a fundamental-rights assessment and entry in a public EU database.
A Practical Compliance Path
The work is more manageable when it runs in order, and most of it reuses evidence a manufacturer already produces for the MDR, IVDR, or FDA.
Classify the product and fix the role
Confirm whether it is an AI system under Article 3(1), whether it is high-risk (for a medical device, under Article 6(1) and Annex I), and whether the company is provider, deployer, importer, or distributor. For the U.S. market, confirm SaMD status and FDA class. The role sets every obligation that follows.
Run a gap assessment across the regimes
Compare current MDR/IVDR and ISO 13485 compliance against the Act's duties, particularly data governance (Article 10), human oversight (Article 14), and transparency (Article 13). Set that against the FDA's expectations, including GMLP, the PCCP, and real-world monitoring, so one gap list serves both markets.
Extend the QMS and technical documentation
Fold the Article 17 AI elements into the existing quality system, and build the Article 11 technical documentation (architecture, data sources and governance, risk controls, and cybersecurity under Article 15) so it supports both an EU conformity assessment and an FDA submission.
Put the right expertise in place
Secure people who understand high-risk AI in healthcare, across model validation, bias mitigation, and DPIA and FRIA drafting, whether in-house or through review.
Govern the datasets
Keep training, validation, and test data traceable and documented, record preprocessing and labelling, and be ready to show the datasets to a Notified Body or an FDA reviewer. Flag any special-category data and apply the GDPR safeguards.
Track the guidance
Follow the European Commission, the EU AI Office, and national authorities on aligning the MDR and the Act, and the FDA on GMLP, the PCCP, and its implementation of the QMSR, which now incorporates ISO 13485.
Where This Leaves a Manufacturer
Across the three parts, the shape of the task is clear. The Act classifies most AI-enabled medical devices as high-risk under Article 6(1) and Annex I, attaches a requirement set that largely extends the MDR and ISO 13485 systems already in place, and meets the GDPR, the FDA, and the MDR at defined points that can be handled together. The deadline for medical devices is 2 August 2028.
Compliance on paper is the reachable part. The part that lasts is building AI-enabled devices and quality systems a team can run, keep current as the model changes, and defend to a Notified Body.
A manufacturer that treats the Act as an extension of the systems it already operates, rather than a separate regime, is in the better position to get there.
Frequently Asked Questions
Does meeting the GDPR mean the data is compliant under the AI Act?
No. The GDPR governs whether data may be used; the AI Act (Article 10) governs whether it is representative and free enough of bias to be used in a high-risk system. Data can be lawful under the GDPR and still fail the Act's quality requirements.
Is a Fundamental Rights Impact Assessment the same as a DPIA?
No. A DPIA under GDPR Article 35 assesses risk to personal data. A Fundamental Rights Impact Assessment under AI Act Article 27 assesses risk to fundamental rights such as non-discrimination and autonomy, and can be required for certain high-risk deployments in addition to a DPIA.
Does the EU AI Act align with the U.S. FDA approach?
Partly. Both are risk-based, both require transparency, monitoring, and quality management, and since February 2026 both build on ISO 13485 through the FDA's QMSR. They diverge on fundamental rights, public registration, and how substantial changes are handled, so a global manufacturer plans for both.
What is the first practical step toward AI Act compliance?
Classification and role. Confirm whether the product is an AI system, whether it is high-risk under Article 6(1) and Annex I, and whether the company is the provider or the deployer. Those answers determine every obligation that follows.
