GDPR × AI Act × MDR: Health Data Rules for Medical AI

Patient data sits under three regimes at the same time, and they stack rather than replace each other:

• GDPR decides whether you may process it at all. Health data is a special category under Article 9: processing is prohibited unless you meet a specific condition (explicit consent, health or social care, public health, research), and you still need a lawful basis under Article 6. Both are required.
• The AI Act governs your model's data. Article 10 sets data-governance duties, and Article 10(5) gives a narrow route to process special-category data for bias detection, under six strict safeguards.
• The MDR/IVDR governs the clinical use of that data (clinical evaluation, performance evaluation).
• The AI Act does not displace the GDPR. Article 2(7) says the Regulation "shall not affect" the GDPR. They apply together.
• You may owe two assessments: a GDPR DPIA and an AI Act FRIA, and the FRIA complements the DPIA (Article 27).

Plan for all three, and do not assume compliance with one covers another.

Every legal claim below is cited. See Sources.

Why this trips teams up

Founders often treat "AI Act compliance" and "GDPR compliance" as one project. They are not. The GDPR asks may you use this personal data, and on what basis. The AI Act asks is the data feeding your model well-governed, representative and documented. A model can be perfectly GDPR-lawful and still fail the AI Act's data-governance bar, or vice versa. With health data, a third layer (the MDR/IVDR clinical framework) runs at the same time. Keeping the three questions separate is what stops the compliance work from turning into mush.

Layer 1: GDPR decides if you may process the data

Health data is a special category of personal data under GDPR Article 9(1), and processing it is prohibited by default. To process it lawfully you need two things at once:

1. A lawful basis under Article 6 (for example, consent, contract, legitimate interests), and
2. A special-category condition under Article 9(2). The ones that matter in health are:
   • 9(2)(a) explicit consent (a higher bar than ordinary consent);
   • 9(2)(h) preventive or occupational medicine, diagnosis, provision of health or social care, under a basis in law and an obligation of professional secrecy;
   • 9(2)(i) public health, with a basis in law;
   • 9(2)(j) scientific research, with safeguards.

The common trap: teams point to "consent" for the model but forget that Article 9 sits on top of Article 6, so both have to hold. In clinical settings, Article 9(2)(h) (health care under professional secrecy) is often more workable than trying to build model training on explicit consent, which must be specific to the sensitive data and purposes and can be withdrawn.

Layer 2: the AI Act governs your model's data (Article 10)

Separately, Article 10 requires that the training, validation and test datasets behind a high-risk AI system are relevant, representative, as error-free as possible, and examined for bias. This is a data-quality and governance duty, distinct from the GDPR's may-you-process-it question.

There is one important bridge between the two. Article 10(5) lets providers exceptionally process special categories of personal data (as defined in GDPR Article 9) to the extent strictly necessary to detect and correct bias, but only under six safeguards:

• bias detection cannot be achieved with other data, including synthetic or anonymised data;
• the special data has technical limits on re-use plus state-of-the-art security and pseudonymisation;
• it is subject to strict access controls and documentation;
• it is not transmitted or accessed by other parties;
• it is deleted once bias is corrected or the retention period ends; and
• the processing is documented as strictly necessary.

So the AI Act does not hand you a free pass on sensitive data; it carves a narrow, safeguard-heavy lane for the specific purpose of fairness testing, and it points straight back to the GDPR's definition of special-category data while doing so.

Layer 3: the MDR/IVDR governs clinical use

On top of both, your clinical or performance evaluation under the MDR/IVDR uses patient data within its own framework. For medical AI, this is where the "does it work, and is it safe" evidence lives. It does not answer the GDPR lawfulness question or the AI Act governance question; it runs in parallel. Our medical-AI high-risk guide covers how the AI Act and MDR/IVDR conformity integrate under Article 43(3).

The role mismatch: controller/processor vs provider/deployer

A subtle trap: the GDPR's roles (controller and processor) do not map one-to-one onto the AI Act's roles (provider and deployer). You can be the AI Act provider of a system while a hospital is the GDPR controller for the patient data it runs through that system, and you may be its processor, or a separate controller for your own training data. Work out both sets of roles separately; assuming "we are the provider, so we are the controller" is how data-protection responsibilities get misassigned. See provider vs deployer for the AI Act side.

DPIA vs FRIA: two assessments, not one

Two different impact assessments can apply:

• A DPIA under GDPR Article 35, triggered by high-risk processing of personal data.
• A FRIA under AI Act Article 27, required of certain deployers of high-risk AI (public bodies, private providers of public services, and deployers of specific Annex III systems).

Crucially, Article 27(4) says the FRIA shall complement an existing DPIA, not replace it. So a hospital deploying a high-risk medical AI may owe both, and they are meant to sit side by side, each covering what the other does not.

Worked examples

Common mistakes

• "We have consent, so we are covered." Article 9 sits on top of Article 6; you need both, and explicit consent is a high, withdrawable bar.
• "The AI Act replaces our GDPR work." Article 2(7): it does not affect the GDPR. Both apply.
• "Provider means controller." The role sets are separate; map each.
• "A DPIA covers the FRIA." They are different instruments; the FRIA complements the DPIA where both apply.
• "Bias testing on patient data is fine because the AI Act allows it." Only under the six Article 10(5) safeguards, and you still need a GDPR footing.

Practical checklist

• Nail your GDPR footing first: identify your Article 6 basis and your Article 9(2) condition for every use of health data.
• Treat AI Act data governance (Art 10) as a separate workstream about quality, representativeness and bias, not lawfulness.
• If you process sensitive data for bias-checking, build the Article 10(5) six safeguards in from the start.
• Map your GDPR roles and your AI Act roles separately.
• Map whether you owe a DPIA, a FRIA, or both, and keep them complementary.

Does the AI Act replace the GDPR for health data?

No. Article 2(7) of the AI Act states it shall not affect the GDPR. They apply together: the GDPR governs whether and how you may process personal data, and the AI Act adds data-governance duties for the datasets behind a high-risk system.

Can I use patient data to test my model for bias?

Only under strict conditions. Article 10(5) permits exceptional processing of special-category data for bias detection and correction, but requires six safeguards, including that no other data (synthetic or anonymised) would work, pseudonymisation and strong security, no third-party access, and deletion once bias is corrected. You also still need a GDPR footing.

Do I need a DPIA or a FRIA?

Possibly both. A DPIA under GDPR Article 35 is triggered by high-risk processing of personal data. A FRIA under AI Act Article 27 is required of certain deployers of high-risk AI. Article 27(4) says the FRIA complements the DPIA rather than replacing it, so where both apply, do both.

Is "explicit consent" enough to process health data for AI?

It can be a valid Article 9(2)(a) condition, but it is a higher bar than ordinary consent and does not remove the need for an Article 6 lawful basis. In clinical settings, Article 9(2)(h) (health care under professional secrecy) is often more workable.

Are the GDPR and AI Act roles the same?

No. GDPR controller and processor are defined by who determines the purposes and means of processing personal data; AI Act provider and deployer are defined by who makes and who uses the AI system. You can hold different roles under each regime, so analyse them separately.

Sources (official)

• GDPR, Regulation (EU) 2016/679: official text on EUR-Lex. Cited: Article 6 (lawfulness), Article 9 (special categories, including health data and the Article 9(2) conditions), Article 35 (data protection impact assessment), Chapter V (international transfers).
• EU AI Act, Regulation (EU) 2024/1689: per-article on the European Commission AI Act Service Desk. Cited: Article 2(7) (the Regulation does not affect the GDPR), Article 10 and Article 10(5) (data governance; processing special categories for bias detection under safeguards), Article 27 (FRIA, complementing the DPIA), Article 43(3) (integrated conformity); official text on EUR-Lex.
• MDR / IVDR, Regulations (EU) 2017/745 and 2017/746: clinical and performance evaluation frameworks.

Legalithm provides compliance information and tooling, not legal advice. Data protection outcomes depend on your specific processing and legal basis; confirm with a data protection officer and qualified counsel. Article references are to Regulation (EU) 2024/1689 (the AI Act) and Regulation (EU) 2016/679 (the GDPR).