EU AI Act Compliance Checklist for Healthcare Deployers

Most hospitals, clinics, and health systems deploying AI are not building it — they are buying it, licensing it, or connecting it to existing clinical workflows. That makes them deployers under Article 26 of Regulation (EU) 2024/1689. Deployers carry lighter obligations than providers, but those obligations are real, documented, and enforceable. This checklist maps the steps a healthcare organisation needs to take, in sequence, from first inventory to ongoing monitoring.

If you need the device-classification angle — how diagnostic AI embedded in a medical device reaches CE marking under MDR 2017/745 — that lives on the healthcare AI and medical devices page. If you are building a governance programme from the ground up, start with the healthcare governance guide. This page is about the operational journey: what you do, in what order, and against which deadlines.

---

Step 1 — Inventory every AI system in use

You cannot classify what you have not found. Healthcare organisations routinely run AI they have not formally catalogued: radiology decision-support integrated into PACS, risk-stratification models embedded in the EHR, triage scheduling tools procured by a department without central IT involvement.

Start with a structured discovery exercise across clinical, operational, and administrative systems. For each system, document the vendor, the intended purpose, the patient population it touches, whether outputs feed into clinical decisions, and whether the vendor has shared a CE-marking or conformity declaration. No system is too minor to log — the Article 6(3) filter (see Step 2) will eliminate low-risk entries; you cannot apply it to systems you do not know exist.

Confir's AI register lets you add each system in plain English and stores the intake answers that drive classification. Rule-based, deterministic: the same inputs produce the same classification every time.

---

Step 2 — Classify each system: two routes to high-risk

Under Article 6, a healthcare AI system reaches high-risk status by one of two routes.

Route A — Safety component of an Annex I product (Art 6(1))

If the AI is a safety component of a medical device regulated under MDR 2017/745 or IVDR 2017/746, it is high-risk by definition. The conformity assessment runs alongside the MDR/IVDR process and the deadline is 2 August 2028. Examples: a CT image-analysis algorithm that flags pulmonary nodules and is embedded in the scanner's software; an in-vitro diagnostic algorithm that interprets biomarker data. For most deploying hospitals, these systems arrive with MDR conformity documentation already in hand — your obligation is to verify it (Step 3).

Route B — Stand-alone Annex III listing

Stand-alone clinical AI that is not embedded in a regulated device reaches high-risk status through Annex III. Two points are directly relevant in healthcare:

• Annex III, point 5(a): AI used in emergency dispatch — systems that determine the priority or urgency of calls, triage patients to emergency resources, or allocate ambulance responses. Deadline: 2 December 2027.
• Annex III, point 5(c): AI used in health and life insurance risk assessment and pricing — if your organisation operates a captive insurer or integrates directly with health insurance eligibility. Deadline: 2 December 2027.

Diagnostic AI tools — the AI that helps a clinician read an imaging scan, spot a sepsis risk score, or predict a deterioration event — typically reach high-risk status via Route A (the MDR/IVDR device route), not Annex III. Do not assume Annex III point 5 covers all clinical decision support. The medical device classification is the spine of clinical AI compliance; Annex III picks up the gaps.

The Art 6(3) filter

A system that falls within an Annex III category is still not high-risk if it does not pose a significant risk of harm — for example, it performs a narrow procedural task, supports a previously completed human assessment without influencing it, or does preparatory work only. Any system that profiles natural persons is always high-risk regardless. If you apply the Art 6(3) filter, document the assessment and register the result under Article 49.

---

Step 3 — Confirm vendor conformity for each high-risk system

As a deployer, you do not run the conformity assessment — the provider does. Your obligation under Article 26 is to use high-risk AI only in accordance with the instructions of use provided under Article 13, and to verify that the provider has completed the required conformity steps.

In practice that means requesting and reviewing:

• The EU Declaration of Conformity (Article 47 / Annex V) — confirms the provider has completed the Article 43 conformity assessment.
• The Annex IV technical documentation — or the relevant summary for deployers, as required by Art 13.
• CE marking for any Annex I device route systems.
• Registration in the EU database under Article 49, which you can cross-check via the public EU AI database (Article 71 establishes the database).

Build a vendor conformity file for each high-risk system. Ask your procurement team to make conformity documentation a contractual condition of supply before a new clinical AI system is signed off.

---

Step 4 — Establish human oversight for clinical AI (Article 14)

Article 14 requires that high-risk AI systems be designed and deployed so that human oversight is possible throughout their use. As a deployer, your obligation is to ensure the oversight measures envisaged by the provider are actually in place — and to assign oversight to specific, competent people.

For clinical AI this has concrete operational implications:

• Clinicians who act on AI outputs (radiologists reviewing AI-flagged findings, emergency physicians acting on triage AI recommendations) must understand the system's limitations, including its performance across different patient populations.
• The organisation must define which decisions require mandatory human review before action — and document that workflow.
• There must be a mechanism for a clinician to override or disregard the AI output without penalty or delay. Article 14(4)(d) specifically requires that operators can choose not to use or override the system.
• New staff using a high-risk AI system need documented orientation on its intended use and known failure modes.

Article 4 (AI literacy, in force since 2 February 2025) already requires organisations to ensure staff using AI have adequate skills and knowledge. The literacy baseline and the Art 14 oversight mandate overlap in clinical settings. Treat them together.

---

Step 5 — Govern health data under GDPR Article 9

Clinical AI operates almost entirely on special-category data. Health data, genetic data, and biometric data used to uniquely identify a person are Article 9 data under the GDPR. Processing them lawfully requires one of the conditions in GDPR Article 9(2) — most commonly, explicit consent (9(2)(a)) or processing necessary for healthcare provision under domestic law (9(2)(h)).

The EU AI Act and the GDPR are separate regulations but the obligations stack. Running a high-risk AI system on patient records without a clear GDPR Article 9 basis is simultaneously an AI Act compliance gap and a data protection breach. Coordinate with your DPO before any high-risk system goes live. Specifically:

• Confirm the Article 9(2) basis for the processing.
• Assess whether a Data Protection Impact Assessment under GDPR Article 35 is required (processing likely to result in high risk to natural persons, including large-scale processing of health data).
• Check the data minimisation and purpose limitation constraints — AI training on identifiable patient data for a purpose beyond direct care generally requires a separate legal basis.

If your organisation has already conducted a GDPR DPIA for an AI system, Article 27(4) of the AI Act permits the Fundamental Rights Impact Assessment (FRIA) to build on it. The FRIA under Article 27 applies to deployers in certain categories — primarily public-body deployers and deployers of health/life insurance systems under Annex III point 5(c). Most hospital deployers running clinical AI are exempt from the FRIA requirement unless they are public bodies or running insurance-pricing AI.

---

Step 6 — Keep logs (Article 26)

Deployers of high-risk AI systems must retain logs generated automatically by the system for a minimum of six months under Article 26. For clinical AI, this means the system's outputs — the scores, flags, recommendations, or alerts it generated — must be preserved for that period and be retrievable.

In practice, logs from AI systems embedded in EHR or PACS workflows may be stored in the clinical record system automatically. Confirm that the logs meet the minimum retention requirement, are attributable to the specific AI system, and are accessible if a supervisory authority or patient requests them.

Log retention of ten years applies to technical documentation maintained by providers under Article 18 — that is a provider obligation, not a deployer one.

---

Step 7 — Establish incident reporting (Article 73 + MDR vigilance)

Providers carry the formal duty under Article 73 to report serious incidents — defined in Article 3(49) as incidents that have or could have resulted in a patient's death or serious health deterioration — to the relevant market-surveillance authority. The timelines are short: 15 days from awareness (Art 73(2)), 2 days for widespread or serious-and-irreversible harm (Art 73(3)), 10 days where a person has died (Art 73(4)).

As a deployer, your obligation is operational: Article 26 requires you to monitor the AI system's performance, identify serious incidents or risks, and notify the provider immediately. The provider then handles the formal report to authorities. In practice, write this notification duty into your contracts with AI providers — you need a named contact and a response SLA.

For AI embedded in a medical device, the incident-reporting chain runs through the MDR/IVDR vigilance system in parallel. A malfunction in an AI-enabled device that leads to patient harm triggers both the AI Act notification path and the MDR Article 87 serious-incident reporting to the relevant national competent authority. Draft a single joint escalation procedure that satisfies both requirements rather than running two separate workflows.

---

Step 8 — Set up ongoing post-deployment monitoring

The compliance clock does not stop at go-live. Article 26 requires deployers to monitor the operation of high-risk AI systems on the basis of the instructions of use and report anomalies or unexpected behaviour to the provider.

Define, at minimum, three operational controls before deployment:

1. Performance review cadence: schedule a quarterly review of the system's outputs against clinical benchmarks. AI model performance can degrade when the real-world patient population shifts from the training population — a risk especially relevant in post-pandemic or post-restructuring contexts.
2. Anomaly escalation path: designate a clinical AI lead who receives reports from staff and is responsible for escalating to the vendor and, if serious, to the internal incident process described in Step 7.
3. Periodic re-validation: when the system is updated by the vendor, require updated performance data. A substantial modification by the provider may trigger a new conformity assessment on the provider's side; you need to know when that has happened.

---

The penalty exposure is real

Healthcare is not exempt from Article 99. Failure to comply with high-risk deployer obligations — including the Article 26 use, monitoring, and logging duties — falls under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. A district hospital with €80M annual turnover has a maximum exposure of €2.4M under the percentage tier.

The penalties framework has been active since 2 August 2025. What changes at the 2027/2028 deadlines is the mandatory application of the substantive high-risk obligations; the enforcement machinery is already running.

---

How Confir helps

Confir's classification logic works the same way for a hospital deployer as it does for a SaaS provider. Answer plain-English questions about each AI system; the rule-based engine derives the risk tier, the route (Annex I device or Annex III), the applicable deadline, and the deployer obligation set. For each high-risk system, the structured assessment (AIGM module: Article 9, 72, 73; AITO module: Article 13, 14, 27) walks you through the checklist items in Steps 4–8 and generates an auditable record of what you have confirmed.

A mid-size NHS trust or German Klinik running five to fifteen clinical AI systems can complete initial classification in under two hours. No consultants, no six-month implementation.

---

Frequently Asked Questions

Is a hospital a provider or a deployer under the EU AI Act?

It depends on what the hospital does with the AI. A hospital that licenses or procures an AI system from a third-party vendor and uses it in clinical operations is a deployer under Article 26. A hospital that builds its own diagnostic AI and puts it into service under its own name becomes a provider under Article 16, inheriting the full obligation set (Articles 9–15, 17, 43, 47, 49, 72, 73). Most healthcare organisations are deployers; the obligations are real but lighter than the provider stack.

Which clinical AI systems are actually high-risk under the EU AI Act?

The two main routes: (1) AI that is a safety component of a medical device regulated under MDR 2017/745 or IVDR 2017/746 is high-risk via Article 6(1), with a deadline of 2 August 2028. (2) Stand-alone AI used in emergency dispatch (Annex III point 5(a)) or health/life insurance risk assessment (point 5(c)) is high-risk via Annex III, deadline 2 December 2027. General clinical decision-support tools not embedded in a regulated device often reach high-risk status only through route (1). The Article 6(3) filter can remove a system from high-risk if it poses no significant harm risk and does not profile natural persons — but that finding must be documented.

What must a hospital actually check when a vendor says their AI is compliant?

Request the EU Declaration of Conformity under Article 47 (Annex V format), confirm it references a completed Article 43 conformity assessment, check the system is registered in the EU database under Article 49, and verify the instructions of use under Article 13 are in a language usable by your clinical staff. For device-route AI, check CE marking and the MDR/IVDR conformity documentation. Put the obligation to provide updated documentation in the supply contract.

Does the EU AI Act require hospitals to do a Fundamental Rights Impact Assessment?

Article 27 requires a FRIA from deployers that are public bodies, or deployers using Annex III point 5(b) creditworthiness AI, or Annex III point 5(c) health/life insurance AI. A private hospital deploying clinical decision-support AI under the device route is generally not required to run a FRIA. A public hospital or NHS trust deploying AI that falls under point 5(a) (emergency dispatch) or that qualifies as a public body for other high-risk purposes should assess Article 27 applicability with legal counsel. The FRIA may build on an existing GDPR DPIA under Article 27(4).

When do high-risk obligations apply to healthcare AI?

The substantive high-risk obligations apply from 2 December 2027 for stand-alone Annex III systems (emergency dispatch, health insurance) and from 2 August 2028 for AI embedded in Annex I regulated medical devices. Article 4 (AI literacy) applied from 2 February 2025. The penalties under Article 99 have applied since 2 August 2025 — so enforcement authority exists now, even if the full high-risk obligation set triggers later. Starting the deployer checklist now is not precautionary; it is operationally necessary given documentation and vendor-verification lead times.

What are the logging obligations for hospital deployers?

Article 26 requires deployers to retain logs automatically generated by the high-risk AI system for at least six months. The ten-year documentation retention obligation under Article 18 falls on providers, not deployers. Confirm with each vendor which logs the system generates, whether they are stored in your EHR or PACS, and that they satisfy the six-month minimum and are attributable to the specific system.

How does incident reporting work when a clinical AI system causes patient harm?

The provider holds the Article 73 duty to report serious incidents to the market-surveillance authority — within 15 days from awareness, 2 days for widespread or irreversible harm (Art 73(3)), 10 days where a person has died (Art 73(4)). As a deployer, you must notify the provider immediately when you become aware of a serious incident or malfunction. For AI embedded in a medical device, MDR/IVDR vigilance reporting runs in parallel — draft a single joint escalation procedure to avoid gaps between the two regimes.

---

Related guides

• EU AI Act compliance for small businesses
• healthcare AI and medical devices (device route)
• healthcare governance programme
• AI risk classification levels
• Article 6 high-risk classification
• Article 26 deployer obligations
• Article 14 human oversight requirements