EU AI Act and Healthcare: What AI in Medicine Must Comply With

Two routes to high-risk classification

The EU AI Act (Regulation (EU) 2024/1689) classifies healthcare AI as high-risk through two separate mechanisms. Understanding which one applies to your system matters because it affects your compliance timeline and conformity assessment procedure.

Route 1: Medical devices (Annex I, Section A)

Article 6(1) of the AI Act cross-references Annex I, Section A, which lists Union harmonisation legislation. That list includes Regulation (EU) 2017/745 (the Medical Devices Regulation, or MDR) and Regulation (EU) 2017/746 (the In Vitro Diagnostic Medical Devices Regulation, or IVDR). If your AI system is itself a medical device, or is a safety component of a medical device, it is automatically high-risk under the AI Act.

This covers a wide range of software: diagnostic imaging AI, pathology analysis tools, AI-assisted surgical planning, clinical decision support systems that are classified as medical devices under the MDR, and AI components embedded in physical medical devices. The classification follows the MDR/IVDR classification, not the AI Act’s own risk categories.

The compliance deadline for Annex I high-risk systems has been deferred to 2 August 2028 under the Digital Omnibus (provisional agreement 7 May 2026, European Parliament approved 16 June 2026, approved by Council 29 June 2026, pending OJ publication).

If your system falls under Annex I, the conformity assessment follows the MDR/IVDR procedures. This typically involves a notified body. You do not get to self-assess.

Route 2: Access to essential services (Annex III, Category 5)

Annex III, Category 5 covers AI systems intended for use by public authorities or private entities to evaluate eligibility for essential public and private services, or to grant, reduce, revoke, or reclaim such services. In healthcare, this covers AI used in emergency dispatch systems (determining ambulance priority), triage tools (deciding which patients are seen first), and systems that determine whether a patient qualifies for a specific treatment pathway or service.

This is a different classification from medical devices. An emergency dispatch AI that prioritises 999 calls is not a medical device under the MDR, but it is high-risk under Annex III because it affects access to an essential service.

The compliance deadline for Annex III high-risk systems has been deferred to 2 December 2027 under the Digital Omnibus. Unlike Annex I systems, Annex III high-risk systems generally use provider self-assessment for conformity, unless they also fall under another piece of Union harmonisation legislation that requires third-party assessment.

Emotion inference: the medical exemption

Article 5(1)(f) of the AI Act prohibits AI systems that infer emotions in the workplace and educational institutions. This is a banned practice, enforceable since 2 February 2025. However, the Article explicitly exempts systems used for medical or safety purposes.

What this means in practice: an AI system that monitors patient emotional state for clinical purposes — pain assessment in non-verbal patients, distress detection in mental health settings, affect monitoring during therapy — is permitted. A system that uses the same technology to monitor staff emotions in a hospital workplace is not.

The exemption does not remove other obligations. If the emotion inference system is part of a medical device, it must still meet the full Article 9 risk management and other high-risk requirements. And Article 50 transparency obligations apply regardless: people interacting with the system must be informed that it is performing emotion inference.

For more on what Article 5 prohibits and permits, see the full breakdown of prohibited AI practices.

What Articles 9-15 require for healthcare AI

Once classified as high-risk through either route, your system must meet the requirements of Articles 9 through 15. Here is what each article means for healthcare AI specifically.

Article 9: Risk management

You need a risk management system that runs throughout the entire lifecycle of the AI system. For healthcare AI, this means identifying risks to patient safety and health outcomes, not just commercial risks. A diagnostic AI that misclassifies a malignant tumour as benign is a different category of risk from one that recommends a slightly suboptimal treatment. Your risk management framework must account for the severity and probability of harm, and you must test for foreseeable misuse — clinicians relying on AI outputs without independent verification, for example.

Article 10: Data governance

Training, validation, and testing datasets must be relevant, sufficiently representative, and as free of errors as practicable. For healthcare AI, representativeness is not abstract. If your training data is drawn from one population (say, patients at a single hospital system), the model may perform differently on patients from different demographic or geographic backgrounds. Skin condition classifiers trained primarily on lighter skin tones are a well-documented example. Article 10 requires you to identify and address these gaps.

Article 11: Technical documentation (Annex IV)

You must produce technical documentation following the Annex IV template before placing the system on the market. For medical device AI, this overlaps significantly with the MDR’s own technical documentation requirements, but the AI Act adds AI-specific elements: training methodology, data governance practices, validation results specific to the AI components, and design choices that affect model behaviour.

Article 12: Record-keeping

The system must automatically log its operations at a level that enables traceability. For a diagnostic AI, this means logging each prediction: what input was received, what output was generated, what confidence level was assigned, and ideally what features contributed to the decision. For triage systems, it means logging each patient prioritisation decision with enough detail to reconstruct why patient A was prioritised over patient B.

Article 13: Transparency

Deployers — in this case, hospitals, clinics, and healthcare providers — must be able to understand the system’s capabilities, limitations, and the degree of accuracy achieved in testing. Patients interacting with the system must be informed that AI is being used. This is not a footnote in terms of service. The obligation is to provide clear, accessible information about what the AI does and does not do.

Article 14: Human oversight

A qualified human must be able to understand the AI’s output, intervene, and override it. For healthcare, this typically means a clinician reviews AI-generated diagnoses or recommendations before they are acted on. An AI system that autonomously makes treatment decisions without clinical review does not meet Article 14. The human must have the competence and authority to override, and the system must be designed to support that override.

Article 15: Accuracy, robustness, and cybersecurity

The system must achieve appropriate levels of accuracy for its intended purpose, be resilient to errors, and be protected against adversarial attacks. For healthcare AI, the accuracy requirement has direct patient safety implications. A model with 95% accuracy overall but 70% accuracy for a specific demographic subgroup has an Article 15 problem. Robustness testing must include realistic failure scenarios — what happens when the input data is noisy, incomplete, or from an edge case the model has not seen before.

What Regula can detect

Regula scans source code for patterns that indicate high-risk classification. In healthcare software, it looks for patterns associated with medical device functionality, clinical decision support, diagnostic outputs, and triage or prioritisation logic.

Here is what the scan looks like on a medical AI file:

$ regula check sample_medical.py

Regula Scan: sample_medical.py
============================================================

  Verdict: HIGH-RISK
  Your project is classified as high-risk under EU AI Act Annex III.
  You must comply with Articles 9-15 before the enforcement deadline.

  Why:
    1. sample_medical.py:13 — Access to essential services
       (Art. 9, Art. 10)
  Files scanned:      1
  High-risk:          1

  HIGH-RISK INDICATORS:
    [WARN] [ 70] sample_medical.py — Access to essential services [plan]
      Add explainability and human override for credit/financial decisions

The output identifies the file as high-risk under the “Access to essential services” category. The remediation text references “credit/financial decisions” because this Annex III category covers both healthcare and financial services — Regula uses a generic suggestion for the category. The underlying obligation (explainability and human override) applies equally to healthcare AI under Articles 13 and 14.

If you are not sure whether your AI system falls under the EU AI Act at all, the web assessment tool walks through the scope questions without requiring a CLI installation. For installation and usage instructions, see the Regula homepage. For a broader look at scanning Python projects with Regula, see the Python-specific guide.

What Regula covers and what it does not

Regula can	Regula cannot
Detect code patterns associated with medical device AI or healthcare access systems	Perform clinical validation of your AI model
Generate Annex IV documentation scaffolds	Replace MDR/IVDR conformity assessment procedures
Run a gap analysis against Articles 9-15	Assess clinical safety or patient outcomes
Identify missing transparency notices, logging, and human oversight mechanisms in code	Determine your MDR device classification (Class I, IIa, IIb, III)

Regula is a code scanning tool. It can tell you that your codebase has patterns indicating high-risk classification, that you are missing logging infrastructure for Article 12, or that there is no human override mechanism for Article 14. It cannot tell you whether your model is clinically safe, whether your training data is representative of your patient population, or whether your conformity assessment documentation will satisfy a notified body. Those are questions for your clinical team, your regulatory affairs team, and your notified body respectively.

For a broader view of how code scanning and questionnaire-based compliance tools complement each other, see the risk tiers in code explainer.

Medical device AI vs healthcare access AI: which path are you on?

If you are uncertain which classification route applies to your system, here is a practical test:

• Is the software itself a medical device under the MDR? This is the case if it is intended by the manufacturer to be used for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. If yes, you are on the Annex I path. Deadline: 2 August 2028. Conformity: MDR/IVDR procedures, typically with a notified body.
• Does the software determine access to a healthcare service without being a medical device? Emergency dispatch prioritisation, appointment allocation algorithms, or eligibility screening for treatment programmes. If yes, you are on the Annex III, Category 5 path. Deadline: 2 December 2027. Conformity: self-assessment (unless other legislation applies).
• Both? Some systems are both a medical device and an access-determining tool. In that case, the stricter requirements apply. You follow MDR conformity procedures and meet the AI Act obligations on the Annex I timeline.

If you are still not sure whether the AI Act applies to your system at all, the scope decision tree covers provider vs deployer, territorial reach, and the general-purpose AI carve-outs.

Practical steps for healthcare AI developers

The gap between where most healthcare AI projects are today and where Articles 9-15 require them to be is wide. Here is a priority order for starting compliance work.

1. Determine your classification

Run regula check on your codebase to see what risk patterns are detected. Cross-reference with your intended purpose documentation and your MDR classification (if applicable). The code scan is one input, not the final answer.

2. Start technical documentation early

Article 11 (Annex IV documentation) is consistently the biggest gap in healthcare AI projects. Use regula docs . to generate a scaffold, then fill it in. The template covers system description, intended purpose, training methodology, validation results, and risk management measures. For medical device AI, align this with your MDR technical file.

3. Implement structured logging

Article 12 requires automatic logging of system operations. For diagnostic AI, log every prediction with input metadata, output, confidence, and contributing features. For triage systems, log each prioritisation decision. Build this into the system now rather than retrofitting later.

4. Build human override into the architecture

Article 14 requires that a human can understand, intervene in, and override the system. In healthcare, this typically means clinician review of AI outputs before action. Design the override mechanism as a first-class feature, not an afterthought. The human oversight guide covers the technical requirements in detail.

5. Test for demographic subgroup performance

Article 15 requires appropriate accuracy for the intended purpose, and Article 10 requires representative data. Test your model’s performance across demographic subgroups — age, sex, ethnicity, comorbidity profiles. Document the results, including where performance degrades. Regulators will ask for this.

---

Omnibus caveat: All dates referencing the Digital Omnibus are based on the provisional political agreement of 7 May 2026, approved by the European Parliament on 16 June 2026. The Council approved it on 29 June 2026; publication in the Official Journal is expected before 2 August 2026. Until OJ publication, the original EU AI Act deadlines technically remain in force.

Last verified: 25 June 2026 · Author: Kuziva Muzondo · Sources: Regulation (EU) 2024/1689, Digital Omnibus provisional agreement (7 May 2026) · Not legal advice. Regula identifies risk indicators for developer review.