# EU AI Act risk classification: The 4-tier system explained > The EU AI Act sorts every AI system into four risk tiers - unacceptable, high, limited, and minimal. The tier determines your compliance obligations, documentation, and exposure to fines and it turns on what the system does, not how it is built. **Author:** Maarten Stolk **Last reviewed:** 31 July 2026 **Source:** https://deeploy.ai/eu-ai-act-hub/articles/eu-ai-act-risk-classification-4-tier-system/ The EU AI Act classifies every AI system into one of four risk tiers: unacceptable, high, limited, and minimal. The tier your system falls into determines your compliance obligations, documentation requirements, and exposure to fines. Risk classification is not optional, and it is not self-evident. Getting it wrong in either direction carries real consequences: under-classify a high-risk system and you face enforcement action; over-classify a minimal-risk one and you waste compliance budget. The EU AI Act's framework is deliberately use-case-driven - what matters is not how technically sophisticated your model is, but what it does and to whom. This guide walks through all four tiers, explains how classification actually works under Article 6, and surfaces the edge cases that trip up most organisations. ## How the EU AI Act risk framework works The EU AI Act is built on a risk-based regulatory philosophy. Rather than applying uniform rules across all AI, it calibrates obligations to the level of risk a system poses to health, safety, and fundamental rights. The less risk, the lighter the regulatory burden. That principle sounds simple. In practice, classification depends on two things: **Intended purpose**: The same underlying model can sit in different tiers depending on its deployment context. A generative AI system used to write marketing copy is minimal risk. The same model integrated into a credit-decisioning workflow almost certainly is not. **Use case domain**: Article 6 defines two routes to high-risk classification. Either the AI system is a safety component of a regulated product requiring third-party certification (Article 6(1)), or the system falls within one of eight use case domains listed in Annex III of the Act (Article 6(2)). Everything else; the model architecture, the parameter count, whether it is open-source or proprietary, is legally irrelevant to classification. ## The four EU AI Act risk tiers at a glance | **Tier** | **Legal basis** | **Enforcement date** | **Compliance obligation** | | --- | --- | --- | --- | | Unacceptable risk | Article 5 | 2 February 2025 | Prohibited - no permitted use | | High risk | Articles 6–15 | 2 December 2027 (Annex III stand-alone systems)2 August 2028 (Annex I embedded systems) | Extensive requirements | | Limited risk | Articles 50–52 | 2 August 2026 | Transparency obligations | | Minimal risk | No mandatory provision | N/A | No mandatory requirements | ## Tier 1: Unacceptable risk (prohibited) Unacceptable risk AI systems are banned outright under Article 5. The prohibitions have been enforceable since 2 February 2025. Any organisation operating these practices in connection with the EU is already in violation. The eight prohibited categories cover: - [**Subliminal or manipulative techniques**](https://deeploy.ai/eu-ai-act-hub/articles/manipulative-ai-under-the-eu-ai-act-what-article-51a-actually-bans/): Systems that alter behaviour without the person's awareness in ways that cause or are likely to cause significant harm. - **Exploitation of vulnerabilities**: AI that targets age, disability, or socioeconomic circumstances to distort behaviour harmfully. - [**Social scoring by public authorities**](https://deeploy.ai/eu-ai-act-hub/articles/social-scoring-ai-eu-ai-act-ban/): AI used to evaluate or classify individuals based on social behaviour or personal characteristics in contexts unrelated to where the data was collected. - **Real-time remote biometric identification in public spaces**: With narrow exceptions for law enforcement in pursuit of specific serious crimes, subject to judicial or prior authorisation. - **Biometric categorisation by protected attributes**: Systems that infer race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation from biometric data. - **Emotion recognition in workplace or educational settings** - **AI-generated or manipulated content that constitutes criminal offences**: Such as deepfake child sexual abuse material. - **Predictive policing based solely on profiling**: Risk assessments of individuals based on personality traits without factual indicators of criminal behaviour. The [penalty for prohibited AI practices](https://deeploy.ai/eu-ai-act-hub/articles/eu-ai-act-fines-explained-penalty-tiers-up-to-e35-million-under-article-99/) is up to €35 million or 7% of global annual turnover for the highest tier in the Act, exceeding GDPR's maximum ceiling. **For deployers:** If a vendor offers a capability that falls within any of these categories, deploying it is itself a violation. Provider classification does not shield the deployer. ## Tier 2: High risk High-risk AI systems are permitted but [subject to extensive requirements](https://deeploy.ai/eu-ai-act-hub/articles/high-risk-ai-system-requirements-compliance-checklist/) before and during deployment. This is where the bulk of the EU AI Act's obligations sit, and where most enterprise AI systems in regulated sectors will land. ### What makes an AI system high risk? Classification as high risk flows from one of two routes under Article 6: **Route 1 - Article 6(1): Safety components of regulated products:** If an AI system is embedded in a product that must already undergo third-party conformity assessment under EU harmonisation legislation (Annex I, covering medical devices, machinery, vehicles, aviation equipment, and others), that AI system is automatically high risk, provided its failure or malfunction would endanger health or safety. Following the Digital Omnibus, AI used solely for non-safety purposes, such as user assistance, optimisation, service efficiency, automation, convenience, or non-safety quality control, no longer qualifies as a safety component under this route. **Route 2 - Article 6(2): Annex III listed domains:** If the AI system's intended use falls within one of the eight domains listed in Annex III, it is classified as high risk. Those domains are: - **Biometrics**: Remote biometric identification; biometric categorisation by sensitive attributes; emotion recognition at work or in education. - **Critical infrastructure**: AI managing safety components of road, rail, water, gas, electricity, or digital infrastructure. - **Education and vocational training**: AI that determines access, evaluates learning outcomes, or monitors students during assessments. - **Employment and workforce management**: AI used for recruitment, CV screening, promotion decisions, task allocation, or performance monitoring. - **Access to essential services**: AI for creditworthiness, credit scoring (excluding fraud detection), insurance risk pricing, emergency call triage, and benefit eligibility assessment. - **Law enforcement**: AI for individual risk assessment, polygraph-type tools, evaluation of evidence reliability, crime prediction. - **Migration, asylum, and border control**: AI for assessing application risk, document verification, security threat screening. - **Administration of justice and democratic processes**: AI assisting courts or arbitration, AI that influences elections and political campaigns. ### The Article 6(3) exception Not every Annex III system is automatically high risk. Article 6(3) allows an AI system to escape that classification if it does not pose a significant risk of harm and meets one of four conditions: - It performs only a **narrow procedural task** - It improves the result of a **previously completed human activity** - It detects decision-making patterns but is **not meant to replace or influence** human assessment without proper review - It performs only a **preparatory task** to an assessment Important caveat: if a system profiles natural persons, the Article 6(3) exception does not apply, regardless of how narrow the task appears. Providers who rely on this exception must document their reasoning before placing the system on the market and notify the relevant authority. ### What high-risk compliance requires Organisations deploying high-risk AI systems must meet obligations across six areas: - **Risk management system (Article 9)**: A continuous, iterative process identifying and mitigating reasonably foreseeable risks throughout the system lifecycle. - **Data governance (Article 10)**: Training, validation, and testing data must be subject to appropriate governance practices, with bias examination> - **Technical documentation (Article 11 + Annex IV)**: A full documentation dossier covering system design, architecture, data, intended purpose, performance benchmarks, and modification history. - **Logging and record-keeping (Article 12)**: Automatic event logging with sufficient granularity to enable post-market monitoring and investigation of incidents. - **Transparency and user information (Article 13)**: Instructions for use, clear information on capabilities and limitations. - **Human oversight (Article 14)**: Humans must be able to understand the system's output, override or interrupt it, and avoid over-reliance. For deployers specifically: you must implement the technical and organisational measures set out by the provider, monitor the system's operation, report serious incidents to the provider and relevant authorities, and (if you substantially modify a high-risk system) take on provider obligations. ## Tier 3: Limited risk Limited-risk AI systems are subject to targeted transparency obligations rather than full compliance requirements. The focus is on ensuring users know they are interacting with AI. The main obligations apply to: - **Chatbots and conversational AI**: Users must be informed they are talking to an AI, unless this is obvious from context. - **Deepfake and synthetic media**: AI-generated or manipulated images, audio, and video must be labelled as artificially generated, with narrow exceptions for legitimate creative or satire purposes. - **Emotion recognition systems and biometric categorisation**: Where not already classified as high risk, users must be notified. Most general-purpose AI assistants, customer service chatbots, and content generation tools sit in this tier, provided they are not embedded in a high-risk decision-making workflow. ## Tier 4: Minimal risk Minimal-risk AI systems face no mandatory compliance requirements under the EU AI Act. The vast majority of AI applications currently in use (spam filters, recommendation engines, AI-enabled games, basic process automation) fall into this category. The Act encourages providers and deployers of minimal-risk AI to adopt voluntary codes of conduct and adhere to AI literacy standards, but these carry no enforcement consequences. **Important note:** Minimal-risk classification is not a permanent status. If your organisation redeploys a system for an Annex III use case, or substantially modifies it in ways that affect its risk profile, the classification must be reassessed. Reclassification obligations sit with the provider, but deployers who direct how a system is used carry responsibility for ensuring the deployed purpose matches the classification. ### Where GPAI models sit General-purpose AI models (foundation models and large language models trained on broad data for a wide range of tasks) sit outside the four-tier classification framework in a separate regulatory regime under Title VIII (Articles 51–56). They are not automatically classified as high risk. However, a GPAI model deployed within a high-risk application becomes subject to high-risk requirements for that deployment. And GPAI models deemed to pose "systemic risk" (those trained with more than 10^25 FLOPs of compute, or assessed as such by the AI Office) face additional obligations including incident reporting, adversarial testing, and cybersecurity measures. GPAI obligations, for all providers of GPAI models, have applied since 2 August 2025. ## Practical classification: First questions to ask Before placing or deploying any AI system, work through these questions: - Is the system's intended use explicitly listed in Article 5? → If yes: prohibited. Stop. - Is the system a safety component of an Annex I product requiring third-party certification? → If yes: high risk. - Does the system's intended purpose fall within an Annex III domain? → If yes: likely high risk; assess whether Article 6(3) applies and document the outcome. - Does the system interact with users in a way they could mistake for being human? And / or does it generate synthetic content? → If yes: transparency obligations apply (limited risk minimum). - None of the above? → Minimal risk, but document your reasoning. Classification is not a one-time exercise. It must be revisited whenever the system is substantially modified, redeployed for a different purpose, or when the European Commission updates Annex III. ## How Deeploy supports high-risk compliance For organisations deploying high-risk AI systems, the most operationally demanding obligations are the ongoing ones: continuous monitoring, automatic event logging, incident detection, and post-market surveillance. These cannot be addressed with documentation alone, they require infrastructure. Deeploy is purpose-built for exactly this layer of high-risk compliance. See how Deeploy addresses [EU AI Act monitoring obligations](https://deeploy.ai/product/monitoring-insights/). ## Frequently asked questions ## Frequently asked questions ### How do I know if my AI system is high-risk within the EU AI Act? There are two routes to high-risk classification. Under Article 6(1), an AI system that is a safety component of a product covered by EU harmonised legislation (such as medical devices or machinery) is high-risk, provided its failure or malfunction would endanger health or safety. Following the Digital Omnibus, AI used solely for non-safety purposes, such as user assistance, optimisation, service efficiency, automation, convenience, or non-safety quality control, no longer qualifies under this route. Under Article 6(2), standalone AI systems listed in Annex III are high-risk. Annex III covers eight sectors: biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration and asylum, and administration of justice. ### Is our recruitment screening tool high-risk within the EU AI Act? Almost certainly yes. Annex III Point 4 covers AI systems used for recruitment, candidate selection, CV screening, task allocation, performance monitoring, and promotion or termination decisions. If your tool performs any of these functions, it falls within scope and is subject to the full high-risk requirements. ### We use AI for credit scoring. Does the EU AI Act apply? Yes. Annex III Point 5 covers AI systems used to evaluate the creditworthiness of individuals or establish their credit score. This applies whether the system is built in-house or procured from a third party. ### Is a recommendation algorithm high-risk within the EU AI Act? Not automatically. Classification depends on use case, not technology. A product recommendation engine on a retail website is typically minimal risk. The same algorithmic logic applied to determining access to essential services, or to allocating workers to tasks, would be high-risk under Annex III. ### Does the Act cover AI used internally, or only customer-facing systems? Both. The Act covers AI systems regardless of whether they face customers or are used solely for internal operations such as HR, finance, or IT management. Internal employee monitoring or performance evaluation tools are explicitly within Annex III scope. ### What counts as a "significant change" that would trigger re-classification of an existing system in the EU AI Act? The Commission's guidance defines a significant change as one that affects the intended purpose of the system, its performance on safety-relevant tasks, or the nature of risks it poses. A model retrained on substantially different data, or repurposed for a new use case, is likely to qualify. Minor parameter updates typically do not.