What Is Not High-Risk Under Annex III? Common Misclassifications in Healthcare

Two pathways that are often conflated

Article 6 creates two separate routes to high-risk status. Under Article 6(1), an AI system is high-risk when both conditions are met: it is intended as a safety component of a product, or is itself a product, covered by Annex I Union harmonisation legislation, and that product must undergo third-party conformity assessment. Recital 50 lists medical devices and in vitro diagnostic medical devices among the product types. Under Article 6(2), AI systems referred to in Annex III are high-risk in addition to those caught by Article 6(1).

The most consequential misclassification follows from mixing these up. The Article 6(3) derogation is framed as a derogation from Article 6(2). A team that concludes "our tool is not an Annex III use case, so it is not high-risk" has answered only one of the two questions. A team that treats Article 6(3) as a way out of a medical-device classification has applied an Annex III mechanism to an Annex I pathway.

The practical rule is to run both screens for every healthcare AI system and record the outcome of each. The device screen depends on how the product is regulated under the relevant medical device rules, so it needs input from regulatory affairs as well as compliance.

Healthcare patterns and the question that decides each one

The table sets out the first question to ask for each common pattern. It is a screening aid, not a classification. Each answer must be checked against the operative Annex III wording and the full Article 6(3) text, with legal review.

• Administrative scheduling: Does it only organise appointments, or does it also rank or prioritise patients in ways that affect access to care? Prioritisation moves the analysis toward the Annex III and significant-risk questions.
• Clinical documentation assistance: Does it draft or summarise records for a clinician to review, or does its output feed a decision about a patient? The test is influence on decision outcomes, not the label.
• Clinical-support tools: Is the tool itself, or a safety component of, a medical device or IVD? If so, Article 6(1) must be screened first, independent of Annex III.
• Patient triage: Emergency healthcare patient triage is treated as high-risk in the recitals because it makes decisions in very critical situations for life and health. Other triage uses need testing against the Annex III wording.
• Benefits or coverage eligibility: Test against the Annex III entries on access to essential services and benefits. Any profiling of natural persons removes the derogation.
• Financial services contrast: The same logic applies outside healthcare: classify by what the system does and how far it shapes a decision about a person, not by the sector or the product name.

Applying Article 6(3) and the profiling override

Article 6(3) provides that an Annex III system is not considered high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making. One of the listed conditions is that the system is intended to perform a preparatory task to an assessment relevant to the Annex III use cases. That is only one condition. Before applying the derogation to a scenario, quote the full Article 6(3) text in the assessment and identify exactly which condition is relied on.

The profiling override limits all of this. An Annex III system is always considered high-risk where it performs profiling of natural persons, notwithstanding the derogation. For healthcare, this matters most for coverage and eligibility tools. A function that compiles documents for a human assessor might be a preparatory task. A function that scores or profiles individuals inside the same product cannot rely on Article 6(3), however modest the rest of the product is.

Two errors follow. Over-classification happens when a documentation or scheduling tool is treated as high-risk because it sits in a clinical setting, which adds obligations the intended purpose does not call for. Under-classification happens when a tool is described as "support" or "preparatory" while its output in practice determines who receives a benefit or how quickly. Where a product mixes both kinds of function, separate them in design and in documentation so the derogation is not undermined by the profiling or decision-shaping component.

Where runtime evidence supports a classification

A derogation rests on a claim about behavior: the system is preparatory, does not materially influence outcomes, and does not profile. That claim is made before deployment and is only as strong as the evidence that production behavior stays inside it. A classification memo alone does not show that a documentation assistant never produced eligibility recommendations, or that a scheduling tool never touched a function outside its stated purpose.

This is where runtime policy enforcement is relevant. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval at the level of individual interactions and tool calls. Each enforcement decision generates audit-ready evidence mapped to the EU AI Act, HIPAA and NIST. In a healthcare setting, a policy can block a tool call outside the documented purpose, redact PHI before it reaches a model, or route a consequential output to a human for approval. The resulting records can be compared against the intended purpose in the classification file and support HIPAA 164.312(b) audit controls.

The limits matter. Trussed does not determine legal classification, and the evidence does not replace the assessment. It gives the compliance owner a durable record of what the system was allowed to do and what it did, which is the material a re-assessment or a regulator's question will need. Trussed runs in production with healthcare and pharma organizations.

Timing of the high-risk obligations, as of November 2026

The original application date for the high-risk provisions was 2 August 2026. The Digital Omnibus on AI would move it. The Council and Parliament reached a provisional agreement on 7 May 2026, and the Commission's AI Act page already states 2 December 2027. Formal adoption should be tracked before internal milestones are fixed. The Commission also published guidelines for providers and deployers of high-risk AI systems on 30 October 2026, which clarify classification and give practical examples. Review existing classification decisions against them.

• 2 August 2026: Original application date for the high-risk provisions.
• 7 May 2026: Provisional agreement on the Digital Omnibus on AI.
• 2 December 2027: Provisionally agreed date for stand-alone high-risk AI systems.
• 2 August 2028: Provisionally agreed date for high-risk AI systems embedded in products. Which medical-device AI falls here needs confirming for each product.