EU AI Act for Medical Devices: What Founders Need to Know

If you're building AI into a product that is already, or might become, a regulated medical device, the AI Act isn't a separate compliance project. It's a second layer on top of work you're already doing under MDR, and the EU AI Act for medical devices sets out the full obligation set that layer brings. This guide sets out who it applies to, what it actually requires, and where things stand on the dates that matter right now.

In short: If your AI system is a medical device under MDR or IVDR and requires Notified Body conformity assessment, it's automatically high-risk under the EU AI Act, in practice MDR Class IIa and above. The Digital Omnibus, published in the Official Journal on 24 July 2026 and in force from 27 July 2026, moves the medical-device-specific deadline from 2 August 2027 to 2 August 2028 and the general high-risk deadline from 2 August 2026 to 2 December 2027 — from entry into force, the deferred dates are the legally binding ones and the original dates are superseded. Separately, the Article 4 AI literacy obligation has already applied since 2 February 2025, with no grace period.

The timeline at a glance

For readers who want the dates before the explanation, here's where things stand as of this review.

Who this applies to: the automatic high-risk rule

The EU AI Act sorts AI systems into risk tiers, and most of the substantive obligations attach to one tier: high-risk. For most industries, working out whether a system counts as high-risk means checking it against the use cases listed in Annex III, a catalogue of sectors and applications the legislators decided warranted scrutiny.

Medical devices don't have to check that list. Article 6(1) of the AI Act sets out a separate, automatic route: if your AI system is itself a medical device (or a safety component of one) under the Medical Device Regulation or the In Vitro Diagnostic Regulation, and that device requires third-party conformity assessment by a Notified Body under the sectoral rules, the AI system is high-risk. No use-case test, no borderline judgment call. The MDR classification does the work.

In practice, this turns a familiar question, what class is my device, into the question that decides your AI Act exposure. Class I self-certified devices sit outside Article 6(1) unless a Notified Body is otherwise involved (for example, certain Class I devices with a measuring function, or reusable surgical instruments). Everything from Class IIa upward, where a Notified Body signs off before you can place the device on the market, is automatically high-risk under the AI Act the moment it uses an AI system as defined in the Act. On that definitional gate: the Act's Article 3(1) definition turns on a system that infers from its inputs how to generate outputs with some degree of autonomy — machine-learning and similar inference-based approaches are squarely in, while a fixed, fully rules-based algorithm generally sits outside it.

A few concrete examples make the rule easier to apply. A diagnostic imaging tool that flags likely findings for radiologist review, Class IIa or above under MDR, is automatically high-risk. A dosing-recommendation engine embedded in an infusion pump, typically Class IIb, is automatically high-risk. A self-certified Class I wellness tracker with an AI-powered insights feature isn't caught by Article 6(1), because no Notified Body is involved in its MDR conformity route, though it may still be worth checking against the Annex III use-case list separately if it touches an adjacent regulated context. Two Routes to High-Risk AI in Healthcare covers that distinction in full.

For a founder, the practical translation is this: if you already know you need a Notified Body for your MDR conformity assessment, and any part of your product involves an AI or machine learning component that contributes to the device's function, assume Article 6(1) applies to you. The question "is my software a medical device," and if so which class, now answers two regulatory questions at once. See MDR Rule 11: Why Software Lands in Class IIa for how that determination is made.

What "high-risk" obligations actually require

High-risk status under the AI Act isn't a label. It's a package of engineering and documentation obligations that sit alongside, and substantially overlap with, what MDR already asks for. The core requirements, drawn from Articles 9 to 15 of the Act, cover the following ground.

A risk management system runs across the AI system's lifecycle, identifying and mitigating risks to health, safety, and fundamental rights. If you already run ISO 14971 risk management for your device, this is the same discipline applied to AI-specific risks, data drift, performance degradation, adversarial inputs, layered on top of what you already manage. The practical addition is usually a dedicated AI risk register, cross-referenced against your existing hazard analysis rather than replacing it.

Data governance covers the training, validation, and testing datasets used to build the model: their relevance, representativeness, freedom from errors, and completeness for the intended purpose, plus an examination of possible biases. This requirement has the least direct MDR equivalent, and it's often the one that catches teams out, because it demands documentation of decisions made early in model development, sometimes before the company had formal design controls in place.

Technical documentation describes the system, its design, its intended purpose, and evidence of conformity, in a format that maps closely onto a technical file already required under MDR Annex II.

Record-keeping means automatic logging of the system's operation across its lifetime, sufficient to enable traceability and post-market monitoring. For most software teams this is an engineering task as much as a regulatory one: logs need to be designed into the architecture, not bolted on before an audit.

Transparency and instructions for use let professional users understand the system's capabilities, limitations, and how to interpret its output. This parallels the labelling and instructions-for-use obligations MDR already imposes.

Human oversight is designed into the system so a natural person can understand its output, intervene, and override or halt it where appropriate.

Accuracy, robustness, and cybersecurity are tested and documented at a level appropriate to the system's intended purpose.

None of this is unfamiliar territory to a team that has already built a technical file and a quality management system for MDR. What's new is that these obligations now sit in a distinct piece of legislation, with its own conformity logic, enforcement bodies, and penalties, which is why the two frameworks need to be read together rather than treated as duplicate paperwork. One Notified Body for MDR and the AI Act sets out how the two conformity assessments integrate in practice.

The timeline, in detail

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

The Digital Omnibus, the package of amendments that resets the AI Act's rollout schedule, 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 postponed dates are the legally binding ones: 2 December 2027 for Annex III stand-alone high-risk systems, and 2 August 2028 for high-risk AI in regulated products — including medical devices under Article 6(1). The original 2 August 2026 and 2 August 2027 deadlines are superseded. Plan against the postponed dates.

Three timelines matter for medical devices specifically. Article 6(1) high-risk classification, the rule described above that automatically catches Notified-Body-assessed AI-enabled devices, applies from 2 August 2028 — the deferred date, which supersedes the original 2 August 2027 date from the Omnibus's entry into force on 27 July 2026. The general Annex III high-risk obligations that apply across other sectors follow the same pattern: 2 December 2027, superseding the original 2 August 2026 date. And Article 4, the AI literacy obligation, sits outside this rescheduling entirely: it has applied since 2 February 2025, and the Commission has confirmed there's no transitional arrangement for it — the obligation is in force as law now, with the Act's broader enforcement and penalty machinery (Articles 70 and 99) applying from 2 August 2026. One further date the Omnibus does not move: Article 50's transparency obligations — disclosing AI interaction to users and labelling AI-generated content — remain due 2 August 2026 on their original schedule, which for a user-facing AI product can make them the soonest-biting obligation of all.

One horizon note worth carrying alongside the dates: in December 2025 the European Commission published a proposal to simplify the MDR and IVDR (COM(2025) 1023, procedure 2025/0404(COD)). If adopted, it would among other things move AI devices from the AI Act's Annex I "Section A" to "Section B", so the AI Act would apply only as specified in the MDR/IVDR sectoral provisions — changing how the AI Act layers onto MDR. It is a proposal, not current law, with adoption realistically ~2027 at the earliest; plan against the current rules while keeping it on the watch list.

AI Act Dates After the Digital Omnibus carries the full breakdown and tracks any further movement. We update that page independently of this one, since deadline tracking moves faster than the rest of this guide needs to.

How AI Act work overlaps with MDR work you're already doing

The good news, and the reason this guide leads with overlap rather than duplication, is that a well-run MDR programme already produces most of the raw material an AI Act technical file needs.

Your ISO 14971 risk management file extends, rather than duplicates, to cover AI-specific risks such as dataset shift and automation bias. Your technical documentation under MDR Annex II expands to include the AI Act's Annex IV content, system description, design specifications, data governance summary, as an additional section rather than a parallel document. Your post-market surveillance plan, already required under MDR Article 83, extends to the AI Act's post-market monitoring obligations, since both ask the same underlying question: is this system still performing safely once it's in the field. Your clinical evaluation, if your device makes claims based on the AI's output, needs to demonstrate those performance claims are clinically substantiated, which is CER work you're already doing, applied to a new class of claim.

Where the two frameworks diverge most is data governance. MDR doesn't currently ask you to document dataset representativeness and bias examination the way the AI Act does. If your model was trained before you had formal documentation discipline in place, this is often the largest gap-filling exercise a team faces, and it's worth starting early rather than discovering the gap during a Notified Body's technical documentation review.

A useful way to think about the relationship: MDR asks whether your device is safe and performs as intended for its stated population. The AI Act asks a narrower, upstream question about the component that makes modern AI-enabled devices different, the model, and whether the data and process behind it were sound. Teams that treat the second question as an extension of the first, rather than a separate track, tend to move faster through Notified Body review.

Where founders get this wrong

A few patterns recur often enough across the products we see to be worth naming directly.

The first is treating AI Act compliance as something to bolt on just before submission, once the MDR technical file is otherwise finished. Data governance evidence is far cheaper to produce contemporaneously, as you train and validate your model, than to reconstruct retroactively from commit history and old notebooks months later.

The second is assuming that because a product is "just using an off-the-shelf model" or a third-party API, the AI Act obligations sit with the model provider rather than the device manufacturer. They don't. If you integrate a foundation model into a regulated medical device, you carry the manufacturer's obligations for that integration, including data governance over how you fine-tuned, prompted, or validated the model for your intended purpose, regardless of who trained the underlying weights.

The third, and the one most worth correcting given how often we still hear it, is treating Article 4 as a future date to plan around. It isn't. The AI literacy obligation has been binding since 2 February 2025, applies to providers and deployers of AI systems alike — regardless of whether the system is high-risk — and carries no grace period. Teams that spent 2026 focused on the revised high-risk timeline sometimes assumed literacy training could wait alongside it. It couldn't: the obligation is in force as law now, and the Act's enforcement and penalty machinery applies from 2 August 2026. If your organisation hasn't put this training in place, the question isn't when to start, it's how quickly you can close an existing gap.

A fourth pattern: assuming that because the Omnibus pushed the high-risk dates back, the whole AI Act timeline has loosened. It hasn't. The Omnibus rescheduled two specific obligations. It didn't touch Article 4, and it didn't remove any of the substantive requirements described earlier in this guide, only when full conformity assessment against them becomes mandatory.

What to do this quarter

Start by mapping your product against Article 6(1) if you haven't already: confirm your MDR or IVDR class, and confirm whether your AI system is integral to the device's intended purpose or a genuinely separate, non-medical function. This single determination decides whether the rest of this guide applies to you at all.

Confirm your Article 4 AI literacy training is already in place, rather than treating it as something to get ahead of. This obligation has applied since February 2025 with no transitional period; the Act's enforcement and penalty machinery follows from 2 August 2026, so the window to close the gap quietly is now. If you can't point to evidence that staff working with your AI systems have proportionate literacy training, close that gap this quarter, not next.

Begin, or continue, a documentation gap analysis against Annex IV, focused specifically on data governance, since this remains the area with the least direct MDR precedent and the longest lead time to close if training data documentation wasn't captured contemporaneously. The extra runway from the revised 2028 date is useful here, but it's runway to close real gaps, not a reason to defer starting.

Finally, update your internal planning to target the deferred dates, which are the legally binding ones now that the Digital Omnibus is in force (from 27 July 2026): 2 December 2027 for general Annex III obligations and 2 August 2028 for the medical-device-specific Article 6(1) rule. The original 2 August 2026 and 2 August 2027 dates are superseded. Keep evidence-generation moving regardless — a programme built for the earlier dates automatically satisfies the later ones — and factor in Notified Body capacity and your own quality system's lead time either way.

Frequently asked questions

Does the EU AI Act apply to every medical device with software in it? No. It applies specifically to AI systems as defined in the Act, and within medical devices, Article 6(1) captures those requiring Notified Body conformity assessment under MDR or IVDR, broadly Class IIa and above. A rules-based algorithm that doesn't meet the Act's definition of an AI system, and a self-certified Class I device, both sit outside this automatic route.

Is my Class I software affected by the AI Act? Generally not through Article 6(1), because that route requires third-party conformity assessment, which standard Class I devices don't undergo. It's still worth checking your product against the Act's separate Annex III use-case list, since a small number of non-device AI applications are caught that way regardless of MDR class. Article 4's AI literacy obligation, however, applies regardless of device class, since it attaches to the organisation deploying any AI system, not to high-risk status.

What happens if I miss the Article 6(1) deadline (2 August 2028, deferred from 2 August 2027 by the Digital Omnibus, in force from 27 July 2026)? The AI Act's enforcement mechanisms, including fines calculated as a percentage of global turnover, apply once the relevant obligations become applicable. In practice, for Notified-Body-assessed devices, non-compliance is also likely to surface during your MDR conformity assessment itself, since AI Act evidence is expected to sit inside the same technical file. That deadline applies only to Article 6(1) high-risk obligations; Article 4 AI literacy already applies and isn't affected by it.

Do I need a separate AI Act submission alongside my MDR submission? No. The AI Act is designed to integrate into the existing MDR conformity assessment procedure through the same Notified Body, rather than create a parallel one — provided that Notified Body is also designated to assess AI Act conformity, which not every MDR Notified Body will automatically be; ask yours directly. One Notified Body for MDR and the AI Act covers the mechanics in detail.

Is the Digital Omnibus definitely final now, or could the dates move again? It is final. The package was published in the Official Journal on 24 July 2026 and enters into force on 27 July 2026. From entry into force, the deferred dates — 2 December 2027 (Annex III) and 2 August 2028 (Article 6(1) medical devices) — are the legally binding ones, and the original 2 August 2026 and 2 August 2027 dates are superseded. Only a new legislative act could move these dates again, and none is on the table; this guide and the dedicated deadlines page were updated on 25 July 2026 to reflect the in-force position.

I've already started AI literacy training assuming it was due in 2026. What do I do now? Nothing changes about the training itself, only your understanding of when it was due. The obligation has been in force since 2 February 2025, so if training is underway or complete, you're closing a gap that's already open rather than getting ahead of a future one. The priority is making sure the training and its documentation are complete now, since a market surveillance authority could ask for evidence of compliance at any point.

If you want a first read on your own position, the free MedTech Compass can tell you, in minutes, whether your product falls under the AI Act, MDR, or both, based on the inputs you provide. It's an AI-generated starting point, not a validated determination, a useful first read before a working session with an expert on where you actually stand.

---

Where next: MDR Rule 11: Why Software Lands in Class IIa · One Notified Body for MDR and the AI Act · AI Act Dates After the Digital Omnibus · Two Routes to High-Risk AI in Healthcare

Find out in minutes whether your product falls under the AI Act, MDR, or both. Start the MedTech Compass →

This page carries a dated status line because AI Act timing followed a moving legislative package. That package — the Digital Omnibus — was published in the Official Journal on 24 July 2026 and is in force from 27 July 2026, making the deferred dates the legally binding ones. Status (updated 25 July 2026), next review 1 October 2026.