- Risk classification is a scoping decision, not a compliance afterthought. Get it wrong at initiation and you’ll discover mid-execution that your project needs a risk management system, 10-year technical documentation, and a conformity assessment it was never budgeted for. Run the checklist during chartering, not during UAT.
- Annex III doesn’t automatically mean high-risk — but the exception isn’t free. Article 6(3) lets you self-classify downward if the system performs a narrow procedural, preparatory, or pattern-detection task without materially influencing decisions. The catch: you must document the reasoning before deployment, register it in the EU database, and defend it to regulators. Any system that profiles individuals is high-risk regardless.
- Classification is a living decision, not a one-time box-check. A scope change that adds scoring, ranking, or recommendation functionality to an Article 6(3) system can flip it to high-risk. Build classification review into your change control process and treat any expansion of decision influence as a trigger event.
Every project needs scope definition. For AI projects, that means answering not just “what are we building?” but “how risky is what we’re building, and to whom?” The answer shapes everything from governance overhead to stakeholder engagement to go/no-go decisions.
The EU AI Act’s risk classification framework provides a structured, legally grounded basis for that question. Even for projects outside EU regulatory scope, the framework is worth using: it forces systematic thinking about potential harms to natural persons, it maps those harms to governance obligations with real consequence, and it gives teams a shared vocabulary for scoping conversations that often stall on vague notions of “responsible AI.”
This article walks through the classification structure, covers the Article 6(3) downward self-classification mechanism that most tier summaries omit, explains the profiling override that closes the most common compliance gap, and maps classification outcomes to project planning decisions.
The Four-Tier Classification Structure
The EU AI Act classifies AI systems into four risk categories. Each carries a different set of obligations. Classification is determined by the system’s intended purpose and use case — not by its technical architecture, training data, or model type.
Unacceptable Risk — Prohibited (Article 5)
These practices are banned outright. The prohibition applied from 2 February 2025. There are no compliance pathways — prohibited systems cannot be placed on the market or put into service in the EU under any conditions:
- Subliminal, manipulative, or deceptive techniques that distort behavior and impair informed decision-making, causing significant harm
- Exploitation of vulnerabilities related to age, disability, or socio-economic circumstances to distort behavior, causing significant harm
- Biometric categorization systems that infer sensitive attributes — race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation — from biometric data
- Social scoring: evaluating or classifying individuals based on social behavior or personal traits in ways that cause detrimental or disproportionate treatment in unrelated contexts
- Assessing the risk of an individual committing a criminal offence based solely on profiling or personality traits, without objective verifiable facts directly linked to criminal activity
- Compiling facial recognition databases by untargeted scraping of facial images from the internet or CCTV footage
- Inferring emotions of individuals in workplaces or educational institutions, except for medical or safety purposes
- Real-time remote biometric identification in publicly accessible spaces for law enforcement purposes, subject to three narrowly defined exceptions
PM implication: If your project involves any of these practices, stop. The prohibition is absolute — no risk management system, no conformity assessment, no documentation pathway makes a prohibited system compliant. Redesign the use case or cancel the project.
High Risk (Articles 6, 8–17)
High-risk AI systems are authorized but subject to a mandatory compliance regime before they can be deployed. Two categories qualify as high-risk under Article 6:
Article 6(1) — Safety components in regulated products: AI systems intended as a safety component of, or themselves constituting, a product covered by EU harmonisation legislation listed in Annex I, where that product is required to undergo third-party conformity assessment. This covers AI in medical devices, in vitro diagnostics, civil aviation safety systems, vehicles, agricultural machinery, lifts, toys, and radio equipment.
Article 6(2) — Annex III use-case categories: AI systems falling within the eight application areas listed in Annex III: (1) biometric identification and categorization of natural persons; (2) management and operation of critical infrastructure; (3) education and vocational training; (4) employment, workers management, and access to self-employment; (5) access to essential private and public services and benefits; (6) law enforcement; (7) migration, asylum, and border control; (8) administration of justice and democratic processes.
The compliance obligations under Articles 8–17 include: a risk management system maintained throughout the lifecycle (Article 9); data governance over training, validation, and testing datasets (Article 10); technical documentation maintained for ten years (Article 11); automatic logging and record-keeping (Article 12); transparency and instructions for use (Article 13); five specific human oversight capabilities (Article 14); and accuracy, robustness, and cybersecurity requirements (Article 15). Before deployment, providers must complete conformity assessment and register in the EU database.
PM implication: High-risk classification means compliance work is a project deliverable, not a governance aspiration. Budget, schedule, and resource plans must account for risk management system development, data governance documentation, technical documentation maintenance, conformity assessment, and post-deployment monitoring. For most Annex III systems, self-assessment under Annex VI is the conformity assessment pathway — no notified body is required. The work is substantial; the administrative process is self-administered.
Limited Risk (Article 50)
AI systems that interact directly with people or generate certain types of content carry transparency obligations, but not the full high-risk compliance regime:
- Chatbots and conversational AI: Deployers must ensure that users are informed they are interacting with an AI system, unless this is obvious from the context.
- Emotion recognition and biometric categorization systems: Providers and deployers must inform natural persons who are exposed to the system.
- Deepfakes and AI-generated content: Providers must ensure that AI-generated images, video, audio, and text are labelled as artificially generated or manipulated in a machine-readable format, with a visible marking for audio-visual content.
- AI-generated text on matters of public interest: Must be disclosed as AI-generated, unless the text has undergone substantial human review or editorial control.
PM implication: Limited risk requires disclosure mechanisms built into the user experience, not a compliance program. The design question is: how and when does the system notify users of AI involvement? Build this into UX requirements and test it explicitly.
Minimal Risk
AI systems that do not fall into the above categories. Spam filters, recommendation engines, content moderation tools, most internal business process automation, and video game AI all fall here. The EU AI Act imposes no obligations on minimal-risk systems.
PM implication: No regulatory requirements does not mean no governance. Organizational AI policies, stakeholder expectations, and reputational risk considerations may still apply. Minimal-risk classification is a floor, not a ceiling.
The Article 6(3) Mechanism: Annex III Does Not Always Mean High Risk
This is the most commonly omitted element in risk classification summaries. Article 6(3) provides that an AI system falling within an Annex III use-case category shall not be considered high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights — including by not materially influencing the outcome of decision-making. This is not a policy aspiration; it is a statutory carve-out with defined conditions.
| Article 6(3) Condition | What It Means in Practice |
|---|---|
| (a) Narrow procedural task | The system performs a bounded, well-defined task within a larger human-administered process. Example: an Annex III employment-context tool that extracts structured data from unstructured CVs for display to a human recruiter, without ranking, scoring, or filtering candidates. |
| (b) Improvement of a previously completed human activity | The system augments or improves the output of an assessment that a human has already completed independently. Example: a proofreading or formatting tool applied to a draft assessment already written by a human assessor. |
| (c) Pattern detection without replacing human assessment | The system detects patterns or deviations in prior decision-making data, and is not configured to replace or influence the human assessment without proper human review. Example: an analytics dashboard that flags statistical anomalies in historical hiring decisions for HR review, without making recommendations. |
| (d) Preparatory task | The system performs a task that is preparatory to an assessment under an Annex III use case. Example: a document classification tool that organizes files before a human caseworker reviews them for a benefits eligibility determination. |
There is a hard override: regardless of whether any Article 6(3) condition is met, an Annex III system is always high-risk if it performs profiling of natural persons. The Act defines profiling as automated processing of personal data to evaluate aspects of a natural person’s life — work performance, economic situation, health, personal preferences, interests, reliability, behavior, location, or movements. Any Annex III system that scores, ranks, or categorizes individuals against these dimensions is high-risk, period.
The administrative consequence of invoking Article 6(3) is also frequently overlooked. A provider who determines that an Annex III system is not high-risk must: document the assessment before placing the system on the market; register the documentation in the EU database under Article 49(2); and provide documentation to national competent authorities on request. Market surveillance authorities can challenge the classification under Article 80. If a system is found to have been misclassified to circumvent compliance requirements, the provider faces fines under Article 99.
Article 6(3) is a documented, challengeable position, not a self-issued exemption. If you intend to rely on it, the classification reasoning must be written down before deployment, kept updated as the system evolves, and defensible on its merits.
Classification Drives Project Decisions
Risk classification is most useful when it happens at initiation, because the classification outcome determines the shape of the project — not just its governance overhead.
| Planning Decision | How Classification Changes It |
|---|---|
| Stakeholder scope | Minimal risk: IT and business owner. Limited risk: UX, legal, communications. High risk: legal, compliance, affected user groups, data governance, potentially external stakeholders and regulators. Prohibited: stop. |
| Documentation | Minimal risk: standard project documentation. Limited risk: transparency disclosure records. High risk: technical documentation demonstrating Articles 8–17 compliance, data governance records, risk management logs, 10-year retention. |
| Testing | Minimal risk: functional QA. Limited risk: disclosure mechanism testing. High risk: accuracy, bias, robustness, adversarial testing, validation against intended purpose across subgroups, documented TEVV program. |
| Timeline and budget | High-risk compliance work — risk management system, data governance, technical documentation, conformity assessment, EU database registration — adds material time and cost. Identify this at chartering, not during execution. |
| Go/no-go | Classification is a viability test. If the project falls in the prohibited tier, stop. If it falls in the high-risk tier and the organization cannot meet the compliance requirements, change the use case, scope down, or do not proceed. |
| Change control | Scope changes in Annex III use-case areas, changes that add profiling functionality, and changes that extend the system’s decision influence are classification-trigger events. Route them through classification review, not just standard change control. |
Classification Checklist: Working Through It at Initiation
Apply these questions during project initiation or as part of an AI Impact Assessment. Work through them in order — each positive answer determines the outcome.
| Question | If Yes |
|---|---|
| 1. Does the system use subliminal manipulation, social scoring, banned biometrics, untargeted facial scraping, workplace/school emotion inference, or real-time public biometric identification for law enforcement? | Prohibited. Stop — no compliance pathway exists. |
| 2. Is the system a safety component of, or itself a product governed by, EU product harmonisation legislation in Annex I, and does that product require third-party conformity assessment? | High risk under Article 6(1). Articles 8–17 obligations apply plus sector conformity assessment. |
| 3. Does the system fall within any of the eight Annex III use-case categories (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice)? | Potentially high risk. Proceed to Questions 4 and 5. |
| 4. Does the system perform profiling of natural persons (automated processing to evaluate work performance, economic situation, health, preferences, behavior, location)? | High risk regardless of anything else. Article 6(3) does not apply. Articles 8–17 obligations apply. |
| 5. Does the system perform only a narrow procedural task, improve a previously completed human activity, detect patterns without replacing human assessment, or perform only a preparatory task? | Potentially not high risk under Article 6(3). Document the reasoning, register in EU database under Article 49(2), and review whenever scope changes. |
| 6. Does the system interact directly with users, generate synthetic content, or infer emotions? | Limited risk under Article 50. Transparency and disclosure obligations apply. |
| 7. None of the above? | Minimal risk. No EU AI Act obligations, but organizational governance may still apply. |
A few practical notes on applying the checklist. Classification is based on intended purpose — the use case the system is designed and deployed for, not the use case it theoretically could be used for. A general-purpose large language model is not inherently high-risk; a deployment of that model for automated employment screening is. Context matters: the same underlying model deployed in two different organizational contexts may have two different classifications. If classification is genuinely borderline, the conservative choice is high-risk, because the documentation burden of a wrongly downward-classified system is far greater than the compliance burden of a correctly classified one.
Right-Sizing for Your Situation
The formality of classification work should match your context. A team doing a first-ever AI project in an Annex III area needs a guided framework; an organization running a portfolio of AI projects needs a classification process integrated into standard intake and approval workflows.
Use the checklist in this article during your project scoping session. Focus on Questions 1–5: prohibited, Article 6(1), Annex III, profiling, and Article 6(3). You don’t need a formal classification program yet — you need to ask the right questions before architecture is locked in. The answer to Question 4 (profiling) is the one most teams miss. If you can’t answer it with certainty, that’s your first governance task.
Create a classification decision record template and route it through your standard project intake process. The goal is a documented, dated classification for every AI initiative — with the reasoning written down before deployment and a review trigger built into change control. The template should capture: the Annex III use-case analysis, the Article 6(3) assessment if applicable, the profiling determination, and the approval authority. One page, defensible, updatable.
Integrate classification into your AI governance intake workflow and connect it to your AI Impact Assessment process. For organizations operating in the EU, coordinate with legal and compliance on Article 6(3) positions and build the EU database registration step into your deployment checklist. Classification records should be version-controlled alongside the system documentation — market surveillance authorities can request them, and the reasoning must be current, not just accurate at the time of the original assessment.
The AI Governance Advisor at app.aipmo.co can walk through risk classification for your specific project context, including whether Article 6(3) applies to your use case.
Framework References
EU AI Act (Regulation (EU) 2024/1689) — Article 5 (prohibited practices), Article 6 (classification rules for high-risk systems, Article 6(3) downward self-classification conditions, profiling override), Articles 8–17 (high-risk compliance obligations), Article 49(2) (EU database registration), Article 50 (limited-risk transparency obligations), Article 80 (market surveillance challenge), Article 99 (penalties). Core framework for all four tiers and the Article 6(3) mechanism.
EU AI Act Annex III — Eight high-risk use-case categories: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice. Reference for Annex III scope determination.
NIST AI Risk Management Framework 1.0 (NIST AI 100-1, 2023) — GOVERN 1.1, MAP 1.1, MAP 1.5, MAP 2.1. Complementary governance layer for risk tolerance, context establishment, intended use specification, and go/no-go framing for projects regardless of EU jurisdictional scope.
This article is part of AIPMO’s Frameworks series. See also: AI Impact Assessments | EU AI Act Timeline | The PM’s Guide to NIST AI RMF | ISO 42001 for Project Managers