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 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.
MDR source for software as a possible medical device and intended-purpose analysis.
software
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.
Commission source for notified-body conformity assessment context.
conformity assessment
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 under Rule 11 unless another applicable Annex VIII rule produces a higher class.
Non-binding MDCG guidance supporting the Rule 11 software-classification examples and decision factors.
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.
MDR source for QMS, PMS, PMCF, vigilance, and corrective-action records.
post-market surveillance
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.
Articles 9-17 and 72 establish high-risk AI system requirements, provider QMS controls, 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.
MDR source for technical documentation, clinical evidence, QMS, PMS, vigilance, UDI, and EUDAMED records.
technical documentation
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.
Articles 9-17, 72, and Annex IV ground the high-risk AI evidence and post-market records described here.
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.
MDR source for notified-body assessment, certificates, QMS audit, and surveillance.
notified body
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).
Article 1(40) amends Article 113 so that Article 6(1) and the corresponding obligations apply from 2 August 2028.
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.
Articles 72 and 73(10) ground post-market monitoring and the medical-device-specific serious-incident routing rule.
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.
MDR source for software as a possible medical device and intended-purpose analysis.
software
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.
MDR source for software as a possible medical device and intended-purpose analysis.
software
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.
Article 6(1) supplies the medical-device product-route test.
Document an MDR conclusion and an AI Act conclusion. A single 'regulated medical AI' label is not enough for either file.
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.
MDR source for software as a possible medical device and intended-purpose analysis.
software
EU AI Act
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.
Article 6(1) supplies the two-part high-risk test; Annex I includes MDR and IVDR.
Operational implication
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 .
MDR classification and AI Act roles
EU MDR
MDR classification controls the conformity assessment route, notified-body involvement, certificate scope, and technical documentation expected for the medical-device software.
Commission source for notified-body conformity assessment context.
conformity assessment
EU AI Act
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.
Articles 3 and 16-27 define operator roles and allocate obligations.
Operational implication
Keep the MDR economic-operator map and AI Act operator map separate, then identify the same legal entity where responsibilities overlap.
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 under Rule 11 unless another applicable Annex VIII rule produces a higher class.
Non-binding MDCG guidance supporting the Rule 11 software-classification examples and decision factors.
EU AI Act
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.
MDR source for QMS, PMS, PMCF, vigilance, and corrective-action records.
post-market surveillance
EU AI Act
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.
Articles 9-17 and 72 establish high-risk AI system requirements, provider QMS controls, and post-market monitoring.
Operational implication
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.
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.
MDR source for technical documentation, clinical evidence, QMS, PMS, vigilance, UDI, and EUDAMED records.
technical documentation
EU AI Act
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.
Articles 9-17, 72, and Annex IV ground the high-risk AI evidence and post-market records described here.
Operational implication
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.
Notified-body interface and application dates
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.
MDR source for notified-body assessment, certificates, QMS audit, and surveillance.
notified body
EU AI Act
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).
Article 1(40) amends Article 113 so that Article 6(1) and the corresponding obligations apply from 2 August 2028.
Operational implication
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.
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.
Articles 72 and 73(10) ground post-market monitoring and the medical-device-specific serious-incident routing rule.
Operational implication
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.
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.
MDR source for software as a possible medical device and intended-purpose analysis.
software
EU AI Act
AI Act and MDR controls can share evidence, but the AI Act classification, operator duties, and post-market conclusions remain separate legal determinations.
Articles 6, 9-17, 43, and 72 support the separate classification, control, assessment, and monitoring conclusions.
Operational implication
Use one controlled artifact only where it identifies both requirements, both acceptance criteria, the responsible owner, and the review trigger.
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.
MDR source for software as a possible medical device and intended-purpose analysis.
software
EU AI Act
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.
Article 6(1) supplies the medical-device product-route test.
Operational implication
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.
Binding source for the amended Article 43 assessment route and Article 113 dates.
1
Section 1
Start with MDR software qualification
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.
MDR source for the medical-device definition, software as a possible device, intended purpose, QMS, technical documentation, clinical evaluation, PMS, vigilance, UDI, and EUDAMED.
software
Recommended next step
Review your MDR and AI evidence boundary
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.
Commission source explaining that notified bodies assess conformity before certain medical devices are placed on the market and that NANDO publishes designated-body lists.
NANDO source showing Regulation (EU) 2024/1689 on artificial intelligence as an active legislation entry; it does not provide detailed AI Act obligations.
Binding source for the amended Article 3(14) safety-component definition, Article 43(3) conformity assessment, and Article 113 application dates.
3
Section 3
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.
Articles 9-17 establish requirements and provider controls for high-risk AI systems; Articles 72 and 73 cover post-market monitoring and serious-incident reporting.
Binding AI Act source for high-risk classification, provider obligations, post-market monitoring, and serious incidents.
Binding source for Article 6(1) and Annex I references to MDR and IVDR.
Articles 9-17 establish requirements and provider controls for high-risk AI systems; Articles 72 and 73 cover post-market monitoring and serious-incident reporting.
Show 9 more
Article 6(1) supplies the two-part high-risk test; Annex I includes MDR and IVDR.
Articles 3 and 16-27 define operator roles and allocate obligations.
Article 6(1) and Annex I establish the product or safety-component condition and the third-party conformity-assessment condition.
Articles 9-17 and 72 establish high-risk AI system requirements, provider QMS controls, and post-market monitoring.
Articles 9-17, 72, and Annex IV ground the high-risk AI evidence and post-market records described here.
Articles 72 and 73(10) ground post-market monitoring and the medical-device-specific serious-incident routing rule.
Articles 6, 9-17, 43, and 72 support the separate classification, control, assessment, and monitoring conclusions.
Article 6(1) supplies the medical-device product-route test.
Binding source for the Article 6(1) classification test and operator obligations.
MDR source for the medical-device definition, software, conformity assessment, QMS, technical documentation, clinical evaluation, PMS, vigilance, UDI, and EUDAMED.
MDR source for the medical-device definition, software as a possible device, intended purpose, QMS, technical documentation, clinical evaluation, PMS, vigilance, UDI, and EUDAMED.
MDR source for classification, conformity assessment, quality management system assessment, technical documentation, PMS, PMCF, vigilance, and notified-body certificates.
Show 8 more
MDR source for clinical evaluation, technical documentation, PMS, PMCF, vigilance, UDI, and EUDAMED evidence expectations.
MDR source for software as a possible medical device and intended-purpose analysis.
MDR source for classification, conformity assessment, QMS assessment, technical documentation, and notified-body certificates.
MDR source for clinical evaluation, clinical evidence, PMCF, and technical documentation.
MDR source for QMS, PMS, PMCF, vigilance, and corrective-action records.
MDR source for technical documentation, clinical evidence, QMS, PMS, vigilance, UDI, and EUDAMED records.
MDR source for notified-body assessment, certificates, QMS audit, and surveillance.
MDR source for the medical-device software workstream and MDR evidence expectations.
Commission source for what notified bodies do and how medical-device notified-body lists are published.
Commission source explaining that notified bodies assess conformity before certain medical devices are placed on the market and that NANDO publishes designated-body lists.
Commission source for notified-body conformity assessment context.
Show 1 more
Commission source for medical-device notified-body roles and NANDO publication of designated bodies.
NANDO lists Regulation (EU) 2024/1689 on artificial intelligence as active legislation. Use the AI Act legal text for the detailed obligations.
NANDO source showing Regulation (EU) 2024/1689 on artificial intelligence as an active legislation entry; it does not provide detailed AI Act obligations.