The EU AI Act for Medical Devices: The Complete Founder's Handbook

Last reviewed: 25 July 2026

If you are building AI into anything that touches diagnosis, treatment, monitoring, or prevention of disease, you are almost certainly navigating two regulatory frameworks at once, whether or not you have mapped both yet. The EU AI Act doesn't replace MDR or IVDR for medical devices; it sits on top of them, adding a distinct set of obligations that trigger automatically the moment your device needs a Notified Body. This handbook is the complete, chapter-by-chapter version of that story: who the Act catches, exactly what it demands, where the real deadlines stand today, how to fold AI Act work into the MDR programme you are probably already running, and a practical twelve-month sequence for getting from "we haven't started" to "we have a defensible file." It nests five more focused guides on this site, each covering one piece of this in more depth than a single page could; we summarize and link each of them as we go, so you can drop into detail on exactly the chapter your team is working through right now.

In short: AI systems that are medical devices requiring Notified Body assessment under MDR or IVDR are automatically high-risk under the EU AI Act — in practice, Class IIa and above. This handbook covers who is caught, every deadline including the Digital Omnibus deferral in force from 27 July 2026, the dual-conformity route with MDR, and a practical compliance sequence.

Status (updated 25 July 2026), next review 1 October 2026, or immediately on any material development, whichever is sooner. This is the most actively maintained page on the site: the deadlines discussed in Chapter 2 changed materially in the ten weeks before this review, and we treat that chapter as requiring re-verification on every scheduled pass, not just a periodic skim. The Digital Omnibus package that postpones the AI Act's high-risk deadlines 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.

On this page: Does the Act apply to you? · The deadline map, honestly · What high-risk obligations require · Data governance for medical AI · Dual conformity with MDR · AI literacy: the one obligation nobody can defer · Agentic and adaptive AI · Your 12-month compliance sequence · FAQ

Does the Act apply to you? The automatic high-risk rule

Start here, because everything else in this handbook depends on the answer. The EU AI Act sorts AI systems into risk tiers, and almost all the substantive obligations attach to exactly one tier: high-risk. For most sectors, working out whether a system is high-risk means checking it against Annex III, a list of specific use cases (biometrics, critical infrastructure, employment, education, and a handful of others) that the legislators decided warranted scrutiny regardless of what product they show up in.

Medical devices do not go through that use-case test. Article 6(1) of the AI Act creates a separate, automatic route: if your AI system is itself a medical device, or a safety component of one, under MDR or IVDR, and that device requires third-party conformity assessment by a Notified Body, the AI system is high-risk. There is no judgment call or borderline analysis to make, and no "it depends on how the use case is characterized." Your existing MDR or IVDR classification does the work.

In practice, this converts a question you are already answering, 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 some other reason (certain Class I devices with a measuring function, or reusable surgical instruments, are the standard exceptions). Everything from Class IIa upward, where a Notified Body signs off before the device reaches the market, is automatically high-risk under the AI Act from the moment it uses an AI system as the Act defines the term.

A note on the horizon: this doesn't change today's rule. Under MDR's Rule 11 as it stands today, most decision-support software effectively starts at Class IIa, with only narrow categories falling to Class I — which is why Class IIa is the accurate default to plan against right now. But on 16 December 2025, the European Commission published a proposal (COM(2025) 1023, procedure 2025/0404(COD)) to simplify MDR and IVDR that would, among other things, revise Rule 11 so software starts at Class I and is up-classified based on intended use — a structural reversal of the current default. This is early in the legislative process: it still needs European Parliament and Council agreement, and multiple trackers estimate 2027 at the earliest before any amended Rule 11 could take effect, so it doesn't change today's binding rule. We flag it here the same way we track the Digital Omnibus elsewhere in this handbook: a live, on-topic development to watch, not yet a reason to plan differently.

A few worked examples make the rule concrete. A diagnostic imaging tool that flags likely findings for radiologist review, classified 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-driven insights feature sits outside Article 6(1), because no Notified Body reviews its MDR conformity route at all — though it is still worth a separate check against the Annex III use-case list if any part of the product touches an adjacent regulated context, such as workforce or benefits-eligibility functions. A triage tool that both makes a diagnostic-adjacent recommendation (Class IIa or above, so Route 1 applies) and separately touches an Annex III-listed emergency-dispatch function can be caught by both routes at once — a genuinely dual-capture case, not a redundant one, since the two routes attach to two different functions of the same product.

For a founder, the practical translation is this: if you already know you need a Notified Body for MDR conformity, and any part of your product involves an AI or machine learning component contributing 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.

Our nested spoke, When Medical Device AI Becomes High-Risk, is the fastest single read on this rule if you want the concentrated version: it walks through Article 6(1) itself, the core Articles 9–15 obligation set at a summary level, and the overlap with MDR work, in roughly 3,000 words aimed at a founder encountering the topic for the first time. This handbook builds on that foundation with the full deadline history, the article-by-article walkthrough, the data governance deep-dive, the dual-conformity mechanics, and the compliance sequence — the pieces that a single introductory guide cannot cover at the depth a team actually implementing this needs.

Two related routes into high-risk status deserve their own treatment, and we cover them fully in Chapter 3 of this handbook and in more depth in our nested guide Two Routes to High-Risk AI in Healthcare: the Article 6(1) medical-device route described above (Route 1), and the separate Annex III use-case route (Route 2), which can catch healthcare-adjacent AI that never touches MDR at all — benefits-eligibility tools, certain employment and recruitment systems used by healthcare organizations, and biometric categorization systems. Most direct clinical AI lands in Route 1 because it already meets the medical-device definition; Route 2 is more likely to catch the adjacent categories. If your product's shape is unusual enough that you are not sure which route (or both) applies, that guide's step-by-step decision tree is built to be worked through directly against your specific product.

Companion asset: the AI Act applicability checklist. This handbook is paired with an ungated AI Act applicability checklist, freely available through our assessment flow described below — no email required to see the output. It works through the same decision points as Chapter 1 above (medical purpose, MDR/IVDR class, Notified Body involvement, Annex III adjacency) and returns a plain-language read on which route, if any, applies to your product and which deadline attaches to it. Because part of the checklist's reasoning is AI-generated, its output carries an explicit "AI-generated content, reviewed by regulatory team" framing rather than being presented as a validated determination — treat it as a fast, well-informed first pass, not a substitute for the expert conversation that should precede any compliance programme built around the answer.

Find out in minutes whether the AI Act applies to your product, and if so, which route and deadline attach to it. Start the MedTech Compass →

The deadline map, honestly — where the Digital Omnibus actually stands

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

This is the chapter most likely to be stale if you are reading a cached copy of this page, or reading older commentary elsewhere on the AI Act's timeline. So we want to be precise about exactly what changed and when: the Digital Omnibus completed its final legislative step with Official Journal publication on 24 July 2026 and enters into force on 27 July 2026, making the deferred dates below the legally binding ones.

What actually changed. Here is the compressed reference table, current as of this status date:

Two things follow directly from that table, and they pull in different directions, which is exactly why this chapter exists as a standalone section rather than a single line item. First, if you built a compliance plan around the original 2 August 2027 date for Article 6(1), the deferral gives you roughly a year of additional runway before full high-risk conformity obligations bind for medical devices — genuinely useful for a board conversation about sequencing spend, now that the 2 August 2028 date is the legally binding one to plan against. Second, and more urgent in the other direction: if you were tracking Article 4 AI literacy against an August 2026 deadline, that deadline was never correct anywhere on this site or, as far as we can tell, in most industry commentary that repeated it. The obligation has been in force since 2 February 2025, with no transitional period; the Act's broader enforcement and penalty machinery follows from 2 August 2026, but the obligation itself is already live. We cover this obligation on its own, in full, in Chapter 6, because it differs in kind from the two dates above: there's nothing to plan for, only something to confirm you've already closed.

A third date worth separating out clearly: Article 50 is not part of the deferral. It is easy to read the Digital Omnibus as pushing back "the AI Act timeline" broadly, but the deferral is specific to the high-risk obligations above. Article 50's transparency obligations — disclosing that a user is interacting with an AI system, labeling AI-generated or manipulated content, and related duties — were not touched by the Digital Omnibus and remain due from 2 August 2026, on their original schedule, running in parallel with the now-deferred Annex III and Article 6(1) dates. If your product has any user-facing AI interaction or generates content a user might mistake for human-authored, treat 2 August 2026 as a live date, not one of the dates that just moved.

Why medical devices got a later date than the general Annex III timeline. The reasoning shapes how you should think about the extra runway. Medical devices already sit inside a mature, sector-specific conformity assessment system — Notified Bodies, technical documentation requirements, post-market surveillance, an established audit cadence, all under MDR and IVDR already. The AI Act's drafters recognized that forcing high-risk AI obligations onto the same date as the general Annex III timeline would have meant asking an already-stretched Notified Body system to absorb a second, simultaneous compliance wave, with device manufacturers given no lead time to adapt technical files that, in many cases, predate AI-specific requirements existing at all. That logic produced the original later date for medical devices in the Act's text, and it is the same logic the Digital Omnibus extends further in pushing both dates out.

What the package changes beyond dates. This chapter focuses on dates because that is a founder's most immediate planning question, but the Digital Omnibus also touches definitional and procedural elements of the Act more broadly. We track the dates here and the substantive obligations in Chapter 3; if a procedural change affects how your Notified Body reviews AI Act content specifically, it is more likely to surface in our nested deadlines tracker or our dual-conformity chapter than as a standalone item here.

A worked scenario, to make the arithmetic concrete. Consider a startup with a Class IIa diagnostic AI product, previously planning a Notified Body submission in the second half of 2027 to meet the original Article 6(1) date. The Digital Omnibus deferral changes the arithmetic: the binding date is now 2 August 2028, roughly a year later than the plan this team originally built around. Treating the extra year as a reason to deprioritize AI Act work generally would be a mistake — the data governance documentation covered in Chapter 4 is cheapest to produce contemporaneously, while training and validating the model, and becomes progressively more expensive to reconstruct the longer a team waits. Better to use the additional runway deliberately: sequence AI Act evidence-gathering alongside ordinary MDR technical file development on a steady, continuous timeline, rather than compressing it into a rushed sprint immediately before whichever date eventually applied.

How to talk about this timeline with investors. Founders raising during this period are often asked directly whether AI Act compliance is "handled." The answer that holds up under diligence distinguishes three components, not two: Article 4 AI literacy (already in force since February 2025 — the question here is confirmation, not planning), general Annex III obligations (2 December 2027 under the Digital Omnibus deferral in force from 27 July 2026, relevant mainly if you have adjacent non-device AI functions), and Article 6(1) conformity for medical devices (2 August 2028 under the same deferral, integrated into your MDR submission timeline, covered fully in Chapter 5). A founder who presents the superseded original dates as current — or one whose tracking has missed the deferral's entry into force entirely — signals to a diligence-minded investor that their regulatory tracking is imprecise, often a bigger credibility problem in the room than the underlying compliance status itself. The more credible position states the position precisely: the deferred dates became the legally binding ones when the Omnibus entered into force on 27 July 2026, superseding the original 2 August 2026 and 2 August 2027 dates.

Frame every date claim the same way. The Digital Omnibus (in force from 27 July 2026) postpones the AI Act's high-risk deadlines: 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) — and the original 2 August 2026 and 2 August 2027 deadlines are superseded. We therefore frame every deferred deadline in this handbook the same way: in force and the dates to plan against. We will update this page if anything else material changes.

For the full legislative history, the complete date table, the investor-communication framing in more depth, and a live status tracker maintained independently of this pillar's broader content, see our nested spoke AI Act Dates After the Digital Omnibus. We keep that page separate deliberately: these dates change on a legislative timeline driven by EU institutional process, independent of the substantive material in the rest of this handbook, and a reader who only needs the current date should not have to work through an 8,000-word document to get it.

Find out in minutes which deadline, if any, applies to your specific product. Start the MedTech Compass →

What high-risk obligations actually require, article by article

High-risk status under the AI Act is not a label; it is a package of engineering and documentation obligations, drawn from Articles 9 through 15, that sits alongside — and substantially overlaps with — what MDR already asks of you. Reading these article by article, rather than as a single undifferentiated "compliance burden," makes the actual scope of new work much clearer.

Article 9 — Risk management system. A risk management system run across the AI system's entire lifecycle, identifying and mitigating risks to health, safety, and fundamental rights. If you already run ISO 14971:2019 risk management for your device, this is the same discipline extended to AI-specific risk sources: dataset shift, performance degradation over time, automation bias in the clinicians using your output, and adversarial robustness. The practical addition is usually a dedicated AI risk register, cross-referenced against your existing hazard analysis rather than replacing it wholesale.

Article 10 — Data governance. Covers the training, validation, and testing datasets used to build the model: their relevance, representativeness, error-freeness, and completeness for the intended purpose, plus an examination of possible biases. This is the requirement with the least direct MDR equivalent, and the one that catches teams out most often, because it demands documentation of decisions made early in model development, sometimes before the company had formal design controls in place at all. We give this article its own full chapter below, because in our experience building compliance programmes with founders, it is consistently the single largest source of unplanned rework.

Article 11 and Annex IV — Technical documentation. Describes the system, its design, its intended purpose, and evidence of conformity, in a format that maps closely onto what a technical file already contains under MDR Annex II. The genuinely new content here is largely the data governance summary (see Article 10) and specific AI system description elements; the document structure itself is not unfamiliar to a team that has already built an MDR technical file.

Article 12 — Record-keeping and automatic logging. Requires the AI system to automatically log events across its operation, sufficient to enable traceability of its functioning and to support 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 system architecture from the start, not bolted on before an audit. This overlaps with, but is more specific than, MDR's general post-market surveillance obligations — the Act is asking for machine-readable operational logs, not just adverse event tracking.

Article 13 — Transparency and instructions for use. Requires information about the system's capabilities, limitations, tested accuracy, and circumstances that could affect performance, presented to professional users 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 — tested accuracy ranges, known failure modes, and conditions (image quality, input completeness, patient population fit) that could degrade performance.

Article 14 — Human oversight. Requires the system to be designed so a natural person can understand its output, monitor its operation, and intervene, override, or halt it where appropriate. This has no direct MDR equivalent for most device types, though it echoes usability engineering principles many teams already apply under IEC 62366-1. It becomes materially harder to satisfy for autonomous, multi-step systems — a point we return to in Chapter 7 on agentic AI.

Article 15 — Accuracy, robustness, and cybersecurity. Requires the system to achieve, and be tested and documented against, a level of accuracy, robustness, and cybersecurity appropriate to its intended purpose. This is the article most likely to overlap with verification and validation work you are already producing under IEC 62304:2006+A1:2015 software lifecycle processes, extended with AI-specific performance metrics, test conditions, and adversarial-robustness considerations.

None of these seven obligations is unfamiliar territory to a team that has already built a technical file and quality management system for MDR. What's new is that they now sit in a distinct piece of legislation, with its own conformity assessment logic, its own enforcement body outside your Notified Body relationship in some cases, and its own penalty regime (fines calculated as a percentage of global annual turnover) — which is why the two frameworks need to be read together, not treated as duplicate paperwork. Chapter 5 of this handbook, and our nested spoke on dual conformity, cover exactly how that integration works in a Notified Body review.

A note for teams building on third-party foundation models. If your product integrates a general-purpose AI model rather than training your own, the obligations above still land on you as the device manufacturer for how you fine-tuned, prompted, or validated that model for your specific intended purpose — regardless of who trained the underlying weights. Separately, general-purpose AI model providers (companies that themselves supply a foundation model, rare for this audience but worth naming precisely) carry their own distinct obligations, and those obligations are phased rather than a single flat date: they apply from 2 August 2025 for GPAI models placed on the market on or after that date, while models placed on the market before 2 August 2025 have until 2 August 2027 to comply, and the European Commission's own enforcement powers over GPAI obligations only begin applying from 2 August 2026. Most founders reading this handbook are integrators, not providers, and carry the integrator's obligations described throughout this handbook — but if your company is unusual in also providing a general-purpose model to others, or you are evaluating a vendor's provider-side compliance timeline as part of due diligence, that phased schedule is worth confirming with counsel rather than assuming a single date covers it.

Data governance (Article 10) for medical AI

This chapter gets its own space in the handbook because, across every product we have looked at, Article 10 data governance is the single most underestimated line item in an AI Act compliance programme. Teams underestimate its scope, its lead time, and — most damagingly — how much of it needs to have been documented as you went, not reconstructed after the fact.

What Article 10 actually asks for. Training, validation, and testing datasets need to be documented against four qualities: relevance to the intended purpose, sufficient representativeness of the population the device will actually be used on, freedom from errors to the extent reasonably possible, and completeness appropriate to the intended purpose. On top of that baseline, the Act requires an examination of possible biases in the data that are likely to affect health, safety, or lead to discriminatory outcomes, and documentation of the measures taken to detect, prevent, and mitigate those biases.

Why this has no direct MDR precedent. MDR's clinical evaluation asks whether your device works and is safe for its intended population, evaluated largely through clinical evidence about the finished device's performance. Article 10 asks a narrower, upstream question about the specific component that makes modern AI-enabled devices different: was the data that produced the model itself sound, representative, and examined for bias, independent of how the finished device later performs in clinical evaluation. A device can pass clinical evaluation on the population it was tested against while still carrying an Article 10 gap if the underlying training data's representativeness and bias examination were never documented in the first place.

The specific evidence a Notified Body will expect to see, based on how reviewers are currently approaching AI Act-adjacent content within MDR technical documentation reviews:

• Provenance documentation for every dataset used in training, validation, and testing: where the data came from, under what legal basis it was obtained or licensed, and what consent or ethics approvals covered its use.
• A representativeness analysis comparing the demographic, clinical, and technical characteristics of the training population against the device's intended-use population — age, sex, ethnicity where clinically relevant, disease severity or stage, and, for imaging or signal-based devices, the equipment types and acquisition settings represented in the data.
• A documented bias examination: what subgroups were checked for differential performance, what methodology was used, what was found, and what mitigation (if any) followed from those findings.
• Data quality controls: how errors, mislabeling, and missing data were identified and handled, and what completeness thresholds were applied before a dataset was considered fit for use.
• Version control linking specific model versions to the specific dataset versions used to train and validate them, so that a reviewer can trace any deployed model back to the exact data that produced it.

Why lead time matters more here than almost anywhere else in this handbook. If your model was trained before your company had formal documentation discipline in place — which describes a large share of the AI-enabled medical device startups we work with — closing an Article 10 gap retroactively is a genuinely difficult reconstruction exercise: pulling dataset provenance from commit history, old notebooks, and institutional memory that degrades every month a key team member is no longer around to explain a decision. Teams that start capturing this evidence contemporaneously, as they train and validate each model version, spend meaningfully less time and money on this article than teams that start reconstructing it eighteen months from now under deadline pressure, even with the extra runway the Digital Omnibus provides.

A practical starting discipline, if your team has not yet formalized this: treat every new training run as an event that produces two artefacts, not one — the model, and a dataset-provenance-and-representativeness memo attached to that specific model version. It does not need to be a polished document initially; it needs to exist, be dated, and be traceable to the model it describes. Retrofitting this discipline is far cheaper than retrofitting the evidence.

The Article 10 walkthrough above is the concentrated version specific to this handbook. For how this requirement sits inside a combined MDR + AI Act technical file structurally, and how much of the surrounding documentation (risk management, technical documentation, instructions for use) you can extend rather than duplicate, see Chapter 5 below and our nested spoke on dual conformity.

Dual conformity: integrating the AI Act into your MDR assessment

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, checked against two sets of requirements. Understanding how that integration is designed to work — and what a combined submission package actually looks like — is the difference between a team that treats AI Act work as a fifth, bolted-on workstream and one that folds it into the MDR programme it is already running.

Why the Act was written to integrate rather than duplicate. 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. 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. 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 hold or acquire the necessary AI-specific expertise.

What a combined submission package actually looks like. 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 (General Safety and Performance Requirements) checklist, risk management file, design and manufacturing information, verification and validation evidence, clinical evaluation report, and labelling. The AI Act content does not sit in a separate binder; it is 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 Article 10 data governance documentation described in Chapter 4 above, since this content has no natural home elsewhere in a standard MDR file structure. A Notified Body wants to see a technical file that reads as one coherent document, written by a team that understood both frameworks from the start — not two documents stapled together by two teams working from two different requirement lists.

Documentation reuse map. For teams planning the actual work, this table maps each MDR artefact you are likely already producing to the AI Act requirement it extends to cover, and flags how much genuinely new work each row represents.

Where Notified Bodies actually are on this today. It's worth being honest about current readiness, since it affects how much guidance you should expect from a given Notified Body versus how much your own team needs to drive. As of this review, no Notified Body has yet completed a fully integrated MDR + AI Act certification for a medical device — the AI Act's device-specific obligations simply aren't in force yet (they apply from 2 August 2028 under the Digital Omnibus deferral, in force from 27 July 2026, per Chapter 2). Several MDR-designated Notified Bodies are already building AI-specific technical assessment capacity in anticipation, though, 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. The practical implication: don'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 the relationship, what AI-specific expertise your assigned reviewers have.

A worked example. 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 needs a technical file covering intended purpose, device description, GSPR mapping, a clinical evaluation report, verification and validation testing (including software verification under IEC 62304), risk management under ISO 14971, and post-market surveillance procedures. Layering the AI Act on top does not create a second file of comparable size. It adds: an AI-specific risk analysis appendix covering dataset shift and false-negative risk specifically (a missed finding is the dominant safety concern for this product type); a data governance section documenting training data provenance, representativeness, and bias examination, particularly around imaging equipment variation and patient demographic representation; model performance testing reporting sensitivity and specificity with the test conditions under which they were measured; transparency content describing tested accuracy range and performance-degrading circumstances; and a logging capability built into the software itself, so individual predictions and their inputs can be traced after deployment.

One dual-conformity watch item on the horizon. The same MDR/IVDR simplification proposal flagged in Chapter 1 (COM(2025) 1023, procedure 2025/0404(COD)) would also move AI devices from Annex I "Section A" to "Section B" of the AI Act's framework, so that the AI Act would apply only as specified in the MDR/IVDR sectoral provisions — a change that would reshape exactly the integration mechanics this chapter describes. It is a proposal, not law, with adoption realistically 2027 at the earliest; plan against the current architecture while keeping this on the watch list.

For the full mechanics of this integration, including the practical sequencing question of when to start folding AI Act work into an MDR programme already underway, see our nested spoke One Notified Body for MDR and the AI Act, which covers this at roughly 2,800 words with additional detail on the joint-assessment procedural questions that remain genuinely open alongside the now-settled timing question.

AI literacy (Article 4): the one obligation nobody can defer

Every other deadline in this handbook is, in some sense, a future planning question — even the deferred 2 December 2027 and 2 August 2028 dates (binding from 27 July 2026) give you real runway to sequence work deliberately. Article 4 differs in kind, not just in date, and deserves to be read as its own item rather than folded into the general timeline discussion in Chapter 2.

Article 4 has applied since 2 February 2025. It has no connection to the Digital Omnibus, no transitional period, and no grace period — the European Commission has confirmed none exists. It has been a binding legal obligation since that date; the Act's wider enforcement and penalty machinery applies from 2 August 2026, so the sensible posture is to treat the obligation as live now rather than waiting for the enforcement apparatus to catch up. If any internal roadmap, board deck, or investor data room you are working from has AI literacy training scheduled against an August 2026 or later date, that roadmap reflects a drafting error that circulated widely across AI Act commentary (including, at points, on this site) by conflating Article 4 with the general Annex III high-risk date. The right framing isn't "get ahead of this" — it's "confirm you're already compliant," because the obligation has already been live for well over a year.

What Article 4 actually requires. The obligation applies to providers and deployers of AI systems — meaning, for most companies reading this handbook, both the sense in which you build AI into your product and the sense in which your own staff use AI tools day to day — to ensure staff and other people dealing with the operation and use of AI systems on your behalf have a sufficient level of AI literacy. That literacy needs to be proportionate to their technical knowledge, experience, education, training, and the context the AI system is used in. It applies regardless of whether the AI system in question is high-risk: this is one of the reasons it is worth confirming even for teams whose product does not clear either high-risk route described in Chapter 1, since the obligation attaches to your organization's use and deployment of AI generally, not specifically to a high-risk product.

Why this is easy to get wrong in the other direction, too. A newer mistake pattern, since the Digital Omnibus deferral was agreed, is treating the extra runway on Article 6(1) and Annex III as a reason to deprioritize AI Act work broadly, including Article 4. The two are unrelated. The additional time to 2027 and 2028 changes nothing about Article 4's status, which has been settled and binding since February 2025 regardless of anything the Digital Omnibus does or does not change.

Checklist — closing out Article 4. "Confirm compliance" is more useful as an actual list than as a general instruction:

☐ Identify every role in your organization that touches the operation, oversight, or output interpretation of an AI system — not just your data science or ML engineering team, but clinical affairs staff reviewing model output, customer-facing staff explaining AI-driven features, and leadership making product decisions informed by AI system behavior. ☐ Confirm a documented AI literacy programme exists for each of those roles, proportionate to their actual involvement — a data scientist needs a different depth of literacy than a customer success representative, and the Act's proportionality language supports tailoring rather than a single generic training module for everyone. ☐ Confirm the programme has actually been delivered, not just designed — documentation of a training plan that was never executed does not satisfy an obligation that has applied since February 2025. ☐ Keep a record of who completed what training and when, since this is the evidence a market surveillance authority would expect to see if Article 4 compliance were ever questioned. ☐ Revisit the programme when your AI system's function changes materially, or when new staff take on AI-adjacent roles, rather than treating initial training as a one-time event.

This remains, relative to every other obligation in this handbook, inexpensive to close. That is exactly why it is worth confirming now rather than assuming it is someone else's problem, or worse, someone else's future problem.

Agentic and adaptive AI: the open questions

No regulator has published a framework written specifically for agentic AI in healthcare. We won't manufacture confidence we don't have here; what follows is an honest map of how existing rules apply today, where they genuinely strain, and how to build a defensible posture in the meantime.

What makes agentic AI different for regulators. Most of MDR and the AI Act were written with a mental model of software as a fixed, bounded system: defined input, defined process, defined output, validated once and then locked, changing only through a controlled, documented, re-validated update. An agent breaks that model in three specific ways. Autonomy — an agent can take multi-step action toward a goal with less human intervention at each step than a traditional decision-support tool, changing where human oversight actually has to sit in the chain. Tool use — an agent that calls external tools or invokes other models introduces a composition problem: its behavior depends not just on its own training but on everything it calls, much of which may not have been validated as part of the same regulatory submission. Continuous change — agentic systems built on foundation models that are themselves updated by their providers can change behavior without the deploying organization initiating or controlling that change, a structurally different problem from the "we shipped a new model version" change management both MDR and FDA's evolving AI/ML frameworks were built to handle. No single property is unprecedented on its own; having all three at once, in a healthcare context where an unvalidated behavior change means patient harm rather than a degraded recommendation feed, is genuinely new.

How existing frameworks apply today, honestly. Regulators have not published agent-specific rules, but agentic systems in healthcare are not unregulated. Under MDR, the question is unchanged: does the agent have a medical purpose, regardless of how it arrives at its output? An agent that autonomously adjusts a treatment recommendation or flags a clinical concern meets the same medical-purpose test as any other software, classified under Rule 11 the same way. Under the AI Act, if that agent is a medical device requiring Notified Body assessment, Article 6(1) makes it automatically high-risk, the same as any other AI-enabled device, and the Articles 9–15 obligations from Chapter 3 apply — even though satisfying them, particularly human oversight and logging given multi-step autonomous action, is genuinely harder in practice for an agent than for a static model.

Three genuinely open questions. Change control: if an agent's behavior can shift because an underlying foundation model provider updates that model, who is responsible for re-validating clinical behavior, on what cadence, and how does that fit inside MDR's change-management framework, which was built around the manufacturer controlling the change directly? FDA's predetermined change control plan (PCCP) framework offers the closest existing template — FDA PCCP: Updating AI Models After Clearance covers how it works — but it presumes changes the manufacturer specifies in advance, a different problem from a dependency changing underneath you. Human oversight in a multi-step process: what meaningful oversight means for an agent taking several autonomous actions, each individually low-risk but cumulatively consequential, is not yet settled in guidance from any regulator we track. Liability chains: when an agent calls a tool and that tool's output contributes to an adverse outcome, existing product liability and MDR vigilance frameworks assume a single accountable manufacturer for a single product — an assumption a multi-vendor agentic architecture strains in ways liability law has not caught up with.

A defensible posture now, in the absence of agent-specific rules. Classify your agent under MDR and the AI Act with the same rigor you would apply to any other software, without treating agentic architecture as grounds for a lighter touch. Design human oversight into the workflow at points that correspond to genuine clinical decision moments, not just at the start or end of a multi-step process, and document why those points were chosen. Define and document the bounds of the agent's autonomy — what tools it can call, what actions it can take without escalation, what triggers a stop — as though writing a change control plan, even though no regulator currently requires you to submit one in this form. Build logging that captures intermediate steps and tool calls, not just final output, since traceability requirements under both frameworks will be far easier to satisfy retrospectively if captured from the start.

Evaluating a vendor-supplied agentic component. Many teams are not training their own foundation models; they are orchestrating third-party models and tools inside an agentic framework they built. That raises a distinct question: what do you need from a vendor to defend your own regulatory position? At minimum: precise, reproducible documentation of which model version your agent relies on; a vendor commitment (contractual or otherwise) to notify you of material model changes, or a detection mechanism if no such commitment exists; documented, repeatable evaluation of the component against your own specific clinical intended use, not just the vendor's general-purpose benchmarks; a defined fallback and degradation behavior if the component becomes unavailable or behaves anomalously; and contractual clarity, however general, on liability allocation if the vendor's component contributes to an adverse outcome.

A note on UK market sequencing

This is a UK-specific point, not part of the EU AI Act's own framework — it sits here because founders weighing multi-market sequencing for adaptive AI products often need it alongside the agentic discussion above, not because it's related in substance.

The practical answer, stated plainly: the UK's legacy Class I self-certification route for standalone software remains open today, with no confirmed closing mechanism. A product that is Class IIa under EU MDR's Rule 11 can currently still self-certify as Class I in Great Britain under UK MDR 2002 as amended, and nothing in the MHRA's current draft changes that. If your sequencing plan leans on this route, treat it as open today, worth monitoring rather than assuming either permanence or a specific expiry date.

This chapter is the concentrated version of a topic we treat as genuinely unsettled rather than pretend to have resolved. Our nested spoke Agentic AI Governance in Healthcare covers all of this in more depth, including a standalone vendor-evaluation checklist formatted for direct use against a specific vendor relationship, at roughly 2,800 words.

Your 12-month compliance sequence

Everything above this chapter is diagnostic and explanatory. This chapter is the plan. It assumes you have already confirmed, via Chapter 1, that Article 6(1) applies to your product — if you have not yet made that determination, start there, since nothing below is useful until you know whether it applies to you at all.

Months 1–2: Classification and gap baseline. Confirm your MDR or IVDR class and Notified Body requirement definitively, if you have not already — this is the single determination the rest of your AI Act exposure depends on. Confirm Article 4 AI literacy status across your organization immediately; per Chapter 6, this is not a future item, so closing any gap here happens in month one, not month eleven. Run a documentation gap analysis against Annex IV, focused specifically on data governance (Chapter 4), since this is the area with the least MDR precedent and the longest lead time to close if training data documentation was not captured contemporaneously. Identify every AI system your organization uses internally, not just your product, since Article 4 and general governance hygiene apply to internal tool use as well as your shipped product.

Months 2–4: Data governance reconstruction and forward process. For every model version already trained, reconstruct dataset provenance, representativeness analysis, and bias examination to the extent the underlying records allow, prioritizing the model version closest to your current production system. In parallel, stand up a forward-looking process so every new training run automatically produces a dataset-provenance-and-representativeness memo alongside the model itself, per the practical discipline described in Chapter 4. Begin extending your ISO 14971 risk management file with an AI-specific risk register covering dataset shift, automation bias, and adversarial robustness.

Months 4–6: Architecture work for logging and oversight. Design and implement automatic logging (Article 12) into your system architecture if it is not already present — this is engineering work, not documentation work, and needs to happen before, not after, the rest of your technical file is finalized. Design human oversight checkpoints into your product workflow at genuine clinical decision points, documenting why each checkpoint was chosen (this is materially more important if your product has any agentic or multi-step autonomous element, per Chapter 7). Begin model performance testing structured to produce the accuracy, robustness, and cybersecurity evidence Article 15 requires, alongside your existing IEC 62304 verification and validation work.

Months 6–8: Technical file integration. Fold the AI-specific risk analysis appendix into your existing MDR risk management file rather than maintaining it separately. Draft the Article 10 data governance section as its own technical file section, typically placed near your clinical evaluation report. Extend your instructions for use and labelling with Article 13 transparency content: tested accuracy ranges, known limitations, and performance-affecting circumstances. Extend your post-market surveillance plan to explicitly cover AI Act post-market monitoring obligations.

Months 8–10: Notified Body engagement. If you have not already, have an explicit conversation with your Notified Body about their AI-specific technical assessment capacity and how they expect to review combined MDR + AI Act content, per the honesty check in Chapter 5 about where Notified Body readiness actually stands today. Walk your near-complete technical file through an internal readiness review, ideally with someone who has seen a Notified Body review AI Act-adjacent content specifically, checking that the file reads as one coherent document rather than MDR content with an AI Act annex stapled on.

Months 10–12: Submission preparation and continuous monitoring. Finalize your combined technical file for submission on your actual MDR timeline (which may run well ahead of the Article 6(1) date of 2 August 2028; see the note below). Stand up your post-market monitoring process so it is operational before, not after, your device reaches the market. Set a recurring review cadence (we recommend quarterly, at minimum) to re-check this handbook's Chapter 2 deadline table and your organization's Article 4 status, since both are the kind of thing that degrades silently if nobody owns checking them.

A note on why this sequence does not wait for 2028. The 2 August 2028 date in Chapter 2 is when Article 6(1) obligations become legally binding under the Digital Omnibus deferral (in force from 27 July 2026) — it is a deadline, not a recommended start date, and treating it as one is the single most common sequencing mistake we see. Your actual MDR submission timeline, driven by your own product roadmap and Notified Body queue, is very likely to land well before 2028 regardless of the AI Act's own deadline, and Notified Bodies are already factoring AI Act-adjacent expectations into MDR technical documentation reviews ahead of the formal requirement. Build to your MDR timeline, with AI Act work integrated throughout, rather than to the AI Act's binding date in isolation.

Talk to someone who can sequence this against your specific product, MDR class, and Notified Body timeline, rather than a generic twelve-month template. Book an expert conversation →

Frequently Asked Questions

We are pre-clinical and haven't picked a Notified Body yet. Does any of this apply to us now? Article 4 AI literacy applies to your organization already, regardless of your product's development stage, since it attaches to your organization's use and deployment of AI systems generally, not to a specific product's regulatory status. The Article 6(1) obligations from Chapters 3–5 become legally relevant once you can determine your likely MDR class and Notified Body requirement — a determination worth making early, even pre-clinical, because it shapes how you design your data governance and logging practices from the start, when they are cheapest to build in.

Our AI model is licensed from a third party, not trained in-house. Whose obligation is data governance? Yours, for how you fine-tuned, prompted, validated, or otherwise adapted the model for your specific intended clinical use, regardless of who trained the underlying weights. You are the device manufacturer; you carry the manufacturer's Article 10 obligations for your integration. The vendor evaluation checklist in Chapter 7 covers what to request from the third party to support this, but the underlying obligation does not transfer to them by default.

Now that the Article 6(1) deadline has moved to 2028, is there any real cost to waiting until 2027 to start? Yes, and the cost is concentrated specifically in data governance (Chapter 4). That evidence is cheapest to produce contemporaneously, while you are actually training and validating each model version; waiting means reconstructing provenance, representativeness, and bias documentation from commit history and institutional memory that degrades every month a key team member moves on. The extra runway the Digital Omnibus deferral adds is useful for sequencing overall spend, but it does not reduce the cost of late data governance work — if anything, it increases the gap between what contemporaneous documentation would have cost and what reconstruction eventually costs.

Does a Class I, self-certified product ever need to worry about the AI Act? Not through Article 6(1), since that route requires third-party Notified Body conformity assessment, which standard Class I devices do not undergo. It is still worth checking your product against the separate Annex III use-case list from Chapter 1, since a small number of non-device AI applications (certain benefits-eligibility tools, employment-related AI, biometric categorization) are caught that way regardless of MDR class. And Article 4 AI literacy applies to your organization regardless of your product's classification at all.

We're building something agentic. Should we wait for regulatory clarity before shipping? That is a commercial decision as much as a regulatory one, and reasonable teams land differently on it. What we would caution against, per Chapter 7, is building without applying existing frameworks conservatively in the meantime. Waiting for clarity and building without governance discipline are two different choices, and only the second is defensible if something goes wrong before agent-specific guidance eventually arrives — which, as of this handbook's status date, no regulator we track has published.

Is there a version of this handbook's checklist we can actually use against our own product, rather than just reading the reasoning? Yes — the AI Act applicability checklist described in Chapter 1's companion-asset callout works through the same decision points this handbook covers (medical purpose, MDR/IVDR class, Notified Body involvement, Annex III adjacency) and returns a written, plain-language read specific to what you enter. It is ungated, so there is no email requirement to see the output, and because part of its reasoning is AI-generated, its output is explicitly framed as AI-generated content reviewed by our regulatory team, not a validated determination — a strong first pass, not a substitute for the expert conversation that should precede any compliance programme built around the answer.

---

Where next — the five spokes nested in this handbook:

When Medical Device AI Becomes High-Risk — the concentrated ~3,000-word introduction to the Article 6(1) automatic-capture rule and the Articles 9–15 obligation set, the right starting point if you are new to this topic and want the fast version before returning here for depth.

One Notified Body for MDR and the AI Act — the full mechanics of how one Notified Body reviews one technical file against two frameworks, including the documentation reuse map and a worked Class IIa imaging example in more depth than Chapter 5 above.

AI Act Dates After the Digital Omnibus — our standalone, most-frequently-updated tracker for the exact dates in Chapter 2, including the full Digital Omnibus legislative history and its entry into force.

Two Routes to High-Risk AI in Healthcare — the full Route 1 / Route 2 decision tree referenced in Chapter 1, with worked examples covering triage tools, wellness AI, and administrative AI edge cases.

Agentic AI Governance in Healthcare — the full version of Chapter 7, including a standalone vendor-evaluation checklist for teams orchestrating third-party models inside an agentic architecture.

See also our sibling pillar, data and AI governance for health tech, for the broader data governance and AI oversight questions that extend beyond AI Act scope specifically.

Find out in minutes whether the AI Act applies to your product, and which deadline and route attach to it. Start the MedTech Compass →

Talk to someone who has built AI Act evidence into an actual MDR submission, not just read about the framework. Book an expert conversation →

This page carries the most prominent dated status line on the site because it is the flagship living document for AI Act content. Status (updated 25 July 2026): the Digital Omnibus package that postpones the AI Act's high-risk deadlines 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 for Annex III; 2 August 2028 for Article 6(1) medical devices) are the legally binding ones, and the original 2 August 2026 and 2 August 2027 dates are superseded. Article 4 AI literacy has applied since 2 February 2025 and is unaffected by any of this. Every reference to 2 December 2027 or 2 August 2028 in this handbook now reflects settled statute. Next review 1 October 2026, or on any other material development, whichever comes first.