AI Medical Imaging Triage Under the EU AI Act: Annex I or Annex III, and What Changes at Runtime

What Article 6 actually asks

Article 6 gives two routes to high-risk status, and they are independent. Article 6(1) applies where two conditions are both met. First, the AI system is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I. Second, that product, or the AI system as a product, must undergo a third-party conformity assessment before being placed on the market or put into service under that legislation.

The Article 6(1) test applies whether or not the AI system is placed on the market independently of the product. Standalone software is therefore not outside the Annex I pathway simply because it ships separately from hardware. Article 6(2) then adds the systems listed in Annex III as high-risk, regardless of any product legislation.

The wording "intended to be used" matters. Classification follows the intended purpose you define for the triage function, not only what the model technically does. That is why the intended purpose statement is the first artefact to write down.

Why Annex I is the likely pathway, and where Annex III still matters

The Commission's guidance names AI-based medical software as an example of AI that constitutes a product covered by Annex I legislation. Imaging triage software that qualifies as a medical device under the MDR fits that description. If the MDR also requires third-party assessment for the device, both Article 6(1) conditions are met and the product is high-risk through Annex I. The MDR classification of the specific product decides condition two, so it should be confirmed rather than assumed.

Annex III remains relevant as a separate screen. A product can be high-risk under both routes if its intended purpose also matches an Annex III use case, including healthcare-related ones. The more narrowly and accurately the intended purpose is written, the more defensible that screen is. Vague claims such as "supports clinical prioritisation" invite a broader reading than "orders an imaging worklist by suspected finding."

One point is easy to get wrong. The Article 6(3) derogation lets certain Annex III systems escape high-risk status where they do not pose a significant risk of harm, including by not materially influencing decision making. It is expressed as a derogation from paragraph 2, so it ties to Annex III systems. Do not assume it relieves a product that is high-risk under Article 6(1). Systems that profile natural persons are always high-risk under Annex III.

Annex I and Annex III pathways compared

The table summarises what differs for a compliance team scoping an imaging triage product.

• Trigger: Annex I: the system is, or is a safety component of, a product under Annex I legislation requiring third-party conformity assessment. Annex III: the intended purpose matches a listed use case.
• Article 6 provision: Annex I: Article 6(1). Annex III: Article 6(2), with the Article 6(3) derogation available only to Annex III systems.
• Application date as of November 2026: Annex I: 2 August 2028. Annex III: 2 December 2027. Both follow the political agreement on the AI Omnibus.
• Typical medical imaging fit: Annex I: likely for triage software that is a medical device. Annex III: only if the intended purpose also matches a listed use case.

Current application dates

The Commission proposed the Digital Omnibus on AI on 19 November 2025. Council and Parliament reached a provisional agreement on 7 May 2026. As a result, the Commission's AI Act page now describes an extended transition to 2 August 2028 for high-risk systems embedded in regulated products under Annex I, and to 2 December 2027 for Annex III use cases. The original proposal had tied application to the availability of standards and tools.

These dates should be treated as the working baseline as of November 2026, with a defined trigger to revisit scoping when the final text is published. The dates change when obligations apply. They do not change which pathway a product is on, so the classification record should be completed now.

Where runtime enforcement fits

Runtime policy actions such as allow, redact, block and escalate for human approval are a design choice for enforcing obligations. The AI Act does not prescribe them, and this guide does not present them as legal requirements. They are useful because they turn a written policy into something enforced at runtime, not reviewed after the fact.

Trussed enforces policy in the execution path for AI interactions and tool calls, with actions that include allow, redact, block, rate limit and escalate for human approval. That enforcement generates continuous audit-ready evidence mapped to the EU AI Act, among other frameworks. A regulated enterprise can use it to show what its AI was allowed to do and what it did, including records of escalations to human reviewers. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

This does not replace the classification work or any conformity assessment, and it is not legal advice. Classification and MDR interplay questions need qualified regulatory counsel.