EU AI Act in Healthcare: Which Hospital and Clinical AI Is High-Risk Beyond Medical Devices?
Most healthcare teams meet the EU AI Act through one door: the medical device route. If your software is a regulated device under the MDR or IVDR, you already know you are in scope (we cover that interplay in our guide to the MDR/IVDR and the AI Act). But a large share of hospital and digital health AI is not a medical device at all, and it can still be high-risk under Annex III. This guide covers that second door.
Why Annex III matters for healthcare
High-risk classification has two routes: Annex I (products under sectoral law such as the MDR) and Annex III (listed use cases). Our classification guide explains the mechanics. For healthcare, three Annex III entries do most of the work: emergency triage (point 5(d)), life and health insurance (point 5(c)), and biometric categorisation (point 1).
The Commission's draft guidelines on high-risk classification under Article 6(5), open for consultation until 23 July 2026, add no new obligations but show how these entries apply in practice, according to Osborne Clarke's analysis.
Emergency triage: Annex III point 5(d)
Annex III covers AI intended to evaluate emergency calls, dispatch emergency services, or triage emergency patients. The draft guidelines treat an emergency department patient-prioritisation tool as a confirmed high-risk example [1], and say a mental health crisis triage chatbot may also be in scope. Excluded are appointment management, patient identification, and transcription of emergency calls.
If the same triage tool is also a medical device, both Article 6(1) and Article 6(2) routes apply at once, covering data governance, technical documentation, human oversight and registration.
Health and life insurance: Annex III point 5(c)
AI used for risk assessment or pricing in life and health insurance is high-risk; either function alone is enough. The draft guidelines extend the reading to private long-term care insurance, personal pension products that significantly affect old-age livelihood, and credit life insurance. Health risk analytics whose outputs feed underwriting may also fall in scope where that use is reasonably foreseeable and not excluded in the documentation, promotional material or terms.
Clinical biometrics: Annex III point 1
AI that categorises people by sensitive attributes inferred from biometric data, including health data, is high-risk. The draft guidelines give an example: a system that infers health data from gait and assigns patients to early or advanced disease stages. ECG, EEG, heartbeats and eye tracking all count as biometric data. For the line between this category, emotion recognition and the outright bans, see our biometrics and emotion recognition guide.
Two points trip up digital health teams. Research-phase tools get no carve-out, because intended purpose is assessed across all documentation and marketing, not only the study protocol. And adding clinician review does not change classification: human oversight is a requirement for high-risk systems, not an exemption from them.
A quick classification table
| Use case | Annex III entry | Likely status |
|---|---|---|
| ED patient-prioritisation tool | 5(d) | High-risk |
| Mental health crisis triage chatbot | 5(d) | Possibly high-risk |
| Appointment scheduling, patient identification, call transcription | None | Not high-risk under 5(d) |
| Underwriting risk score for health or life cover | 5(c) | High-risk |
| Gait analysis staging disease progression | 1(b) | High-risk |
| Hospital access control using face recognition | 1(a) | Possibly high-risk |
Hospitals are usually deployers, until they are not
Most hospitals buy rather than build, which makes them deployers with the duties in Article 26: use per instructions, assign competent human oversight, monitor, keep logs, and inform affected people. Public hospitals and other bodies governed by public law must also complete a fundamental rights impact assessment before first use.
The trap is a change of purpose. Osborne Clarke notes that organisations that modify an AI tool's purpose may take on developer obligations [1]. Repurposing a scheduling optimiser as a bed-priority tool, for example, can turn a hospital into a provider. See Article 25 and procurement.
Timeline
After the Digital Omnibus, Annex III high-risk obligations are reported to start in December 2027 and Annex I obligations in August 2028 [1]; see our EU AI Act summary for the full deadline table. Article 4 AI literacy and the Article 5 bans already apply.
A 90-day plan
- Inventory: list every AI-enabled tool, including features inside your EHR, triage and insurance software.
- Classify by intended purpose: read vendor documentation and marketing, not just contracts.
- Flag purpose drift: document where staff use tools for something the vendor did not intend.
- Ask vendors for evidence: instructions for use, logging capability, oversight design and their classification reasoning.
- Prepare oversight and FRIA: name the clinicians responsible and draft the FRIA template.
Is a hospital triage AI high-risk if a nurse always reviews the output?
Yes, if its intended purpose is triaging emergency patients. Human review is a required safeguard for high-risk systems, not a reason to classify them out.
Does the Annex III route apply to systems that are not medical devices?
Yes. Annex III classifies by intended purpose, independent of the MDR or IVDR. A tool can be high-risk under Annex III whether or not it is a device.
Are appointment scheduling tools high-risk?
Not under point 5(d). The draft guidelines exclude appointment management, patient identification and emergency call transcription.
When do the obligations start?
Annex III high-risk obligations are reported to start in December 2027 after the Digital Omnibus, but the Article 5 bans and Article 4 AI literacy already apply.
This article is general information, not legal advice.
Related reading
Article 14 EU AI Act: Engineering Human Oversight That Actually Works
Article 14 is a design obligation, not an HR policy. Here's how to engineer the five oversight capabilities, split provider vs deployer duties, handle the biometric two-person rule, and build an audit-ready evidence trail.
EU AI Act Article 13: What Your Instructions for Use Must Contain, and What Deployers Should Demand From Vendors
Article 13 turns the instructions for use into the contract between a high-risk AI provider and its deployers. Here is what Article 13(3) requires, the evidence deployers should ask for, and where harmonised standards stand after 14 October 2026.
GPAI Models With Systemic Risk: The Safety and Security Chapter of the Code of Practice, Explained
Providers of the most capable general-purpose AI models carry extra duties. Here is what the Safety and Security chapter of the GPAI Code of Practice asks for, the incident timelines, and the dates that matter now the AI Office can enforce.