MDR-first comparisonEU

MDR vs AI Act for medical-device software

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.

The MDR grounding folder contains only limited AI Act support: a NANDO legislation listing that names Regulation (EU) 2024/1689. This page therefore treats AI Act obligations cautiously and keeps MDR evidence boundaries explicit.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
3

Structured answer sets in this page tree.

Primary sources
6

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

Use this comparison when a software or AI-enabled product may be a medical device in the EU. First decide whether the software has an MDR medical purpose or drives, influences, or is an accessory to a medical device. Then separate the MDR file from any AI Act workstream until the AI Act basis is independently confirmed from a valid AI Act source.

Side-by-side comparison

MDR vs AI Act for medical-device software

An MDR-first comparison for software or AI-enabled products where MDR qualification, classification, clinical evidence, QMS, PMS, and notified-body evidence must stay distinct from any separately grounded AI Act obligations.

Review all sources
First framework
EU MDR

The MDR side is grounded here: software can be a medical device when intended for a medical purpose, and the resulting file must cover qualification, classification, conformity assessment, technical documentation, clinical evidence, QMS, PMS, vigilance, UDI, and EUDAMED.

Second framework
EU AI Act

The AI Act side is intentionally limited because the MDR grounding folder only confirms a NANDO legislation entry for Regulation (EU) 2024/1689. Treat AI Act duties as a separate workstream requiring its own source before making detailed conclusions.

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.

EU AI Act

AI Act scope is not determined from the MDR sources used here. The available AI-related grounding only confirms an active NANDO legislation entry for Regulation (EU) 2024/1689.

Operational implication

Route the product through MDR qualification first, then open a separate AI Act analysis only when a valid AI Act source is available.

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.

EU AI Act

Do not infer AI Act classification, role, or assessment route from MDR classification alone; those facts need an AI Act source.

Operational implication

Keep MDR classification rationales and any AI Act classification rationale as separate records, even if one product team owns both.

Comparison row 3

Trigger

EU MDR

MDR clinical evidence must support the medical purpose, safety, performance, benefit-risk, and claims made for the device; PMCF updates the clinical evaluation through post-market use.

EU AI Act

AI development validation, model performance reports, or data studies should not be labelled clinical evidence unless they meet the MDR clinical-evaluation purpose and are tied to the MDR claims.

Operational implication

Tag model evidence as software or risk evidence unless the clinical-evaluation owner accepts it into the MDR clinical evidence file.

Comparison row 4

Core obligations

EU MDR

MDR requires lifecycle quality-system control, design and change control, risk management, clinical evaluation updates, PMS, PMCF where applicable, vigilance, and corrective action.

EU AI Act

AI monitoring controls may be useful inputs, but this MDR grounding does not establish which AI Act monitoring obligations apply.

Operational implication

Map monitoring outputs to MDR PMS, PMCF, vigilance, or risk-management records only when the output supports an MDR requirement.

Comparison row 5

Evidence record

EU MDR

MDR reuse is acceptable only when the same document supports a defined MDR requirement, claim, risk control, clinical conclusion, PMS finding, or notified-body request.

EU AI Act

AI Act reuse remains unconfirmed in this MDR-only grounding set; do not claim one MDR artifact satisfies an AI Act requirement without a separate AI Act citation.

Operational implication

Use a bridge note for each shared artifact: source requirement, supported claim, owner, limitation, and where the artifact cannot be reused.

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.

EU AI Act

The AI Act may have its own conformity-assessment interface, but this page only has NANDO evidence that the AI Act appears as an active legislation entry.

Operational implication

Before combining assessor communications, verify the designated scope, certificate scope, legal basis, and submission package for each regime.

Comparison row 7

Enforcement

EU MDR

MDR traceability records include UDI, Basic UDI-DI, device registration, actor registration, certificates, vigilance, PMS, and EUDAMED submissions where applicable.

EU AI Act

AI system registers or logs, if applicable under another source, should not be substituted for MDR UDI or EUDAMED records.

Operational implication

Keep medical-device traceability keyed to MDR device identifiers and registration records, with any AI artifact index linked separately.

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.

EU AI Act

AI Act scope is not determined from the MDR sources used here. The available AI-related grounding only confirms an active NANDO legislation entry for Regulation (EU) 2024/1689.

Operational implication

Route the product through MDR qualification first, then open a separate AI Act analysis only when a valid AI Act source is available.

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.

EU AI Act

AI Act scope is not determined from the MDR sources used here. The available AI-related grounding only confirms an active NANDO legislation entry for Regulation (EU) 2024/1689.

Operational implication

Route the product through MDR qualification first, then open a separate AI Act analysis only when a valid AI Act source is available.

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 also appears to be AI-enabled, open a separate AI Act workstream only after sourcing the AI Act role, category, assessment route, evidence, and timing from a valid AI Act source.
  • Reuse evidence only with a bridge note that names the legal source, supported claim, owner, limitation, and review trigger for each regime.
Section 1

Start with MDR software qualification

The MDR expressly 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. MDR software analysis is therefore not triggered merely because software is used in healthcare; it turns on intended purpose, claims, users, output, and whether the software acts for individual patient benefit.

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.
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.

Section 2

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.

The available MDR grounding supports only a narrow AI Act statement: NANDO lists Regulation (EU) 2024/1689 on artificial intelligence as active legislation for notified-body search. That supports checking whether a separate AI Act conformity assessment interface may be relevant, but it does not support detailed AI Act duties, deadlines, penalties, or high-risk-system conclusions on this page.

  • 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 a separate AI Act evidence record only when a valid AI Act source confirms the applicable role, system category, assessment route, and evidence requirements.
Section 3

Define the evidence boundary before reusing documents

MDR evidence is built to demonstrate safety, performance, benefit-risk, clinical evaluation, conformity with general safety and performance requirements, lifecycle QMS control, and post-market learning. AI model documentation, validation reports, data governance notes, or monitoring dashboards may be useful inputs, but they are not automatically MDR clinical evidence or PMS evidence.

For medical-device software or AI, tag each document by the claim it supports. A model validation report may support software verification or risk controls; a clinical evaluation report supports MDR clinical claims; PMCF and PMS outputs update the clinical evaluation and risk management file; UDI and EUDAMED records support traceability and registration.

  • 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.
Primary sources

References and citations

health.ec.europa.eu
Referenced sections
  • MDCG guidance source for UDI system questions.
"Unique Device Identification"
Related guides

Explore more topics

Custom-made medical devices under the EU MDR | EU MDR FAQ
Concise EU MDR FAQ on custom-made device definition, mass-produced exclusions, Annex XIII statements, documentation, conformity assessment, PMS, vigilance, and records to retain.
EU MDR Annex II and III Technical Documentation
Build an MDR technical documentation index for Annex II device files and Annex III post-market surveillance evidence, including GSPR, risk, clinical, PMS, UDI, and EUDAMED records.
EU MDR Annex VIII Classification Guide
Classify EU MDR medical devices under Annex VIII using intended purpose, duration, invasiveness, active device and software rules, and conformity assessment impact.
EU MDR Annex XVI products without a medical purpose
source-linked EU MDR guide for Annex XVI products: listed product groups, common specifications, clinical evidence, notified-body route, UDI, EUDAMED, PMS, and vigilance evidence before launch.
EU MDR Applicability Test
Test whether a product, accessory, software function, or Annex XVI product falls under the EU Medical Device Regulation, and record the evidence for the next classification step.
EU MDR change assessment workflow
Assess EU MDR device, design, software, intended purpose, QMS, clinical, PMS, UDI, classification, and notified-body impacts before releasing a medical device change.
EU MDR Checklist for Medical Device Compliance
Practical EU MDR checklist covering qualification, classification, conformity assessment, technical documentation, GSPR, clinical evidence, UDI, EUDAMED, PMS, vigilance, QMS, and legacy transition evidence.
EU MDR classification workflow
A concrete EU MDR classification workflow for intended purpose, device or accessory qualification, Annex VIII rule selection, Rule 11 software review, class outcome, and notified body impact.
EU MDR Clinical Evaluation Overview
EU MDR clinical evaluation overview covering Article 61, Annex XIV, clinical data sources, equivalence, PMCF, CER evidence, notified body review, GSPR, and benefit-risk support.
EU MDR Clinical Evaluation Report Template
A source-linked EU MDR clinical evaluation report template covering intended purpose, GSPR linkage, clinical data appraisal, equivalence limits, PMCF, conclusions, and reviewer signoff.
EU MDR clinical evidence guide
source-linked EU MDR guide to clinical evaluation, clinical investigations, equivalence, PMCF, GSPR support, technical documentation, and notified-body review.
EU MDR compliance obligations
EU MDR compliance guide for device qualification, classification, conformity assessment, QMS, technical documentation, UDI, EUDAMED, PMS, vigilance, and legacy transition controls.
EU MDR conformity route workflow
source-linked EU MDR workflow for classifying a device, choosing the conformity assessment route, preparing technical and QMS evidence, and reaching certificate, DoC, UDI, EUDAMED, and CE outputs.
EU MDR deadlines and compliance calendar
Grounded EU MDR calendar for application, legacy-device transition, UDI, EUDAMED, and recurring QMS, technical documentation, clinical, PMS, vigilance, certificate, and change reviews.
EU MDR Device Classification Guide
Classify an EU MDR medical device by intended purpose, Annex VIII duration, invasiveness, active-device and software rules, then document the conformity route impact.
EU MDR EUDAMED and UDI registration
source-linked MDR guide to Basic UDI-DI, UDI-DI, EUDAMED device registration, actor roles, labels, technical documentation, and UDI data governance.
EU MDR FAQ: qualification, evidence, UDI, and transition
Concise EU MDR FAQ covering device qualification, software classification, accessories, custom-made devices, clinical evidence, UDI, EUDAMED, notified bodies, significant changes, and legacy transition.
EU MDR Legacy Device Transition
source-linked EU MDR legacy device transition guide covering Regulation (EU) 2023/607 conditions, certificate validity, significant-change limits, surveillance, PMS, vigilance, QMS, and evidence records.
EU MDR notified body route selection
Choose an EU MDR conformity assessment route by device class, Article 52 option, notified body designation scope, QMS readiness, technical documentation, clinical evidence, and certificate evidence.
EU MDR penalties and enforcement risk
source-linked EU MDR penalties and enforcement-risk guide covering Article 113, Member State penalty rules, market restrictions, recalls, certificate consequences, and evidence.
EU MDR PMS and Vigilance Guide
EU MDR guide to post-market surveillance, PMCF updates, PMS reports, PSURs, serious incident reporting, FSCA/FSN handling, trend reporting, and evidence records.
EU MDR PMS and vigilance records
source-linked EU MDR guide to PMS plans, PMS reports, PSURs, PMCF updates, serious incident and FSCA reporting, trend reporting, and EUDAMED evidence handling.
EU MDR PMS Plan Template for Medical Devices
A source-linked EU MDR post-market surveillance plan template covering device scope, PMS data sources, PMCF linkage, vigilance, trend reporting, PMSR or PSUR outputs, roles, cadence, and evidence records.
EU MDR QMS and technical file evidence map
Map EU MDR Article 10 QMS duties to Annex II and Annex III technical documentation, PMS, vigilance, UDI records, and notified-body review evidence.
EU MDR QMS requirements under Article 10
EU MDR QMS guide for Article 10 manufacturer controls covering regulatory strategy, design, risk, clinical evaluation, PMS, vigilance, UDI, suppliers, CAPA, and conformity records.
EU MDR qualification and borderline products
EU MDR qualification guide for medical purpose claims, accessories, software, Annex XVI products, and borderline routes to classification and conformity assessment.
EU MDR qualification workflow
A concrete EU MDR workflow for deciding whether a product is a medical device, accessory, Annex XVI product, IVD interface, medicinal-product interface, or non-MDR product before classification and conformity assessment.
EU MDR requirements checklist
Concrete EU MDR requirements for medical-device scope, classification, GSPR, conformity assessment, technical documentation, QMS, clinical evidence, UDI, EUDAMED, PMS, vigilance, and economic-operator records.
EU MDR Rule 11 software classification
Classify MDR medical device software under Rule 11 using intended purpose, diagnosis or therapy decision impact, physiological monitoring, conformity route, clinical evidence, and software-change records.
EU MDR significant changes FAQ: legacy-device transition and notified-body review
FAQ on MDR significant changes for legacy devices, including intended-purpose, design, software, material, sterilisation, clinical, QMS, notified-body, and evidence impacts.
EU MDR Transition Timelines: practical guide
EU Medical Device Regulation guide to Transition Timelines with scope decisions, owner actions, evidence records, source-linked citations, and practical next steps.
EU MDR UDI and EUDAMED registration guide
EU MDR guide to Basic UDI-DI, UDI-DI, UDI carriers, EUDAMED actor and device registration, change impacts, and evidence governance.
EU MDR vigilance reporting workflow
Concrete EU MDR vigilance workflow for incident intake, serious incident assessment, FSCA and FSN handling, trend reporting, EUDAMED caveats, CAPA, PMS, clinical evaluation updates, and records.
How should Basic UDI-DI and UDI-DI be assigned under the EU MDR? | EU MDR FAQ
EU MDR FAQ explaining what Basic UDI-DI and UDI-DI identify, how they connect to UDI carriers, EUDAMED records, change triggers, and retained evidence.
MDR vs GPSR: medical-device boundary checks
Compare MDR medical-device scope with general product-safety fallback questions for borderline, non-medical, and Annex XVI products.
MDR vs IVDR: medical devices and IVDs compared
Compare EU MDR and IVDR scope, classification, conformity routes, technical documentation, clinical or performance evidence, UDI, EUDAMED, PMS, and vigilance.
MDR vs Product Liability Directive evidence comparison
Compare EU MDR market-access evidence with Product Liability Directive exposure without treating compliance records as a liability outcome.
What should an EU MDR PMCF plan and report cover? | EU MDR FAQ
Under the EU MDR, PMCF is part of PMS and clinical evaluation. See what the plan, activities, report, updates, and retained evidence should cover.
What should manufacturers do when an EU MDR classification changes? | EU MDR FAQ
Concise EU MDR FAQ on classification changes, intended purpose, software, notified-body route impact, certificates, technical documentation, and retained evidence.
When can clinical equivalence be used under the EU MDR?
EU MDR FAQ on clinical equivalence, including technical, biological, and clinical characteristics, access to equivalent-device data, class III and implantable-device limits, clinical evaluation, PMCF, and retained evidence.
When do software or products make medical purpose claims under the EU MDR? | EU MDR FAQ
EU MDR FAQ on medical purpose claims, intended purpose evidence, software qualification, Annex XVI contrasts, and records to keep.
When is a PSUR required under the EU MDR and what should it contain? | EU MDR FAQ
EU MDR FAQ on PSUR scope, content, update cadence, PMS and PMCF links, notified-body handling, EUDAMED submission, and evidence to retain.
When is an accessory regulated under the EU MDR? | EU MDR FAQ
EU MDR FAQ on when an article is a medical device accessory, how intended purpose affects classification, and what evidence to keep.
When is software regulated as SaMD under the EU MDR? | EU MDR FAQ
Concise EU MDR FAQ on software qualification, intended medical purpose, Rule 11 classification, modules, clinical evidence, change assessment, UDI, and EUDAMED.
Which devices need an SSCP under the EU MDR and what should it include? | EU MDR FAQ
EU MDR FAQ on when an SSCP is required, who prepares, validates, uploads, and updates it, and what evidence should support the summary.
Which EUDAMED modules matter under the EU MDR? | EU MDR FAQ
EU MDR FAQ mapping EUDAMED modules to actor registration, UDI/device data, certificates, clinical investigations, vigilance/PMS, market surveillance, and practical records.