EU AI Act Risk Tiers: How Healthcare, Insurance and Banking AI Are Classified

The four tiers and the current timeline

The Commission describes the AI Act as built on four levels of risk. Its 2026 document names them as unacceptable risk, high risk, transparency risk, and minimal to no risk. Many teams, and this guide's headline, use "limited risk" for the third tier. Both labels refer to the same tier, so use whichever your internal policy already uses and keep it consistent.

Unacceptable-risk practices are prohibited. High-risk systems carry the substantive requirements, including risk management, human oversight and record-keeping. Transparency-risk systems carry disclosure duties. For minimal or no risk, the Act introduces no rules. In practice most of the compliance workload sits in the high-risk tier, which is why classification errors are expensive in both directions.

The dates have changed. High-risk provisions were originally due to apply on 2 August 2026. Under the Digital Omnibus on AI, the Council and Parliament reached a provisional agreement on 7 May 2026 that sets 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for high-risk systems embedded in products. The Commission's AI Act page already states that high-risk obligations start on 2 December 2027. As of November 2026, plan against these dates and track formal adoption of the amendments.

• Unacceptable risk: Prohibited practices.
• High risk: Annex I product route (Art. 6(1)) or Annex III use cases (Art. 6(2)).
• Transparency risk: Disclosure duties. Often labelled limited risk.
• Minimal or no risk: No rules introduced by the Act.

Healthcare AI: two routes to high-risk

Healthcare is the hardest sector to classify because the two high-risk routes are independent. Article 6(1) captures AI that is a safety component of, or is itself, a product regulated by Annex I legislation. Article 6(2) captures Annex III use cases. A healthcare system can be high-risk through either route, and the checks should run separately for every system.

On the Annex III route, the Commission lists AI used in access to essential private and public services and benefits, including healthcare, as high-risk. Its examples include systems that assess whether someone can receive a certain medical treatment. The recitals also classify emergency healthcare patient triage systems as high-risk. A treatment-eligibility model or a triage prioritisation tool therefore lands in the high-risk tier on use case alone.

On the Annex I route, the question is whether the system is, or is a safety component of, a regulated product. Clinical software that forms part of such a product is assessed through this route regardless of whether any Annex III use case applies. Whether a system is stand-alone or embedded in a product also determines which application date is relevant, 2 December 2027 or 2 August 2028.

Systems with a purpose that matches neither route, such as internal drafting or scheduling support, are assessed on their own function. They may fall into the transparency tier or the minimal tier. The Article 6 derogation can apply to Annex III systems, but it is lost where the system profiles natural persons, and any reliance on it should be documented.

Insurance and banking within the same framework

The same logic applies outside healthcare. AI intended for risk assessment and pricing for natural persons in life and health insurance is high-risk. AI used to evaluate the credit score or creditworthiness of natural persons is high-risk because it determines access to financial resources or essential services.

The carve-outs are narrow and sit in the recitals. AI systems provided for by Union law to detect fraud in offering financial services should not be considered high-risk. Neither should systems used for prudential purposes to calculate the capital requirements of credit institutions and insurers. The practical consequence is that one insurer or bank can run models in different tiers. A life underwriting model is high-risk, while a fraud model and a capital model may not be. Each needs its own entry in the inventory with its own rationale.

There is also a deployer-side duty. Operators providing creditworthiness or life and health insurance risk and pricing systems, as well as public-law bodies and private operators providing public services, must perform a fundamental rights impact assessment and notify the national authority of the results. Assign an owner for that assessment at the time of classification, not after deployment is planned.

What high-risk status requires at runtime

High-risk classification brings the requirements in Articles 9 to 15, which include risk management, human oversight, and record-keeping and logging. The Commission also highlights risk assessment and mitigation systems and high-quality datasets among the obligations that start on 2 December 2027.

Article 9 requires a risk management system that is established, implemented, documented and maintained, taking into account intended purpose and the generally acknowledged state of the art. Article 14 requires that high-risk systems be designed, including with appropriate human-machine interface tools, so that natural persons can effectively oversee them while in use. That wording gives a concrete test: an approval step exists only in a useful sense if the reviewer can see enough context to intervene meaningfully.

Some of these requirements are about design and documentation, and cannot be met by any runtime control. Others concern behaviour in operation: who approved an action, what the system was permitted to do, and what record exists. For those, ask per system whether the control acts while the system runs, whether the output is retained in a form you can produce on request, and who signs off on that evidence. Whether any particular control satisfies a specific article is a question for your legal team and the Commission's high-risk guidelines.

• Does the control act during operation, or only review after the fact?
• Can a human reviewer see enough context to oversee effectively (Article 14)?
• Is a durable record kept per system and per decision?
• Can the record be produced to a regulator on request?
• Is there a named owner who approves the evidence?

Where runtime policy enforcement fits

Trussed is a runtime control and evidence layer. It does not classify systems or replace a risk management system, and the tier decision stays with your compliance team and counsel. What it addresses is the operational part of high-risk obligations, which is showing what an AI system was allowed to do and what it did.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Policy is enforced at runtime, not reviewed after the fact, with outcomes of allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. Enforcement produces continuous audit-ready evidence mapped to the EU AI Act, alongside HIPAA, NAIC, NYDFS and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

The mapping of these controls to Articles 9 to 15 is a design view, not a regulatory requirement. Escalation for human approval is one way to give reviewers a point of intervention that can be evaluated against Article 14. Trussed runs in production with healthcare and pharma organizations, and it has operated continuously in a regulated enterprise for more than 18 months.