EU AI Act compliance for healthcare AI in 2026

Annex III of the AI Act contains two healthcare-relevant entries. Point 5(d) covers AI systems "intended to be used by public authorities or on behalf of public authorities to evaluate and classify emergency calls by natural persons or to be used to dispatch, or to establish priority in the dispatching of, emergency first response services, including by police, firefighters and medical aid, as well as of emergency healthcare patients triage systems" [1]. Triage AI used at the front door of public hospitals or used by national emergency-call dispatchers is therefore high-risk on the Annex III dimension.

The second pathway is Article 6(1) and Annex I. AI that is itself a safety component of a product covered by EU harmonisation legislation, or that is itself such a product, becomes high-risk by classification overlap. The Medical Devices Regulation (MDR) and the In Vitro Diagnostic Regulation (IVDR) are listed in Annex I Section A. AI-as-medical-device under MDR Class IIa or above and AI-as-IVD under IVDR Class B or above is high-risk under the AI Act because it is already a regulated medical device [2].

For AI-as-medical-device the existing MDR conformity assessment procedure absorbs the AI Act conformity assessment. Article 43(3) of the AI Act requires that the AI Act technical documentation be integrated into the MDR technical documentation, and the notified body designated under MDR also assesses conformity with the AI Act requirements of Articles 8 to 15 [1]. The result is one notified-body assessment, not two, but the assessment has to cover both regimes and the technical file has to evidence both.

For Annex III point 5(d) triage AI that is not a medical device, the internal-control procedure of Annex VI applies and no notified body is required. The provider runs the self-assessment, draws up the EU declaration of conformity and the technical documentation, and registers the system in the EU database. The MDCG (Medical Device Coordination Group) has issued guidance on the borderline between MDR and the AI Act, which is the canonical reading for AI tools that sit close to but outside the medical device definition.

Three pathways. First, AI-as-medical-device under MDR or IVDR. The intended purpose stated in the device's instructions for use determines the device class; AI Class IIa or above is high-risk under the AI Act by overlap with MDR. Second, Annex III point 5(d) public-authority triage and dispatch. Public hospitals and national emergency dispatchers are inside; private clinics outside the public-authority perimeter generally are not, although the deployer may still trigger Article 26 obligations. Third, Annex III point 1 biometric categorisation - relevant for AI that infers protected attributes from a patient's voice, face or other biometric signal.

The Article 6(3) carve-out applies in narrow cases. A documentation summarisation tool that produces a draft for a human clinician to review is a strong "preparatory task" candidate. A diagnostic AI that produces a confidence-ranked differential is generally not, because the output substantially shapes the clinical decision even with human review. The carve-out has to be documented in the technical file. The European Medicines Agency reflection paper sets parallel expectations on AI used in the medicinal product lifecycle, including discovery, clinical trials, and pharmacovigilance [3].

Annex IV of the AI Act sets the contents [1]. For AI-as-medical-device the Annex IV pack is integrated into the MDR Annex II and Annex III technical documentation. The integration creates two specific deliverables that are uncommon in non-medical AI: a clinical evaluation report, and a post-market clinical follow-up plan. Both extend the AI Act's risk management and post-market monitoring expectations into a clinical-evidence framework where claims have to be supported by published or sponsor-generated clinical study evidence.

For Article 10 data governance, the additional consideration is GDPR Article 9 special-category data. Health data is special-category and may only be processed under one of the Article 9(2) lawful bases. Training a clinical AI on patient records requires either explicit consent (Article 9(2)(a)) or a public-interest research basis (Article 9(2)(j)) or a healthcare-purposes basis (Article 9(2)(h)) supported by Member-State law and professional secrecy. The EDPS and the EDPB have issued joint guidance reflecting these expectations. The WHO ethics and governance guidance for large multi-modal models gives the parallel international floor on validation and bias evaluation [4].

Article 14 expects oversight by a natural person with the competence and authority to override. For diagnostic and triage AI, the meaningful test is whether a clinician can override the system's recommendation in real time, with the override logged and reviewed. The reviewer interface has to surface the input features, the output, the confidence band, and the differential alternatives. Hospital clinical governance committees commonly add a parallel review of override patterns at population level - a model whose overrides cluster on a particular demographic is a model with a representativeness problem.

The MDR Article 14 user-information obligations interact with the AI Act Article 13 transparency obligations. The instructions for use must describe the AI system's intended purpose, performance characteristics, the conditions under which performance was validated, foreseeable misuse, and the human oversight measures. Article 86 of the AI Act gives the patient the right to a clear and meaningful explanation of the role of the AI in any decision producing legal or similarly significant effects, applying from 2 August 2026. For high-risk healthcare AI, the explanation artefact is best designed at build time as part of the clinical evaluation evidence.

Impetora ships every clinical AI system with a written risk classification analysis (MDR overlap yes or no, Annex III point 5(d) yes or no, with the reasoning written out), a data-governance description aligned with Article 10 plus GDPR Article 9 lawful-basis evidence, an integrated AI Act plus MDR technical documentation pack where applicable, a clinical evaluation outline aligned with the MDR clinical evidence framework, a human-oversight design spec mapped to Article 14 and the MDR user-information obligations, an Article 86 explanation artefact, and a post-market monitoring plan that satisfies both the AI Act post-market obligations and the MDR post-market clinical follow-up plan.

For non-medical-device healthcare AI - hospital operations, scheduling, document workflow, internal knowledge - the same Annex IV pack is produced even though no notified body assessment is triggered, because the next deployment context (a clinical pilot, a national emergency-services contract) can trigger MDR or Annex III reclassification. Cross-references: the EU AI Act overview, the healthcare industry hub, the document processing automation use case, and the TRACE methodology.