The EU AI Act for Medical Devices: Foundations and Scope
By Vaclav Vlcek, MD
Three questions decide how the AI Act applies to a device: is it an AI system at all, is it high-risk, and what role does the company play? The answers set every obligation that follows.
This part works through the definitions, scope, timeline, and risk tiers that decide where a given system lands. It is the reference layer behind the overview in the [Introduction].
Summary
The EU AI Act defines an AI system broadly, and it sorts systems into risk tiers that carry very different obligations. An AI-enabled medical device is high-risk under Article 6(1) and Annex I, because it already undergoes third-party conformity assessment under the MDR or IVDR.
The company that places the system on the market is the provider and holds the pre-market duties; the organisation that uses it, such as a hospital, is the deployer. After the Digital Omnibus on AI (Regulation (EU) 2026/1744), the high-risk obligations for medical devices apply from 2 August 2028.
What Counts as an AI System
The Act's definition of an AI system is deliberately wide, and it centres on one thing: the capacity to infer.
Article 3(1) defines an AI system as "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments."
In plain terms, an AI system takes inputs, such as patient data or sensor readings, and produces outputs that act on the world: predictions, recommendations, or decisions, whether in a physical device or an electronic health record.
A clinical decision-support tool that recommends a cancer treatment from patient history, genetic data, and live lab results fits the definition. If it keeps refining those recommendations as new outcomes come in, it also shows the adaptiveness Recital 12 describes: the capacity to learn or change after deployment.
That last point matters for medical software, because a system that learns in the field is exactly the kind the Act was written to catch.
Embedded and Non-Embedded Systems
The Act covers AI whether or not it is built into the product.
An embedded system is part of the device and cannot work on its own, like the algorithm inside a smart insulin pump that adjusts dosage from glucose readings.
A non-embedded system sits outside the device but still shapes clinical decisions, like a cloud diagnostic tool that reads medical images and sends results to a radiology workstation.
Both are in scope. Where the AI physically lives changes nothing about whether the Act applies.
Who Is Responsible: Provider and Deployer
The Act assigns obligations by role, and the two that matter most are provider and deployer. Getting the role right is the first compliance decision a company makes, because the duties follow from it.
A provider (Article 3(3)) develops an AI system, or places it on the market under its own name, whether for a fee or free of charge. A health-tech company that builds and markets a diagnostic tool is the provider, even if hospitals use it at no cost.
A deployer (Article 3(4)) uses the system under its authority in a professional capacity. A hospital running an AI triage tool to prioritise emergency patients is the deployer.
The split is practical. Providers carry the pre-market obligations: risk management, data governance, technical documentation, and conformity assessment.
Deployers carry the in-use obligations: human oversight, monitoring, and reporting serious incidents.
Where the Act Applies
The AI Act reaches beyond the EU's borders. What matters is where a system is placed, used, or has its effect, wherever the company itself is based.
A US software firm that sells an AI radiology platform to EU hospitals is a provider, with no EU presence required. A German hospital using a CE-marked AI tool in cardiology is a deployer.
An EU distributor that imports a US tool, rebrands it, and markets it under its own name takes on the provider's obligations in full.
That last case is a role transition, and it is easy to miss.
A distributor or deployer that rebrands a system, substantially modifies it, or changes its intended purpose can become the provider by operation of law, inheriting the full set of obligations. Article 25 governs when that shift happens along the AI value chain.
Missing it carries real consequences: non-compliance, invalidated certificates, and liability for a non-conforming system in clinical use.
Reclassification and When a New Conformity Assessment Is Needed
A high-risk AI system has to pass conformity assessment before it reaches the market. For a medical device, that assessment is carried out by a Notified Body designated under the MDR or IVDR.
It covers the AI-specific ground: risk management, data governance, technical documentation, and post-market monitoring.
A fresh assessment is needed at three points: before the system is first placed on the market, after a substantial modification, and when a party other than the original provider makes a change that affects the system's compliance.
"Substantial modification" is defined in Article 3(23), and the requirement to run a new assessment after one is set by Article 43(4).
Retraining a diagnostic algorithm on new data after launch can qualify, unless the change was already foreseen and documented in the original assessment. For a system designed to keep learning, changes the provider predetermined and recorded in the technical documentation do not count as substantial.
The Implementation Timeline
The Act applies in stages, and the Digital Omnibus on AI moved several of the later dates. The deadline that matters for medical devices is 2 August 2028. The table below reflects the amended timeline.
| Year | Milestone | Reference |
|---|---|---|
| 2024 | European Parliament approval (13 March); Council adoption (21 May); Official Journal publication (12 July); entry into force (1 August) | — |
| 2025 | Prohibited practices apply (2 February) | Article 5 |
| 2025 | General-Purpose AI Code of Practice published (10 July) | Article 56(9) |
| 2025 | GPAI model rules apply (2 August); governance bodies and penalties framework in place | Chapter V; Articles 99–100 |
| 2026 | Draft Commission guidelines on high-risk classification published (19 May), after the 2 February statutory deadline passed; consultation ran to 23 June, final version pending | Article 6(5) |
| 2026 | General application date (2 August): transparency duties, governance, and GPAI enforcement take effect | Article 113; Article 50 |
| 2026 | New prohibitions (non-consensual intimate imagery, CSAM) and the Article 50(2) synthetic-content marking duty apply (2 December) | Article 5; Article 50(2) |
| 2027 | Member States establish at least one national AI regulatory sandbox (2 August) | Article 57 |
| 2027 | Stand-alone high-risk systems under Annex III apply (2 December) | Annex III |
| 2028 | High-risk AI embedded in regulated products under Annex I, including medical devices and IVDs, apply (2 August); conformity assessed by a Notified Body | Article 6(1); Annex I; Article 43 |
| 2030 | High-risk AI in large-scale EU IT systems (31 December); public authorities using high-risk AI in full compliance (2 August) | Article 111 |
Table 1: EU AI Act implementation timeline, as amended by Regulation (EU) 2026/1744.
The longest runway belongs to regulated sectors such as healthcare, where the medical-device deadline now falls on 2 August 2028. The shortest belonged to the prohibited practices, enforced from February 2025, six months after the Act took force.
A set of duties was never deferred at all. The Article 50 transparency obligations and GPAI enforcement still begin on 2 August 2026, so a manufacturer has an earlier date to track alongside 2028.
The Articles That Matter Most
The Act runs to more than a hundred articles. For a medical-device manufacturer, a smaller set does most of the work, and the table below maps them.
| Article(s) | Theme | What it covers |
|---|---|---|
| 3 | Definitions | AI system, provider, deployer, high-risk, GPAI, substantial modification |
| 6–7 | Risk classification | How systems are classified as high-risk; updates to the Annex III list |
| 9–15 | Requirements for high-risk AI | Risk management, data governance, documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity |
| 16–21 | Provider obligations | Quality management, documentation, logging, corrective action, cooperation |
| 26 | Deployer obligations | Human oversight, use per instructions, monitoring |
| 27 | Fundamental Rights Impact Assessment | FRIA for certain high-risk deployments |
| 43 | Conformity assessment | Pre-market assessment; re-assessment after substantial modification (43(4)) |
| 49 | Registration | Registration of high-risk systems in the EU database |
| 50 | Transparency | Disclosure and marking obligations for certain systems |
| 72–73 | Post-market monitoring and incidents | Real-world monitoring; serious-incident reporting |
| 74–83 | Market surveillance | Authorities' powers over non-compliant systems |
Table 2: Key articles of the EU AI Act for medical-device manufacturers.
The Risk Tiers
The Act scales its demands to risk, and a system's tier decides how heavy those demands are.
Unacceptable risk (Article 5). Some practices are banned outright, such as social scoring and certain manipulative techniques. The Digital Omnibus added two further prohibitions, on AI that generates non-consensual intimate imagery and on AI that generates child sexual abuse material, which apply from 2 December 2026. The full list of prohibited practices sits in Article 5 itself.
High risk (Article 6). This is the tier that captures medical devices, and it has two routes in.
The first, Article 6(1) with Annex I, covers AI that is a safety component of, or is itself, a product regulated under the EU product laws listed in Annex I, which include the MDR and IVDR. A medical device lands here when it undergoes third-party conformity assessment under those regulations.
The second, Article 6(2) with Annex III, covers stand-alone systems used in listed areas such as biometrics, employment, and credit scoring.
The distinction carries the deadline. Medical devices sit in the Annex I route, which is why they comply by 2 August 2028 rather than the Annex III date of 2 December 2027.
General-purpose AI with systemic risk (Article 51, Annex XIII). Large models that pose systemic risk through their scale or reach carry their own transparency, documentation, and risk-mitigation duties.
Limited and minimal risk. Systems that fall below the high-risk line carry lighter duties. Some owe transparency obligations under Article 50, such as telling a person they are dealing with an AI system. The rest are largely unregulated, with voluntary codes of conduct encouraged.
What Part 1 Establishes, and What Comes Next
At this point a manufacturer can place its product: whether it is an AI system, which tier it falls into, what role the company holds, and when the obligations bite.
For most medical devices the answers are that the product is an AI system, it is high-risk under Article 6(1) and Annex I, the manufacturer is the provider, and the deadline is 2 August 2028.
Part 2 turns from classification to obligation: the article-by-article requirements a high-risk medical-device AI has to meet, and how they layer onto the MDR, ISO 13485, and IEC 62304.
Frequently Asked Questions
What makes an AI-enabled medical device high-risk under the EU AI Act?
A medical device is high-risk under Article 6(1) and Annex I when it undergoes third-party conformity assessment under the MDR or IVDR. Annex I lists those regulations among the product laws that place a device in the high-risk tier.
Is the manufacturer the provider or the deployer?
Usually the provider. The provider (Article 3(3)) develops and markets the system and holds the pre-market obligations. A hospital or clinic that uses it is the deployer (Article 3(4)) and holds the in-use obligations.
When does an AI medical device need a new conformity assessment?
After a substantial modification, as defined in Article 3(23) and required by Article 43(4). Changes the provider foresaw and documented in the original assessment, including predetermined learning behaviour, do not count as substantial.
Does rebranding or modifying someone else's AI system make my company the provider?
It can. Under Article 25, a party that rebrands a system, substantially modifies it, or changes its intended purpose so that it becomes high-risk takes on the provider's obligations.
