EU AI Act deadlines for clinical AI and medical devices after the 2026 Omnibus

The 2026 Digital Omnibus changed the timetable for high-risk AI systems. It did not postpone the EU AI Act as a whole.

For European healthtech companies, the main dates are now:

• 2 August 2026 for Article 50 transparency obligations;
• 2 December 2026 for certain generative AI systems already on the market to implement machine-readable content marking;
• 2 December 2027 for high-risk systems classified under Article 6(2) and Annex III;
• 2 August 2028 for high-risk systems classified under Article 6(1) and Annex I, including qualifying medical devices and in vitro diagnostic devices.

The difficult part is not finding the dates. It is deciding which date belongs to which system.

A patient chatbot, diagnostic algorithm, emergency triage tool and appointment assistant may all be described as healthcare AI. They do not necessarily fall into the same regulatory category.

Legislative status: The European Parliament and the Council adopted the Digital Omnibus on AI in June 2026. As of 30 June 2026, publication of the amending regulation in the Official Journal remained the final formal step. The dates below reflect the adopted legislative text, PE-CONS 30/26.

The short answer

Key EU AI Act dates for healthtech

The Omnibus also introduces new prohibited practices concerning certain non-consensual intimate and child sexual abuse material. Those additions are scheduled to apply from 2 December 2026. They should not be confused with the original prohibited-practice provisions that have applied since February 2025.

Classify the system, not the company

The AI Act does not classify an entire healthtech business as high-risk. It classifies individual AI systems.

A useful classification record should explain:

• the system’s intended purpose;
• who uses it;
• whose decisions or outcomes it affects;
• whether it interacts directly with patients or healthcare professionals;
• whether it generates synthetic content;
• whether it qualifies as a medical device or IVD;
• whether it performs a safety function;
• whether third-party conformity assessment is required;
• whether it falls within an Annex III use case;
• the organisation’s role as provider, deployer, importer, distributor or product manufacturer.

Intended purpose is especially important because it connects AI Act classification with MDR or IVDR qualification.

Marketing claims, instructions for use, technical documentation and the actual product workflow should describe the system consistently. A tool should not be documented as administrative support while being promoted elsewhere as providing diagnosis or treatment recommendations.

Route 1: AI as or within a medical device

Article 6(1) establishes two cumulative conditions.

An AI system is classified as high-risk through the regulated-product route where:

1. the AI system is itself a product covered by legislation listed in Annex I, or is intended to be used as a safety component of such a product; and
2. the product or system is required to undergo third-party conformity assessment under that legislation.

Both the Medical Devices Regulation and the In Vitro Diagnostic Medical Devices Regulation appear in Annex I of the AI Act.

Potential examples include:

• medical-image analysis software intended to support diagnosis;
• an algorithm producing patient-specific treatment recommendations;
• AI interpreting laboratory or genomic results for a medical purpose;
• software predicting clinical deterioration where the output drives clinical action;
• an AI component whose failure could endanger a patient.

Each system must still be assessed against its actual intended purpose and conformity-assessment route. The fact that a medical device contains AI does not automatically make every AI function within it high-risk.

A non-safety analytics function, user-preference feature or administrative optimisation component may remain outside Article 6(1), even when it operates within a regulated product.

What counts as a safety component?

The Omnibus narrows and clarifies this concept.

An AI system can be a safety component where:

• its intended purpose is to prevent or mitigate risks to health, safety or property; or
• its failure or malfunction could endanger health, safety or property.

AI used solely for convenience, service efficiency, automation, non-safety quality control or performance optimisation should not qualify as a safety component for that reason alone.

The mere presence of AI inside a regulated medical product is therefore not enough. Its purpose and the consequences of failure matter.

“Stand-alone” does not mean “software-only”

The Omnibus and related communications often describe Annex III systems as “stand-alone high-risk AI” and Article 6(1) systems as “AI embedded in products”.

These are labels for two legal routes, not descriptions of technical architecture.

Software can itself be a medical device. A cloud-based diagnostic application may therefore follow the Article 6(1) regulated-product route and the 2028 deadline, even though it is not physically embedded in medical hardware.

A SaaS delivery model does not automatically place a system in the 2027 Annex III category.

Route 2: Annex III healthcare systems

Annex III does not classify healthcare AI as a whole. It lists particular uses in sensitive areas.

Healthcare-related examples include AI intended to:

• evaluate eligibility for certain essential public services, including healthcare services;
• evaluate or classify emergency calls;
• dispatch or prioritise emergency first-response services;
• establish priority in emergency healthcare patient triage.

An AI system used in an emergency department to prioritise patients may therefore fall within Annex III even if it does not perform diagnosis.

A mental-health crisis chatbot that assesses urgency and directs an emergency response may also fall into this route.

By contrast, a system that only transcribes an emergency call, without evaluating urgency or influencing prioritisation, may remain outside that particular Annex III use case.

The European Commission published practical examples in its high-risk classification guidance. As of July 2026, that guidance remained a draft under consultation and was not legally binding. It is useful for interpretation but should not replace a documented assessment of the actual system. The Commission’s essential-services examples illustrate how differences in purpose and decision impact can change the result.

The Article 6(3) filter

Some AI systems listed in Annex III may nevertheless be treated as non-high-risk where they do not create a significant risk to health, safety or fundamental rights and do not materially influence decision-making.

The filter can apply where a system performs:

• a narrow procedural task;
• a preparatory task;
• an improvement to a previously completed human activity;
• pattern detection that does not replace or improperly influence an earlier human assessment.

Providers relying on this exception must document their assessment and meet the applicable registration requirement.

A system performing profiling of natural persons remains high-risk under the Article 6 rules.

Healthcare AI that is not high-risk

A system can fall outside both high-risk routes and still have significant obligations.

The Article 50 distinction matters.

Article 50(2) concerns technical marking by providers of systems generating synthetic content. Article 50(4) concerns disclosure by deployers of certain deepfakes and AI-generated or manipulated text published to inform the public about matters of public interest.

Human review and editorial responsibility may create an exception under the public-interest text provision in Article 50(4). They do not create a general exception from the provider’s Article 50(2) marking obligation.

“Not high-risk under the AI Act” does not mean “unregulated”. The GDPR, MDR, IVDR, cybersecurity rules, consumer protection, product liability, professional standards and contractual requirements may still apply.

What applies in 2026?

The high-risk delay should not be treated as permission to pause AI governance until 2027 or 2028.

AI literacy

AI-literacy duties have applied since February 2025.

The adopted Omnibus refines the wording but retains the expectation that providers and deployers take measures supporting the AI literacy of staff and others operating AI on their behalf. It clarifies that organisations are not expected to guarantee a particular level of literacy for every individual.

Training should reflect the system, role and risk.

A clinician reviewing an AI recommendation, a developer monitoring model performance and a customer-support agent operating a patient chatbot need different knowledge.

Informing people that they are interacting with AI

From 2 August 2026, providers of AI systems intended to interact directly with natural persons must generally ensure that people are informed that they are interacting with AI, unless this is obvious to a reasonably informed user in the circumstances.

This is relevant to:

• patient chatbots;
• conversational symptom-collection tools;
• virtual care-navigation assistants;
• automated study-participant interfaces;
• AI agents communicating with patients.

The information must be clear, distinguishable and accessible, and provided no later than the first interaction or exposure.

Machine-readable marking of synthetic content

Article 50(2) requires providers of systems generating synthetic audio, images, video or text to make covered outputs detectable as artificially generated or manipulated in a machine-readable format, subject to the provision’s limitations and exceptions.

The Omnibus creates a specific transition:

• qualifying systems placed on the market from 2 August 2026 must comply when the obligation begins;
• qualifying systems already placed on the market before 2 August 2026 have until 2 December 2026.

This transition concerns Article 50(2). It does not postpone the interaction notice, emotion-recognition notice or deployer disclosure obligations elsewhere in Article 50.

The European Commission’s Article 50 page sets out the individual obligations and exceptions.

How the AI Act fits with MDR and IVDR

The AI Act does not replace medical-device regulation.

For high-risk AI covered by the MDR or IVDR, relevant AI Act requirements become part of the sectoral conformity-assessment process. Manufacturers should integrate the evidence into their existing medical-device system rather than build a disconnected compliance programme.

The main areas include:

• risk management;
• data and data governance;
• technical documentation;
• automatic logging and traceability;
• information provided to users;
• human oversight;
• accuracy, robustness and cybersecurity;
• quality management;
• corrective actions;
• post-market monitoring.

The MDCG 2025-6 FAQ explains the complementary application of the AI Act, MDR and IVDR.

The Omnibus also allows the European Commission to limit specific AI Act requirements through delegated acts where sectoral legislation already provides equivalent or stronger protection.

This is not an automatic exemption for medical devices. Until a relevant delegated act applies, manufacturers should map overlapping requirements, identify genuine gaps and avoid assuming that an MDR control automatically removes an AI Act obligation.

Existing and legacy systems

The adopted Omnibus links the high-risk transition to the relevant Chapter III application date.

A high-risk system placed on the market or put into service before that date is generally covered by the transitional rule unless it undergoes a significant design change after the date.

The relevant cut-offs are therefore:

• 2 December 2027 for Annex III systems;
• 2 August 2028 for Article 6(1) regulated-product systems.

The recitals to the adopted text explain that the transition can cover a system type and model where at least one unit was lawfully placed on the EU market or put into service before the applicable date. Additional units of the unchanged type and model may remain within that transition.

A significant design change after the applicable date can trigger the high-risk requirements, including conformity assessment where required.

Teams should be able to show:

• when the type and model were first placed on the market or put into service;
• the intended purpose at that time;
• the approved design and performance boundaries;
• subsequent model and product changes;
• why each material change was or was not considered significant.

The transition does not disapply the GDPR, MDR, IVDR or other legislation that already applies to the system.

Do the dates differ in the Netherlands, Germany or France?

The core AI Act dates apply across the European Union, including the Netherlands, Germany and France.

National differences can still affect:

• supervision and enforcement;
• hospital and insurer procurement;
• reimbursement and market-access processes;
• professional and clinical-governance requirements;
• competent-authority expectations;
• notified-body availability and scope;
• related national healthcare legislation.

Launching first in the Netherlands or Germany does not create a later AI Act deadline. At the same time, hospitals, notified bodies and enterprise buyers may request AI-governance evidence well before the statutory application date.

The legal deadline is the latest compliance point. It is not necessarily the date at which the market begins asking questions.

A practical preparation plan

1. Build a system-level AI inventory

Record the provider, deployer, product manufacturer, intended purpose, users, affected persons, model, data, output, autonomy and decision impact.

Include third-party APIs and embedded models—not only products marketed as AI.

2. Separate the classification questions

For every system, document:

1. Is it an AI system under the AI Act?
2. Is it medical-device software or part of a medical device or IVD?
3. Is it high-risk under Article 6(1), Annex III, both or neither?

These decisions are connected but not interchangeable.

3. Assign the correct date

Record the high-risk route and deadline. Assess Article 50 and other general obligations separately rather than assuming they move with the high-risk date.

4. Identify the organisation’s legal role

A company may deploy a general-purpose model while acting as provider of the final clinical system.

Rebranding a system, making a substantial modification or changing its intended purpose can also shift provider responsibilities.

Contracts should identify who supplies:

• technical documentation;
• model and data information;
• logs;
• incident support;
• performance evidence;
• change notifications.

5. Connect AI and medical-device evidence

Where relevant, connect AI risk management to ISO 14971 processes and the existing quality-management system. Model monitoring should feed into post-market surveillance rather than operate as an isolated technical dashboard.

ISO/IEC 42001 can support AI governance, but the AI Act does not generally require healthtech companies to obtain ISO 42001 certification.

6. Implement Article 50 requirements before August 2026

Review patient-facing interfaces and generated content now. Interaction notices, accessibility and output-marking requirements should be treated as product requirements—not added later as generic website disclaimers.

7. Establish model change control

Record model versions, training-data changes, performance thresholds, planned updates and third-party dependencies.

A company cannot make a reliable legacy-system or significant-change assessment without a controlled design history.

Common mistakes

“All clinical AI is high-risk”

High-risk status depends on Article 6, Annex I, Annex III and the system’s intended purpose.

“All software-only systems use the 2027 date”

Software can itself be a regulated medical device and follow the Article 6(1) route and 2028 deadline.

“The Omnibus postponed the AI Act until 2028”

Article 50 and other general provisions continue to apply earlier.

“Our MDR CE marking automatically covers the AI Act”

The assessment processes are integrated, but relevant AI Act requirements must still be addressed unless a valid legal mechanism limits an overlapping obligation.

“Human review makes the system non-high-risk”

Human oversight can reduce risk but does not by itself change the classification. The intended purpose, decision impact and Article 6 conditions still apply.

“Our existing system is permanently exempt”

A significant design change can end the transition. Other applicable legislation continues to apply throughout.

This article provides general regulatory information and does not replace a system-specific legal, clinical or conformity-assessment review.