Part 1: EU AI Act Foundations and Scope for Medical Devices

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 to the EU AI Act for medical devices.

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) when two conditions hold together: the AI is a safety component of, or itself is, a product covered by a law listed in Annex I, Section A, such as the MDR or IVDR; and that product requires third-party conformity assessment. The provider is the entity that develops the system, or has it developed, and places it on the market or puts it into service under its own name or trademark; the organisation that uses it, such as a hospital, is the deployer. After the Digital Omnibus on AI (Regulation (EU) 2026/1744), the relevant Chapter III provisions apply from 2 August 2028 to systems classified solely through Article 6(1), subject to Article 111; Annex III must be assessed separately.

What Counts as an AI System

The Act's definition of an AI system is deliberately wide. Inference is the central feature distinguishing an AI system from conventional software, but Article 3(1) has to be assessed as a whole.

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."

The definition is technology-neutral and broad, but not every piece of software that processes inputs and produces outputs is an AI system. Article 3(1) has to be read as a whole. The system needs some degree of autonomy and the capacity to infer how to generate its outputs. Software that merely executes fixed human-programmed rules, or performs basic data processing, does not qualify on that basis alone. Adaptiveness after deployment is optional.

Example: A clinical decision-support tool may qualify where it uses machine learning, or logic- and knowledge-based inference, to derive its recommendations from patient history, genetic data and live lab results. The fact that it receives patient data and returns a recommendation does not by itself establish that it is an AI system. If it keeps refining those recommendations as new outcomes come in, it also shows the adaptiveness Recital 12 describes, though that is not a condition of qualifying.

This tracks the Commission's non-binding guidelines on the AI system definition, which treat inference as indispensable and expressly place basic processing and some fixed-rule software outside the definition.

Embedded and Non-Embedded Systems

"Embedded" and "non-embedded" are practical labels rather than AI Act definitions, but the distinction is a useful way to think about where AI sits relative to a device.

An embedded system forms part of the device and is generally not usable separately from it.

Example: The algorithm inside a smart insulin pump that adjusts dosage from glucose sensor readings. It operates as part of the device rather than as a separate product.

A non-embedded system runs outside the device and still shapes clinical decisions.

Example: A cloud diagnostic tool that reads medical images and sends results to a radiology workstation. The AI runs remotely, yet it influences the clinical decision. Note that such software may itself be an MDR or IVDR regulated product in its own right, rather than an adjunct to one.

Embedding does not itself determine scope. Each system must still satisfy Article 3(1) and Article 2, and fall outside the applicable exclusions.

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)) is an entity that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether for a fee or free of charge. Both halves matter: developing a system alone does not make a company the provider, and neither does placing someone else's branded system on the market.

Example: A health-tech company builds a diagnostic AI tool and markets it under its own brand in radiology software. It is the provider, even if hospitals receive the software at no cost. An importer that brings a third-country provider's system into the EU under that provider's brand does not become the provider by doing so.

A deployer (Article 3(4)) uses the system under its authority in a professional capacity.

Example: A hospital runs an AI triage tool to prioritise patients in the emergency department. The hospital is the deployer.

The split is practical. For high-risk systems, once the relevant provisions apply, 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 the immediate notification duties concerning risks and serious incidents under Article 26(5). The formal Article 73 report is principally the provider's obligation, applying to the deployer only where the provider cannot be reached.

Where the Act Applies

The AI Act reaches beyond the EU's borders. Article 2 catches, among other cases, providers outside the EU who place systems on the EU market, and providers or deployers outside the EU where the output of the system is used in the Union.

Example: distributor becoming provider. An EU importer brings a US AI tool into the Union and then markets that already-marketed high-risk system under its own name. It takes on the provider's obligations.

That last case is a role transition, and it is easy to miss.

Article 25 sets out when it happens, and the triggers are specific rather than general. A party becomes the provider where it puts its own name or trademark on a high-risk system already placed on the market; where it makes a substantial modification to a high-risk system such that the system remains high-risk; or where it changes the intended purpose of a system that was not high-risk so that the system becomes high-risk.

Getting this wrong carries real consequences. Provider status brings the provider's obligations with it. Liability is a separate question, assessed under the AI Act, the MDR or IVDR, product-liability law and national law, and it is not confined to whoever holds provider status. Article 25 itself does not automatically invalidate certificates, but continued validity and any reassessment have to be determined under the applicable AI Act and MDR or IVDR procedure. Under Article 44(3), where an AI system no longer meets the Section 2 requirements an AI Act notified body must restrict, suspend or withdraw the certificate unless appropriate corrective action is taken within the deadline it sets.

When a New Conformity Assessment Is Needed

Once the relevant Chapter III provisions apply, and subject to Article 111, a high-risk AI system must ordinarily undergo conformity assessment before it reaches the market, subject to the narrow exceptional derogation in Article 46. For a medical device, the sectoral notified body may assess the AI Act requirements where the competence conditions in Article 43(3) are met. A body already notified under the MDR or IVDR may perform that assessment only where the existing sectoral notification has checked and evidenced that it meets the requirements of Article 31(4), (5), (10) and (11). The Annex I Section A notified bodies to which Article 43(3) refers must apply for designation under the Act by 28 January 2028. Applying is not the same as being designated, so capacity is worth confirming early rather than assumed.

The integrated assessment covers the Section 2 requirements (risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness and cybersecurity) together with the Article 17 quality management system. Post-market monitoring and incident reporting enter through that QMS; Articles 72 and 73 are not themselves part of Section 2.

There are two points at which assessment arises. The initial conformity assessment before the system is placed on the market or put into service, and a new assessment under Article 43(4) after a substantial modification.

"Substantial modification" is defined in Article 3(23). A change made by a party other than the original provider is not a separate third trigger; it matters because it can shift provider status under Article 25, and the new provider then carries the assessment obligation.

Example: A manufacturer retrains a diagnostic algorithm on new data after launch. This can count as a substantial modification and trigger a new assessment.

The exception is narrow and specific to high-risk systems that continue to learn after being placed on the market. For those systems, a change does not count as a substantial modification where it was predetermined by the provider at the initial conformity assessment and included in the Annex IV technical documentation. The documentation condition is what preserves it: predetermined changes have to be recorded in the Annex IV file at the outset, not characterised as foreseen after the fact.

The Implementation Timeline

The Act applies in stages, and the Digital Omnibus on AI moved several of the later dates. The relevant provisions apply from 2 August 2028 to systems classified solely under Article 6(1) and Annex I, including AI that is itself the product or a safety component. The table below reflects the amended timeline.

Table 1: EU AI Act implementation timeline, as amended by Regulation (EU) 2026/1744. Article references are to Regulation (EU) 2024/1689.

Two features of this timeline stand out.

Of the two general application dates for Chapter III, Sections 1 to 3, the later belongs to the Article 6(1) and Annex I regulated-product route: the relevant provisions apply from 2 August 2028 to systems classified solely by that route. The shortest belonged to Chapters I and II, applicable from 2 February 2025, including Article 4 on AI literacy and the original Article 5 prohibitions; most of the penalty chapter followed on 2 August 2025, with Article 101 excluded until 2 August 2026.

The Omnibus did not postpone Article 50 or the general application date. The Article 50 obligations have applied since 2 August 2026, and from that date the AI Office and national authorities began enforcing the applicable rules. A manufacturer whose systems fall within Article 50 therefore has an earlier date to track alongside 2028.

One rule decides whether any of this reaches a product already on sale, and it is the most commercially significant provision in the timeline. Under Article 111(2), the high-risk regime applies to the operators of systems already placed on the market or put into service before the applicable date only where, from that date, those systems undergo significant changes in their designs. The Digital Omnibus removed the former fixed reference to 2 August 2026, so the trigger now follows the applicable Chapter III date in Article 113: Article 113 assigns 2 December 2027 to the Article 6(2) and Annex III route and 2 August 2028 to the Article 6(1) and Annex I route. Where only one route applies, the date is clear. The Regulation does not expressly resolve the date where both routes independently apply.

Recital 39 of the Omnibus makes clear that the transition operates at the level of type and model. Where at least one unit of a high-risk AI system was lawfully placed on the market or put into service before the applicable cut-off, further units of the same type and model fall within the transition for as long as the design remains unchanged. The date of the first unit is what counts. A significant change in design after the cut-off triggers full application of the relevant high-risk provisions, including conformity assessment.

Two cautions. "Significant changes in their designs" is the statutory test in Article 111(2), and it is a different test from the "substantial modification" that triggers a fresh conformity assessment under Article 43(4). The two terms should not be used interchangeably. And providers and deployers of high-risk systems intended for use by public authorities face a separate backstop of 2 August 2030.

A further development is worth tracking rather than relying on. Article 2(13), inserted by the Omnibus, empowers the Commission to limit specific requirements in Articles 9 to 15 and 17 to 25 for Article 6(1) systems, on two cumulative conditions: that Annex I Section A legislation such as the MDR provides equivalent or higher protection in relation to the particular requirement, and that limiting it does not reduce the Act's overall level of protection. The Commission must adopt the specifying delegated acts by 2 August 2027. Article 2(13) provides no self-executing limitation for operators: subject to the Article 113 application dates, Articles 9 to 15 and 17 to 25 remain applicable unless and until a delegated act limits specified requirements for specified systems. None was in force as at 10 August 2026.

Example: using a sandbox. From 2 August 2027 each member state must run at least one national AI regulatory sandbox. A company developing an AI tool for early cancer detection may apply to participate in one, testing the system and discussing the MDR and AI Act requirements under supervision from the national authority before committing to launch. Participation replaces neither conformity assessment nor any required authorisation. Member States must ensure a sandbox exists, but Article 58 contemplates eligibility and selection procedures, so admission is not automatic. A sandbox does not waive other law: the GDPR, the MDR or IVDR and clinical-testing rules continue to apply. Article 59 permits further processing of lawfully collected data only on cumulative conditions, including necessity, public interest, an isolated environment and risk controls, and real-world testing needs the relevant approvals and safeguards under Articles 58 and 60.

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.

Table 2: Key articles of the EU AI Act for medical-device manufacturers. All article references are to Regulation (EU) 2024/1689; note that the Omnibus amended several of these. The consolidated text is a useful working reference; the authentic Official Journal texts of Regulations 2024/1689 and 2026/1744 should be used for authoritative legal citation.

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 prohibited, such as social scoring and certain manipulative techniques. The Digital Omnibus added two further prohibitions at Article 5(1), points (ba) and (bb), applicable from 2 December 2026. They cover AI that generates or manipulates specified realistic images, video, audio or similar intimate material, and AI that generates specified child sexual abuse material or performance. Neither is a flat ban on a technology. The conditions are spread across several provisions. Point (ba) carries the consent condition; point (bb) reserves a defence of acting "without right" under national law. Article 5(1a) carries the limitations on intended purpose, reasonably foreseeable and reproducible generation, safeguards, and the deployer's purpose. Article 5(1b) contains the narrow manipulation rule, covering manipulation that neither increases the visibility of the depicted intimate body parts nor alters the depicted activity. The full text sits in Article 5 itself.

• High risk (Article 6).

  • This tier captures qualifying AI-enabled medical devices, and it has two routes in.

    The first is Article 6(1) with Annex I, Section A, and it sets two conditions that must both be met. The AI has to be intended as a safety component of a product, or be that product itself, where the product is covered by one of the EU product laws listed in Annex I, the MDR and IVDR sit at points 11 and 12 of Section A. And that product has to require third-party conformity assessment under the same legislation.

    The Digital Omnibus added three paragraphs that qualify how those conditions work, and the distinction between them matters.

    Article 6(1a) narrows the safety-component route: AI used solely for non-safety purposes, such as user assistance, performance optimisation, service efficiency, automation, convenience or quality control, does not qualify as a safety component. Article 6(1b) then reverses that where failure or malfunction of the AI would endanger health and safety, in which case it does qualify. Read together with the amended definition in Article 3(14), the effect is that AI serving only non-safety purposes escapes the safety-component route unless its failure would create a health or safety risk.

    That relief is narrower than it first appears, but it is also not nothing. Articles 6(1a) and 6(1b) qualify only the safety-component branch of Article 6(1)(a). An AI system that is itself an MDR or IVDR regulated product satisfies Article 6(1)(a) without relying on safety-component status at all, but it is high-risk through Article 6(1) only if Article 6(1)(b) is also satisfied, subject to Article 6(1c). Standalone Software as a Medical Device is therefore not automatically high-risk: a self-declared Class I standalone device fails the second condition just as any other self-declared product does.

    Article 6(1c) works on that second condition. Where a product requires third-party conformity assessment solely because of risks unrelated to health and safety (radio-spectrum or non-health-and-safety electromagnetic interference, for example), that assessment does not satisfy Article 6(1)(b).

    Device class is what usually decides the second condition, and we cover that detail separately in medical device classification under the EU MDR, with support available through our EU MDR compliance consulting and IVDR consultancy.

    Class I is not a blanket exemption. Under MDR Article 52(7), a notified body is involved for Class I devices placed on the market sterile, having a measuring function, or constituting reusable surgical instruments, though only as to sterility, metrology or reuse respectively. Under IVDR Article 48(10), Class A sterile devices need notified body involvement limited to sterility. Non-sterile Class A devices are ordinarily self-declared.

  • The second, Article 6(2) with Annex III, works on intended use rather than on where the AI sits in a product. It covers systems used in listed areas such as biometrics, employment and credit scoring, and the list includes emergency healthcare triage, which is why a medical-device AI can meet this route independently of the Annex I one.

    Being listed in Annex III is not the end of it. Under Article 6(3), a listed system is not high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, and satisfies one of the conditions in that provision, for instance performing a narrow procedural task or improving the result of a previously completed human activity. Two limits apply. A system that performs profiling of natural persons is always high-risk, with no filter available. And a provider relying on the filter must document its assessment before placing the system on the market, and register the system under Article 49.

    The two routes carry different dates. Article 113 assigns 2 December 2027 to the Article 6(2) and Annex III route and 2 August 2028 to the Article 6(1) and Annex I route. Where only one route applies, the date is clear. The Regulation does not expressly resolve the date where both routes independently apply. Article 43(3) selects the sectoral conformity-assessment procedure for a dual-listed system, but not its application date.

    One carve-out follows from the second condition. Where all the conditions of MDR Article 5(5) are met, including the limits on transfer and industrial-scale manufacture, a device manufactured and used within the same health-institution legal entity established in the EU, without transfer to another legal entity, is not subject to the ordinary third-party conformity assessment route. It therefore fails the second condition and is not high-risk through Article 6(1). The joint MDCG and AI Board guidance reaches the same conclusion at Question 35 (MDCG 2025-6). That guidance is the latest officially listed joint guidance on the interplay, but it is non-binding, dated 19 June 2025, and published before the Digital Omnibus, so it is outdated wherever its dates or legal propositions conflict with the amended Regulation.

    Failing Article 6(1) does not end the analysis. Article 6(2) classifies Annex III systems as high-risk independently, and emergency healthcare triage is one of the listed Annex III use cases. An in-house system has to be assessed against Annex III on its own terms — including whether the Article 6(3) filter applies. Where it does fall within Annex III, the Article 49 registration duties apply according to the outcome: paragraph 1 where the system is high-risk, subject to its exception for Annex III point 2; paragraph 2 where the provider relies on the Article 6(3) filter. In that second case Article 6(4) also requires the assessment to be documented. The Act's generally applicable provisions apply either way, including the Article 4 duty to take measures supporting staff AI literacy and the Article 5 prohibitions.

    Example: A university hospital builds its own AI system to flag sepsis risk from its patient records, uses it only in its own wards, and meets the MDR Article 5(5) conditions. The system is not high-risk under the Annex I route, but the hospital still owes the Act's general duties and cannot rely on the exemption once it transfers the system to another legal entity. Transfer to another legal entity is the decisive boundary; different sites belonging to the same legal person are not necessarily outside Article 5(5).

• General-purpose AI models (Article 3(63), Articles 51 to 56 and Annex XIII)

  • This sits apart from the system risk tiers rather than beside them: GPAI models are regulated under their own model regime, with additional duties where a model has systemic risk. Systemic-risk classification is what Article 51 and Annex XIII govern, through a high-impact-capabilities test or a Commission designation.

    Example: A large language model that writes text, answers questions, and summarises documents across many industries is a general-purpose model. A device manufacturer integrating such a model into a clinical feature does not become the model's provider merely by integrating it, nor merely by putting its brand on it. The test is the one in Article 3(3): developing the model, or having it developed, and then placing it on the market under its own name. The Commission's non-binding guidance on general-purpose AI separately notes that a significant modification may exceptionally confer provider status. Either way it needs to know what the model provider documents and what it does not, because that documentation feeds its own technical file.

    Organisations putting formal governance around AI development often do it through an AI management system, which we cover in our ISO 42001 consulting for AI systems.

• Below the high-risk line

  • Systems that do not meet either high-risk route carry lighter duties, not none. Article 50 transparency obligations can apply, such as telling a person they are dealing with an AI system. The Article 4 duty to take measures supporting AI literacy, which is a duty to support rather than to guarantee a particular level for every individual, and the Article 5 prohibitions apply regardless of risk tier, and other EU and national law continues to apply. Voluntary codes of conduct are encouraged on top of that.

    Example: A manufacturer that itself provides a support chatbot on its website is not dealing with a high-risk system, but Article 50(1) has applied to it since 2 August 2026, unless it is obvious to a reasonably well-informed, observant and circumspect person that they are interacting with AI. Where the chatbot is a third-party product, that design-and-development duty sits with its provider.

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 an AI-enabled medical device that meets both Article 6(1) conditions, the manufacturer will usually be the provider, and for a system classified solely through the Article 6(1) route the applicable date is 2 August 2028. A separate Annex III analysis remains necessary, and the date for a system independently classified under both routes is not expressly resolved.

Part 2: Core Requirements for Medical Device AI Systems 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.

Manufacturers working through classification with us do it as part of our EU AI Act consulting for health software.

Frequently Asked Questions

1. What makes an AI-enabled medical device high-risk under the EU AI Act?

   • Two conditions have to hold together under Article 6(1). The AI must be a safety component of, or itself be, a product covered by one of the laws listed in Annex I, Section A, which include the MDR and IVDR. And that product must require third-party conformity assessment. Meeting only one of the two is not enough.

     Three Omnibus paragraphs qualify this. Article 6(1a) takes AI serving only non-safety purposes out of the safety-component route, Article 6(1b) puts it back where failure would endanger health and safety, and Article 6(1c) discounts a third-party assessment required solely for risks unrelated to health and safety. Note that 6(1a) and 6(1b) qualify only the safety-component route. An AI system that is itself an MDR or IVDR product, such as standalone Software as a Medical Device, satisfies Article 6(1)(a) without them, but it is high-risk through Article 6(1) only if Article 6(1)(b) is also satisfied, subject to Article 6(1c).

2. 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.

3. 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). For a high-risk system that continues to learn after being placed on the market or put into service, changes predetermined by the provider at the initial conformity assessment and included in the Annex IV technical documentation do not trigger a new one.

4. Does the Act apply to AI a hospital builds for its own use?

   • Partly. Where all the conditions of MDR Article 5(5) or IVDR Article 5(5) are met, a device manufactured and used only within health institutions established in the Union, not transferred to another legal entity, and satisfying all the other conditions of Article 5(5), is not subject to the ordinary third-party conformity assessment route, so it is not high-risk through Article 6(1). That is not the end of it: Article 6(2) classifies Annex III systems as high-risk independently, and emergency healthcare triage is a listed Annex III use case, so the system must be assessed against Annex III separately. The Act's generally applicable provisions, including the Article 5 prohibitions, apply either way. A health institution that develops a system and puts it into service under its own name can also be both provider and deployer.

5. Does rebranding or modifying someone else's AI system make my company the provider?

   • It can, on three specific triggers in Article 25: putting your own name or trademark on a high-risk system already placed on the market; making a substantial modification to a high-risk system such that it remains high-risk; or changing the intended purpose of a system that was not high-risk so that it becomes high-risk.