US developers of AI-enabled medical software read the EU AI Act the way they read most regulation: find the date, count backward, staff the project. The date that has fixed itself in the market's mind is 2 August 2026, when the high-risk regime is widely said to arrive.1Regulation (EU) 2024/1689 (AI Act), Art. 113: the Regulation applies from 2 August 2026, but Art. 6(1) obligations apply from 2 August 2027. For a diagnostic algorithm, an imaging triage tool, or a clinical-decision-support engine that is itself a regulated medical device, that date is almost certainly not the one that governs. The AI Act routes such software through a classification door most US teams walk past, and what waits on the other side is a different deadline and a second regime layered on the first.
1. The Classification Fork US Teams Read Backwards
The US frame is familiar. AI/ML medical software clears the FDA on a risk-based pathway, usually a 510(k) or De Novo, and, where the sponsor secures one, under a Predetermined Change Control Plan that lets the algorithm evolve within agreed limits. The instinct that carries over is that high-risk status is a property the developer reads off a public list, then maps to a single deadline. The AI Act invites that instinct and then defeats it. It contains two distinct routes into the high-risk category, and medical software almost never travels the one US teams expect.
The category most readers have heard about is Annex III, the list of stand-alone high-risk uses, biometrics, critical infrastructure, employment, essential services. The one that actually captures a regulated medical device is the other. Under Art. 6(1) AI Act, an AI system that is a device, or a safety component of one, is high-risk where the device must undergo third-party conformity assessment under the relevant EU product legislation, listed in Annex I.2Regulation (EU) 2017/745 (MDR), Art. 52 and Annex IX: conformity assessment routes by device class. Annex I, Section A names the MDR and its in vitro counterpart.3AI Act, Art. 6(1) and Annex I, Section A (listing the MDR and IVDR); the Art. 6(3) no-significant-risk derogation is Annex III only; recital 51: the AI Act high-risk label should not necessarily mean the product is high-risk under the product legislation. There is no relief valve, either: the AI Act's one statutory exit from the high-risk label, the derogation for systems that pose no significant risk, is written for Annex III alone and does not reach a product caught by Annex I. The fork is not academic; it determines which calendar the device is on.
It also runs in a direction US teams tend to reverse. Being classified as high-risk under the AI Act does not raise a device's class under the MDR or the IVDR; the causation flows the other way.4Regulation (EU) 2017/746 (IVDR): the in vitro diagnostic counterpart to the MDR; notified-body involvement for Class B and above. A device's medical-device classification decides whether it needs a notified body, and the need for a notified body is what makes the AI inside it high-risk. A Class I app a manufacturer self-certifies without a notified body is not high-risk AI on this route at all, and a Class IIa, IIb, or III device is. The line does not sit exactly on the class boundary, though. A Class I device that is supplied sterile, has a measuring function, or is a reusable surgical instrument draws a notified body in for those aspects alone, and that limited involvement is enough to satisfy the Art. 6(1) condition, so whether a given app measures anything in the regulatory sense can decide its AI Act status. The same asymmetry runs through the IVDR, where a Class A device is self-certified unless it is supplied sterile, and every class above it carries notified-body assessment. The Medical Device Coordination Group and the European Artificial Intelligence Board set this out in joint interplay guidance, whose own table records the sterile, measuring and reusable-surgical Class I device as satisfying the Art. 6(1) conditions, and which also confirms that software developed and used inside a single health institution under the MDR in-house provision is not high-risk AI, a carve-out a US company selling a productized tool cannot claim.5AIB 2025-1 / MDCG 2025-6 (19 June 2025): FAQ on the joint application of the MDR, IVDR and the AI Act for medical-device AI; Q2 and Table 1 (Art. 6(1) conditions by device class) and Q31 (Art. 111(2) before 2 August 2027); not legally binding.
Follow the fork to its end and the date moves. Stand-alone Annex III high-risk obligations apply from 2 August 2026. The Art. 6(1) obligations, the path a regulated medical device travels, apply from 2 August 2027.1 A program built to August 2026 has therefore either mis-dated its own obligation by a year or is quietly preparing for an Annex III use case it may not actually have. The apparent answer, high-risk means August 2026, turns out to be correct for a different device.
For a US medical-AI developer, the deadline that governs turns on whether the device needs a notified body at all, a question the AI Act headline the whole market is reading never asks.
2. When One Device Needs Two Conformity Verdicts
Once a medical AI is high-risk through the product route, the AI Act does not replace the MDR; it layers onto it. The system must satisfy the high-risk requirements in Chapter III, a risk-management system, data and data-governance duties, technical documentation, automatic logging, transparency to the deployer, human oversight, and an accuracy, robustness, and cybersecurity standard, on top of the general safety and performance requirements the MDR already imposes.6AI Act, Art. 9, 10, 11, 12, 13, 14 and 15 (high-risk requirements), Annex IV (technical documentation) and Art. 17 (quality management system). These are not the same requirements wearing a different label. The AI Act's data-governance and bias provisions interrogate training, validation, and testing data in a way the MDR's clinical-evidence regime does not, and the human-oversight obligation asks a design question the MDR never framed.
The AI Act tries to keep this from becoming two parallel audits. For a device on the Annex I product route, the high-risk requirements are assessed inside the conformity assessment the MDR already requires, rather than through a separate AI Act procedure.7AI Act, Art. 43(3): for Annex I, Section A products the high-risk requirements are checked within the conformity assessment of that legislation. One assessment, in principle. The qualification is load-bearing. An MDR notified body may control the AI Act requirements only where its competence against the AI Act's notified-body criteria has itself been assessed in the notification procedure, and the MDR notified-body pool is already a capacity bottleneck before that additional layer is added on top. Whether a body competent for a given device type, in a given technology area, and assessed for the AI Act layer will be available at the moment a manufacturer needs it is not a question the regulation answers. The single-assessment promise depends on a designation pipeline that, for many device types, has not yet produced a dual-competent body.
The documentation interface carries the same hazard. For a device on the product route, the AI Act requires a single set of technical documentation carrying both regimes, which reads like consolidation. It is integration, not equivalence. The two regimes ask different questions of the same file, and a technical documentation set that satisfies the MDR assessor may leave the data-governance, logging, and oversight questions only partly answered. A device that holds a valid CE certificate under the MDR is not, by that fact, in conformity with the AI Act; the AI Act requirements are additional conditions of the same CE mark, not a box the MDR certificate already ticks. Regulatory affairs may understand the device file. The data-science team may understand the model. Whether the combined dossier satisfies an assessor reading it through two regimes at once is the question neither function owns alone.
The quality system carries the duplication forward. The MDR already requires a quality management system as the backbone of the Annex IX route, and the AI Act requires a quality management system of its own for providers of high-risk systems, reaching data management, the risk process, post-market monitoring, and record-keeping. The two are meant to run as one, yet they are scoped differently, and a quality manual written to satisfy a device assessor will not, without deliberate extension, carry the AI-specific elements the AI Act adds. Which body audits which manual, and against which standard, is left to an interface the regulation sketches rather than draws.
3. Two Post-Market Calendars That Do Not Align
Conformity is the entry ticket; the obligations that follow a device for the rest of its life are where the two regimes diverge most quietly. The MDR builds an entire post-market architecture: a surveillance system, a surveillance plan, periodic safety update reporting, post-market clinical follow-up, and vigilance reporting of serious incidents to the competent authority.8MDR, Art. 61 and 83 to 88, and Annexes III and XIV: post-market surveillance, PSUR, clinical evaluation, and vigilance reporting. The AI Act builds its own: a post-market monitoring system and plan kept by the provider, and serious-incident reporting on the AI Act's own definitions and timelines. For a device covered by the MDR or the IVDR the Regulation qualifies both, loosening the one and narrowing the other. The provider may fold the AI Act monitoring elements into the post-market system that legislation already requires, provided the integration achieves an equivalent level of protection, and the AI Act notification is confined to serious incidents that directly or indirectly lead to an infringement of obligations under Union law intended to protect fundamental rights, made to whichever national competent authority the Member State has chosen for that purpose.9AI Act, Art. 72 and 72(4) (post-market monitoring; integration into a sectoral system already established), Art. 73(1) and 73(10) (serious incidents; the narrowed regime for MDR and IVDR devices), Art. 3, point (49)(c) and Art. 74(3) (the market surveillance authority for Annex I, Section A products). The narrowing settles less than it promises. Whether a given event leads to an infringement of fundamental-rights obligations, and whether an integration the manufacturer treats as equivalent reads as equivalent to an assessor, are questions the two systems still answer on non-identical triggers, thresholds, and recipients.
Risk management shows the seam. The MDR does not name ISO 14971. It requires risk control measures that conform to safety principles and take account of the generally acknowledged state of the art, and the standard reaches the file indirectly, as EN ISO 14971:2019 cited in the Official Journal, carrying a presumption of conformity for what it covers and nothing beyond. The AI Act's risk-management duty overlaps with that standard but is not satisfied by it: the AI Act reaches risks to fundamental rights and the iterative character of a learning system in terms ISO 14971 was not written to address, and its automatic-logging requirement runs on a record-keeping logic the MDR's documentation duties do not map onto cleanly. A model that changes after launch compounds the seam. Such a change sits simultaneously inside the MDR's significant-change analysis and the AI Act's concept of a substantial modification, and the two do not trigger on the same facts, an interaction examined for the device side in Insight 14. Whether a given retraining crosses one threshold, the other, both, or neither is not a question a quality system calibrated to a single regime is built to answer.
Logging widens the same seam. The AI Act requires a high-risk system to record events automatically across its lifetime, a traceability logic aimed at reconstructing what a model did and when, which the MDR's documentation duties were not built around. What records the two regimes expect a manufacturer to keep, for how long, and available to whom do not coincide, and the same post-market data stream feeds both systems on different cadences. A data pipeline engineered to one regime's retention and access logic may satisfy the other only by accident.
The result, in operation, is two incident clocks whose recipients need not be two bodies. On the MDR side an incident reaches a notified body and a competent authority. On the AI Act side, for a product covered by Annex I, Section A, the market surveillance authority is by default the authority already designated under the MDR, unless the Member State names another, while the AI Act's own device notification goes to whichever national competent authority that Member State has chosen for the purpose.9 Which address a given event belongs to, and whether one filing discharges the other, is left to a national designation rather than to the Regulation. The familiar shorthand, one incident, one report, understates the coordination the manufacturer is silently expected to perform, and the contract that allocates post-market responsibility across a supply chain rarely says which regime its language was written for.
4. A Cliff That Keeps Moving
The temptation is to treat the date as the one stable thing in the analysis. It is the least stable thing in it. Even within the base Regulation the obligations arrive in tranches: the prohibited-practice rules have applied since 2 February 2025 and the governance, penalty, notified-body and general-purpose-AI provisions since 2 August 2025, though the Regulation expressly excepts from that tranche the fines on providers of general-purpose AI models; the general application and the Annex III high-risk and transparency obligations attach on 2 August 2026; and the Art. 6(1) route for medical devices attaches on 2 August 2027.1 A medical AI built on a third-party general-purpose model adds a timing layer the device maker does not control, because the general-purpose-AI obligations sitting upstream of the device entered their window in August 2025, so part of the stack is already inside the regime while the device itself is not.
Then the date moved again. On 7 May 2026 the Council and the Parliament reached a provisional agreement on the Digital Omnibus on AI, the simplification package the Commission proposed in November 2025, which would defer the stand-alone Annex III high-risk obligations to 2 December 2027 and the embedded Annex I obligations, the medical-device route, to 2 August 2028.10Digital Omnibus on AI: Council and Parliament provisional agreement of 7 May 2026 deferring the high-risk dates; legal effect only on formal adoption and OJ publication. That agreement takes legal effect only on formal adoption and publication in the Official Journal, which had not occurred as of publication of this article. Neither the harmonised standards under Art. 40 AI Act nor the notified-body designations the single-assessment route depends on were complete at that date. The deadline is, in a precise sense, a function of infrastructure that does not yet exist.
The installed base offers less shelter than it appears. A high-risk system already on the EU market escapes the new obligations only until it undergoes a significant change in design after the application date, and the AI Act reads that threshold as equivalent in substance to a substantial modification.11AI Act, Art. 111(2): high-risk AI on the market before 2 August 2026 is caught only on a significant change in design, which recital 177 equates with a substantial modification; Art. 3, point (23) and Art. 43(4) exclude pre-determined changes in a continuously learning system. The equivalence cuts in two directions. Changes to the system and its performance that the provider pre-determined at the moment of the initial conformity assessment and recorded in the technical documentation are expressly not a substantial modification, so a device does not forfeit the shelter merely by continuing to learn; but the shelter reaches exactly as far as the pre-determination was drawn and not one retraining further. The grandfathering anchor sits at 2 August 2026, while the medical-device obligations attach in 2027, so a device first marketed in the months between falls into a gap the text does not cleanly close. The joint interplay guidance reads Art. 111(2) as inapplicable to an Annex I medical-device system before 2 August 2027 and then applicable by analogy to significant changes on or after that date.5 That reading fills the gap without binding anyone, since the guidance says on its own face that only the Court of Justice of the European Union can give binding interpretations of Union law.
This leaves a planning problem with no comfortable answer. A program cannot safely treat 2028 as its deadline, because the Digital Omnibus deferral was provisional and unpublished as of publication, and a deferral that fails to clear formal adoption leaves the base dates standing. It cannot treat August 2026 as its deadline either, because for a regulated medical device that is the wrong date. Waiting for the Omnibus is not a plan; it is a bet on a legislative outcome, taken by a company whose CE timeline does not pause while the bet resolves. What a program indifferent to all three dates would have to look like, and whether a notified-body slot can be held open across a two-year spread of possible application dates, are questions the calendar poses and does not answer.
5. Strategic Considerations
The hardest questions sit upstream of the calendar, in who bears the obligations and how the contracts allocate them. When a US lab supplies a general-purpose model, a second company fine-tunes it into a clinical tool, and a hospital deploys it, the AI Act's roles, provider, deployer, and the manufacturer the MDR already names, do not fall on one entity. Art. 25 AI Act can shift the provider's obligations onto a downstream actor, or onto the product manufacturer, on facts the commercial structure does not announce, so which party ends up carrying the Chapter III duties and signing the declaration of conformity is rarely obvious from the deal the parties actually built.12AI Act, Art. 25: responsibilities along the AI value chain; when a downstream actor or the product manufacturer is the provider. A licensing or supply agreement drafted on standard US templates allocates IP and indemnities; it is unlikely to allocate the combined-documentation duty, the cost of a notified body that must be dual-designated, or the consequence of an upstream model that changes after the device ships.
Switzerland sharpens the point rather than softening it. Switzerland is not an EU Member State and has no AI Act analogue as of publication, so a US manufacturer selling the same device into the Swiss market answers to the MepV (the Swiss medical devices ordinance) and to Swissmedic but not, on the Swiss side of the border, to the AI Act at all. One product can therefore carry materially different obligations across the Rhine, and a conformity strategy engineered solely for the EU does not resolve the Swiss route. Whether the same algorithm is a high-risk system in one market and an ordinary regulated device in the other is a question of where the box is sold, not of what the box does.
The stakes do not stay contained on the European side. The AI Act's administrative fines for high-risk non-compliance reach the higher of EUR 15 million or 3% of total worldwide annual turnover, and they sit on top of, not instead of, the MDR enforcement a competent authority can already bring, including certificate suspension and withdrawal from the market.13AI Act, Art. 99(4): administrative fines up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, for high-risk non-compliance. A certificate delayed or withdrawn in Europe does not stay a European problem either: it becomes a revenue-recognition question, a risk-factor disclosure, and a board-level exposure on the US side, the mechanism that turns a conformity question in Brussels into a matter for US counsel. Whether a particular medical-AI system meets one regime, both, or neither, and on which of several possible dates, resolves only against the specific device, its risk class, its model supply chain, and the contracts that move it across borders.