AI Act + MDR: How Dual Conformity Assessment Works

Status (updated 25 July 2026), next review 1 October 2026.

A device that is both a regulated medical device and a high-risk AI system does not go through two separate approval processes run by two separate bodies. It goes through one Notified Body, working from one technical file, checking against two sets of requirements, the second of which is set out in full under AI Act obligations for medical devices. This article explains how that integration is designed to work, and what to actually do about it.

In short: AI-enabled medical devices requiring Notified Body assessment must satisfy both MDR and the EU AI Act. The AI Act is designed to integrate into the existing MDR conformity assessment rather than run as a separate procedure, so most AI Act evidence, risk management, data governance, technical documentation, extends work MDR already requires.

Why one product now hits two regulations

If your device is an AI system under the Act's definition and it is a medical device requiring Notified Body assessment under MDR, Article 6(1) of the AI Act makes it automatically high-risk. When Medical Device AI Becomes High-Risk covers how that determination is made. The consequence is that your product now sits inside two legislative frameworks simultaneously: MDR, which governs safety and performance of the device as a whole, and the AI Act, which governs the specific risks introduced by the AI component.

This isn't an accident of drafting. The AI Act's authors were explicit that layering an entirely separate conformity assessment procedure on top of the existing MDR framework, for a device that already goes through Notified Body review, would be duplicative and would slow an already lengthy process further. So the Act was written to integrate into sectoral conformity assessment systems that already exist, medical devices being the clearest example, rather than to create a parallel one.

What the AI Act adds on top of MDR

Integration doesn't mean the AI Act adds nothing new. It means what it adds slots into a process you're already running, rather than requiring a second one from scratch. The real additions cluster around four areas.

Under Article 10, data governance is the requirement with the least MDR precedent. It requires documented evidence that training, validation, and testing datasets are relevant, sufficiently representative of the intended patient population, and have been examined for possible biases that could affect safety or lead to discriminatory outcomes. MDR's clinical evaluation asks whether your device works and is safe for its intended population; the AI Act asks a more specific, upstream question about the data that produced the model in the first place.

Article 12 requires automatic logging: the AI system needs to record events across its operation sufficient to enable traceability of its functioning and to support post-market monitoring. This overlaps with, but is more specific than, MDR's general post-market surveillance obligations, since it asks for machine-readable operational logs, not just adverse event tracking.

Transparency and instructions for use, under Article 13, means giving professional users information about the AI system's capabilities and limitations, the level of accuracy it was tested for, and circumstances that could affect its performance, in a way that lets them interpret and use the output appropriately. MDR already requires instructions for use; the AI Act asks for AI-specific content within them.

And human oversight, under Article 14, needs to be designed into the system so a natural person can understand its output, monitor its operation, and intervene or override it. Most device types have no direct MDR equivalent for this, though it echoes usability engineering principles many teams already apply.

The integrated assessment route and what Notified Bodies will check

Under the AI Act, Notified Bodies already designated under MDR or IVDR for the relevant device type are, in principle, positioned to also check AI Act conformity as part of the same assessment procedure, provided they have or acquire the necessary AI-specific expertise. In practice, your existing (or planned) Notified Body relationship is the same relationship through which AI Act conformity gets checked. You shouldn't expect to need a second, separate Notified Body engagement solely for AI Act purposes.

What a Notified Body will actually look for, in an integrated review, is evidence that your quality management system, risk management file, and technical documentation address the AI-specific requirements as extensions of the MDR-standard content, not as a bolted-on annex nobody has integrated into your actual development process. Reviewers are increasingly used to seeing AI Act content presented as a dedicated section of the technical file cross-referenced against the GSPR (General Safety and Performance Requirements) checklist, rather than as a wholly separate document.

What a combined submission package actually looks like

For teams who haven't seen one yet, it helps to picture the finished artefact rather than just the list of requirements. A combined submission is still, structurally, one MDR technical file: device description, intended purpose, GSPR checklist, risk management file, design and manufacturing information, verification and validation evidence, clinical evaluation report, and labelling. The AI Act content doesn't sit in a separate binder; it's woven through the same sections. The risk management file gains an AI-specific risk analysis appendix. The verification and validation section gains model performance testing, including the accuracy metrics and test conditions Article 15 requires. The labelling and instructions for use gain the AI-specific transparency content Article 13 requires. A single new section, typically placed alongside or near the clinical evaluation report, houses the data governance documentation Article 10 requires, since this content has no natural home elsewhere in a standard MDR file structure.

The result a Notified Body wants to see is a technical file that reads as one coherent document written by a team who understood both frameworks from the start, not two documents stapled together by two different teams working from two different requirement lists.

Documentation reuse map: MDR artefact to AI Act requirement

For teams planning the work, the practical question is which existing artefacts to extend and which to build new. The table below maps each MDR artefact you're already producing to the AI Act requirement it extends to cover, and flags how much genuinely new work each row represents.

Two rows deserve a second look before you plan a timeline around this table. Data governance (row 2) is the row most teams underestimate, because it asks for documentation of decisions made early in model development, sometimes before a company had any formal documentation discipline in place at all. Automatic logging (row 5) is the row most teams misclassify as "just documentation," when in practice it's a software architecture decision that needs to be made before, not after, your logging infrastructure is built.

Annex I architecture and where things stand

Status (updated 25 July 2026). The Digital Omnibus, which shifts the timing side of this integration, was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 and enters into force on 27 July 2026. From entry into force, the deferred dates are the legally binding ones: 2 August 2028 for Annex I obligations for medical devices under Article 6(1), and 2 December 2027 for general Annex III obligations. The original 2 August 2027 and 2 August 2026 dates are superseded. Plan against the deferred dates.

The timing is therefore settled. What is genuinely open on the substance is the fine procedural detail of joint assessment: exactly how a Notified Body documents dual conformity on a single certificate, and precisely what a combined audit trail needs to contain to satisfy both regimes simultaneously. The practical architecture of "one Notified Body, one file, two frameworks" described in this article is the direction of travel and the current working assumption, supported by the legislative text now in force, but that operational detail is still being settled by Notified Bodies and the Commission as the framework matures. One further watch item: the Commission's MDR/IVDR simplification proposal (COM(2025) 1023, procedure 2025/0404(COD)) would move AI devices from Annex I "Section A" to "Section B", so the AI Act would apply only as specified in the MDR/IVDR sectoral provisions — a proposal, not law, but one that would directly affect how the AI Act attaches to devices. We'll update this page as any of that firms up; next scheduled review 1 October 2026. AI Act Dates After the Digital Omnibus tracks the timing side of this in full, including the corrected Article 4 AI literacy date, which has applied since 2 February 2025 and is unaffected by any of the Omnibus changes described here.

A worked example: one product, one combined file

Abstractions like "extend, don't duplicate" are easier to apply with a concrete case in front of you. Take a Class IIa AI-enabled diagnostic imaging tool that flags likely findings on chest X-rays for radiologist review, a common product shape among the teams we talk to.

Under MDR alone, this product needs a technical file covering intended purpose, device description, GSPR mapping, design and manufacturing information, a clinical evaluation report built on equivalence or original clinical data, verification and validation testing (including software verification under IEC 62304), risk management under ISO 14971, and post-market surveillance and vigilance procedures. That file, on its own, is a substantial undertaking. Building an MDR Technical File and CER walks through the full structure.

Layering the AI Act on top doesn't create a second file of comparable size. It adds an AI-specific risk analysis appendix to the existing ISO 14971 file, covering dataset shift and false-negative risk specifically, since a missed finding is the dominant safety concern for this product type. It adds a data governance section, new to most teams, documenting where the training data came from, how representative it is of the population the device will actually see in deployment, and what bias examination was performed, particularly around imaging equipment variation and patient demographic representation. It adds model performance testing to the verification and validation section, reporting sensitivity and specificity with the test conditions under which they were measured. It adds transparency content to the instructions for use, describing the system's tested accuracy range and the circumstances, image quality, positioning, equipment type, that could degrade its performance. And it adds a logging capability built into the software itself, so individual predictions and their inputs can be traced after deployment.

The Notified Body reviewing this file, on the current architecture, doesn't see two files. It sees one MDR technical file with AI Act content integrated at each relevant section, reviewed by the same technical experts who would otherwise have reviewed the MDR content alone, provided they hold or acquire the AI-specific competence the AI Act requires of assessment personnel.

Where Notified Bodies actually are on this today

Let's be honest about the current state of Notified Body readiness, since it affects how much you should expect a given NB to guide you through the integration versus how much your own team needs to drive it. As of this review, no Notified Body has yet completed a fully integrated MDR + AI Act certification for a medical device, simply because the AI Act's device-specific obligations aren't yet in force — they apply from 2 August 2028 under the Digital Omnibus deferral, in force from 27 July 2026. Several MDR-designated Notified Bodies are, however, already building AI-specific technical assessment capacity in anticipation, and some are informally reviewing AI Act-relevant content within ongoing MDR technical documentation reviews, treating it as good practice ahead of the formal requirement rather than a compliance gap.

For a startup, that means you shouldn't assume your Notified Body will proactively flag AI Act gaps in your file today, even if you're already building AI Act content into it. Ask directly, early in your relationship, what AI-specific expertise your assigned reviewers have and how they expect to handle combined content once the obligation becomes binding. It's a reasonable, increasingly common question, and a Notified Body's answer to it is a useful signal about how smoothly your eventual combined review is likely to go.

Practical sequencing for a startup

The sequencing mistake we see most often is treating AI Act work as a separate project that starts after the MDR technical file is otherwise complete. This creates rework, because risk management and data governance decisions made without AI Act requirements in view often have to be revisited once those requirements are added later.

The more efficient order is to build AI Act considerations into your MDR programme from the point you start assembling your technical file, treating Articles 9 through 15 as an additional checklist applied within each relevant MDR workstream, risk management, technical documentation, instructions for use, post-market surveillance, rather than as a fifth, separate workstream. For data governance specifically, the earlier you formalise documentation of your training data's provenance and representativeness, the less reconstruction work you face when a Notified Body asks for it.

This is deliberately not a do-it-yourself checklist beyond that framing: getting the integration right, particularly the data governance evidence and the risk management extension, benefits from a working session with someone who has seen how a Notified Body actually reviews combined files, since the standard of evidence expected is still settling as the framework matures.

One sequencing question we hear often enough to address directly: should you wait for the Digital Omnibus's extra runway (to December 2027 and August 2028, binding from 27 July 2026) before starting AI Act work at all? Our answer is no, and the reason has nothing to do with regulatory optimism. The data governance documentation described in this article is cheapest to produce contemporaneously, while you're training and validating your model, and becomes progressively more expensive to reconstruct the longer you wait. A team that starts collecting this evidence now, even with over a year of formal runway remaining, will spend meaningfully less time and money on it than a team that starts eighteen months from now under deadline pressure. Extra time on the calendar isn't the same as extra time you should actually use.

---

Where next: When Medical Device AI Becomes High-Risk · AI Act Dates After the Digital Omnibus · Building an MDR Technical File and CER · PRRC Under MDR Article 15: What to Know

Talk to someone who has seen how this integration actually works in practice. Book an expert conversation →