For medical-device software, the MDR analysis starts with intended medical purpose, software qualification, classification, conformity assessment route, technical documentation, clinical evidence, QMS, PMS, vigilance, UDI, and EUDAMED.
Both laws can apply to one product. An AI system is high-risk under AI Act Article 6(1) only when it is a safety component of, or is itself, a product listed in Annex I and that product requires third-party conformity assessment.
An AI-enabled medical device can fall under both the MDR and the EU AI Act. Apply the MDR qualification and classification rules to the device, then apply AI Act Article 6 to the AI system. MDR status alone does not make every medical-device AI system high-risk: Article 6(1) also requires the AI system to be the product or a and the medical device to undergo third-party conformity assessment.
Side-by-side comparison
MDR vs AI Act for medical-device software
A side-by-side comparison for deciding when an AI-enabled medical device falls under both laws and how to map shared controls without merging the legal conclusions.
Software can be a medical device when intended for a medical purpose. The MDR file then covers qualification, classification, conformity assessment, technical documentation, clinical evidence, QMS, PMS, vigilance, UDI, and EUDAMED.
Second framework
EU AI Act
The AI Act regulates the AI system and its operators. For medical devices, Article 6(1) can classify the system as high-risk when both the Annex I product or safety-component condition and the third-party conformity-assessment condition are met.
MDR scope turns on whether the software or accessory is intended for an MDR medical purpose, whether it drives or influences a device, and whether medical claims are supported by the MDR file.
AI Act Article 6(1) treats an AI system as high-risk when it is itself an Annex I product or a of one and the product requires third-party conformity assessment. MDR and IVDR are listed in Annex I.
MDR classification controls the conformity assessment route, notified-body involvement, certificate scope, and technical documentation expected for the medical-device software.
The AI Act assigns duties by role, including provider, product manufacturer, deployer, importer, distributor, and authorised representative. A company can hold more than one role, and the role can differ from its MDR role.
MDR classification follows the software's intended purpose and Annex VIII rules. Rule 11 can place software in class IIa, IIb, or III according to the decisions or monitoring it supports and the harm that a wrong output could cause; other software is class I.
The medical-device route to AI Act high-risk status requires both Article 6(1) conditions: the AI system is the Annex I product or its , and the MDR conformity route requires a third party.
High-risk AI systems are subject to AI Act requirements for risk management, data governance where relevant, technical documentation, logs, instructions, human oversight, accuracy, robustness, cybersecurity, QMS, and post-market monitoring.
Map each shared control to an MDR requirement and an AI Act requirement. Preserve separate acceptance criteria and conclusions where the laws ask different questions.
MDR clinical evidence must support the medical purpose, safety, performance, benefit-risk conclusion, and claims made for the device; PMCF updates the clinical evaluation through post-market use.
AI Act technical evidence for a high-risk system covers matters such as risk management, data governance where relevant, design specifications, validation and testing, logging, human oversight, accuracy, robustness, cybersecurity, QMS, and post-market monitoring.
A model-performance report can support software verification or an AI Act control without becoming MDR clinical evidence. Use a bridge note that states each requirement, acceptance criterion, owner, and limitation.
For MDR routes requiring notified-body involvement, the MDR interface includes QMS assessment, technical-documentation assessment, certificates, surveillance, and updates for substantial changes.
The AI Act generally applies from 2 August 2026, but Article 6(1) and its corresponding obligations apply from 2 August 2028. This later date covers the product-safety route used for qualifying medical-device AI systems under Article 6(1).
Plan the Article 6(1) assessment and evidence now, but label 2 August 2028 correctly as the application date for that route. Verify later amendments before a release that depends on the date.
MDR traceability and post-market records include UDI, Basic UDI-DI, device and actor registration, certificates, PMS, vigilance, field safety corrective actions, and EUDAMED submissions where applicable.
The AI Act requires post-market monitoring for high-risk AI systems. For high-risk AI systems that are medical devices or device safety components, Article 73(10) limits the separate AI Act serious-incident notification to the fundamental-rights category in Article 3(49)(c), using the designated national authority.
Use one intake record if useful, but document the MDR vigilance decision and the AI Act incident decision separately. AI logs or registration do not replace MDR UDI and EUDAMED records.
MDR scope turns on whether the software or accessory is intended for an MDR medical purpose, whether it drives or influences a device, and whether medical claims are supported by the MDR file.
AI Act and MDR controls can share evidence, but the AI Act classification, operator duties, and post-market conclusions remain separate legal determinations.
MDR scope turns on whether the software or accessory is intended for an MDR medical purpose, whether it drives or influences a device, and whether medical claims are supported by the MDR file.
Apply AI Act Article 6(1) only after identifying the AI system, its intended use, whether it is the product or a , and whether the MDR route requires third-party assessment.
Document an MDR conclusion and an AI Act conclusion. A single 'regulated medical AI' label is not enough for either file.
Comparison row 1
Scope boundary
EU MDR
MDR scope turns on whether the software or accessory is intended for an MDR medical purpose, whether it drives or influences a device, and whether medical claims are supported by the MDR file.
AI Act Article 6(1) treats an AI system as high-risk when it is itself an Annex I product or a of one and the product requires third-party conformity assessment. MDR and IVDR are listed in Annex I.
Complete both tests. Record the MDR device class and conformity route, then record why the AI system is or is not the product or a .
Comparison row 2
Covered actors
EU MDR
MDR classification controls the conformity assessment route, notified-body involvement, certificate scope, and technical documentation expected for the medical-device software.
The AI Act assigns duties by role, including provider, product manufacturer, deployer, importer, distributor, and authorised representative. A company can hold more than one role, and the role can differ from its MDR role.
Keep the MDR economic-operator map and AI Act operator map separate, then identify the same legal entity where responsibilities overlap.
Comparison row 3
Classification trigger
EU MDR
MDR classification follows the software's intended purpose and Annex VIII rules. Rule 11 can place software in class IIa, IIb, or III according to the decisions or monitoring it supports and the harm that a wrong output could cause; other software is class I.
The medical-device route to AI Act high-risk status requires both Article 6(1) conditions: the AI system is the Annex I product or its , and the MDR conformity route requires a third party.
High-risk AI systems are subject to AI Act requirements for risk management, data governance where relevant, technical documentation, logs, instructions, human oversight, accuracy, robustness, cybersecurity, QMS, and post-market monitoring.
Map each shared control to an MDR requirement and an AI Act requirement. Preserve separate acceptance criteria and conclusions where the laws ask different questions.
Comparison row 5
Evidence record
EU MDR
MDR clinical evidence must support the medical purpose, safety, performance, benefit-risk conclusion, and claims made for the device; PMCF updates the clinical evaluation through post-market use.
AI Act technical evidence for a high-risk system covers matters such as risk management, data governance where relevant, design specifications, validation and testing, logging, human oversight, accuracy, robustness, cybersecurity, QMS, and post-market monitoring.
A model-performance report can support software verification or an AI Act control without becoming MDR clinical evidence. Use a bridge note that states each requirement, acceptance criterion, owner, and limitation.
Comparison row 6
Timing and deadlines
EU MDR
For MDR routes requiring notified-body involvement, the MDR interface includes QMS assessment, technical-documentation assessment, certificates, surveillance, and updates for substantial changes.
The AI Act generally applies from 2 August 2026, but Article 6(1) and its corresponding obligations apply from 2 August 2028. This later date covers the product-safety route used for qualifying medical-device AI systems under Article 6(1).
Plan the Article 6(1) assessment and evidence now, but label 2 August 2028 correctly as the application date for that route. Verify later amendments before a release that depends on the date.
Comparison row 7
Post-market and incident routing
EU MDR
MDR traceability and post-market records include UDI, Basic UDI-DI, device and actor registration, certificates, PMS, vigilance, field safety corrective actions, and EUDAMED submissions where applicable.
The AI Act requires post-market monitoring for high-risk AI systems. For high-risk AI systems that are medical devices or device safety components, Article 73(10) limits the separate AI Act serious-incident notification to the fundamental-rights category in Article 3(49)(c), using the designated national authority.
Use one intake record if useful, but document the MDR vigilance decision and the AI Act incident decision separately. AI logs or registration do not replace MDR UDI and EUDAMED records.
Comparison row 8
Overlap and reuse
EU MDR
MDR scope turns on whether the software or accessory is intended for an MDR medical purpose, whether it drives or influences a device, and whether medical claims are supported by the MDR file.
AI Act and MDR controls can share evidence, but the AI Act classification, operator duties, and post-market conclusions remain separate legal determinations.
Use one controlled artifact only where it identifies both requirements, both acceptance criteria, the responsible owner, and the review trigger.
Comparison row 9
Practical decision rule
EU MDR
MDR scope turns on whether the software or accessory is intended for an MDR medical purpose, whether it drives or influences a device, and whether medical claims are supported by the MDR file.
Apply AI Act Article 6(1) only after identifying the AI system, its intended use, whether it is the product or a , and whether the MDR route requires third-party assessment.
Document an MDR conclusion and an AI Act conclusion. A single 'regulated medical AI' label is not enough for either file.
Practical decision rule
How should teams decide what to do next?
If the software has an MDR medical purpose or drives, influences, or is an accessory to a device, complete the MDR qualification, classification, and evidence record first.
If the product is AI-enabled, record the AI system and operator roles, apply Article 6(1), and identify the Article 43 conformity route and 2 August 2028 application date.
Reuse evidence only with a bridge note that names the legal source, supported claim, owner, limitation, and review trigger for each regime.
The MDR includes software in the definition of a medical device when the manufacturer intends it for a medical purpose such as diagnosis, monitoring, prediction, prognosis, treatment, alleviation, investigation, replacement, or modification. Use in healthcare alone does not trigger MDR software status. Intended purpose, claims, users, output, and individual patient benefit determine the analysis.
For AI-enabled software, keep the first record MDR-specific: intended purpose, medical claims, input data, output data, user population, patient impact, whether the software is independent or part of another device, and whether it drives or influences a hardware device. Do not use an AI label to skip the MDR qualification and classification steps.
Record the intended purpose exactly as it appears in product requirements, labels, instructions for use, clinical evaluation, sales material, and customer-facing claims.
Separate administrative, search, storage, communication, and population analytics features from software that creates or modifies medical information for individual patients.
For software that controls, modifies, or supplies output to a hardware medical device, document whether it is part of the device, an accessory, or medical device software in its own right.
Map medical-device software claims, MDR technical documentation, clinical evidence, QMS controls, PMS records, and any separate AI Act workstream before reusing artifacts across regimes.
Keep MDR classification and conformity assessment separate from AI Act assumptions
Once software is in MDR scope, classification and conformity assessment drive the MDR workstream. The MDR file should show the classification rule used, the chosen conformity assessment procedure, whether notified-body involvement is required, and which technical documentation and QMS records support the route.
AI Act Article 6(1) creates a separate two-part test. The AI system must be intended as a of a product, or be the product itself, under legislation listed in Annex I; and that product must require third-party conformity assessment under that legislation. Annex I lists both the MDR and IVDR. A class I MDR device that can use manufacturer self-assessment will not meet the second condition merely because it contains AI, while an AI system in a device requiring notified-body assessment may meet it if the safety-component or product condition is also satisfied.
For Annex I products, AI Act Article 43(3) generally places the AI Act conformity assessment within the sectoral conformity assessment. The notified body must be entitled to assess the AI Act requirements. Check its MDR designation and AI competence rather than assuming that any MDR certificate covers the AI system.
A conclusion that Article 6(1) does not make the system high-risk does not end the AI Act review. Chapters I and II have applied since 2 February 2025, except for the prohibited practices added by Regulation (EU) 2026/1744, which apply from 2 December 2026. Other role-specific or transparency provisions may apply from their own dates. Record the reason each workstream applies or does not apply instead of using one high-risk label as the whole analysis.
Do not collapse MDR notified-body review and any AI Act assessment into one owner unless both legal bases and designation scopes have been checked.
Use MDR artifacts for MDR claims: classification rationale, Annex II and Annex III technical documentation, clinical evaluation, PMS/PMCF, vigilance, UDI, EUDAMED, and certificate records.
Create an AI Act classification record that states the provider and deployer roles, the Article 6 condition relied on, the sectoral conformity route, and the notified body's relevant competence.
Define the evidence boundary before reusing documents
MDR evidence demonstrates device safety, performance, benefit-risk, clinical evaluation, conformity with the general safety and performance requirements, QMS control, and post-market performance. For a , the AI Act separately requires risk management, data governance for training, validation and test data where those techniques are used, technical documentation, automatic logs, instructions for use, human oversight, accuracy, robustness, cybersecurity, a QMS, and post-market monitoring.
One artifact can support both laws only where its scope and acceptance criteria answer both requirements. A model validation report may support MDR software verification and AI Act accuracy or robustness, but it is not automatically MDR clinical evidence. MDR PMS data may feed AI Act post-market monitoring, but the owner must still assess the event under each law's definitions and reporting route.
Create an evidence index with columns for MDR claim, source requirement, artifact name, owner, review status, and whether the same artifact is being proposed for any AI Act workstream.
Require a bridge note before reusing AI development evidence as MDR clinical evidence, PMS evidence, or notified-body submission evidence.
Keep unresolved AI Act facts out of MDR certificates, labels, instructions for use, and clinical claims unless separately substantiated.
NANDO source showing Regulation (EU) 2024/1689 on artificial intelligence as an active legislation entry; it does not provide detailed AI Act obligations.