High-Risk AI Classification in Healthcare, Explained

Status (updated 25 July 2026), next review 1 October 2026.

Founders often ask "is my AI high-risk?" as though there were one test to run. In healthcare there are two separate routes into high-risk status under the EU AI Act, and they work differently enough that conflating them leads to real misclassification. Both routes carry the same obligations and the same timing, covered in the EU AI Act and the 2028 deadlines. This guide keeps them apart and shows how to tell which one applies to you.

In short: Healthcare AI becomes high-risk under the EU AI Act by two routes. Article 6(1) automatically captures AI that is a medical device requiring Notified Body assessment; Annex III lists specific high-risk use cases independent of device status. Most clinical AI startups are caught by the first route, since MDR Class IIa and above means high-risk by default.

The two routes into high-risk

The AI Act's high-risk category isn't a single gate. It's reached by two structurally different mechanisms, and a healthcare AI system can be caught by either one, or in unusual cases both at once.

Route 1, Article 6(1), the sectoral product-safety route. If your AI system is, or is a safety component of, a product already regulated under one of the EU harmonisation laws named in Annex I of the Act, MDR and IVDR among them, and that product requires third-party conformity assessment, the AI system is automatically high-risk. There's no separate use-case judgment call here: your existing product-safety classification does the work. When Medical Device AI Becomes High-Risk covers this route and the obligations that follow it in full.

Route 2, Annex III, the use-case route. Independent of any product-safety framework, the Act lists specific categories of AI use, spanning biometrics, critical infrastructure, education, employment, and, most relevant here, certain uses touching essential services and emergency response, that are deemed high-risk because of what they do rather than what product they're embedded in. Healthcare-adjacent Annex III entries include AI used to evaluate eligibility for essential public assistance benefits and services, and AI used in the context of emergency first-response dispatch. Most direct clinical AI doesn't sit in Annex III at all; it sits in Route 1, because it's already a medical device.

The distinction matters practically because the two routes carry different high-risk timelines — 2 December 2027 for Annex III and 2 August 2028 for Article 6(1) medical devices, under the Digital Omnibus deferral in force from 27 July 2026 — and because a system can, in unusual cases, be caught by both. An AI triage system that is also a regulated medical device and also touches an Annex III-listed emergency-dispatch use case is the clearest example. AI Act Dates After the Digital Omnibus tracks both dates in detail.

Where the dates actually stand

Status (updated 25 July 2026). The Digital Omnibus package that postpones the AI Act's high-risk deadlines was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 and enters into force on 27 July 2026. From entry into force, the deferred dates are the legally binding ones: 2 December 2027 for Route 2 (Annex III stand-alone high-risk systems), and 2 August 2028 for Route 1 (high-risk AI in regulated products, including medical devices under Article 6(1)). The original dates — 2 August 2026 for Route 2 and 2 August 2027 for Route 1 — are superseded. Plan against the deferred dates.

One date is unaffected by any of this and is worth stating plainly, because we've seen it misreported elsewhere: Article 4's AI literacy obligation, which requires organisations deploying AI systems to ensure staff have a sufficient level of AI literacy, has applied since 2 February 2025. It is not tied to the Annex III or Annex I dates, and the Digital Omnibus does not touch it. If your organisation deploys AI systems in any capacity, that obligation is binding today, not at some point on the horizon.

Route 1: the medical-device automatic capture, by MDR class

Because Route 1 follows your MDR classification directly, working through it by class is the clearest way to see how it plays out.

A Class I self-certified device, one that doesn't require Notified Body involvement, generally falls outside Article 6(1)'s automatic capture, because the trigger condition (third-party conformity assessment) isn't met. One footnote to that "generally": Class I devices that are sterile (Is), have a measuring function (Im), or are reusable surgical instruments (Ir) do involve a Notified Body for those limited aspects, which can meet the Article 6(1) trigger despite the Class I label. That's a genuinely different position from Class IIa and above, and it's one reason getting your MDR classification right matters as much as it does: it's the gate for AI Act status too. MDR Rule 11: Why Software Lands in Class IIa covers how software classification is determined.

A Class IIa device using an AI system integral to its function is automatically high-risk under Article 6(1), full stop, once the Article 6(1) date applies (2 August 2028, the deferred date now in force). This is the outcome for most AI-driven clinical decision-support software, since Rule 11 puts most such software in Class IIa by default. One caveat on that premise: a pending Commission proposal to simplify the MDR and IVDR (COM(2025) 1023, procedure 2025/0404(COD)) would move Rule 11 toward a risk-based model under which much stand-alone software would start at Class I — which would take it outside Article 6(1)'s automatic capture. It is a proposal, not law, with adoption realistically 2027 at the earliest, so today's Class IIa default still governs. Class IIb and Class III devices are automatically high-risk on the same basis. The AI Act's obligations apply at the same intensity regardless of whether the underlying device is IIa, IIb, or III; the Act doesn't scale its requirements by MDR sub-class the way MDR itself scales clinical evidence requirements.

Route 2: Annex III health use cases outside MDR

Annex III's list is worth checking even when you're confident your product isn't a medical device, because a small number of entries can apply to healthcare-adjacent AI that never touches MDR at all. The clearest example is AI systems used to evaluate the eligibility of natural persons for essential public assistance benefits and services, including healthcare services, relevant to benefits-navigation or insurance-adjacent health tools that aren't devices in the MDR sense but touch access to care in a way the Act treats as high-stakes.

A second, less obvious category covers AI used in an employment context within healthcare organisations. Recruitment tools, workforce allocation systems, and staff-monitoring AI used by a hospital or clinic operator can fall under Annex III's employment-related entries even though the underlying organisation is a healthcare provider, not because the tool itself does anything clinical. A third category, biometric categorisation and identification systems, can apply to health-adjacent products that use biometric data for purposes beyond the direct medical purpose that would otherwise trigger MDR, such as patient identity verification at scale across a health system.

Most direct-to-clinician or direct-to-patient clinical software doesn't land in Annex III; it lands in Route 1 because it already meets the medical device definition. Annex III is more likely to catch adjacent categories: health-benefits eligibility tools, certain workforce and recruitment tools used by healthcare employers, or biometric categorisation systems used in a health context. If your product doesn't have a medical purpose in the MDR sense but does something on this list, it's worth a specific check rather than assuming healthcare AI is only ever caught through MDR.

A text-based decision tree

Founders tell us the prose version of this logic is hard to follow on a first read, so here's the same test laid out as a sequence of branches you can walk through against your own product.

Step 1. Does your AI system have a medical purpose under MDR, meaning it diagnoses, prevents, monitors, predicts, or treats disease? If no, skip to Step 3. If yes, continue to Step 2.

Step 2. Does that medical-purpose software require Notified Body conformity assessment, meaning it's classified Class IIa or above under Rule 11? If yes, you're high-risk under Route 1 — obligations bind from 2 August 2028 under the Digital Omnibus deferral now in force. If no, meaning your device is Class I self-certified, Route 1 doesn't apply to you, and you move to Step 3 to check Route 2 anyway, since a Class I device can still, in principle, touch an Annex III use case.

Step 3. Does your system perform a function listed in Annex III, most plausibly for healthcare-adjacent tools: benefits or insurance eligibility evaluation, employment decisions within a healthcare organisation, biometric categorisation, or emergency-service dispatch? If yes, you're high-risk under Route 2 — obligations bind from 2 December 2027 under the deferral now in force. If no, your system likely falls outside the Act's high-risk tier.

Step 4, regardless of the outcome above. Does your organisation deploy any AI system, high-risk or not? If yes, Article 4's AI literacy obligation already applies to you, and has since 2 February 2025.

What high-risk status obliges you to do

Whichever route gets you there, the substantive obligations are the same set: a risk management system across the AI system's lifecycle, data governance covering training and testing data quality and bias, technical documentation, automatic logging for traceability, transparency and instructions for professional users, human oversight designed into the system, and tested accuracy, robustness, and cybersecurity. When Medical Device AI Becomes High-Risk covers what these requirements mean in practice, and how they map onto MDR work you may already be doing.

A worked example: a symptom-triage tool

Abstractions are easier to apply with a concrete case. Consider a symptom-triage chatbot deployed by a hospital network: patients describe symptoms, the system suggests a likely urgency level and points them toward emergency care, urgent care, or routine scheduling.

Run it through Step 1: the tool does inform a decision about urgency of care, which touches monitoring and, arguably, a diagnostic-adjacent function, so it likely has a medical purpose. Step 2: given the potential consequence of under-triaging a genuine emergency, this kind of software typically lands at Class IIa or above under Rule 11, which means Route 1 applies once the medical device is Notified-Body-assessed (from 2 August 2028, the deferred date now in force).

Now suppose the same hospital network also uses the tool's output to route calls into its emergency dispatch queue, prioritising which callback happens first. That additional function plausibly touches the Annex III entry for emergency first-response dispatch, meaning this single product could be caught by both routes: Route 1 because it's a regulated medical device, Route 2 because one of its functions overlaps an Annex III use case. In a case like this, the obligations aren't doubled, but the evidence needs to satisfy both bases, and getting an expert read on which specific functions trigger which route is worth far more than working through the general logic alone. This is exactly the kind of case where a five-minute self-assessment isn't the finish line.

What the free MedTech Compass tool actually evaluates

Because we point to a free MedTech Compass tool throughout this content set, it's worth being precise about what it does and doesn't do. The tool walks through the same branching logic laid out in the decision tree above, applied to the specific details you provide about your product's intended purpose, its user base, and its MDR status if known. It gives you an AI-generated first read: a likely route, a likely MDR class if you haven't classified yet, and a plain-language explanation of why.

What it doesn't do is replace a Notified Body's or a regulatory consultant's classification judgment. Edge cases, like the triage-and-dispatch example above, or products whose claims sit ambiguously between wellness and diagnostic, are exactly where the tool's output should be treated as a starting hypothesis rather than a determination you build a compliance programme around.

Edge cases: wellness AI, admin AI, triage tools

A few categories are worth naming because founders ask about them repeatedly. Wellness AI that stays genuinely general, with no diagnostic, therapeutic, or monitoring claim tied to a specific condition, sits outside both MDR and, in most cases, Annex III, and so isn't high-risk under either route. The caveat from our software-classification guide applies equally here: claims, not technology, decide this, and wellness framing that drifts into clinical claims can pull a product into device territory and, from there, into Route 1.

Administrative AI, scheduling, billing, documentation support that doesn't touch diagnosis or treatment decisions, generally sits outside both routes as well, though it's worth checking whether any HR- or employment-adjacent Annex III entries apply if the tool is used in staffing or workforce decisions within a healthcare organisation.

Triage tools, as the worked example above shows, are the genuinely hard case, because they can be caught by both routes depending on exactly how they're designed and deployed. The consequence of getting this wrong, building and deploying a high-risk AI system without the required risk management, data governance, and oversight infrastructure, is a compliance gap that tends to surface at the worst possible time: a Notified Body audit, or a regulator inquiry, rather than during your own planning process.

Frequently asked questions

Can a product be high-risk under both routes at once? Yes, in unusual cases, most commonly triage or dispatch tools that are both a regulated medical device and touch an Annex III-listed use case such as emergency response. Where both apply, the obligations aren't doubled, but evidence needs to satisfy both bases for high-risk status.

Does Route 2 apply outside the EU? No. Both routes are EU AI Act mechanisms and apply to AI systems placed on the EU market or whose output is used in the EU, regardless of where the developing company is based.

If my product is not high-risk under either route, am I fully exempt from the AI Act? Not entirely. Article 4's AI literacy obligation applies to any organisation deploying AI systems, high-risk or not, and has applied since 2 February 2025. You'd be exempt from the substantive high-risk obligations, risk management, data governance, and so on, not from the Act as a whole.

How do I know if my Annex III use case genuinely applies to a healthcare-adjacent product? Read the specific Annex III entry text closely rather than relying on a sector label. The entries are drafted around specific functions, benefits eligibility, employment decisions, biometric categorisation, rather than industries, so a healthcare company's product can sit outside every entry despite operating in a sensitive sector.

Does classification under Route 1 or Route 2 change over time? Yes, if your intended purpose or use case changes. A product that adds a feature touching an Annex III use case, or that changes MDR class as its claims evolve, needs its AI Act classification revisited alongside that change, not assumed fixed at initial launch.

If you want that first read now, the free MedTech Compass can walk through this decision tree against your specific product and give you an AI-generated first read in minutes. It isn't a validated classification. The stakes of getting Route 1 and Route 2 right are high enough to warrant expert review before you build a compliance programme around the answer.

---

Where next: When Medical Device AI Becomes High-Risk · MDR Rule 11: Why Software Lands in Class IIa · AI Act Dates After the Digital Omnibus

Find out in minutes which route applies to your product. Start the MedTech Compass →