How do I know which risk tier my AI system falls into?

Classification depends on your system's intended purpose and deployment context, not just the code. Article 6 of the EU AI Act defines the routes: systems listed in Annex III by use case are high-risk, systems embedded in products covered by Annex I are high-risk, and systems with transparency obligations fall under limited risk (Article 50). Everything else is minimal risk. A code scanner can detect risk indicators but cannot make the final determination — that requires understanding your deployment context.

What is the Article 6(3) derogation for high-risk AI?

Article 6(3) allows a system listed in Annex III to be classified as non-high-risk if it performs a narrow procedural task, improves the result of a previously completed human activity, or is used for human decision support where the human decision is not bypassed. You must document this assessment. This is a self-assessment — it is not automatic, and the conditions are narrow.

When do the high-risk obligations start applying?

Under the Digital Omnibus provisional agreement of 7 May 2026, approved by European Parliament on 16 June 2026, Annex III (use-based) high-risk obligations are postponed to 2 December 2027. Annex I (product-embedded) obligations apply from 2 August 2028. The Council approved it on 29 June 2026; publication in the Official Journal is expected before 2 August 2026. Until OJ publication, the original 2 August 2026 deadline remains technically in force.

Can a code scanner classify my AI system for me?

Not fully. A code scanner like Regula can detect risk indicators — AI library imports, pattern matches suggesting high-risk use cases, credential exposure, and agent autonomy markers. It can suggest a risk tier based on code patterns. It cannot determine if your system meets the significant risk threshold, assess your deployment context, verify Article 6(3) exemption applicability, or replace legal advice.

What are the Article 5 prohibitions under the EU AI Act?

Article 5 defines practices not permitted under the Act. The original 8 categories have been enforceable since 2 February 2025. The Digital Omnibus (provisional agreement 7 May 2026, approved by European Parliament 16 June 2026) adds 2 further categories (CSAM and NCII generation), bringing the total to 10; these 2 new prohibitions take effect on 2 December 2026 (approved by Council on 29 June 2026; pending OJ publication). The specific categories are listed in Article 5(1)(a) through (h) of the original text plus the Omnibus additions. If your system falls into any of these categories, it may not be placed on the EU market.

11 June 2026 · Kuziva Muzondo

How to Classify Your AI System Under the EU AI Act

Classification depends on your system’s intended purpose and deployment context, not just what the code does. Article 6 defines the routes. A code scanner like Regula can detect risk indicators but cannot make the Article 6 determination for you — that requires understanding how, where, and on whom your system is deployed.

The four risk tiers

The EU AI Act classifies AI systems into four tiers: practices not permitted (Article 5), high-risk (Annex III use-based or Annex I product-embedded), limited risk (Article 50 transparency obligations), and minimal risk (no specific obligations). Your compliance obligations, deadlines, and conformity assessment requirements depend entirely on which tier your system falls into.

The EU AI Act sorts AI systems into four tiers. Your obligations depend entirely on which tier applies.

Practices not permitted (Article 5)

Article 5 defines 10 categories of AI practices not permitted under the Act — 8 in the original text (in force since 2 February 2025) plus 2 additions from the Digital Omnibus provisional agreement, approved by European Parliament on 16 June 2026 (the 2 new prohibitions take effect 2 December 2026, approved by Council on 29 June 2026; pending OJ publication). If your system falls into any of these categories, it may not be placed on the EU market. See Article 5(1) of Regulation (EU) 2024/1689 for the full list.

High-risk: use-based (Annex III)

Systems whose intended purpose falls into one of eight domains: biometrics, critical infrastructure, education and vocational training, employment, access to essential services, law enforcement, migration and border control, and administration of justice. Classification is determined by what the system is used for, not what libraries it imports. Compliance deadline: 2 December 2027 (Digital Omnibus provisional agreement of 7 May 2026, approved by European Parliament on 16 June 2026; approved by Council on 29 June 2026; pending OJ publication; original deadline was 2 August 2026).

High-risk: product-embedded (Annex I)

AI systems that are safety components of, or are themselves, products covered by EU harmonisation legislation listed in Annex I — including medical devices, machinery, toys, lifts, and radio equipment. These follow the existing CE marking framework. Compliance deadline: 2 August 2028 (Digital Omnibus).

Limited risk (Article 50)

Systems with transparency obligations: chatbots that interact with people, systems generating synthetic content (deepfakes, AI-generated text or images), emotion recognition systems, and biometric categorisation systems. The obligation is disclosure, not the full high-risk conformity assessment. These obligations apply from 2 August 2026.

Minimal risk

Everything else. No specific obligations under the Act. Most AI systems fall here. You may still choose to follow the voluntary codes of practice.

How Article 6 works

Article 6 is the gateway provision. It determines whether your Annex III system is actually high-risk by introducing a significant risk threshold. A system listed in Annex III is high-risk only if it poses a significant risk of harm to health, safety, or fundamental rights.

Article 6(3) provides a narrow derogation. An Annex III system is not high-risk if it:

Performs a narrow procedural task (e.g. converting unstructured data to structured data);
Improves the result of a previously completed human activity; or
Is intended for human decision support where the human decision is not bypassed or overridden by the AI output.

This is a self-assessment, not an automatic exemption. You must document why your system qualifies. The conditions are narrow and context-dependent — the same model used for different purposes can fall on different sides of this line. Context matters more than code.

What Regula can and cannot tell you

Regula can detect risk indicators in your code — AI library imports, pattern matches suggesting high-risk use cases, credential exposure, and agent autonomy markers — and suggest a risk tier. It cannot determine whether your system meets the Article 6 significant risk threshold, assess your deployment context, or replace legal advice. The code scan is a starting point, not a legal determination.

Regula is a code scanner. It reads your source code and matches patterns. That is useful, but it has clear boundaries.

Regula can	Regula cannot
Detect risk indicators in your code (AI library imports, pattern matches, credential exposure, agent autonomy markers)	Determine if your system meets the Article 6 “significant risk” threshold
Classify your risk tier based on code patterns	Assess your deployment context (who uses it, where, on whom)
Flag gaps in your technical documentation	Verify Article 6(3) exemption applicability
Generate an evidence pack for your compliance file	Replace legal advice

The code-level scan is a starting point. It narrows the field. It does not make the legal determination.

Practical steps

To classify your AI system, run three Regula commands in sequence: regula assess for a guided assessment of your intended purpose and deployment context, regula check . to scan your codebase for risk indicators, and regula gap . to identify which obligations apply and where your documentation falls short.

Start with the guided assessment, then scan your code, then check for gaps:

# 1. Guided assessment: 5 questions, no code needed
regula assess

# 2. Scan your codebase for risk indicators
regula check .

# 3. Check for compliance gaps against the Act
regula gap .

regula assess asks about your intended purpose and deployment context — the factors that code scanning alone cannot determine. It then maps your answers to a risk tier. regula check scans your source code for risk indicators that corroborate or challenge that classification. regula gap identifies which obligations apply to your tier and where your documentation or technical measures fall short.

Omnibus caveat

All dates referencing the Digital Omnibus are based on the provisional political agreement of 7 May 2026, approved by the European Parliament on 16 June 2026 (423 for, 57 against, 174 abstentions). The Council approved it on 29 June 2026; publication in the Official Journal is expected before 2 August 2026. Until OJ publication, the original EU AI Act deadlines technically remain in force. We will update this post when the Omnibus is formally adopted.

Last verified: 11 June 2026 · Author: Kuziva Muzondo · Sources: Regulation (EU) 2024/1689, Digital Omnibus provisional agreement (7 May 2026) · Not legal advice. Regula identifies risk indicators for developer review.