AI Medical Device Regulation: EU MDR, FDA and ISO 42001

Table of Contents

• Introduction
• What “AI medical device regulation” actually means in 2026
• Qualification and classification under EU MDR: Rule 11 first, everything else after
  • When AI software qualifies as a device
  • How Rule 11 sets the class, and therefore the AI Act trigger
• The EU AI Act: what changed in 2026 and what did not
  • The Digital Omnibus on AI: adopted, and it did not exempt you
  • MDR 2.0 and the Section B question
• What Chapter III actually demands, and how much of it you already have
• Conformity assessment: one notified body, two regimes, one certificate path
• FDA: AI-enabled device software functions and the total product lifecycle
  • What the FDA expects in a marketing submission
  • PCCP: pre-authorising the change your model will need
• ISO 42001 and prEN 18286: what a management system actually buys you
• Building one technical file instead of three
• Frequently asked questions
• Conclusions

Introduction

AI medical device regulation is now the single most confusing area of medtech compliance in Europe, and the confusion is structural rather than technical. A diagnostic algorithm placed on the EU market is a medical device under Regulation (EU) 2017/745, a piece of medical device software under IEC 62304, and — in almost every commercially interesting case — a high-risk AI system under Regulation (EU) 2024/1689. Three regimes, three vocabularies, one product. In the United States the picture is simpler in law and harder in practice: there is no AI statute, only a device framework that the FDA is stretching around models that change after clearance. This article sets out what actually applies in July 2026, which requirements genuinely overlap, which do not, and how to build one technical file instead of three. It assumes you already understand how software qualifies as a medical device and that your development lifecycle is anchored in the IEC 62304 complete guide.

What “AI medical device regulation” actually means in 2026

There is no such thing as an AI medical device approval. There is a medical device conformity assessment, and there is an AI Act layer that rides on top of it. Understanding that architecture is the whole game, because every practical question — which notified body, which certificate, which declaration of conformity, which deadline — follows from it.

In the EU, the MDR and IVDR are listed in Annex I, Section A of the AI Act. That listing is what converts a regulated device into a regulated AI system. Article 6(1) of the AI Act classifies an AI system as high-risk when two conditions are both met: the AI system is a safety component of a product covered by the legislation in Annex I, or is itself such a product; and that product must undergo a third-party conformity assessment under that same legislation. For medical devices this means the trigger is not clinical risk, model architecture, or autonomy. The trigger is whether a notified body has to be involved. Rule 11 of Annex VIII MDR decides that, and Rule 11 pushes the overwhelming majority of medical device software to Class IIa or above. The consequence is blunt: if your AI software drives a diagnostic or therapeutic decision, it is a high-risk AI system, and no amount of arguing about how simple the model is will change that.

In the United States, the AI question is absorbed into the device question. The FDA has authorised well over a thousand AI-enabled devices, roughly three-quarters of them in radiology, and it has done so entirely through 510(k), De Novo and PMA. What has changed is not the pathway but the evidentiary expectation: the model, meaning the algorithm together with the data used to train it, is treated as part of the device’s mechanism of action. Data lineage, subgroup performance, bias and drift are review issues, not internal engineering hygiene.

ISO/IEC 42001 sits outside both. It is a management system standard, not a conformity route, and the distinction matters more than most vendors admit. We return to it below, because the honest answer about where it fits is not the answer most consultants give.

Qualification and classification under EU MDR: Rule 11 first, everything else after

Every AI regulatory strategy in Europe starts with two determinations under the MDR, in strict order. First, is the software a medical device at all. Second, what class is it. Only then can you know whether the AI Act’s high-risk chapter applies, because the AI Act borrows the answer from the MDR rather than making its own.

When AI software qualifies as a device

MDCG 2019-11, revised in June 2025, remains the operative guidance on qualification and classification of software under the MDR and IVDR, and the revision also addressed the interface with the European Health Data Space. The qualification test has not changed: software qualifies as medical device software when it performs an action on data beyond storage, archival, communication or simple search, and when that action is for the benefit of an individual patient for one of the medical purposes in Article 2(1) MDR.

This is where AI developers reliably lose time. A model that identifies a lung nodule and hands the finding to a radiologist qualifies. A model that reorders a worklist so urgent cases surface first does not perform a medical purpose for an individual patient and generally does not qualify, even though it is trained on exactly the same images. A model that computes a risk score for a named patient qualifies even if a clinician makes every downstream decision. The presence of machine learning is irrelevant to qualification. Intended purpose is everything, and the intended purpose you write in your instructions for use is the one that binds you — not the one your engineers describe in the pitch deck.

How Rule 11 sets the class, and therefore the AI Act trigger

Rule 11 of Annex VIII MDR is short, aggressive and widely misread. Software intended to provide information used to take decisions with diagnosis or therapeutic purposes is Class IIa. It rises to Class III where those decisions may cause death or an irreversible deterioration of health, and to Class IIb where they may cause serious deterioration of health or a surgical intervention. Software intended to monitor physiological processes is Class IIa, rising to Class IIb where it monitors vital physiological parameters and variations could result in immediate danger. All other software is Class I.

Read those sentences against Article 6(1) of the AI Act and the interaction becomes obvious. Class IIa and above means notified body involvement, which means third-party conformity assessment, which means high-risk AI system. Only genuinely Class I software escapes the AI Act’s high-risk chapter, and under Rule 11 genuinely Class I software is rare — usually general wellness adjacent, workflow, or accessory functions. Manufacturers who believe they have found a clever Class I argument for a clinical AI product have, in my experience as a former notified body auditor, almost always mis-stated their intended purpose rather than found a loophole. It is worth adding that the Commission’s December 2025 proposal to revise the MDR and IVDR includes amendments to Rule 11; until that proposal completes the legislative process, Rule 11 as written today is the rule you classify against.

The EU AI Act: what changed in 2026 and what did not

Two things happened between November 2025 and July 2026 that every AI device manufacturer needs to have straight, because the trade press reported them as one story when they are two, and they point in opposite directions.

The Digital Omnibus on AI: adopted, and it did not exempt you

The Commission tabled the Digital Omnibus on AI on 19 November 2025. After a trilogue collapse on 28 April 2026 and a political agreement on 7 May, the European Parliament endorsed the text on 16 June 2026 and the Council formally adopted it on 29 June 2026, with publication in the Official Journal and entry into force following in July. The headline is the deferral of the high-risk obligations. Stand-alone Annex III systems now apply from 2 December 2027, and high-risk AI embedded in products regulated under Annex I — medical devices included — from 2 August 2028, replacing the original 2 August 2027 date. The stated reason is that CEN-CENELEC indicated the harmonised standards underpinning high-risk conformity assessment would not be available before late 2026, and assessing conformity against standards that do not exist is legally incoherent.

The part that got lost in the headlines matters more. The MDR and IVDR were not moved out of Annex I Section A. Parliament negotiators raised it early in the trilogue; the sectors stayed where they were. The exemption that industry expected did not materialise: AI-based medical devices remain subject to the substantive high-risk requirements of Chapter III in addition to the MDR and IVDR. By way of compromise, a new mechanism in Article 2 empowers the Commission to limit the application of specific AI Act requirements, by implementing act, where Section A sectoral legislation already provides an equivalent or higher level of protection, and the Commission is obliged to publish guidance minimising overlap. Machinery, by contrast, was moved and is largely carved out. Medical devices were not so lucky.

So the dual burden survives, deferred by a year, with a promise of future relief that does not yet exist in any adopted implementing act. Anyone planning on the basis of “medical devices are out of the AI Act” is planning against a proposal, not against the law.

MDR 2.0 and the Section B question

The proposal people are thinking of is real but separate. On 16 December 2025 the Commission published its proposal to revise the MDR and IVDR, COM(2025) 1023 final, and Article 4 of that draft would move the MDR and IVDR from Annex I Section A to Section B of the AI Act. That move would engage Article 2(2) of the AI Act, under which high-risk systems covered by Section B legislation escape the substantive Chapter III requirements, leaving the MDR and IVDR as the governing regime with AI-specific requirements folded in sectorally. It is a coherent idea and it is what most of the industry asked for. It is also, as of today, a proposal in the ordinary legislative procedure with no adoption date, and the AI Omnibus outcome of 7 May sits awkwardly against it.

The planning conclusion is unglamorous. Build to the law as adopted: high-risk, Chapter III, 2 August 2028. If Section B arrives, you will have built a well-governed AI file that the MDR will demand anyway. If it does not, you are compliant. The asymmetry is entirely one-sided, and the AI Act’s application date is not the date to start — it is the date to finish, and notified body capacity will not expand to absorb a 2028 stampede.

What Chapter III actually demands, and how much of it you already have

The good news, and it is real, is that a mature MDR technical file already satisfies a substantial share of the AI Act. The joint guidance from the Medical Device Coordination Group and the AI Board, MDCG 2025-6 on the interplay between the MDR, IVDR and the AI Act, published on 19 June 2025, makes this its central message: integrate, do not duplicate. It also fixes vocabulary that had been causing genuine confusion, confirming that the MDR “manufacturer” is the AI Act “provider”, and warning that the AI Act “deployer” does not simply map onto the MDR “user”.

The delta breaks down as follows.

Article 9 requires a risk management system running across the lifecycle. If you have a compliant ISO 14971 risk management file, you have most of the structure. What you almost certainly lack is AI-specific hazard identification: distributional shift, training data bias, automation bias in the human-AI team, adversarial manipulation, silent degradation. AAMI CR34971 and ISO/IEC 23894 are the practical references; neither is harmonised, both are usable.

Article 10 is the requirement with no MDR analogue at all, and it is the one that fails audits. Training, validation and testing data sets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. It requires documented data governance: collection provenance, annotation protocols, assumptions, gap assessment, and examination for biases likely to affect health, safety or fundamental rights. If your data was scraped from a hospital partnership three years ago with no annotation protocol under configuration control, no amount of clinical evaluation will rescue you. This is the single largest gap in the files I review.

Article 11 requires technical documentation to Annex IV of the AI Act. Article 12 requires automatic logging over the system’s lifetime, and Article 19 requires providers to keep those logs. Article 13 requires transparency and instructions for use that let the deployer interpret output — accuracy metrics, known limitations, foreseeable misuse, the specification of input data. Article 14 requires human oversight designed in, which means the interface must let a clinician understand, question and override, and must address over-reliance rather than assume it away. Article 15 requires accuracy, robustness and cybersecurity appropriate to the intended purpose, with declared accuracy metrics in the instructions for use — a requirement that goes materially beyond what most MDR files state today, and one that meshes with the secure development lifecycle described in our IEC 81001-5-1 cybersecurity guide.

Article 17 requires a quality management system. ISO 13485 gets you perhaps eighty per cent of the structure; the additions are data governance, record-keeping, transparency and human oversight as managed processes, plus the post-market monitoring plan under Article 72 and serious incident reporting under Article 73 running alongside your existing EU MDR post-market surveillance system. The reporting timelines and the reporting channels are not identical. Do not assume one vigilance procedure covers both.

One correction worth making explicitly, because it recurs in AI files: IEC 62304 does not validate anything. It covers software development and verification. Validation of the health software product comes from IEC 82304-1, ISO 13485 design controls and IEC 62366-1 usability validation. For AI devices this distinction is not academic — the AI Act’s human oversight and transparency requirements land squarely in usability validation, not in unit test coverage. Our guide to IEC 62304 software verification and validation sets out the boundary in detail.

Conformity assessment: one notified body, two regimes, one certificate path

Manufacturers expect a second audit and a second certificate. That is not how it is designed to work. Under Article 43(3) of the AI Act, where a high-risk AI system falls under Annex I Section A legislation, the conformity assessment follows the procedure in that sectoral legislation — your MDR Annex IX route — and the AI Act requirements are assessed within it. The catch is that your notified body must itself be designated under the AI Act for that purpose, having been assessed against the Article 31 requirements. Designation is not automatic and not universal.

The practical consequences are worth stating plainly. Your MDR notified body may not be AI Act designated when you need it. If it is not, you face either a change of notified body or a delay you do not control. Ask now; ask in writing; ask for the scope. Second, Article 47 permits a single EU declaration of conformity covering all Union acts applicable to the product, which is what you should draft — one declaration citing both 2017/745 and 2024/1689, not two documents that will eventually contradict each other on software version. Third, registration duties are cumulative: EUDAMED under the MDR, and the EU database for high-risk AI systems under Article 49. The Omnibus retained the registration obligation for providers, including those who consider their system exempt from high-risk classification.

FDA: AI-enabled device software functions and the total product lifecycle

The FDA has no AI Act. It has a device framework, a glossary, and a set of guidances that together amount to a coherent position: the model is part of the device, and a device whose performance can drift needs a lifecycle answer rather than a one-time clearance.

What the FDA expects in a marketing submission

The controlling document is the draft guidance “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations”, published on 7 January 2025 and, as of mid-2026, still draft — it sits on the agency’s guidance agenda for finalisation, and most observers expect it late 2026 or 2027. Treat it as current expectation regardless. Its central move is that the FDA’s AI-DSF lifecycle guidance treats the algorithm and its training data as the mechanism of action, which makes data management a review topic.

Concretely, a submission for an AI-enabled device software function should describe the model architecture and inputs and outputs; the provenance, size and composition of training, tuning and test data; the segregation between them, with evidence sufficient to address overfitting and bias; performance tied to the specific claims, broken down by clinically meaningful subgroups; the human-AI workflow, including how the output is presented and what happens when it is wrong; and a performance monitoring plan. That last item deserves care: monitoring plans are generally not required for a 510(k), but may be required as a special control for a De Novo or in a PMA, and the agency expects the risk management file to contain the plan wherever it is relied on as a mitigation. If you are pursuing a novel AI indication with no predicate, our FDA De Novo pathway guide covers the special controls mechanics that this interacts with.

Bias, in the FDA’s framing, is a safety issue rather than a policy aspiration. Subgroup analysis is expected to identify limitations and to inform users of them through labelling, and the agency’s transparency expectations push toward structured model documentation — the model card, in AI vernacular — as a labelling artefact.

PCCP: pre-authorising the change your model will need

The Predetermined Change Control Plan is the most consequential piece of AI regulatory machinery the FDA has built, and it is final: the agency issued final guidance on PCCPs for AI-enabled device software functions in December 2024, expanding scope from machine learning to AI generally and aligning terminology with the FDA’s Digital Health and AI Glossary. A PCCP authorised as part of a marketing submission lets you implement specified future modifications without a new 510(k) or PMA supplement, provided you implement them exactly as the plan prescribes.

A PCCP has three parts and all three must be tight. The Description of Modifications states precisely what may change — retraining on new data from the same distribution, a threshold adjustment, an added input modality. The Modification Protocol states the methods: data management, retraining, performance evaluation, acceptance criteria, update procedures. The Impact Assessment analyses how each modification affects safety and effectiveness, including on the parts of the device you are not touching. Implementation happens inside your quality system, which since 2 February 2026 means the QMSR — 21 CFR Part 820 aligned to ISO 13485. Deviating from an authorised PCCP does not merely invalidate the plan; it can render the device adulterated or misbranded.

In August 2025 the FDA, Health Canada and the MHRA published joint guiding principles for PCCPs, which are focused, risk-based, evidence-based, transparent and lifecycle-oriented. The EU has no PCCP equivalent in force; MDCG 2025-6 notes that IMDRF work on change control for medical device AI is expected to inform future European guidance. Until then, a change to a CE-marked AI device is assessed under the MDR’s significant change rules, and there is no pre-authorisation mechanism. This is the sharpest transatlantic divergence in AI medical device regulation today, and it should shape your release strategy: what the FDA lets you ship under a PCCP may still require notified body notification in Europe.

ISO 42001 and prEN 18286: what a management system actually buys you

Here is where I depart from the marketing consensus. ISO/IEC 42001:2023 is a good standard. It is not, and on current evidence will not be, a route to presumption of conformity with the EU AI Act.

The reasoning is documented rather than speculative. The AI Office indicated in May 2024 that ISO/IEC 42001 was not fully aligned with the final AI Act text, and it is consequently not part of the EU harmonisation process; prEN 18286 is being developed specifically to address the AI Act’s quality management requirements, with annexes mapping its structure to ISO/IEC 42001 and ISO 9001. prEN 18286 went to public enquiry from 30 October 2025 to 22 January 2026, alongside prEN 18228 for AI risk management supporting Article 9. CEN and CENELEC took exceptional measures in October 2025 — permitting direct publication after a positive enquiry vote, skipping formal vote — to have the key deliverables available by Q4 2026. Those are the standards that will carry Annex ZA and, if the Commission accepts them, presumption of conformity. ISO/IEC 42001 will not.

So what is it good for? Three things, all genuine. It gives you an auditable governance backbone across a portfolio when only some products are devices. It is increasingly asked for by health system procurement and by partners, and certification answers that question cheaply. And it forces the organisational discipline — AI inventory, roles, impact assessment, supplier control over model providers — that Chapter III will demand in 2028 and that prEN 18286 will formalise. What it does not do is satisfy Article 17. Any consultant telling you that ISO 42001 certification makes you AI Act compliant is selling you a certificate, not a strategy. Build the management system if the business case supports it, and keep a mapping to prEN 18286 as it stabilises so the transition is a gap closure rather than a rebuild.

Building one technical file instead of three

The economics of AI compliance are decided by file architecture, not by effort. Manufacturers who run parallel programmes — an MDR file, an AI Act file, an FDA submission — pay three times and produce three documents that disagree about the software version. The alternative is a single lifecycle producing regime-specific views.

Anchor everything in the MDR technical documentation structure described in our guide to EU MDR technical documentation, then extend rather than duplicate. Risk management stays one file: ISO 14971 structure, with AI hazards added to the hazard register and an explicit annex mapping each Article 9 obligation to the ISO 14971 clause that discharges it. Data governance becomes a new document — there is no MDR home for it — covering provenance, annotation, representativeness, bias examination and the training/validation/test split, written once and cited by the AI Act Annex IV documentation and the FDA submission alike. Performance characterisation is one report with declared accuracy metrics and subgroup breakdowns, which serves Article 15, the FDA’s performance section and your clinical evaluation. Transparency artefacts converge: the instructions for use carry the Article 13 content and the FDA labelling content, and a model card can be a single annex serving both. Post-market becomes one plan with two reporting workflows and a shared data pipeline, because the drift signal you need for Article 72 is the same signal the FDA expects you to monitor.

Two disciplines make or break this. First, configuration control across regimes: the software version in the EU declaration of conformity, the label, the AI Act registration and the FDA submission must be the same string, and version drift between documents is the most common finding I write. Second, third-party model control. If your device incorporates a foundation model or a third-party library, that is SOUP under IEC 62304 and simultaneously a supplier under ISO 13485 and a component whose provider obligations under the AI Act you may have inherited. A model you cannot characterise is a model you cannot declare accuracy metrics for.

Frequently asked questions

Is every AI medical device a high-risk AI system under the EU AI Act?

No, but nearly every clinically useful one is. The Article 6(1) test asks whether the product requires third-party conformity assessment under the MDR. Class IIa and above requires a notified body, so those are high-risk. Only genuinely Class I AI devices, with no notified body involvement, fall outside Chapter III. Because Rule 11 classifies most decision-support and monitoring software as Class IIa or higher, the Class I route is rare and is usually the result of an intended purpose that has been narrowed to the point of being commercially uninteresting.

When do the EU AI Act requirements apply to medical devices?

2 August 2028 for the high-risk obligations, following the Digital Omnibus on AI adopted by the Parliament on 16 June 2026 and the Council on 29 June 2026. That replaced the original 2 August 2027 date. Other AI Act provisions are already live — the prohibitions and AI literacy since February 2025, the general-purpose AI obligations since August 2025, and the Article 50 transparency duties from 2 August 2026 with a grace period to 2 December 2026 for systems already on the market.

Does the MDR revision proposal mean medical devices will be exempt from the AI Act?

Not as things stand. The Commission’s 16 December 2025 proposal, COM(2025) 1023 final, would move the MDR and IVDR to Annex I Section B, which would largely disapply Chapter III. But the AI Omnibus agreed on 7 May 2026 and adopted in June deliberately did not make that move, leaving medical devices in Section A with full high-risk obligations, and instead empowered the Commission to limit specific requirements by implementing act where the MDR already gives equivalent protection. The MDR revision is still in the legislative process. Plan against the law in force.

Do I need a separate notified body for the AI Act?

Not a separate one, but a separately designated one. Article 43(3) routes the AI Act assessment through the MDR conformity assessment procedure, but only where your notified body is also designated under the AI Act and assessed against Article 31. Not every MDR notified body has that designation. Confirm your body’s scope in writing before you build your submission plan around it.

Does ISO 42001 certification make my AI device AI Act compliant?

No. ISO/IEC 42001:2023 is not harmonised under the AI Act and does not confer presumption of conformity with Article 17. The AI Office assessed it as not fully aligned with the final AI Act text, and prEN 18286 is being developed as the harmonised quality management standard. ISO 42001 remains useful for AI governance across a portfolio and for procurement, and it overlaps substantially with what prEN 18286 will require, but it is a complement to your ISO 13485 system, not a substitute for AI Act compliance.

Can I use an FDA Predetermined Change Control Plan in Europe?

No. There is no PCCP mechanism under the MDR. Changes to a CE-marked AI device are assessed against the MDR’s significant change criteria, with notified body involvement where the change is substantial. MDCG 2025-6 points to IMDRF work on change control for medical device AI as the likely basis for future EU guidance, but nothing is in force. Manufacturers running a global release cadence should expect their EU release cycle to be slower than their US one, and should design the change plan around the tighter constraint.

What is the biggest gap in AI medical device technical files?

Data governance under Article 10. Most manufacturers can produce a risk file, a verification report and a clinical evaluation. Very few can produce a documented data provenance chain, an annotation protocol under configuration control, a representativeness assessment against the intended use population, and a bias examination. This work cannot be retrofitted convincingly, because the evidence has to have existed when the data was collected.

Conclusions

The strategic picture for AI medical device regulation in July 2026 is clearer than the noise suggests. In Europe, the AI Act’s high-risk chapter applies to your device, the date is 2 August 2028, the exemption industry hoped for did not survive the trilogue, and the relief that was promised exists only as a power the Commission has not yet exercised. In the United States, the pathway is unchanged but the evidentiary bar has moved to data, subgroup performance and drift, with the PCCP as the only mechanism anywhere in the world that lets a model change without a new submission. ISO/IEC 42001 is a governance asset and not a compliance route; prEN 18286 and prEN 18228 are the standards that will matter, and they arrive around the end of 2026.

The practical takeaways are three. Classify honestly under Rule 11, because the AI Act trigger is a mechanical consequence of that classification and every downstream cost follows from it. Start the Article 10 data governance work now, because it is the one requirement that cannot be reconstructed retrospectively and it is the one that will fail your audit. And confirm your notified body’s AI Act designation in writing this quarter, because designation capacity, not your engineering timeline, is the constraint most likely to delay your 2028.

The AI/ML Medical Device Documentation Kit on MD Regulatory includes the data governance and data management plan, model description and characterisation report, AI risk management procedure and AI hazard register aligned to ISO 14971, bias evaluation and subgroup performance report, human oversight and transparency documentation, performance monitoring plan, model card template and a predetermined change control plan template — mapped across the EU AI Act, EU MDR, FDA, Health Canada and TGA, and immediately deployable in an existing ISO 13485 quality management system. For the underlying software lifecycle documentation, the IEC 62304 Software Lifecycle Documentation Package provides the development plan, architecture, verification and SOUP records that the AI-specific documents build on.

Related articles

• Software as a Medical Device (SaMD)
• IEC 62304 Complete Guide
• EU MDR Technical Documentation
• ISO 14971 Risk Management
• IEC 81001-5-1 Cybersecurity for Health Software
• EU MDR Post-Market Surveillance
• FDA De Novo Pathway
• SOUP Management under IEC 62304