For hospitals, clinics, practices, diagnostic labs and medtech manufacturers, the EU AI Act (Regulation (EU) 2024/1689) is no longer an abstract future topic. Medical AI for diagnosis, triage and clinical decision support sits among the clearest high-risk candidates under the regulation. The interesting question is not "exactly when does what apply?" but "which AI systems are we already using, and do we know which class they fall into?".

We deliberately keep the deadlines soft. Depending on the configuration, the high-risk obligations apply from 2026/2027, but the timing is under revision: the European Commission's so-called Digital Omnibus may still shift the high-risk timeline. We therefore recommend verifying the deadlines in each case and not letting the binding date drive your programme. The real driver is something else: an AI inventory and a clean initial classification take lead time, regardless of whether the deadline ultimately lands six months earlier or later. Those who start today have room to manoeuvre; those who wait for the final date end up under time pressure.

This article is framed as a practical action plan: what should healthcare organisations actually do to get the AI Act for medical AI under control, step by step, without duplicating the existing medical-device documentation.

Medical AI typically falls into the high-risk category via two paths. First, under Art. 6(1) in conjunction with Annex I: if the AI is a safety component of a medical device, or itself a medical device under the MDR 2017/745 or an in-vitro diagnostic under the IVDR 2017/746 and subject to conformity assessment by a notified body, it is high-risk. This captures most clinically deployed AI: image analysis in radiology and pathology, AI-assisted reporting, algorithmic triage in the emergency department, clinical decision support (CDSS) that proposes treatment options or scores risks.

Second, AI can become relevant via Annex III, for example where a system governs the prioritisation of emergency calls or contributes to decisions on access to health services. In clinical practice, however, the MDR/IVDR path dominates.

An important distinction: purely administrative and documentation AI without clinical effect (appointment scheduling, dictation speech recognition with no influence on findings, billing support) is generally not high-risk. What matters is the intended purpose: if the output influences a medical decision about a patient, the high-risk presumption is on the table.

The most important practical lever for medtech and users is how the AI Act and medical-device law interact. The cybersecurity and quality requirements of the MDR/IVDR are already in force. This is not a new set of duties that "starts" in 2027. The AI Act builds on them rather than replacing them.

In concrete terms, the regulation allows the AI Act requirements to be integrated into existing MDR/IVDR structures instead of building a parallel world. The risk management under Art. 9 AI Act can be interlocked with risk management under ISO 14971. The technical documentation under Annex IV AI Act can be incorporated into the MDR technical documentation. The quality management system under Art. 17 AI Act plugs into the existing QMS under ISO 13485. Conformity assessment can also run through the notified body already involved, provided it is notified for the AI Act.

The goal is a single consolidated dossier rather than two mountains of files. Those who map the requirements cleanly early on, which AI Act duty is already covered by which MDR/IVDR artefact and where a genuine gap remains, avoid duplication and contradictory documentation. This mapping is the single most valuable early step.

In practice we see recurring misjudgements. First: "Our AI only gives hints, the doctor decides." Neither Annex III nor the MDR path turns on "autonomous decision". A CDSS that produces a shortlist or a risk score remains high-risk even when the final decision rests with a human.

Second: "It's only a research tool." As long as the system is not used clinically and falls under a genuine research exemption, that may be true; the moment it contributes to routine care, the classification flips. Third: "We buy the product in, so the AI Act doesn't concern us." Wrong: the manufacturer is the provider, but the hospital is the deployer with its own duties (see below). Fourth: "We are a Swiss hospital with no EU nexus." The AI Act reaches you as soon as you deploy an AI system from an EU provider that makes it available on the EU market, or as soon as the output is used in the EU. Switzerland has not adopted the AI Act, yet through supply chains and EU establishments it effectively reaches far.

Fifth: "MDR-compliant means AI-Act-compliant." The overlap is large but not identical. Data quality, bias testing and human oversight go beyond the classic MDR checklist.

Two AI Act requirements deserve particular attention because they go beyond what many institutions have already documented.

Human oversight (Art. 14). High-risk AI must be designed so that medical professionals can understand, question and override the output. For operations this means: defined responsibilities, training for the clinicians and nurses who use the system, documented escalation paths for anomalous recommendations, and protection against automation bias, the uncritical adoption of AI suggestions. Oversight is not a formality; it has to be lived in the clinical workflow.

Data governance (Art. 10). Training, validation and test data must be representative, as error-free as possible and appropriate to the context of use. In healthcare this is especially sensitive: skewed datasets can systematically disadvantage particular patient groups. Providers must demonstrate this; deployers should check whether the validation matches their own population. Both interlock with the data protection impact assessment under Art. 22 nDSG and Art. 35 GDPR, another reason to bring the procedures together early.

The role question determines the scope of your duties. The manufacturer of the medical AI is the provider within the meaning of the AI Act and bears the main load: risk management, technical documentation, conformity assessment, CE marking. The hospital, clinic or practice that buys and uses the product is the deployer under Art. 26, with its own, leaner but real duties: use the system as intended, ensure human oversight, check the input data within its control for relevance, monitor operation and retain logs, report incidents to the provider, and inform staff.

Watch out for the role switch: anyone who substantially modifies a purchased AI, makes it available under its own name or changes its intended purpose can itself become a provider under Art. 25, with the full set of duties. This affects, for example, institutions that re-train a model on their own data or develop their own algorithms. For public bodies and certain configurations, the fundamental rights impact assessment under Art. 27 also comes into play. The role analysis must be done per system and per use type, not generically for the whole institution.

Step 1: Build an AI inventory. Capture all deployed and planned AI systems with a clinical bearing, including AI embedded in devices that was not always procured as "AI". Without this inventory, all further planning is guesswork.

Step 2: Initial classification. For each system, determine the risk class and the path (MDR/IVDR Annex I or Annex III). For a quick first orientation, use our AI Act triage tool for medical AI, a free self-check to get started.

Step 3: Clarify roles and gaps. Provider or deployer? Which AI Act duty is already covered by existing MDR/IVDR artefacts, and where does a genuine gap remain? This is the core of the AI Governance Check (from CHF 3,900), which assesses your portfolio against the AI Act in a structured way.

Step 4: Anchor accountability. Who runs AI governance on an ongoing basis, inventory upkeep, oversight processes, incident reporting? An AI Officer (from CHF 500/month) takes on this role continuously, in-house or outsourced.

Step 5: Go deeper where needed. For LLM, RAG or agent components in clinical tools, our AI Security (from CHF 8,000) adds technical robustness testing. We bundle the overall picture for medical AI on our topic page EU AI Act for medical AI.

SIDD is a legally led Swiss data protection and information security boutique. We support healthcare organisations in classifying medical AI on a sound legal footing: from the AI inventory through initial classification and role analysis to a consolidated dossier that brings the AI Act and MDR/IVDR together rather than documenting them twice. Where a SIDD lawyer advises in a legal capacity, your disclosures may be covered by professional secrecy under Art. 321 of the Swiss Criminal Code.

We connect AI compliance with the data protection impact assessment, information security under ISO 27001/ISMS and, where hands-on testing of medical devices is involved, referral to a specialised testing partner. For a fast initial classification of your medical AI ("Am I high-risk? Which systems?"), reach us via our contact form; for a full mandate, use our quote form. As the high-risk deadlines are under revision, we always verify the concrete timeline for your specific case.