The Act is risk-based in the sense that obligations depend on what a system does and how it is used, not on a single label for all AI. Screening runs in order: Article 5 prohibitions first, then Article 6 high-risk classification through Annex I or Annex III, then Article 50 transparency duties, then Chapter V duties where a general-purpose AI model is involved, with AI literacy in Article 4 applying across providers and deployers. A system can engage more than one tier at once, and a system outside the high-risk tier can still face transparency, literacy, data protection and sectoral duties.
What does risk-based mean in this Act?
Risk-based means the legal consequences follow the risk profile of the use, as defined by the Act's own categories, rather than applying one uniform set of obligations to every AI product. The Act identifies practices it prohibits outright, systems it treats as high-risk because of their product context or use case, uses that trigger targeted transparency duties, and models that trigger Chapter V duties. The categories are legal categories with defined elements, not a general judgement that a system is risky in ordinary language. A powerful system can fall outside the high-risk category, and a modest system can fall inside it, because the test is the defined use and context, not capability alone.
Why does the order of screening matter?
Order matters because each tier changes what happens next. Testing Article 5 first prevents a prohibited practice from being treated as a manageable high-risk system. Testing Article 6 second establishes whether the Chapter III requirements, conformity assessment and actor duties apply. Testing Article 50 separately prevents transparency duties from being overlooked for systems that are not high-risk. Testing Chapter V separately prevents model duties from being confused with system duties. A record that jumps straight to high-risk controls without recording the Article 5 screen and the Article 50 check is incomplete, even if the high-risk conclusion happens to be right, because a reviewer cannot see that the other tiers were considered.
For the broader regulatory framework, see prohibited practices under Article 5.
How do the tiers overlap in one product?
One product can contain several systems and models, each with its own tier. A platform can include a general-purpose model, a high-risk component for one use case, a transparency-triggering interaction feature, and ordinary features that engage none of those tiers. The tiers can also overlap on a single system: a high-risk system can also trigger Article 50 duties for its outputs, and its provider can also be a general-purpose model provider for the model inside it. The record should therefore be kept per system and per use, with the tier conclusion stated separately for each provision, rather than assigning one tier to a whole product or a whole company.
What sits outside the high-risk tier?
Systems outside the high-risk tier are sometimes described as minimal risk or limited risk in explanatory material, but those phrases are not a single legal category that switches off every duty. Article 4 on AI literacy applies to providers and deployers, Article 50 can apply to interaction and synthetic content uses, and other Union law, including data protection, consumer and employment law, can apply regardless of tier. Voluntary codes of conduct under Article 95 are also encouraged for non-high-risk systems. A conclusion that a system is not high-risk should therefore be recorded as a conclusion about Article 6, with the Article 50, Chapter V and other-law checks recorded alongside it, not as a conclusion that no rules apply.
How should uncertainty be handled in a risk assessment?
Uncertainty should be recorded, owned and given a revisit date. A borderline classification, a contested intended purpose, or an incomplete supplier record are reasons to keep the question open, limit the deployment, or seek qualified review, not reasons to choose the more convenient tier. The Article 6(3) filter, where it is relied on, requires documentation and registration even when the conclusion is not high-risk, which shows that the Act treats a not high-risk conclusion as a decision that needs evidence. The same discipline should be applied to Article 5 screening and Article 50 checks, even where the Act does not prescribe the same formal steps, because the reasoning is what a reviewer or authority will ask for.
Continue with understand AI Act risk categories.
What is beyond the scope of this guide?
This guide explains the structure and the screening order. It does not classify any particular system, does not decide whether a practice is prohibited, and does not tell a reader what duties apply to a specific product. Classification needs the intended purpose, the deployment context, the affected people, and the full wording of Articles 5, 6 and 50, read in the consolidated text. Where the tier is contested, or where a wrong tier would change the conformity route or the ability to supply the system at all, confirmation should be sought from a competent authority or legal adviser before the system is placed on the market, put into service or used.
Frequently asked questions
Is every capable AI system high-risk?
No. High-risk status follows Article 6 and the annexes, tested on intended purpose and context. Capability alone does not make a system high-risk, and a system with modest capability can be high-risk if its use matches a listed use case.
Can a system be both high-risk and subject to transparency duties?
Yes. Article 50 duties are tested separately from Article 6 classification, and a high-risk system can also trigger interaction disclosure or synthetic content marking duties for its outputs.
Does the risk-based approach mean risk can be argued away?
No. The tiers are defined by legal tests in Articles 5, 6 and 50 and the annexes. A general argument that a system is low risk in ordinary language does not satisfy a defined test, and the Article 6(3) filter has specific conditions and a profiling override.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗