The EU AI Act classifies systems by risk tier rather than by sector, but the practical effect for healthcare is that a large share of clinical and diagnostic AI lands in the high-risk category — because it is, or is a safety component of, a medical device subject to third-party conformity assessment. That single fact drives most of what a healthcare AI deployment in the EU actually has to do.
Current as of September 2026 — the AI Act's implementing guidance and transition timelines have moved before and may move again; verify the current text and applicable dates before relying on specifics here.
Why healthcare AI is usually high-risk
The AI Act's high-risk category includes AI systems that are themselves medical devices, or safety components of medical devices, requiring third-party conformity assessment under the EU's medical device and in-vitro diagnostic frameworks. Diagnostic support tools, triage systems, and software that influences a treatment decision typically fall inside this description. Administrative and operational AI — scheduling, demand forecasting, document processing that doesn't touch a clinical decision — often does not, which is why classification has to be done per system and per use, not per department.
It layers on MDR, it doesn't replace it
For medical device AI, the intent is for the AI Act's conformity assessment obligations to run through the same notified-body process already used for MDR/IVDR, rather than standing up a second, separate certification track. In practice this means a device manufacturer already doing MDR conformity assessment absorbs additional AI-specific requirements into that same process — it is more work, not a parallel bureaucracy, but the additional work is substantial.
What high-risk classification actually requires
The obligations cluster into a few groups worth planning around separately: a risk management system spanning the AI lifecycle, not a one-time assessment; data governance over training, validation and testing data, including documentation of provenance and known limitations; technical documentation and record-keeping sufficient to reconstruct how the system behaves and why; transparency to deployers about capabilities, limitations and intended use; and human oversight measures designed into the system rather than left to policy. Each of these is closer to an engineering requirement than a paperwork exercise — the documentation has to describe a system that was actually built this way, not retrofitted to look like it was.
Provider and deployer are different jobs
A hospital or health system buying a third-party AI diagnostic tool is typically a deployer, not a provider — and deployers carry their own obligations, distinct from and additional to whatever the vendor has done. Ensuring human oversight in actual use, monitoring the system's performance in your own population, and knowing when to escalate a problem back to the provider are deployer responsibilities that a vendor's own conformity assessment does not discharge for you.
Where Eclypse sits: deployments carry documented risk management, data governance and technical documentation as standard deliverables, built to hand to a deployer's own compliance function rather than assembled after the fact for an audit.
This sits alongside a broader global picture — see how Singapore's sectoral, role-based approach compares in Singapore's AI in healthcare guidelines, and how the FDA frames comparable expectations in the FDA's AI credibility framework.
Common questions about the EU AI Act and healthcare.
Is healthcare AI automatically high-risk under the EU AI Act?
Not automatically, but a large share qualifies — systems that are, or are safety components of, medical devices requiring third-party conformity assessment. Confirm classification per system.
Does the AI Act replace MDR certification?
No. For medical device AI, the AI Act's requirements are designed to integrate with the existing MDR/IVDR conformity assessment process — both bodies of obligation apply.
What does high-risk classification require?
A lifecycle risk management system, data governance, technical documentation and record-keeping, transparency to deployers, and human oversight measures, among other obligations.
Who is the deployer versus the provider under the AI Act?
The provider develops or places the system on the market; the deployer uses it under its own authority and carries distinct obligations, such as human oversight and in-use monitoring.
When do the AI Act's high-risk obligations take effect?
Obligations phase in over several years, with high-risk provisions landing later than the earliest ones. Confirm current applicable dates against the official text.
Walk us through your classification question — we'll map it against the framework.
Book a working session
ECLYPSE
AI
Our proprietary AI orchestration platform for healthcare: one engine, a registry of reusable task modules and domain agents, and a governed knowledge base — deployed inside your walls and run by your team.