All solutionsBy sector

EU AI Act compliance for healthcare AI

High-risk

AI that is a medical device, or a safety component of one, is high-risk under the EU AI Act and must be reconciled with the Medical Device Regulation. Documentation and conformity assessment are central.

AI in healthcare splits in two, and the split decides everything that follows. If the AI is a medical device — or a safety component of one — that must undergo third-party conformity assessment under the Medical Device Regulation, it is high-risk by the Article 6(1) route through Annex I, governed alongside the MDR; a Class I device the manufacturer self-certifies is not caught by that route. If the AI is used to triage patients in emergency care or to decide access to healthcare services, it is high-risk under Annex III instead. The two routes have different conformity paths and different dates.

Why it is in scope

AI embedded in regulated medical products (Annex I) is high-risk; the Digital Omnibus reschedules these embedded-product obligations to August 2, 2028 (Regulation (EU) 2026/1744, in force since 27 July 2026).

What this does not trigger

A great deal of health software is neither route. Practice management, billing, appointment scheduling and clinical documentation tools that do not diagnose, triage, or decide access to care sit outside both high-risk routes. That is not the same as no obligation: a tool that generates text, such as an AI scribe, still owes the Article 50(2) machine-readable marking duty, and that duty is already in force. Research, testing and development before any placing on the market is covered by the Article 2(8) carve-out — except testing in real-world conditions, which Article 2(8) expressly leaves inside the Regulation and Article 60 governs. And a device already CE-marked under the MDR is not automatically high-risk under the AI Act: the Article 6(1) route requires both that the AI is a safety component of a product, or is itself a product, covered by the listed legislation, and that that product must undergo third-party conformity assessment under it.

Provider or deployer?

The manufacturer under the MDR is normally the provider under the AI Act, and the hospital or clinic is the deployer. Where an AI system is a safety component of a product covered by Annex I legislation, the AI Act conformity assessment is carried out within the existing sectoral procedure: you do not run two assessments side by side, you extend the one you already have.

Key obligations

  • Risk management aligned with MDR and Article 9
  • Data governance and clinical data quality (Article 10)
  • Annex IV technical documentation (Article 11)
  • Accuracy, robustness, and post-market monitoring (Articles 15, 72)
  • Conformity assessment, often via a notified body (Article 43)

What this looks like in practice

  • Diagnostic support that reads an image and flags findings is a medical device function. The AI Act obligations fold into the MDR conformity assessment through the notified body that is already involved.
  • Triage software that prioritises patients in emergency care is named in Annex III point 5(d) — a route that under Article 43(2) runs on internal control without a notified body, and on the earlier Annex III date. The two routes are not mutually exclusive: where that same software is itself a medical device requiring third-party assessment under the MDR, Article 6(1) bites as well and Article 43(3) sends the conformity assessment back inside the MDR procedure.
  • Software that determines eligibility for a public health benefit is Annex III point 5(a), essential public services. A private operator running that service on a public body's behalf can be a private entity providing public services, which brings Article 27 into play.
  • A model that recommends dosages or flags drug interactions is normally a medical device by function, so it takes the Annex I route through the MDR rather than the Annex III one — and inherits the notified-body path that its class carries.
  • AI used by a public authority to decide entitlement to reimbursement is not clinical at all. It is Annex III point 5(a), access to essential public services, and it brings Article 27 with it for a public deployer.

Where SMEs get this wrong

  • Running the AI Act file and the MDR file as two separate projects. Article 11(2) requires a single set of technical documentation where a high-risk AI system relates to a product covered by Annex I, Section A — it is mandatory, not optional — and Article 8(2) separately lets you fold the testing, reporting and documentation into procedures that already exist under the MDR. Duplicating them creates two documents that drift apart.
  • Applying the Annex III date to embedded devices. Product-embedded high-risk systems have their own, later date. Mixing the two produces a plan that is eight months wrong in one direction or the other.
  • Under-documenting clinical data governance. Article 10 asks about representativeness and gaps in the training data; a clinical dataset that under-represents a population is exactly the failure that article is written for.

What actually proves compliance

One technical file that satisfies both regimes: the MDR clinical evaluation alongside the Annex IV content, a single risk-management system reconciling Article 9 with ISO 14971, the Article 10 record for the clinical datasets, post-market monitoring under Article 72 aligned with MDR vigilance, and the notified body certificate where the device class calls for one.

What getting it wrong costs

High-risk healthcare AI sits in the Article 99(4) band for provider and deployer breaches: up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, with Article 99(6) capping SMEs and start-ups at whichever of the two is lower and the Digital Omnibus adding Article 99(6a) for small mid-caps. That is the AI Act alone. MDR non-compliance carries its own national penalty regime on top — which is the practical argument for one reconciled technical file rather than two.

When it applies

The two routes diverge. Annex III healthcare uses — emergency triage, access to services — apply from December 2, 2027, while AI embedded in regulated products under Annex I applies from August 2, 2028. Both dates were rescheduled by the Digital Omnibus on AI.

Questions we get asked

Our tool is CE-marked under the MDR. Are we finished?
No, but you are not starting over. The AI Act requirements are assessed within the MDR procedure rather than beside it, so the work extends a file you already maintain — risk management, data governance, logging, human oversight and post-market monitoring, mapped onto what exists.
Does clinical decision support for a doctor count as high-risk?
If it is a medical device that must undergo third-party conformity assessment under the MDR — in practice Class IIa and above, which Rule 11 makes the norm for clinical decision support — it is high-risk by the Article 6(1) route. A self-certified Class I device is not. If it is not a device, check Annex III point 5(d) for emergency triage and point 5(a) for access to services. Most decision-support tools land in one of those three.
We are a hospital, not a manufacturer. What is ours?
The deployer set: use the system as instructed, assign competent human oversight, ensure the input data is relevant, retain the logs, and monitor for and report serious incidents. And if you are a body governed by public law — as most public hospitals are — Article 27 applies to you for Annex III systems, other than those in the critical-infrastructure area of Annex III point 2, which Article 27(1) carves out.
Which conformity assessment route applies to us?
Follow the classification. If the AI is a safety component of a device, or is itself a device requiring third-party assessment under the MDR, the AI Act requirements are assessed inside that existing procedure, with the same notified body. If the system is high-risk only through Annex III, Article 43 normally allows internal control without a notified body, unless a specific case provides otherwise. The routes are not interchangeable: picking the wrong one means the wrong evidence and the wrong date.

Check the law yourself

Further reading

Get to compliance with SetAIComply

Classify your system, auto-draft Annex IV documentation, and track every deadline — built for SMEs.