Skip to content
AIAssuranceLabs
Menu

EU AI Act and medical devices: the MDR overlap

A device manufacturer whose AI function informs a diagnosis or treatment decision holds an MDR technical file, a quality system and a notified body. Where the device class requires a notified body under Regulation (EU) 2017/745, the AI system is high-risk under Art. 6(1), and Art. 9, Art. 11 and Art. 17 enter the MDR conformity assessment under Art. 43(3) from the Annex I application date Deferred. Regulation (EU) 2026/1744 moved that date and left the obligations unchanged. This page maps the three articles onto the MDR file and lists the sequence and the evidence.

Where this starts

Regulation (EU) 2017/745, the MDR, is the Union harmonisation legislation listed in Annex I Section A point 11 of Regulation (EU) 2024/1689. Art. 6(1) classifies an AI system as high-risk when two conditions hold: under point (a) the system is a safety component of a device or is itself a device, and under point (b) the device undergoes third-party conformity assessment under the MDR. The second condition follows the device class. MDR Art. 52(3), 52(4) and 52(6) place class III, class IIb and class IIa devices under a notified body; MDR Art. 52(7) lets a class I device self-declare unless it is sterile, has a measuring function or is a reusable surgical instrument. MDR Annex VIII Rule 11 classifies software that provides information used for decisions with a diagnostic or therapeutic purpose as class IIa, class IIb or class III, so an AI function of that kind meets Art. 6(1)(b) through its class. Art. 6(1a), inserted by Regulation (EU) 2026/1744, removes from the safety component definition a system used solely for non-safety aspects such as user assistance, performance optimisation, service efficiency, automation, convenience or quality control, and Art. 6(1b) returns it where its failure would endanger health and safety. Under Art. 25(3), the manufacturer that places the AI system on the market together with the device under its own name is the provider and carries the Art. 16 obligations. The risk classifier runs the Art. 6(1) route on the published logic; the Annex I manufacturer hub carries the full obligation set with its dates.

The overlap is article by article, and Art. 8(2) sets the rule: the provider integrates the testing, reporting, information and documentation the Act requires into the documentation and procedures the MDR already requires. Three pairs carry most of it. Art. 9 pairs with MDR Art. 10(2) and MDR Annex I section 3: both texts require a risk management system that is a continuous iterative process across the lifecycle, both name hazard identification, estimation and evaluation under intended use and reasonably foreseeable misuse, and both feed post-market data back into the risk estimate; Art. 9(10) lets the provider run the Art. 9 aspects inside that MDR procedure. Art. 11(2) pairs with MDR Art. 10(4) and MDR Annex II: the provider draws up one technical documentation set that holds the Annex IV elements and the MDR Annex II content, where MDR Annex II section 5 already records the risk management results and section 6.1(b) already records software verification and validation with test design, protocols and data analysis. Art. 17(3) pairs with MDR Art. 10(9) and MDR Annex IX Chapter I: the Art. 17(1) aspects may sit inside the quality management system the MDR requires, provided each aspect maps to the element that holds it. What the MDR file does not hold is AI-specific: the Annex IV section 2(d) datasheets for the training, validation and test sets, the section 2(f) description of pre-determined changes, the section 3 degrees of accuracy per group of persons, the section 4 statement on the appropriateness of the performance metrics, and the Art. 9(8) prior defined metrics and probabilistic thresholds recorded before each test run.

The route is fixed by Art. 43(3) as amended by Regulation (EU) 2026/1744. The provider follows the MDR conformity assessment procedure; the Chapter III Section 2 requirements are part of that assessment; Annex VII points 4.3, 4.4 and 4.5 and the fifth paragraph of point 4.6 apply, which give the notified body access to the training, validation and test data sets and, where necessary, to the model. The MDR notified body assesses the Section 2 requirements where its conformity with Art. 31(4), (5), (10) and (11) was assessed in its MDR notification, and it applies for designation under Chapter III Section 4 by the date Art. 43(3) sets. Classification under Art. 6(1) does not change the MDR route, and a system that also falls under an Annex III category follows the MDR procedure. Art. 43(3) also lets a manufacturer keep a route without a third party only where harmonised standards cover all Section 2 requirements; under the MDR that option does not arise, because MDR Art. 52 fixes the route by class, and no harmonised standard for Section 2 is cited in the Official Journal as of the anchor date, so no presumption of conformity is available. The Act sets no numeric threshold in the three articles: Art. 9(8) leaves the metrics and thresholds to the provider, and Art. 17 names aspects without a frequency or a retention period. The structure in use today comes from two JTC 21 documents, neither cited in the Official Journal: prEN 18228Enquiry for the Art. 9(2) cycle, at enquiry stage, and prEN 18286Published for the Art. 17(1) clause structure, published; ISO/IEC 23894:2023Published and ISO/IEC 42001:2023Published sit at the next level; MDR Annex I section 17.2 requires software developed to the state of the art with verification and validation, so the same test evidence serves both texts once the provider records and justifies each threshold.

The sequence

The work runs in the order below: the Art. 6(1) classification and the provider role first, then the route, then the three mappings, then the consistency check and the dry run.

  1. Record the safety component status of the AI function and the MDR Art. 52 route for the device class.

    Record Annex I route record: product, safety component status, conformity assessment route

    [Regulation (EU) 2024/1689, Art. 6(1)(a) and (b), 6(1a) and 6(1b); PR-CLS step 12]

  2. Confirm that the manufacturer places the AI system on the market under its own name and holds the provider role.

    Record Role determination record, provider test, with the Art. 25 trigger record

    [Regulation (EU) 2024/1689, Art. 25(3) and Art. 3(3); PR-CLS steps 8 and 10]

  3. Record the MDR conformity assessment procedure as the route and mark the Annex VII points that join it.

    Record Route selection record and sectoral procedure reference with Annex VII points 4.3 to 4.5 marked

    [Regulation (EU) 2024/1689, Art. 43(3); PR-43-MOCK steps 4 and 5]

  4. Map each Art. 9 paragraph to the MDR risk management file and mark the AI-specific gaps.

    Record Gap register rows Art. 9(1) to 9(9), with the Art. 9(10) mapping to the MDR risk management file

    [Regulation (EU) 2024/1689, Art. 9(1) to 9(10); PR-17-QMS steps 24 to 28]

  5. Check that each AI test record names a metric and a threshold dated before the run.

    Record Prior-definition check: metric, threshold, date recorded, run date, met or not met

    [Regulation (EU) 2024/1689, Art. 9(8); PR-17-QMS step 29]

  6. Map each Art. 17(1) aspect to the MDR quality management system element that holds it.

    Record Sectoral mapping with points (g), (h) and (i) marked as kept in scope, and the gap register per aspect

    [Regulation (EU) 2024/1689, Art. 17(3); PR-17-QMS step 5, then steps 9 to 23]

  7. List the MDR Annex II content that joins the single set and mark each Annex IV row.

    Record Single documentation set scope record naming the MDR Annex II content included, and the Annex IV gap table

    [Regulation (EU) 2024/1689, Art. 11(2) and Annex IV; PR-11-DOC steps 3, 7 and 10]

  8. Compare each declared metric with its dated and signed test report for the same software version.

    Record Declared metric to test report consistency table and test report register

    [Regulation (EU) 2024/1689, Annex IV section 2(g); PR-11-DOC steps 20 and 33]

  9. Walk the file through the MDR procedure with the Annex VII points and register each model change.

    Record Annex IV completeness index, requirement-to-evidence map, modification register and re-assessment trigger record

    [Regulation (EU) 2024/1689, Art. 43(3) and 43(4), Annex VII points 4.3 to 4.6; PR-43-MOCK steps 15, 16, 30 and 31]

Evidence this situation ends with

Artifacts the sequence adds to the MDR technical file, the article element each one answers, and the protocol or party that produces it.
ArtifactAnswersProduced by
Annex I route record: product, safety component status, conformity assessment routeArt. 6(1)(a) and (b): the AI function is a safety component and the device class requires a notified body under MDR Art. 52PR-CLS v1.0
Risk management file (Art. 9(1)) with the Art. 9(10) mapping to the MDR risk management fileArt. 9(1) and 9(10): each Art. 9 aspect is held in the MDR file or in an AI-specific addition, with the location of eachthe provider
Prior defined metrics and probabilistic thresholds declaration (Art. 9(8))Art. 9(8): each metric and threshold recorded and dated before the test run, with the reason it fits the intended purposethe provider
Art. 17(1) to sectoral quality system mapping (Art. 17(3))Art. 17(3): each Art. 17(1) aspect, (a) to (m), mapped to the MDR quality management system element that holds itPR-17-QMS v1.0
QMS gap analysis report (PR-17-QMS output)Art. 17(1)(a) to (m): each aspect marked conforms, partial or gap, with the sampled recordPR-17-QMS v1.0
Annex IV technical documentation set (Annex IV sections 1 to 9) as the AI part of the single setArt. 11(1) and 11(2): the Annex IV elements present beside the MDR Annex II content in one setthe provider
Declared metric to test report consistency table (PR-11-DOC output)Annex IV section 2(g): each declared value matches the dated and signed report for the same software versionPR-11-DOC v1.0
Modification register (PR-43-MOCK output)Art. 43(4) and Art. 3(23): each model change since the last assessment classified as pre-determined, other or substantialPR-43-MOCK v1.0

Each artifact follows a specification with a synthetic sample on the deliverables page: the two mappings and the modification register follow the traceability matrix and the register or checklist specifications, the consistency table follows the traceability matrix specification, and the gap analysis report follows the findings register specification.

If nothing is done

Under Art. 74(3), the market surveillance authority for a high-risk AI system related to an MDR device is the authority responsible for market surveillance under the MDR, and under Art. 79(2) that authority, where it finds that the system does not meet the Chapter III requirements, requires the provider to take corrective action, to withdraw the system or to recall it within a period the authority sets. A finding against the provider obligations in Art. 16, which carry the Section 2 requirements and the Annex IV documentation, falls in the penalty tier of Art. 99(4)(a), and the amount in a given case is set under the Art. 99(7) criteria. A retrained model whose change affects conformity with the Section 2 requirements is a substantial modification under Art. 3(23) unless the provider pre-determined the change at the initial assessment, and Art. 43(4) then requires a new conformity assessment. The manufacturer's action under Art. 20 is corrective action on its own initiative once it has reason to consider that the system does not meet the requirements, and the sequence above produces the mappings and records that Art. 21(1) requires the provider to supply on a reasoned request from the authority.

Services, guides and tools for this situation

The technical documentation service runs the Art. 11(2) single-set scoping and the Annex IV consistency check under PR-11-DOC v1.0, within the limits stated on what we cannot do; the QMS gap analysis runs the Art. 17(3) and Art. 9(10) mappings under PR-17-QMS v1.0, and the pre-conformity mock assessment walks the file through the MDR procedure with the Annex VII points under PR-43-MOCK v1.0 and does not replace the notified body.

Obligations
Services
Guides
Tools
ICP hubs

Questions

How does the AI Act relate to the Medical Device Regulation?

Regulation (EU) 2017/745 is listed in Annex I Section A point 11 of Regulation (EU) 2024/1689. An AI system that is a safety component of a device, or is itself a device, is high-risk under Art. 6(1) when the device class requires a notified body under MDR Art. 52. Art. 43(3) places the Chapter III Section 2 requirements inside the MDR conformity assessment, Art. 11(2) requires one technical documentation set, and Art. 17(3) lets the Art. 17(1) aspects sit in the MDR quality management system.

What is the EU AI Act impact on medical devices?

For a device with a high-risk AI function under Art. 6(1), the MDR conformity assessment gains the Chapter III Section 2 requirements of Regulation (EU) 2024/1689, Art. 9 to Art. 15 and Art. 17, assessed by the MDR notified body under Art. 43(3). The obligations apply from the Annex I application date in the regulation data; Regulation (EU) 2026/1744 moved the date and left the content unchanged. The technical file gains the Annex IV elements MDR Annex II does not hold, such as data set documentation and accuracy per group.

Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.

Ask about scopehello@aiassurancelabs.com