Regulation (EU) 2024/1689 · MDR · IVDR · MDCG 2025-6
AI Act and medical devices
The algorithm now has two rulebooks and one CE mark.
An AI-enabled medical device does not leave the MDR or IVDR when the AI Act arrives. It enters a combined system where medical safety, fundamental rights, data quality, human oversight and lifecycle control must tell one coherent story.
Trace the regulatory signal ↓Intended purpose · model · data · clinical context
Requirements converge in the QMS and technical documentation
CE pathway aligned
The central idea
The AI Act adds a lens, not a second product
The MDR and IVDR ask whether the device is safe, performs as intended and offers an acceptable benefit-risk profile.
The AI Act examines the AI-specific machinery behind that result, including datasets, logging, transparency, oversight, accuracy, robustness, cybersecurity and effects on fundamental rights.
01
One product enters two regulatory systems #
The AI Act does not replace sector-specific medical-device law. When an AI-enabled device meets the relevant conditions, the AI Act and the MDR or IVDR apply simultaneously and complement one another.
That is less dramatic than maintaining two disconnected compliance universes. Article 8(2) of the AI Act allows AI testing, reporting, information and documentation to be integrated into the procedures and documents already required under the MDR or IVDR. The official MDCG 2025-6 FAQ strongly encourages manufacturers to use that flexibility.
Intended purpose, device classification, GSPRs, clinical or performance evidence, benefit-risk, PMS and vigilance
AI risk management, data governance, logging, transparency, oversight, accuracy, robustness, cybersecurity and rights
Can one design decision be traced through the medical-device risk file, AI risk controls, dataset rationale, clinical evidence, human-oversight measure, verification, release record and post-market monitoring?
02
First ask whether the software is an AI system #
The label “AI-powered” on a product page is not a legal classification. The analysis starts with the definition in Article 3(1) of the AI Act. In simplified terms, an AI system is machine-based, operates with varying levels of autonomy, may show adaptiveness after deployment and infers from inputs how to generate outputs that can influence physical or virtual environments.
The next question is whether the software has a medical purpose under the MDR or IVDR. A model that prioritises radiology findings, predicts deterioration or supports a diagnostic decision may be medical device software. A generic scheduling assistant or a text editor used in a hospital may not be. Intended purpose and function decide the route, not the deployment setting alone.
Analyse inference, objectives, autonomy, outputs and possible adaptiveness.
Read the claims, users, population, inputs, outputs and clinical role together.
Include the model, software, data pipeline, cloud services, interfaces and dependencies.
Map manufacturer/provider, importer, distributor, authorised representative and deployer roles.
The AI Act uses “provider” for the actor that develops an AI system or has it developed and places it on the market under its name or trademark. For medical device artificial intelligence, the manufacturer will commonly also be the provider. The concepts should be mapped explicitly rather than assumed to be interchangeable in every commercial arrangement.
03
Not every medical AI system is automatically high-risk #
For the product route in Article 6(1), two conditions must be met. The AI system must be a safety component of a product covered by legislation in Annex I, or itself be such a product, and that product must require third-party conformity assessment.
The AI performs or supports a function relevant to product safety.
The product is covered by legislation listed in Annex I of the AI Act.
The MDR or IVDR route requires involvement of a notified body.
In practical terms, the official MDCG table identifies MDR Class Is, Im, Ir, IIa, IIb and III devices and IVDR Class A sterile, B, C and D devices as examples where the Article 6(1) conditions are fulfilled. Ordinary MDR Class I devices and non-sterile IVDR Class A devices do not pass the third-party condition on that basis.
Failing this product-route test does not make the AI Act disappear. Prohibited-practice rules, AI literacy requirements, transparency obligations or a separate Annex III use case may still be relevant.
04
Two classifications answer two different questions #
The AI Act does not move an MDR Class IIa device into Class IIb or turn an IVDR Class B device into Class C. Device classification remains governed by the MDR or IVDR.
The direction of travel is the reverse. The device class and corresponding conformity route help determine whether its AI system is high-risk under Article 6(1) of the AI Act.
Classification rules assess intended purpose, invasiveness, duration, clinical impact and other product-specific characteristics.
Article 6 examines the AI function, the regulated product and whether third-party conformity assessment is required.
05
Build one management system around the model #
The AI Act requires a quality management system for providers of high-risk AI systems. Medical-device manufacturers already operate a QMS under the MDR or IVDR, usually structured around ISO 13485. Article 17(3) allows the AI Act elements to be incorporated into that existing system.
The practical work is to expand the system where AI creates new objects of control, not to create an “AI binder” that floats beside design control.
Design control · suppliers · software lifecycle · CAPA · PMS · change
Roles, competence, approval, accountability and regulatory strategy
Health, safety and fundamental-rights risks across the lifecycle
Provenance, relevance, representativeness, quality and bias controls
Training, evaluation, versioning, deployment, drift and change
Logging, oversight, instructions, monitoring and incident response
Technical, clinical, usability, security and post-market evidence
Risk management needs the same integration. ISO 14971 remains central to the device safety process, but the AI Act extends the field of view to AI-specific hazards and reasonably foreseeable impacts on fundamental rights, data bias, robustness and the deployment context.
06
The dataset is part of the product argument #
A polished performance metric cannot repair an unclear dataset. Article 10 requires training, validation and test datasets for high-risk AI systems to follow data-governance and management practices appropriate to the intended purpose.
Population, setting, task, endpoint and clinically meaningful subgroups
Origin, permissions, collection conditions, devices and reference standards
Cleaning, annotation, missingness, exclusions, leakage and duplicates
Training, tuning, validation and test data with controlled independence
Subgroups, sites, edge cases, shifts, uncertainty and foreseeable misuse
Input drift, output drift, performance signals and clinical consequences
“Representative” does not mean a miniature copy of every European patient. It means the dataset rationale is scientifically connected to the intended population, clinical environment and foreseeable variation. The manufacturer should know where the model performs well, where evidence is thin and how the limitations will be controlled.
Do not stop at overall accuracy. A model can look excellent in aggregate while systematically underperforming for a clinically important subgroup, site, acquisition protocol or rare but dangerous presentation.
07
Human oversight must be designed, not declared #
“A clinician remains responsible” is not a control by itself. Article 14 requires high-risk AI systems to be designed so that natural persons can oversee them effectively during use. The measures must fit the risk, autonomy and context of deployment.
Confidence · limitations · relevant context · status
Present capabilities, limitations and uncertainty in a usable form.
Support critical review instead of rewarding reflex acceptance.
Allow disregard, override, stop or escalation where appropriate.
Route use problems, overrides and unexpected behaviour into monitoring.
Instructions for use should explain intended and precluded uses, input requirements, performance characteristics, known limitations and the competence needed to interpret outputs. The manufacturer and deployer also have AI-literacy responsibilities under Article 4, proportionate to knowledge, experience and context.
08
A model must survive the world outside the validation set #
Article 15 groups accuracy, robustness and cybersecurity because real-world performance is shaped by more than the mathematical model. Data shifts, integration failures, malicious inputs, degraded sensors, network interruptions and user behaviour can all alter the clinical result.
Use task-appropriate metrics, confidence intervals, thresholds and clinically meaningful acceptance criteria.
Challenge noise, missing data, edge cases, site variation, foreseeable errors and component failure.
Address data poisoning, model manipulation, adversarial inputs, access, integrity, availability and recovery.
Generate records that support traceability, monitoring, investigations and accountability.
The required performance level must be stated in the instructions and supported by evidence. “State of the art” is not a permanent badge. It moves as clinical practice, attack methods, datasets, competing technology and knowledge evolve.
09
Connect model metrics to clinical meaning #
A high area under the curve can be technically impressive and clinically irrelevant. MDR clinical evaluation or IVDR performance evaluation must still demonstrate safety, performance and, where applicable, clinical benefit for the intended purpose.
The AI Act adds evidence about the system’s transparency, oversight, accuracy, robustness, cybersecurity, data controls and fundamental-rights risks. The strongest dossier links these dimensions instead of repeating them in separate reports.
Analytical and technical validation
Accuracy, robustness, software verification and specificationsClinical or performance evidence
Safety, performance, clinical benefit and intended populationUsability and oversight validation
Human factors, transparency, training and risk controlsExternal and subgroup evaluation
Representativeness, bias, sites, devices and deployment conditionsPMS, PMCF or PMPF and AI monitoring
Drift, incidents, complaints, changes and continuing benefit-riskModel output → user interpretation → clinical action → patient consequence. Validation should examine every transition that can change the benefit-risk profile.
10
Learning is useful only when change remains controlled #
A model update can affect performance, subgroup behaviour, clinical workflow, cybersecurity, human oversight and the intended purpose. The MDR or IVDR concept of significant change and the AI Act concept of substantial modification are related, but they are not identical.
Drift, complaint, new data, vulnerability or improvement opportunity
Regulatory, clinical, technical, rights and risk impact
Change boundaries, acceptance criteria and evidence plan
Model, software, clinical, usability and security consequences
Approval, configuration, communication and deployment control
Confirm the changed system behaves as predicted in use
Article 43(4) provides an important route for high-risk systems that continue to learn. Changes predetermined by the provider and assessed during the initial conformity assessment do not constitute a substantial modification when they remain within the documented plan. That flexibility depends on precise boundaries and a credible validation mechanism, not on a broad promise that “the model may improve”.
11
The conformity route should converge #
For high-risk AI systems covered by the MDR or IVDR through Article 6(1), Article 43(3) directs the provider to the conformity assessment procedure required by the relevant product legislation. The AI Act requirements become part of that assessment.
Classification · GSPRs · risk · software · clinical or performance evaluation · PMS
AI risk · data governance · logging · transparency · oversight · accuracy · robustness · security
The notified body question requires early attention. The consolidated 2026 text sets additional conditions for bodies assessing high-risk AI requirements and requires relevant product-law notified bodies to apply for AI Act designation by 28 January 2028, without prejudice to the specific transitional provisions.
Manufacturers should ask their notified body about scope, readiness, submission structure and transition planning well before the final dossier arrives. A brilliant model cannot queue-jump a capacity bottleneck.
12
Work to the current timeline, not the original one #
The timetable changed in 2026. The consolidated AI Act now applies the core high-risk requirements in Chapter III, Sections 1 to 3 on different dates depending on the classification route.
Chapters I and II apply, including AI literacy and most prohibited-practice rules.
The AI Act generally applies, subject to the specific staged dates in Article 113.
Chapter III, Sections 1 to 3 apply to systems classified under Article 6(2) and Annex III.
The corresponding requirements apply to Article 6(1) and Annex I systems, including relevant medical devices and IVDs.
The 2028 date is not permission to postpone architecture. Dataset provenance, clinical study design, logging, oversight, cybersecurity, supplier agreements and change controls are much cheaper to build before the model and QMS harden.
- Confirm the AI-system definition, medical purpose, product boundary and operator roles
- Document MDR or IVDR classification and the separate AI Act high-risk rationale
- Map Articles 8 to 15 and Article 17 into the existing QMS and technical documentation
- Build dataset, bias, logging, oversight, robustness and cybersecurity controls into design inputs
- Connect model validation to clinical or performance evidence and usability engineering
- Define model versions, predetermined changes and post-market monitoring before release
- Align the conformity route and submission structure with the notified body
- Maintain a dated applicability review as guidance, standards and transition measures evolve
Official sources
- Consolidated Regulation (EU) 2024/1689, version applicable from 27 July 2026
- MDCG 2025-6 and AIB 2025-1 FAQ on the interplay between the MDR, IVDR and AI Act
- European Commission overview of the AI Act regulatory framework
- European Commission guidance for navigating the revised AI Act timeline
- European Commission collection of MDCG-endorsed medical-device guidance
The regulatory output
Trustworthy medical AI is a system property
The MDR or IVDR controls the medical device. The AI Act adds AI-specific controls around data, transparency, oversight, robustness and rights. The conformity route brings those controls back together.
The winning strategy is not to write the same product twice. It is to build one evidence architecture that can answer both legal systems without contradiction.
One model. One controlled lifecycle. One defensible regulatory story.
Medical AI regulatory strategy
Need to connect the AI Act with your MDR or IVDR development and evidence system?
Discuss your AI pathway ↗From the knowledge centre
