Radiology AI, clinical decision support software, AI-assisted diagnostics, and other medical AI systems are high-risk under the EU AI Act — typically entering through the Annex II medical device route. Whether you are a MedTech company building AI or a hospital deploying it, here is exactly what you need to do before August 2, 2026.
Unlike employment AI (which is listed by name in Annex III), most medical AI enters the high-risk category through a different mechanism: the Annex II route. Under Article 6(1) of the EU AI Act, any AI system that is a safety component of a product covered by EU harmonisation legislation listed in Annex II is automatically high-risk. Medical Device Regulation (MDR) and the In Vitro Diagnostic Regulation (IVDR) are both in Annex II.
In practical terms: if an AI system is classified as a medical device under MDR, or is an integral safety-critical component of one, it is high-risk under the EU AI Act. There are two routes to high-risk status for healthcare AI:
Any AI system that is itself a medical device — or a safety-critical component of one — under the Medical Device Regulation (MDR, Regulation 2017/745) or In Vitro Diagnostic Regulation (IVDR, Regulation 2017/746) is automatically high-risk under the EU AI Act.
Examples in scope
AI systems used by emergency first responders — including emergency medical services — to dispatch personnel, prioritise incidents, or allocate resources are high-risk under Annex III Section 5(f) regardless of the medical device classification.
Examples in scope
Medical Device Software (MDSW) is classified as a medical device when it is intended to be used for one or more specific medical purposes for an individual patient — including diagnosis, prevention, prediction, prognosis, monitoring, treatment, or therapy management.
The European Commission's MDCG 2019-11 guidance provides the definitive test for Clinical Decision Support (CDS) software: software that makes or influences a clinical decision for a specific patient — rather than simply providing general information or operating on population-level data — is a medical device.
Likely a medical device (high-risk AI)
Probably not a medical device
When in doubt, the conservative position is to treat the software as a medical device and seek a formal classification opinion from your notified body. Using unclassified software in clinical settings creates both patient safety and regulatory risk.
Most administrative and operational AI used in healthcare settings does not constitute a medical device and is not high-risk under the EU AI Act. The distinction is whether the AI makes or influences individual patient clinical decisions.
| Healthcare AI tool | Why it is NOT high-risk |
|---|---|
| AI for hospital appointment scheduling | Administrative workflow only — no clinical decisions about patient care. |
| AI for medical billing and coding | Financial/administrative process with no direct impact on patient safety or clinical outcomes. |
| AI for hospital bed management and logistics | Operational resource allocation not directly linked to individual patient clinical decisions. |
| AI drug discovery tools used only in research labs | Not used in individual patient care decisions. Research software is generally not an MDR medical device. |
| General AI wellness apps (steps, sleep tracking) | Not making clinical claims or intended for medical diagnosis. Not a medical device. Article 50 chatbot disclosure may still apply. |
| AI-assisted medical literature search | Information retrieval only — no individual patient assessment. Not in scope unless it generates patient-specific recommendations. |
| AI transcription for clinical notes | Documentation tool only. No clinical judgement. Standard data protection rules apply. |
The EU AI Act treats MedTech companies that build medical AI very differently from hospitals and clinics that use it. Your obligations depend on your role.
Provider obligations are substantial: 8 obligations including technical documentation (Annex IV), risk management system, conformity assessment, EU registration, and post-market monitoring.
Most healthcare organisations fall here. Six deployer obligations under Article 26 apply — including patient notification and documented clinician oversight.
If you build and market medical AI — whether as a standalone product or as an AI-powered feature of a medical device — you are a provider with eight obligations under the EU AI Act. These run in parallel to your MDR/IVDR obligations, not instead of them.
Implement and maintain a continuous risk management process across the AI system's lifecycle. For MedTech companies with existing MDR quality management systems (ISO 13485), this extends rather than replaces your existing risk management — but AI-specific risks (bias in training data, distribution shift between training and deployment environments, cybersecurity vulnerabilities) must be explicitly addressed.
Training, validation, and test datasets must be subject to documented governance practices. For medical AI this means: examining datasets for biases across protected characteristics (age, sex, ethnicity) and clinical subgroups; ensuring training data is representative of the intended clinical population; documenting data provenance, labelling methodology, and inter-annotator agreement; and applying appropriate data augmentation only where clinically justified.
Prepare and maintain comprehensive technical documentation covering 9 areas: (1) general description and intended purpose; (2) a detailed description of the system including architecture, algorithms, training methodology; (3) information on training, validation and testing; (4) monitoring, functioning and control measures; (5) risk management documentation; (6) change documentation; (7) post-market monitoring plan; (8) EU declaration of conformity; (9) conformity assessment documentation. For MDR-regulated AI, significant overlap exists with the MDR Technical File (Annex II MDR) — but the AI Act's Annex IV is a distinct requirement and may not be fully satisfied by MDR documentation alone.
The AI system must be designed and built to allow effective human oversight. For clinical AI, this means: providing confidence scores or uncertainty quantification alongside outputs; clear visualisation of what the AI detected and why; the ability for clinicians to override or disregard AI outputs without penalty; alerting clinicians when the AI encounters inputs outside its training distribution (out-of-distribution detection); and not presenting AI outputs in ways that anchor or unduly influence clinical judgement.
The AI system must achieve appropriate accuracy for its intended purpose, remain robust against errors and inconsistencies in input data, and meet cybersecurity standards. Clinical AI must specify validated performance metrics (sensitivity, specificity, AUC) for defined use cases. It must be tested for resilience to image quality variations, scanner differences, and demographic shifts. Cybersecurity requirements align with MDR Annex I Section 17 — but the AI Act adds requirements for resilience against adversarial inputs.
Provide deployers (hospitals, clinics, labs) with sufficient information to make informed decisions about using the AI system: its intended purpose, performance characteristics on defined populations, known limitations and contraindications, the level of human oversight required, and instructions for monitoring performance in the deployment environment. This is in addition to MDR's Instructions for Use (Annex I, section 23 MDR).
High-risk AI systems must undergo a conformity assessment before being placed on the market. For medical AI, the appropriate pathway depends on the MDR device class of the product. Many AI medical device manufacturers will complete this through a notified body already engaged for MDR certification (such as BSI, TÜV SÜD, DEKRA) — but the AI Act conformity assessment is separate from the MDR conformity assessment, even if the same notified body conducts both. After conformity assessment, AI providers must affix CE marking and register the system in the EU AI Act database.
Maintain a post-market monitoring system to collect and analyse data on the AI system's performance in real clinical use. Report serious incidents (where the AI system contributes to a death, serious injury, or a significant malfunction) to market surveillance authorities within defined timeframes. This aligns with MDR Article 87 vigilance reporting — but the AI Act's reporting obligations are distinct and may cover AI-specific failure modes not covered by the MDR vigilance system.
Medical AI is the only category of AI that faces two comprehensive regulatory regimes simultaneously. MDR/IVDR governs safety and performance from a patient risk perspective; the EU AI Act adds AI-specific requirements on top. They do not substitute for each other.
| Requirement | MDR/IVDR | EU AI Act |
|---|---|---|
| Technical documentation | MDR Annex II Technical File | AI Act Annex IV — significant overlap but separate document |
| Risk management | ISO 14971 risk management | Article 9 AI-specific risk management (bias, distribution shift, adversarial robustness) |
| Quality management system | ISO 13485 QMS required | Article 17 quality management system — compatible, not identical |
| Clinical/performance evidence | Clinical Evaluation Report required | No separate clinical evaluation — but accuracy/robustness requirements (Article 15) are parallel |
| Post-market surveillance | MDR Article 83 PMSS + PMCF | Article 72 post-market monitoring — additional AI-specific performance monitoring |
| Incident reporting | MDR Article 87 vigilance (serious incidents) | Article 73 serious incident reporting — separate reporting channel to AI market surveillance authorities |
| Conformity assessment | Notified body for Class IIa+ devices | Conformity assessment under AI Act — can share notified body but is a separate process |
| CE marking | MDR CE mark | Separate AI Act CE mark required before placement on EU market |
The good news: significant documentation work done for MDR (technical file, clinical evaluation, QMS, PMCF) can be adapted for AI Act Annex IV and Article 9 purposes. The investment is not wasted — it is extended, not duplicated.
If you are a healthcare organisation using AI tools from a vendor — even an AI system with full MDR CE marking — these six obligations under Article 26 of the EU AI Act apply to you directly. They cannot be delegated to the vendor.
Deploy the AI system strictly within its validated intended purpose and clinical indication. Do not use a radiology AI validated for chest X-ray analysis on CT scans if the Instructions for Use do not cover that modality. Do not extend the AI's use to patient populations, clinical settings, or imaging equipment outside the validated scope.
Designate qualified clinical staff to perform human oversight of AI outputs. For radiology AI, this means a radiologist must review every AI finding before it influences a clinical decision — the AI is a second reader or priority filter, never the sole reader. For clinical decision support, a clinician with appropriate competence must review and take responsibility for any AI recommendation. Document who is responsible for oversight in each clinical context.
Where you control the data fed into the AI system — patient images, electronic health record inputs, laboratory results — you are responsible for ensuring that data is of sufficient quality and relevance. This is especially important in healthcare: poor image quality, incomplete data, or data from patient populations outside the AI's validated scope can lead to inaccurate outputs. Implement quality checks before feeding data to AI systems.
Patients have a right to know when high-risk AI systems are used in clinical decisions that affect them. This does not require obtaining specific consent for AI use (separate from the consent framework for treatment), but patients must be informed — in patient-facing materials, during admission or consent processes, or via the organisation's patient information notices — that AI tools are used in their care pathway. The notification must be clear, not buried in small print.
Where the AI system generates logs (as required under Article 12 of the AI Act for providers), you must retain those logs. In clinical practice: retain records of which AI systems were used in each patient's care, what outputs they produced, which clinician reviewed the outputs, and what clinical decision was ultimately made. Log retention intersects with clinical records retention obligations under national healthcare law — coordinate with your Caldicott/DPO function.
If you have reason to believe the AI system is not conforming to the EU AI Act — for example, because the vendor cannot provide required documentation, because you observe unexpected outputs that suggest the system is performing outside its validated operating range, or because a safety incident is reported — you must suspend use and notify the provider. You cannot continue using a potentially non-conforming clinical AI system because switching it off is inconvenient.
Article 27 of the EU AI Act requires deployers to carry out a Fundamental Rights Impact Assessment (FRIA) before deploying a high-risk AI system when they are a public body, or when the AI system is deployed under a Union or national legal obligation.
In practice, this means: NHS trusts, health boards, public hospitals, ICS organisations, and other public healthcare bodies that deploy high-risk clinical AI must conduct a FRIA. The FRIA must assess the system's impact on:
The FRIA is distinct from and goes beyond a standard GDPR DPIA. It should be conducted before deployment, revisited when the AI system is updated or used in a new clinical context, and made available to market surveillance authorities on request.
This table provides general guidance — the actual classification of any specific tool depends on its intended purpose, clinical function, and the vendor's MDR registration status. Always confirm MDR/IVDR classification with the vendor before deploying in clinical settings.
Analyses medical images to detect pathology. These are medical devices under MDR. AI Act high-risk via Annex II (Article 6(1)).
Hospitals are deployers. Contact vendor for AI Act technical documentation and instructions for use.
Interprets biopsy images for diagnosis. Classified as an IVD or MDR medical device. AI Act high-risk via Annex II.
As a deployer (hospital/lab), implement Article 26 obligations: human oversight by a qualified pathologist, patient notification, log retention.
If it provides patient-specific recommendations that influence clinical decisions for a specific patient, it is likely an MDR medical device and AI Act high-risk.
Verify MDR classification with vendor. If high-risk: human clinician must review all recommendations; override is mandatory, not optional.
Predictive risk scoring for clinical intervention (e.g. sepsis, deterioration) is a safety-critical clinical decision support tool — typically MDR Class IIa or above.
Deployer obligations apply. Nurse/clinician review of all alerts is required. Document the oversight protocol.
Real-time AI analysis of endoscopy video to detect or characterise lesions. Medical device under MDR. AI Act high-risk via Annex II.
As a deployer (endoscopy unit), document human oversight by the endoscopist. Ensure vendor provides conformity documentation.
Depends on scope. If it provides symptom-specific medical guidance that could influence a patient's care decision, it may be an MDR medical device. Broad wellness Q&A chatbots may not be.
Assess whether the tool makes patient-specific clinical recommendations. At minimum: Article 50 chatbot disclosure applies. Consult vendor for MDR classification.
Aggregate population-level analysis not linked to individual patient decisions: generally not high-risk. If outputs are used to make decisions about individual patients' care, it may be in scope.
Examine whether outputs drive individual patient-level clinical decisions. If so, treat as high-risk.
Administrative tools with no clinical decision-making function. Not a medical device. No Annex II or Annex III pathway.
No high-risk AI Act obligations. Standard GDPR data protection rules apply to any staff or patient data processed.
Conduct a clinical AI inventory
List every AI-powered tool used in patient-facing clinical workflows: radiology AI, clinical decision support, diagnostic software, patient monitoring AI, triage tools. Exclude administrative tools (scheduling, billing) from this list — they are out of scope.
Confirm MDR/IVDR classification for each tool
For each clinical AI tool, contact the vendor and ask: (1) Is this product classified as a medical device under MDR or IVDR? (2) What is the CE certification number and which notified body assessed it? Any tool that is a medical device is automatically high-risk under the EU AI Act.
Request AI Act documentation from vendors
Ask each vendor for their EU AI Act conformity documentation: Instructions for Use under Article 13, evidence of completed or in-progress conformity assessment, technical documentation summary, and their planned EU AI Act database registration date. If a vendor cannot provide this, escalate — you cannot deploy a non-compliant high-risk AI system.
Implement and document clinician oversight protocols
For each high-risk clinical AI tool, document the human oversight process in your clinical procedures: which clinical role is responsible for reviewing AI outputs, what training they must have, and how AI recommendations are recorded alongside the clinician's independent decision. Update relevant SOPs and clinical guidelines.
Add patient notification to admission and consent materials
Update your patient information materials — admission forms, consent forms, patient information leaflets, and your privacy notice — to disclose that AI tools may be used in your care. The disclosure does not need to name specific products but should describe the category of use (e.g. "AI-assisted image analysis" or "AI clinical decision support tools used in your care pathway").
Conduct FRIA if required and establish log retention
If you are a public healthcare body or NHS trust: initiate a Fundamental Rights Impact Assessment for each high-risk AI deployment. Establish log retention for AI tool outputs — at least 6 months from each use — and align with your clinical records management policy. Coordinate with your Caldicott Guardian or DPO.
No. CE marking under the Medical Device Regulation and CE marking/conformity assessment under the EU AI Act are separate requirements. MDR regulates the medical device as a whole (safety, performance, clinical evidence). The EU AI Act additionally requires AI-specific risk management (Article 9), data governance (Article 10), Annex IV technical documentation, human oversight by design (Article 14), and EU AI Act database registration (Article 49). Many of the requirements overlap and supporting documentation prepared for MDR can be adapted — but MDR compliance alone does not satisfy EU AI Act obligations. Your vendor should confirm both.
It depends on its intended purpose and function. The MDCG 2019-11 guidance provides the key test: software that is intended to make or influence a clinical decision for an individual patient — including diagnosis, prevention, prediction, prognosis, treatment, or therapy monitoring — is likely to be a medical device. Software that only provides general information, educational content, or operates on population-level data without individual patient outputs is generally not. If your CDS tool generates a patient-specific recommendation (e.g. "this patient is at high risk of sepsis") rather than general statistical information, treat it as a medical device until confirmed otherwise.
Both obligations apply, and you are primarily a provider. When a healthcare organisation develops an AI system for internal use in patient care — even if it is never sold externally — it is considered the provider of that system under the EU AI Act. This means all provider obligations apply: risk management, technical documentation, conformity assessment, and (if the system meets the definition of a medical device under MDR) MDR compliance as well. Building your own clinical AI is a significant regulatory undertaking that most hospitals are not resourced to manage without specialist regulatory affairs support.
Under Article 27, a FRIA is required for public bodies and for private organisations that deploy high-risk AI systems under a legal obligation. Most NHS trusts, public hospitals, and healthcare organisations operating under a statutory framework will fall into this category. Private hospitals and clinics that deploy high-risk AI systems as part of a regulated healthcare service may also be required to conduct one. A FRIA must assess the impact of the AI system on fundamental rights — including non-discrimination, privacy, access to healthcare, and dignity — in the specific deployment context. It goes beyond a standard DPIA.
Generally, AI used solely for drug discovery research — identifying targets, screening compounds, predicting molecular properties — is not high-risk under the EU AI Act, because it does not directly make clinical decisions about individual patients. However, if your AI is used to support regulatory submissions or clinical trial design in ways that could affect which patients receive which treatments, the picture becomes more complex. AI used in clinical trial patient selection may intersect with Annex III categories depending on the specific function. Consult your regulatory affairs team if AI outputs influence clinical trial protocol design or patient enrolment.
Probably not, if it provides only general wellness information without patient-specific medical claims. However, if your app makes claims about detecting or managing specific medical conditions (e.g. "detects atrial fibrillation", "monitors your diabetes", "identifies signs of depression"), those claims trigger MDR classification. Once classified as a medical device, the AI components become high-risk under the EU AI Act. Be very careful about clinical claims in marketing, Terms of Service, and in-app messaging — these are what regulators use to determine intended purpose.
Start with a clinical AI inventory: list every software tool used in patient-facing clinical workflows. For each, ask: (1) does it make or assist in patient-specific clinical recommendations? (2) does it have MDR CE marking? (3) who is the provider? Then prioritise: any tool that is MDR-certified and AI-based almost certainly requires you to implement Article 26 deployer obligations. Contact each vendor for their EU AI Act documentation. Implement patient notification in admission/consent materials. Document clinician oversight protocols for each AI tool. This is achievable by August 2 for most organisations.
Yes. The EU AI Act has extraterritorial effect: it applies when AI systems are placed on the EU market or their outputs are used within the EU, regardless of where the provider is based. A US MedTech company selling AI diagnostic software to EU hospitals must comply with EU AI Act provider obligations. As a hospital deployer, your own Article 26 obligations apply regardless of the vendor's location. If the vendor cannot provide required technical documentation or conformity assessment evidence, you may need to consider alternative suppliers or request that they complete EU compliance before the August 2026 deadline.
Use the free EU AI Act risk classifier. Answer 5 questions about your AI system and get an instant classification — Prohibited, High-Risk, Limited Risk, or Minimal Risk — with your specific obligations listed.
Classify your healthcare AI — free