Part 3: EU AI Act Intersections and Practical Compliance
By Vaclav Vlcek, MD
The AI Act rarely applies on its own. A medical device that falls under it is already under the MDR or IVDR, it often processes personal data governed by the GDPR, and, if it is marketed in the United States as a medical device, it is subject to the applicable FDA framework as well.
Part 2: Core Requirements for Medical Device AI Systems 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 applicable sectoral Regulation (the MDR or IVDR) the GDPR, and, for global products, the U.S. FDA framework. Broadly, the GDPR governs the lawfulness of personal-data processing and the associated safeguards for individuals, while for high-risk systems Article 10 of the AI Act adds dataset-quality and governance requirements. The division is not clean: the GDPR itself regulates accuracy and fairness, and AI Act Article 4a supplies a narrow Union-law authorisation for certain bias-related processing, which does not displace the GDPR's other requirements.
A Fundamental Rights Impact Assessment under Article 27 can be required of some deployers on top of a GDPR Data Protection Impact Assessment, but its scope is narrow. A manufacturer is not caught by virtue of its provider role alone, though the duty can reach it where it is also a deployer falling within one of the categories in Article 27(1). The Act and the FDA framework share a risk-based structure but diverge on fundamental rights, registration and change management. For systems classified solely through Article 6(1), Chapter III, Sections 1 to 3 (except Article 6(5)) apply from 2 August 2028.
How the AI Act and GDPR Intersect
When an AI-enabled medical device processes personal data, two regulations apply at once. Broadly, the GDPR governs the lawfulness of the processing and the safeguards owed to individuals; for high-risk systems, Article 10 of the AI Act adds dataset-quality and governance requirements. The split is not absolute, the GDPR also regulates accuracy and fairness, and Article 4a of the Act supplies a narrow Union-law authorisation for certain bias-related processing, without displacing the GDPR's other requirements, so a manufacturer works both regimes together rather than sequentially.
Data Governance
The starting point is data quality. Article 10 of the AI Act requires the training, validation and testing datasets of a high-risk system to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete, with possible biases examined and appropriately mitigated. Where a high-risk AI system is developed without using techniques involving the training of AI models, Article 10(2) to (4) and Article 4a(1) apply only to the testing datasets. The GDPR comes at the same data from a different angle: under Articles 5 and 6 it must be processed lawfully and fairly, and on a valid Article 6 basis, such as consent, or a task carried out in the public interest that is grounded in Union or Member-State law. A dataset therefore has to clear two separate bars before it can be used.
Example: AI-powered diabetes risk prediction. A health-tech company builds a tool predicting type 2 diabetes risk from electronic health records, lifestyle questionnaires, and genetic data. Under the GDPR, the genetic and health data need a lawful basis under Article 6 and a specific exception under Article 9(2) before they can be touched at all. If the tool is high-risk, Article 10 of the AI Act then asks whether that data is relevant and sufficiently representative for the prediction task, and whether possible biases in labelling and collection have been examined and appropriately mitigated.
Data can be lawful to hold and still fall short of what Article 10 needs.
Data Minimisation and Representativeness
The two regimes have to be satisfied together here, and that takes some care. Article 10 requires relevance, sufficient representativeness and bias controls. It does not require data maximisation, and adding more variables does not by itself reduce performance gaps between patient groups. The GDPR limits collection to what is necessary for the stated purpose under its data-minimisation principle (Article 5(1)(c)). The Article 10 requirements therefore have to be achieved consistently with data minimisation rather than in tension with it.
Example: predicting hospital readmission risk. A healthcare company builds a model predicting readmission within 30 days of discharge, trained on medical history, lifestyle indicators, socio-economic status, language proficiency and living conditions. Article 10 asks whether that dataset is relevant and sufficiently representative for the intended population, and whether possible biases have been examined and mitigated, not whether it is large. The GDPR asks separately whether income level and housing status are necessary for the stated purpose. Each variable has to earn its place on both counts.
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 16) gives a person the right to be told how their data is collected and used, and to act on that, rectification sitting at Article 16. The AI Act (Article 13) requires a high-risk system to be sufficiently transparent for deployers to interpret its output and use it appropriately, supported by instructions for use covering its intended purpose, performance, limitations and the human-oversight measures.
Example: an AI triage system in a hospital. The system prioritises emergency patients from vital signs, symptoms and medical history. Under the GDPR, the hospital must provide the applicable Article 13 or 14 information, subject to the statutory exceptions, covering the purpose, legal basis and retention period, and the rights of access and rectification. The AI Act splits the duties differently: Article 13 obliges the provider to make the system transparent to the hospital as deployer, with instructions covering performance and limitations, while Article 26 puts the in-use duties on the hospital, including assigning human oversight to competent staff and using the system according to those instructions. Note also that this use case sits in Annex III as emergency healthcare triage, so it may be classified under Article 6(2) independently of any Annex I route.
Meeting the GDPR bar does not discharge the Act's. The Act's concern is that deployers can interpret the output and use it appropriately, rather than deferring to it blindly.
Special Categories of Data
Health data gets special treatment under both regimes. Under Article 9 of the GDPR, data concerning health may be processed only under narrow conditions, such as explicit consent or another applicable Article 9(2) condition, for instance a public-health ground provided for by Union or Member-State law. Whether a given signal falls inside Article 9 depends on what it reveals: mood, sleep and wearable measurements are special-category data where they reveal health status or another Article 9 characteristic, and biometric data are special-category as biometric data only where processed for the purpose of uniquely identifying someone.
The AI Act adds conditions of its own through Article 10, requiring the same data to be sufficiently representative and quality-assured. Separately, Article 4a (inserted by the Digital Omnibus, which deleted the former Article 10(5)) provides a narrow Union-law authorisation, intended to satisfy GDPR Article 9(2)(g), for specified bias-detection and correction processing of special-category data. Article 4a(1) covers providers of high-risk systems. Article 4a(2) extends that authorisation, subject to the same conditions and safeguards, to providers and deployers of other AI systems and models and to deployers of high-risk systems. Those safeguards are cumulative rather than alternatives. Article 4a(2) itself creates no obligation for those actors to conduct bias detection or correction; providers of high-risk systems remain subject to the separate duties in Article 10(2)(f) and (g). Note too that Article 4a does not replace the need for an Article 6 GDPR basis, nor does it displace the GDPR's other requirements.
Example: mental-health risk assessment. A digital health platform assesses depression risk from patient questionnaires, behavioural data, and wearable inputs. Where those mood, sleep and wearable signals reveal health status, they are data concerning health under GDPR Article 9, so processing needs explicit consent or another Article 9(2) basis. If the platform is high-risk, Article 10 then requires the same data to be relevant and sufficiently representative for the prediction, with possible biases examined and mitigated, and covered by documented data governance.
A high-quality dataset that lacks a lawful basis cannot be used at all. Technical and organisational security controls can sit partly within an information security management system, which we cover in our ISO 27001 consulting; lawful basis, purpose limitation, data-subject rights and the Article 10 data governance go beyond it.
Impact Assessments
Two impact assessments can apply to the same system, and they are not interchangeable. The GDPR's Data Protection Impact Assessment (Article 35) assesses the impact of the processing on the protection of personal data and the risks it poses to individuals' rights and freedoms.
The AI Act's Fundamental Rights Impact Assessment sits under Article 27 and falls on deployers rather than providers, and its scope is narrow. It applies only to systems classified under Article 6(2), excluding Annex III point 2, and only where the deployer is a body governed by public law, a private entity providing a public service, or a deployer of the Annex III point 5(b) and (c) creditworthiness or life and health insurance systems. A manufacturer is not caught by virtue of its provider role alone, though the duty can reach it where it is also a deployer within one of the Article 27(1) categories. Nor does it attach to every public-sector high-risk system. Where both apply they interlock: Article 27(4) allows the FRIA to cross-refer to, or incorporate relevant parts of, a DPIA carried out under GDPR Article 35. They still answer different questions, since a lawful and well-documented processing operation does not guarantee a fair outcome.
Accountability
Both regimes impose extensive accountability, documentation and retention duties 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), draws up the technical documentation (Article 11) and keeps it, together with the other specified records, available to authorities for ten years after the system is placed on the market or put into service (Article 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 cross-sector fundamental-rights framework with no direct FDA equivalent. The ground has also shifted on the U.S. side: the FDA amended 21 CFR Part 820, retitled it the Quality Management System Regulation (QMSR), and made the revised regulation effective on 2 February 2026. It incorporates ISO 13485:2016 and ISO 9000:2015 clause 3 by reference. The convergence is real but partial. In the EU, use of harmonised standards remains voluntary, and Article 17(3) permits the Act's QMS elements to be integrated into the existing MDR or IVDR quality management system, which is commonly structured around EN ISO 13485, rather than mandating any particular standard. We support that transition through our FDA 21 CFR 820 consulting.
Example: one evidence set, two markets. A manufacturer preparing a 510(k) submission and an EU conformity assessment can build much of the data-governance and performance-validation evidence once and reuse it where relevant, with jurisdiction-specific additions. For a device classified under Article 6(1), the notified body competent under Article 43(3) examines the applicable requirements, including Articles 10 and 15. On the FDA side, applicable statutory and regulatory requirements govern; the Good Machine Learning Practice principles are non-binding guiding principles. A predetermined change control plan is a mechanism for planned modifications that a manufacturer proposes in its marketing submission, with FDA's final August 2025 guidance setting out recommendations for it, not something every submission contains.
The two tables below set the comparison out.
| Aspect | FDA | EU AI Act |
|---|---|---|
| Risk-based approach | Classifies device types according to risk and the controls needed to assure safety and effectiveness; intended use and indications for use also affect classification | Prohibits certain practices (Article 5), classifies some systems as high-risk (Article 6), and attaches transparency duties to others (Article 50) |
| Transparency and explainability | Emphasises labelling, user training, and system understanding | Legally mandates transparency (Article 13): capabilities, purpose, human oversight |
| Lifecycle management | Applicable FDA postmarket duties continue to apply. The January 2025 AI lifecycle document remains draft guidance and recommends total-product-lifecycle monitoring; the August 2025 PCCP guidance is final and addresses specified planned modifications | Requires post-market monitoring (Article 72). A high-risk AI system already subject to conformity assessment must undergo a new conformity assessment in the event of a substantial modification (Article 43(4)) |
| Human oversight | FDA materials address human factors and human–AI team performance where relevant; there is no direct equivalent to the AI Act's horizontal duty | Mandatory for high-risk systems (Article 14) |
| Bias and fairness | GMLP addresses representative datasets and performance across intended populations, but the principles themselves are non-binding; applicable FDA legal requirements remain enforceable | Required under Article 10 (data governance) and Article 9 (risk management) |
| Quality management | QMSR (21 CFR Part 820), which incorporates ISO 13485:2016 and ISO 9000:2015 clause 3, effective 2 February 2026 | Article 17 QMS; under Article 17(3) its elements may be integrated into the existing MDR or IVDR quality management system, with standards use remaining voluntary |
Table 1: Where the FDA and EU AI Act approaches align. AI Act references are to Regulation (EU) 2024/1689 as amended by the Digital Omnibus, Regulation (EU) 2026/1744. Several provisions cited here were amended; see the citation note below.
| Aspect | FDA | EU AI Act |
|---|---|---|
| Legal framework | FDA medical-device framework | Cross-sectoral, with a fundamental-rights emphasis |
| Ethical governance | No directly equivalent cross-sector fundamental-rights regime; FDA materials nevertheless address bias, transparency, human–AI interaction and health equity | Central: prohibits manipulative or exploitative uses (Article 5), and requires FRIAs of specified deployers |
| Change management | PCCPs for planned modifications to AI-enabled device software functions, under final August 2025 guidance | Article 43(4) requires a new conformity assessment in the event of a substantial modification. For continuously learning systems, specified changes pre-determined and documented during the initial conformity assessment do not constitute a substantial modification |
| Fundamental-rights impact | No directly equivalent FRIA requirement | Required of specified deployers of Article 6(2) systems only (Article 27, FRIA); a manufacturer is not caught by its provider role alone, but the duty can reach it where it is a deployer within one of the Article 27(1) categories |
| Public registration | Establishment registration and device listing, as applicable | Article 49 registration principally covers Annex III systems and Article 6(3) determinations; an Article 6(1)-only device is generally outside it, and some sections of the database are non-public |
Table 2: Where the FDA and EU AI Act approaches diverge. AI Act references are to Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744.
The practical read for a global manufacturer: both frameworks address planned post-market changes, but with different triggers, procedures and legal consequences. A PCCP is not equivalent to the Act's substantial modification.
Two often-cited EU additions are narrower than they look. The fundamental-rights assessment reaches only specified deployers of Article 6(2) systems (a manufacturer is not caught by its provider role alone) and Article 49 registration generally does not reach a device classified solely through Article 6(1).
A Practical Compliance Path
The work is more manageable when it runs in order, and many of the evidence artefacts a manufacturer already produces for the MDR, IVDR or FDA can be reused where relevant.
Classify the product and fix the role
Confirm whether it is an AI system by applying every element of Article 3(1). The capacity to infer beyond basic data processing is a key distinguishing feature, and the system must also have some degree of autonomy. For high-risk status, check both limbs of Article 6(1): that the AI is a safety component of, or is itself, a product covered by Annex I, Section A legislation such as the MDR or IVDR, and that the product requires third-party conformity assessment.
Apply Articles 6(1a) and 6(1b) when deciding whether the AI qualifies as a safety component 6(1a) excludes systems used solely for specified non-safety functions, 6(1b) restores safety-component status where failure or malfunction would endanger health and safety) and Article 6(1c) when deciding whether the third-party-assessment condition in Article 6(1)(b) is met. Check Annex III separately, since a system can be classified under Article 6(2) independently. Then establish whether the company is provider, deployer, importer or distributor. For the U.S. market, confirm whether the product or software function is a device, whether it is SaMD or software in a medical device as relevant, its FDA classification, and the applicable premarket pathway. 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 applicable FDA requirements and guidance, including GMLP and, where a PCCP is proposed, FDA's PCCP guidance, together with 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 under Article 17(3), and build the Article 11 technical documentation (architecture, data sources and governance, risk controls, and cybersecurity under Article 15) so it supports an EU conformity assessment and an FDA submission so far as possible in common, with jurisdiction-specific additions. Under Article 43(3) it is the Section 2 requirements and the Article 17 QMS assessment that enter the sectoral procedure.
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 the training, validation and testing data traceable and documented, recording the preprocessing and labelling procedures and the quality controls applied. For the EU assessment, be prepared to grant the notified body full access to those datasets under Annex VII, point 4.3, where relevant and limited to what is necessary for its tasks, subject to the applicable security safeguards. For FDA review, provide the documentation and supporting data required by the applicable submission pathway and any properly issued request; that is not a universal obligation to hand over raw datasets. Flag any special-category data, apply the GDPR requirements, and where Article 4a is relied on for bias detection or correction, meet its cumulative conditions.
Track the guidance and the open dates
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. Two dates are worth diarising: the Commission must adopt delegated acts under Article 2(13) by 2 August 2027, and the Annex I Section A notified bodies to which Article 43(3) refers must apply for designation under the Act by 28 January 2028, which is a deadline to apply rather than to hold designation
Where This Leaves a Manufacturer
Across the three parts, the shape of the task is clear. An AI-enabled medical device is high-risk through Article 6(1) where both conditions are met, applying the qualifications in Articles 6(1a) to 6(1c), the requirement set largely extends the sectoral and quality systems already in place, and the Act meets the GDPR, the FDA and the MDR at defined points that can be handled together. On timing, Chapter III, Sections 1 to 3 (except Article 6(5)) apply from 2 August 2028 to systems classified solely through Article 6(1), subject to Article 111. Article 113 assigns 2 December 2027 to the Article 6(2) and Annex III route and 2 August 2028 to the Article 6(1) and Annex I route. Where only one route applies, the date is clear. The Regulation does not expressly resolve the date where both routes independently apply.
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.
QMLogic works with manufacturers across this ground through EU AI Act consulting for health software. The series starts with how the EU AI Act applies to medical devices.
Frequently Asked Questions
Does meeting the GDPR mean the data is compliant under the AI Act?
No. Broadly, the GDPR governs the lawfulness of the processing and the safeguards owed to individuals, while Article 10 of the AI Act adds dataset-quality and governance requirements for high-risk systems: relevant, sufficiently representative and, to the best extent possible, free of errors and complete, with possible biases examined and appropriately mitigated. Data can be lawful under the GDPR and still fall short of that.
Is a Fundamental Rights Impact Assessment the same as a DPIA?
No. A DPIA under GDPR Article 35 assesses the impact of the envisaged processing on the protection of personal data and the risks to individuals' rights and freedoms. A Fundamental Rights Impact Assessment under AI Act Article 27 assesses risk to fundamental rights. It falls on the deployers listed in Article 27(1), not on providers by virtue of their provider role, and only on specified ones: bodies governed by public law, private entities providing public services, and deployers of the Annex III point 5(b) and (c) creditworthiness and insurance systems, for systems classified under Article 6(2) excluding Annex III point 2. Where both apply, Article 27(4) allows the FRIA to cross-refer to or incorporate relevant parts of a DPIA.
Does the EU AI Act align with the U.S. FDA approach?
Partly. Both are risk-based and both address transparency, monitoring and quality management, and since 2 February 2026 the FDA's QMSR incorporates ISO 13485:2016 by reference. The convergence is partial: EU use of harmonised standards remains voluntary, and Article 17(3) permits integration into the existing MDR or IVDR quality management system rather than mandating a standard. They diverge on fundamental rights, registration and how 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, then check both conditions in Article 6(1): that the AI is a safety component of, or is itself, an Annex I, Section A product such as one covered by the MDR or IVDR, and that the product requires third-party conformity assessment. Articles 6(1a) and 6(1b) qualify the safety-component limb and Article 6(1c) qualifies the third-party-assessment limb. Check Annex III separately, since Article 6(2) can classify a system independently. Then establish whether the company is the provider or the deployer.
