EU AI Act High-Risk Series, Part 4: Healthcare & MedTech

This is Part 4 of our five-part series on high-risk AI under the EU AI Act. Each instalment covers one regulated vertical - what "high-risk" means for it, what the current timeline actually requires, and what has to be different about how you build or buy AI in that space. Part 1 covered recruitment and HR tech; Part 2 covered finance and insurance; Part 3 covered education and EdTech; Part 5 covers critical infrastructure.

Ask two healthcare AI teams when they need to be compliant with the EU AI Act, and you can get two different, both-correct answers - eight months apart. Which one applies to you comes down to a single question: is your AI legally a medical device, or not? Healthcare is the one vertical in this series that splits into two separate tracks with two separate deadlines, and getting the classification wrong in either direction is expensive.

What just changed

As covered earlier in this series, the "Digital Omnibus on AI" - Regulation (EU) 2026/1744, in force since 27 July 2026 - postponed the AI Act's high-risk deadlines. For standalone Annex III systems, that's a shift from 2 August 2026 to 2 December 2027. But healthcare also touches a second category - Annex I, AI that's a safety component of a product already regulated under EU product-safety law - and that deadline moved too: from 2 August 2027 to 2 August 2028.

What wasn't touched by the delay:

Since 2 February 2025: prohibited AI practices are banned outright, and staff AI-literacy obligations apply. Notably, Article 5(1)(f)'s ban on inferring people's emotions from biometric data in the workplace and in education institutions specifically exempts medical and safety purposes - healthcare is the explicit carve-out to a rule that binds recruitment and education elsewhere in this series. That exemption isn't unlimited, though: Commission guidance has clarified it doesn't cover general workplace stress or burnout monitoring dressed up as "wellbeing," and a proportionality test still applies even where the medical exception is genuinely in play.
Since 2 August 2025: obligations for general-purpose AI models, plus the Act's governance and penalty framework, apply.
From 2 August 2026 (unaffected by the delay): transparency duties apply wherever relevant.

The two tracks: is your AI a medical device?

Track 1: your AI is a medical device, or a safety component of one. Under Article 6(1), if your software meets the definition of a medical device or in vitro diagnostic under the EU's Medical Device Regulation (MDR) or IVDR - broadly, MDR class IIa and above, or IVDR class B-D, and it needs third-party conformity assessment from a notified body - it's automatically classified as high-risk, regardless of whether it also appears in Annex III. (There are narrower exceptions too: certain Class I MDR devices with sterile, measuring, or reusable-surgical sub-designations also require notified-body sign-off, and can trigger Article 6(1) despite their nominal "Class I" label.) Diagnostic imaging AI, AI-assisted triage tools sold as devices, and most serious clinical decision-support software sit here. Deadline: 2 August 2028. Per MDCG 2025-6, the joint Commission/Medical Device Coordination Group guidance on exactly this question, the AI Act's requirements - data governance, logging, human oversight, post-market monitoring - get folded into the conformity assessment your notified body already runs under MDR, rather than becoming a second, separate process.

Track 2: your AI isn't a medical device, but it's named directly in Annex III anyway. Two healthcare-adjacent use cases are high-risk in their own right. Annex III point 5(a) covers AI used by public authorities to determine eligibility for essential public assistance benefits and services - a broader category that explicitly names healthcare services as one example, not a dedicated healthcare-only clause. Point 5(d) explicitly names emergency healthcare patient triage systems. Neither needs to be a "device" to be in scope. Deadline: 2 December 2027 - the same date as the rest of this series.

The genuinely tricky part is the grey zone in between: plenty of software marketed as "clinical decision support" sits at a lower MDR risk class that doesn't trigger mandatory third-party assessment, which means it may not automatically pull in Article 6(1) high-risk status at all. Getting that classification right - and documented - is one of the harder calls in the whole series, and exactly the kind of thing worth doing formally rather than assuming.

What actually has to change

The obligations themselves look similar to the rest of this series - risk management, data governance and bias testing, technical documentation, logging, human oversight, transparency, and monitoring after deployment. What's different in healthcare is where that work happens:

If you're on the medical-device track, this isn't a parallel compliance programme - it's additional evidence folded into the technical file and conformity assessment your notified body already reviews. The practical work is making sure your existing MDR documentation actually covers the AI-specific requirements: training data provenance, bias testing, and a genuine human-oversight process for the clinician using the tool, not just for the software itself.
If you're on the Annex III standalone track, the process looks like the rest of this series - conformity assessment and EU database registration in their own right, by December 2027.
Either way, human oversight in healthcare has a specific meaning: a clinician has to be able to understand and override the system's output in a clinical context, not just technically retain a veto that never gets exercised in practice.

What we've left out of this piece, on purpose

To keep this readable, we've deliberately skipped some detail: the precise MDR and IVDR risk-classification rules (a substantial body of regulation in its own right), the general-purpose AI model rules, and how national health-system procurement rules layer on top in individual member states. Those are conversations for your regulatory affairs team and notified body, not a paragraph in a primer.

What's actually at stake

Fines follow a tiered structure under Article 99, and none of these tiers were changed by the Digital Omnibus:

Up to €35M or 7% of global annual turnover, whichever is higher - reserved for violations of the Act's outright prohibitions, such as unlawful emotion recognition.
Up to €15M or 3% - the tier that actually applies to Track 1 and Track 2 high-risk system non-compliance, which is what most healthcare AI failures will fall under.
Up to €7.5M or 1% for supplying incorrect or misleading information to a regulator or notified body.
For SMEs, each of these caps applies as whichever figure is lower, not higher.

In healthcare, an AI Act failure rarely stays contained to the AI Act. For device-track products, it's layered directly onto MDR enforcement - in the worst case, that means a suspended CE mark and a product off the market, on top of any AI Act fine. Patient-safety incidents involving AI draw immediate scrutiny from regulators, clinicians, and the press alike - reputational damage here tends to move faster than any formal enforcement timeline.

Given how much of this depends on getting the medical-device classification right in the first place, it's worth treating that as its own dedicated exercise rather than folding it into a general AI Act review.

Getting ready

If you're building or running AI anywhere in diagnostics, clinical decision support, or patient triage and aren't sure which track you're on, get in touch - we'll help you work out your classification, what's already binding today, and what to prioritise before your actual deadline arrives.

This is our take on the operational and technical side of compliance, not legal advice - pair it with your own legal counsel and regulatory affairs team for formal sign-off. Next in the series: Part 5, Critical Infrastructure.