Diagnostic Medical Imaging AI: High-Risk Classification, MDR Overlap & Compliance Obligations

A CT scan that flags a pulmonary nodule. An MRI algorithm that segments a tumour. A mammography system that scores lesion suspicion. All three are AI — and all three are also medical devices under EU law. That overlap is not incidental: it is the key to understanding how the EU AI Act regulates diagnostic imaging software, which obligations fall on whom, and when the clock runs out.

This guide is for imaging-AI vendors (the provider under Regulation (EU) 2024/1689) and for hospitals and radiology practices that deploy these systems (the deployer). Both roles carry obligations. They are different obligations, and the conformity assessment sits entirely on the vendor's side.

---

The classification question: Annex III or Article 6(1)?

The original version of this page placed diagnostic imaging AI in Annex III. That was wrong, and the error matters in practice.

Annex III lists eight high-risk use-case categories — biometrics, employment, creditworthiness, emergency dispatch, and so on. Diagnostic medical imaging is not in that list. The EU AI Act's drafters did not need to put it there, because it was already caught by a different and more stringent route: Article 6(1) + Annex I.

Article 6(1) makes an AI system high-risk when two conditions are both satisfied:

1. The AI system is intended to be used as a safety component of a product (or is itself a product) covered by Union harmonisation legislation listed in Annex I of the AI Act.
2. That product is required to undergo third-party conformity assessment before it can be placed on the market under the same Annex I legislation.

Both conditions are met for diagnostic imaging software. Annex I of the AI Act, at items 11 and 12, lists the Medical Devices Regulation — Regulation (EU) 2017/745 (MDR) — and the In Vitro Diagnostic Medical Devices Regulation — Regulation (EU) 2017/746 (IVDR). Diagnostic imaging software that detects, diagnoses, monitors, or predicts disease states qualifies as a medical device under MDR Article 2(1) (or as an IVD under IVDR where the analysis draws on biomarkers in body samples). Most imaging AI vendors classify their products as Class IIa, IIb, or III devices under MDR Annex VIII, all of which require third-party notified-body conformity assessment under MDR Article 52.

Both conditions are therefore satisfied. The system is high-risk under Article 6(1), not under Article 6(2)/Annex III.

Why the distinction matters

It is not just a technical footnote. Three practical consequences follow from the correct classification.

Deadline. For Annex III stand-alone systems, the Digital Omnibus (political agreement reached 7 May 2026) sets the application date at 2 December 2027. For Article 6(1) systems — high-risk AI embedded in products subject to Annex I legislation — the date is 2 August 2028. Diagnostic imaging AI vendors have until 2 August 2028, not December 2027. That is a meaningful difference for a product that must also clear MDR conformity assessment.

Conformity assessment integration. For Annex III systems, conformity assessment under the AI Act (Article 43) runs as a distinct process, typically using the internal-control procedure in Annex VI or the notified-body QMS procedure in Annex VII. For Article 6(1) systems, Article 43(3) provides that the AI Act requirements are folded into the existing MDR/IVDR notified-body conformity assessment. There is no separate AI Act conformity assessment procedure. The same notified body that reviews the device under MDR also checks AI Act compliance as part of that assessment. No double assessment.

Supervision. Market surveillance for Article 6(1) systems integrates with the sectoral regulator. MDR vigilance reporting (MDR Article 87 and the related EUDAMED database) runs alongside the AI Act's serious-incident reporting under Article 73.

---

What counts as diagnostic medical imaging AI?

The test is functional: does the software output a clinical finding, a risk score, or a recommendation that directly influences a diagnostic or treatment decision about a named patient?

Systems that typically fall within scope:

• Radiology AI that detects lesions, segments anatomical structures, or scores findings in CT, MRI, PET, X-ray, or ultrasound
• Mammography AI that stratifies lesion risk or generates a BI-RADS score
• Pathology AI that analyses digitised biopsy slides for malignancy markers
• Ophthalmic AI that grades diabetic retinopathy from fundus images
• Cardiac AI that measures ejection fraction or flags arrhythmia from echocardiograms

Systems that typically fall outside the high-risk designation:

• Image pre-processing tools that enhance contrast or reduce noise without producing a clinical output
• Administrative routing software that directs scans to a worklist based on modality, without interpreting content
• Quality-control software that flags technically inadequate scans for repeat imaging
• Research-only analysis tools that operate exclusively on anonymised retrospective datasets with no patient-level clinical output

The boundary is clinical output. An algorithm that tells a radiologist "this nodule has a 14 mm diameter" is part of a regulated diagnostic chain. An algorithm that rotates an image for easier viewing is not.

---

Provider obligations: what the imaging-AI vendor must do

Under Regulation (EU) 2024/1689, the provider is the entity that places the AI system on the market or puts it into service under its own name or trademark — in practice, the imaging-AI company that develops and sells the software. The provider carries the heaviest obligations.

Risk management system (Article 9)

You must establish, document, and maintain a risk management system throughout the product's lifecycle. For medical imaging AI, this means identifying foreseeable failure modes (false negatives, false positives, distribution shift when the system is used on equipment not in the training set), assessing clinical consequences for each, setting acceptable thresholds, implementing technical controls, and validating that those controls remain effective through post-market monitoring.

The Article 9 risk management plan runs alongside — and must be consistent with — the MDR risk management process under ISO 14971. In practice, most MDR-compliant vendors already have an ISO 14971 framework; Article 9 adds explicit requirements around fundamental rights and the EU AI Act's particular concerns (bias across patient subgroups, performance on underrepresented populations, transparency to deployers).

Data and data governance (Article 10)

Training, validation, and test datasets must be relevant, sufficiently representative, and free from errors that could generate discriminatory outputs. For imaging AI, this requires documented demographic breakdowns of training data — age, sex, ethnicity, scanner model, acquisition protocol — and explicit acknowledgement of populations the model was not trained on. A system trained predominantly on CT scans from three academic centres in Western Europe may perform differently in a district hospital in Bucharest using a different scanner generation. Article 10 requires you to document that, not ignore it.

Technical documentation (Article 11, Annex IV)

Technical documentation under Annex IV is the evidence package that demonstrates compliance before market entry. For imaging AI it must cover: a full description of the system's architecture and intended purpose; the training, validation, and test data specifications; performance metrics stratified by clinically relevant subgroups; validation against a ground-truth reference standard (radiologist consensus, pathology confirmation, longitudinal outcomes); identified limitations; and instructions for use including valid operating conditions.

This documentation does not live in isolation. The MDR Technical File — the Clinical Evaluation Report in particular — will overlap with the Article 11 technical documentation. Experienced teams build one integrated documentation structure rather than two parallel sets of files.

Transparency and information to deployers (Article 13)

The instructions for use must tell the hospital or radiology practice everything it needs to correctly deploy the system. This includes: the intended patient population and validated clinical indications; scanner models and acquisition protocols within the validated scope; contraindications; a description of what the system outputs and what confidence or uncertainty indicators mean; the procedure for human review; and clear instructions on what to do when the system outputs a low-confidence result or an out-of-distribution flag.

Human oversight by design (Article 14)

You must design the system so that deployers can effectively oversee its operation. Concretely: outputs must be interpretable by a qualified clinician without specialist AI expertise; the system must flag results where model confidence is low; and the interface must make it straightforward for a radiologist to override or modify a finding. Human oversight is not a deployer add-on — it is a design requirement on the vendor.

Accuracy, robustness, and cybersecurity (Article 15)

Performance must be appropriate for the intended purpose and maintain acceptable levels of accuracy across the system's operational lifecycle. For imaging AI this means resistance to image artefacts, equipment drift, and changes in patient mix. Cybersecurity measures must prevent manipulation of inputs or outputs — a realistic concern for networked imaging software connected to hospital PACS systems.

Post-market monitoring (Article 72) alongside MDR vigilance

Article 72 requires a proactive post-market monitoring plan, collecting real-world performance data from deployers and feeding it into the risk management system and technical documentation. For medical devices this runs alongside the MDR vigilance framework: adverse events and serious incidents that trigger MDR vigilance reporting (MDR Article 87) will ordinarily also constitute serious incidents under Article 73 of the AI Act, requiring reporting to the relevant national market surveillance authority.

In practice: set up one post-market surveillance process that satisfies both MDR and EU AI Act requirements simultaneously. This is achievable; it requires deliberate architecture of the surveillance programme from the start.

Quality management system (Article 17) and CE marking

A QMS meeting Article 17 requirements — covering design, development, production, and post-market — must be in place before the conformity assessment. MDR-compliant vendors typically operate under ISO 13485, which substantially overlaps with Article 17. Once conformity assessment is complete, the vendor issues the EU Declaration of Conformity (Article 47, Annex V) and affixes CE marking (Article 48).

---

Deployer obligations: what the hospital or radiology practice must do

The deployer — the hospital, radiology centre, or diagnostic lab that actually runs the imaging AI on its patients — has a distinct but lighter obligation set. Deployers do not conduct conformity assessment. But they are not passive.

Verify before you deploy

Before putting the system into clinical use, verify that the vendor has completed conformity assessment and holds a current CE certificate under MDR (and that the AI Act compliance is embedded in that certificate, once the 2 August 2028 date has passed). Ask the vendor for the instructions for use; confirm that your scanner hardware, acquisition protocols, and patient population fall within the validated scope. If your patient population differs materially from the training set described in the documentation, that is a clinical risk and a compliance risk. Raise it with the vendor before deployment, not after.

Ensure human oversight in practice (Article 26)

Article 26 requires deployers to assign oversight of the system to a qualified person with the competence, authority, and resources to interpret outputs and intervene. For diagnostic imaging AI, this is a qualified radiologist. The radiologist must review every AI-generated finding before it influences a clinical decision. That review must be genuine, not a rubber-stamp. The AI output should be one input into the diagnostic process, not the final word.

Document the oversight arrangement: who is responsible, what the review protocol is, and how disagreements between the AI output and the radiologist's assessment are resolved.

Monitor and log (Article 26)

Deployers must keep logs of system operation for at least six months (Article 26). For imaging AI, useful logs include: the scan processed (patient identifier pseudonymised), the AI output, the clinician's decision (accepted / modified / overridden), and the clinical rationale where the AI output was not followed. These logs are the evidence base for your own performance monitoring and, if a serious incident occurs, for root-cause analysis.

Monitor performance over time. If you start seeing unusually high override rates, or if clinical outcomes on cases flagged by the AI diverge from expected, that is a signal of distribution shift or model degradation. Escalate to the vendor under Article 26.

Fundamental Rights Impact Assessment (Article 27)

Public bodies, and certain private entities using high-risk AI in public-interest functions, must conduct an FRIA under Article 27. A hospital deploying imaging AI in publicly funded healthcare is likely to fall within scope. The FRIA for diagnostic imaging AI should assess: whether the system produces systematically different performance across patient demographic groups; whether any disparities have clinical consequences (missed diagnoses in a specific population); what data about patients is processed and on what legal basis under GDPR Article 9 (special category health data).

GDPR Article 9 processing requires an explicit legal basis — typically Article 9(2)(h) (necessary for medical diagnosis by a professional bound by professional secrecy) or Article 9(2)(j) (scientific research with appropriate safeguards). The DPIA under GDPR and the FRIA under the AI Act should be built in parallel; they address overlapping questions.

---

GDPR Article 9 and patient health data

Diagnostic imaging AI processes health data — special category personal data under GDPR Article 9(1). The imaging-AI vendor, if it has access to identifiable patient data during training or as part of a cloud-hosted processing model, must establish its own legal basis. The hospital deploying the system is typically the data controller; the imaging-AI vendor acting as a processing service provider is a data processor and needs a Data Processing Agreement meeting GDPR Article 28.

For vendors training on retrospective clinical datasets: the consent or legitimate interest basis for using patient data in training is a live regulatory question across EU member states. The prudent approach is pseudonymisation of training data and, where feasible, contractual confirmation from the source institution that the data transfer and use is covered.

---

Worked example: a 55-person radiology group deploys a nodule-detection system

A radiology group operating three sites in the Netherlands contracts with a Dutch imaging-AI vendor to deploy a CT lung-nodule detection system. The vendor holds MDR CE certification under Class IIa. EU AI Act obligations under Article 6(1) will apply from 2 August 2028.

What the vendor must do by 2 August 2028:

The vendor must ensure that its MDR notified-body conformity assessment covers the AI Act requirements — specifically Article 9 (risk management), Article 10 (data governance), Article 11 (technical documentation), Article 13 (instructions for use), Article 14 (human oversight design), and Article 15 (accuracy, robustness, cybersecurity). If the existing MDR file does not fully address these elements, it needs to be updated before the 2028 date. The notified body conducting the MDR review will check AI Act compliance as part of the same assessment. A fresh EU Declaration of Conformity under Article 47 will cover both MDR and AI Act obligations.

Post-market monitoring under Article 72 must be integrated with the existing MDR post-market surveillance programme. Serious incidents that constitute a reportable event under MDR vigilance will also need to be reported under Article 73 of the AI Act.

What the radiology group must do now (and by 2028):

The group should start governance preparation before 2028. Designate a named radiologist responsible for AI oversight at each site. Draft a review protocol: what does "human review" of the AI output mean for this system in this clinical context? Document it. Establish pseudonymised logging of AI outputs, radiologist decisions, and override rationale. Run a data protection impact assessment covering GDPR Article 9 health data processing. Conduct an FRIA under Article 27 as a public-facing healthcare provider. Verify that the vendor's instructions for use describe the validated scanner models used across all three sites — if one site runs a scanner outside the validation scope, that needs resolution.

None of this requires a compliance budget of six figures. It requires a named owner, a documented process, and a log.

---

Enforcement and penalties

Non-compliance with the high-risk obligations under Chapter III of the AI Act (Articles 9–15 and the provider/deployer obligations in Articles 16 and 26) attracts fines under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For smaller companies, Article 99(6) caps the fine at the lower of the percentage or the fixed amount.

These are the penalties for the AI Act obligations. MDR non-compliance carries separate enforcement under the MDR vigilance and market surveillance framework, which is already operative and not deferred.

The 2 August 2028 deferral covers the EU AI Act obligations for Article 6(1) systems only. MDR obligations are already in force.

---

How Confir helps

Confir's classification engine — rule-based and deterministic, applying the Article 6(1) + Annex I test before the Article 6(2) Annex III test — will correctly identify diagnostic imaging AI as an Article 6(1) system and cross-map the applicable obligations to the MDR framework in three steps or fewer.

For imaging-AI vendors, Confir generates the Article 11/Annex IV technical documentation pack and the Article 47/Annex V Declaration of Conformity, pre-populated from the classification intake. The structured assessment across AITR (data governance, Article 10; technical robustness, Article 15), AITO (transparency, Article 13; human oversight design, Article 14), and AIGM (post-market monitoring, Article 72) is aligned to the MDR lifecycle rather than treated as a parallel obligation.

For deployers, the Article 27 FRIA workflow covers the health-data and demographic-performance questions specific to clinical AI. Pricing starts at €600/year.

---

Key dates

---

Frequently asked questions

Is diagnostic medical imaging AI high-risk under Annex III of the EU AI Act?

No. The correct legal basis is Article 6(1) + Annex I, not Annex III. Diagnostic imaging software that qualifies as a medical device under MDR (EU) 2017/745 or an in vitro diagnostic under IVDR (EU) 2017/746 is high-risk because those regulations are listed in Annex I of the AI Act and require third-party notified-body conformity assessment. Article 6(1) makes any AI safety component of such a product automatically high-risk. The page lives in an annex-iii directory for legacy reasons, but the substantive legal basis is Article 6(1).

When does the EU AI Act apply to medical imaging AI?

2 August 2028, under the Digital Omnibus agreed in May 2026. That is the deadline for high-risk AI systems that are safety components of products subject to Annex I legislation (which includes MDR and IVDR devices). Stand-alone high-risk AI systems on the Annex III list face an earlier deadline of 2 December 2027, but medical imaging AI is not in that category. MDR obligations are already in force and are unaffected by the AI Act timetable.

Does the vendor or the hospital conduct the conformity assessment?

The vendor (provider) conducts it — or more precisely, submits to it, since Article 43(3) integrates the AI Act assessment into the notified-body procedure under MDR. The hospital (deployer) does not conduct conformity assessment. The hospital's job is to verify that the vendor has a valid CE certificate, follow the instructions for use, ensure human oversight, keep logs, and conduct an FRIA if required.

What is the penalty for non-compliance?

Under Article 99(4), the maximum fine for non-compliance with the high-risk obligations is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For smaller companies, Article 99(6) applies the lower of the two. Separate MDR enforcement sanctions are not deferred.

Does GDPR apply to medical imaging AI?

Yes. Medical imaging data is health data — special category personal data under GDPR Article 9(1). Processing requires a specific legal basis under Article 9(2), typically 9(2)(h) (medical diagnosis and treatment) for clinical use. Vendors processing patient data in cloud-hosted inference services must have a Data Processing Agreement under GDPR Article 28 with each deployer institution. A DPIA is required where processing presents a high risk to data subjects.

What is the Article 6(3) filter and does it apply to imaging AI?

Article 6(3) allows providers of Annex III systems to self-assess that their system is not actually high-risk if it performs only a narrow procedural task, improves a previously completed human activity, or similar. That exemption applies only to the Annex III route (Article 6(2) systems). It does not apply to Article 6(1) systems. Diagnostic medical imaging AI goes through Article 6(1) — the Annex III filter is irrelevant.

---

Related guides

• Article 6 high-risk classification
• healthcare AI medical device requirements
• determine your system's risk level
• risk assessment methodology for 2026
• EU AI Act risk classification levels
• Article 9 risk management system
• complete Annex III use cases list
• 2026 implementation roadmap and timeline