Hospital obligations for CE-marked AI medical devices before the August 2028 Annex I date

How the Annex I pathway applies to CE-marked AI devices

High-risk AI systems under the AI Act include safety components of products covered by sectoral Union legislation, and AI systems that are themselves such products. They are always high-risk when the product is subject to third-party conformity assessment under that legislation. The Commission gives medical devices as an example. For a hospital, this means many AI-enabled devices already carrying a CE mark under the MDR or IVDR fall into the Annex I pathway, rather than being assessed as separate stand-alone AI systems.

The timeline has moved. The original AI Act text applied Article 6(1) and the corresponding obligations from 2 August 2027. The Digital Omnibus on AI, proposed by the Commission on 19 November 2025 and the subject of a provisional agreement between Council and Parliament on 7 May 2026, sets 2 August 2028 for high-risk AI embedded in products, including medical devices. Stand-alone high-risk systems follow on 2 December 2027. The Commission attributes the extension to the delayed availability of standards. Because the amending text is still moving through the legislative process, track it and treat 2 August 2028 as your planning date for embedded devices.

Two consequences follow for compliance leaders. First, the AI Act does not replace the MDR or IVDR for these products. Where a product contains an AI system covered by both the AI Act and Annex I Section A legislation, the provider must ensure the product complies with all applicable requirements under that legislation. Second, the hospital is not asked to re-do the manufacturer's conformity work. Its exposure sits in deployment: what it buys, how it is used, who watches it and what it can show afterwards.

Where manufacturer responsibility ends and hospital responsibility begins

A written boundary between the two sets of duties prevents the most common gap, which is assuming that a CE mark means the hospital has nothing left to do. The table below is a working split for policy purposes. Confirm the legal detail of each deployer duty against the AI Act text with counsel.

• Conformity of the product: Manufacturer: conformity assessment, technical documentation and the CE marking. Hospital: confirm the marking and documents exist for each product.
• Instructions for use and declaration of conformity: Manufacturer: produces and maintains them. Hospital: collects them, files them against the device record and uses them to define local procedures.
• Intended purpose: Manufacturer: states the purpose to which conformity is tied. Hospital: ensures clinical use stays within it and records any proposed departure for review.
• Human oversight and monitoring: Manufacturer: designs the device and describes its oversight needs. Hospital: names the people and roles who oversee and monitor use in its own setting.
• Incident escalation: Manufacturer: handles vigilance on its side. Hospital: defines how clinicians report problems internally and to the manufacturer.
• Traceability records: Manufacturer: assigns UDI. Hospital: for class III implantable devices, stores and keeps the UDI of devices it supplied or was supplied with, preferably electronically.

The risk of drifting into a provider role

Under the AI Act, a distributor, importer, deployer or other third party can be treated as a provider of a high-risk AI system in specified circumstances. The practical lesson for a hospital is to be careful with local changes. If a team modifies a device, changes its purpose or builds its own AI tooling around it, legal review should happen before rollout, not after. The MDR also treats devices manufactured and used within health institutions as put into service, so in-house development carries its own obligations.

This is also where GDPR and the sector rules meet. AI-enabled devices that connect to clinical systems handling patient data create data flows that the data protection officer, the clinical safety lead and the compliance team each see differently. Put those three in the same review for any device whose use or connections change.

Sequencing the preparation work before August 2028

The order matters because each step feeds the next. An inventory without intended-purpose data cannot be checked against clinical practice, and ownership assigned before the inventory is complete tends to be assigned to the wrong people.

• 1. Build the inventory: Record each AI-enabled device, its manufacturer, its CE-marked product details, its intended purpose and whether it is subject to third-party conformity assessment, since that determines the Annex I pathway.
• 2. Collect manufacturer documents: Gather instructions for use and the EU declaration of conformity for each device, and ask each manufacturer to confirm its AI Act timeline.
• 3. Confirm intended-purpose use: Compare how clinicians actually use each device with its stated purpose, and log any gap for clinical and legal review.
• 4. Assign human oversight: Name a responsible role per device, with the competence and authority to intervene, and record it in policy.
• 5. Define monitoring and escalation: Set what is watched in use, who reviews it, and how an incident moves from the ward to the compliance lead and the manufacturer.
• 6. Establish retained evidence: Decide which records you keep, for how long, and who can retrieve them. Confirm UDI storage where class III implantable devices are involved.

What evidence a hospital should be able to produce

An auditor or regulator will want to see two layers. The first is manufacturer documentation: the CE marking, instructions for use, the declaration of conformity and anything the manufacturer provides on performance and limitations. The hospital holds copies but does not create this layer, and nothing the hospital generates can substitute for it or for clinical validation.

The second layer is the hospital's own record of use. This should show which device was in service, for which purpose, who was responsible for oversight, what monitoring took place, which incidents were raised and how they were resolved. It should also show changes: updates, new connections to clinical systems, and any change in how the device is used. Much of this layer is organisational, such as role assignments, review minutes and escalation logs. Some of it can be technical, particularly where AI-enabled functions interact with other systems and tools.

A useful test for each device is whether you could reconstruct, after an event, what the device was allowed to do and what it actually did in your environment. Where the answer depends on memory or on the manufacturer's records alone, there is a gap in the hospital's own layer.

Where runtime enforcement can support deployer evidence

Trussed enforces policy in the execution path for AI interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Where a hospital runs AI-enabled functions that call tools or exchange data with clinical systems, enforcement at that point means the decision is made at runtime, not reviewed after the fact. Each enforcement decision generates audit-ready evidence, mapped to the EU AI Act, HIPAA and other frameworks. Trussed runs in production with healthcare and pharma organisations and can be self-managed in the customer's cloud, with configurable retention and data residency.

The scope is specific. This covers individual interactions and tool calls around deployed systems. It can contribute to a hospital's own usage evidence, for example by showing that a human approval step was enforced before a sensitive action or that patient identifiers were redacted before they left a boundary. It does not perform conformity assessment, does not replace manufacturer documentation or clinical validation, and does not make a device compliant with the MDR or IVDR. Whether any set of records satisfies a specific deployer duty is a question for your legal and regulatory teams, and the mapping should be checked against the AI Act text.