€35M / 7% Max fine for prohibited AI practices | 57% of C-suite leaders cite AI regulatory non-compliance as their top AI risk | 14% of CEOs believe their AI systems actually operate in compliance with regulations |
Most compliance officers I speak to are asking the same question: “which of our AI tools actually fall under the EU AI Act?” That’s the right question. But the answer most teams arrive at is wrong; not because the law is unclear, but because they are classifying AI tools by what the vendor calls them rather than by how they are being used. The risk tier depends on use case, not tool category. That distinction is where EU AI Act compliance either works or fails. This guide gives you the classification framework to tell the difference: the four tiers precisely defined, all eight Annex III sectors with enterprise examples, the four-question decision process, your specific obligations as a deployer, and a register structure that connects to your GDPR RoPA and DORA ICT register.
Important Note |
This article is for informational and compliance orientation purposes only. It does not constitute legal advice. Classification decisions for specific AI systems should be reviewed with qualified legal counsel familiar with your deployment context and applicable national guidance. |
The Four Risk Tiers - Precise Definitions
The EU AI Act structures regulatory obligations around a four-tier risk pyramid. The point compliance officers most often miss: the risk tier of an AI system depends on the use case and deployment context, not just the tool category. The same large language model can be minimal risk in one deployment and high risk in another. AI risk classification follows the intended purpose as actually deployed, not the vendor's generic product description.
PROHIBITED Article 5 | AI practices that pose unacceptable risks to fundamental rights, safety, and democratic values. Banned in the EU with no exemption for private actors. Prohibited practices became enforceable on 2 February 2025.
|
HIGH RISK Article 6 + Annex III | AI systems that can significantly affect health, safety, or fundamental rights. Subject to the full obligations of Chapter 3 (Articles 8–15) and deployer obligations under Article 26. Two pathways to high-risk classification exist: (1) safety components of Annex I products requiring third-party conformity assessment, and (2) AI systems listed in Annex III.
|
LIMITED RISK Article 50 | AI systems that interact directly with natural persons or generate synthetic content. Lighter obligations focused on transparency - ensuring users know they are interacting with AI. No conformity assessment required.
|
MINIMAL RISK No mandatory obligations | The majority of currently deployed AI tools - spam filters, recommendation engines, most productivity tools - fall here. No mandatory obligations under the AI Act. The European AI Office and member states may encourage voluntary Codes of Conduct for these systems.
|
Key Nuance: Use-Case Dependency |
An AI writing assistant used for internal marketing content = Minimal Risk. The same AI writing assistant used to generate judicial decisions or political campaign materials targeting voters = potentially High Risk (Annex III §8) or Prohibited (Article 5(1)(b)). A generative AI chatbot on your public website = Limited Risk (Article 50 transparency obligations). The same chatbot integrated into a benefits eligibility workflow that influences payment decisions = High Risk (Annex III §5). Risk classification follows intended use in deployment - not the tool's technical capabilities. |
Annex III - The Complete High-Risk Sector List
Annex III of Regulation (EU) 2024/1689 lists the eight sector categories whose AI use cases are presumptively high-risk under Article 6(2). An AI system listed in Annex III is considered high-risk unless the provider documents a reasoned assessment that it does not pose a significant risk to health, safety, or fundamental rights (Article 6(3)).
For deployers, the obligation runs in the other direction: you must assess whether the specific purpose for which you use a third-party AI tool brings it within Annex III. The vendor's classification does not bind you - if you use a general-purpose model for a purpose that falls within one of the eight sectors below, you must apply the high-risk controls regardless of how the tool is marketed.
“In almost every AI tool audit we run, we find at least one tool that the compliance team has marked as minimal risk, that is operating in a high-risk context. The common culprit: HR tools used for performance ranking, or a general-purpose AI used for credit-adjacent decisions. The vendor never said it was high-risk, so nobody asked the question. The Act requires you to ask the question. That’s the whole point of Annex III.” - Ankur Arora, Co-founder, Montro
SI. No | Sector | Qualifying Scope | Enterprise-Relevant Examples |
1 | Biometrics | Remote biometric identification, biometric categorisation based on sensitive attributes, emotion recognition systems. | 1. Facial recognition in retail/security settings 2. Emotion-detection software in hiring video interviews 3. Real-time biometric ID systems in publicly accessible spaces |
2 | Critical Infrastructure | AI as safety components in digital infrastructure, road traffic, water, gas, heating, electricity supply. | 1. AI managing power grid load-balancing decisions 2. Automated traffic control systems on motorways 3. Predictive maintenance AI for water treatment plants |
3 | Education & Vocational Training | AI determining access to education, evaluating learning outcomes, or proctoring examinations. | 1. Automated student admissions scoring tools 2. AI-proctoring platforms monitoring online exams 3. Systems predicting student dropout risk and course placement |
4 | Employment & Worker Management | AI for recruitment, CV screening, performance evaluation, promotion decisions, and workforce management. | 1. ATS/CV-parsing tools ranking candidates before human review 2. Productivity monitoring software making dismissal recommendations 3. AI-driven shift-scheduling systems affecting worker terms |
5 | Essential Private & Public Services | AI determining eligibility for credit, insurance, social benefits, healthcare triage, or emergency dispatch. | 1. Automated credit-scoring engines for loan approvals 2. Insurance pricing algorithms using health or behavioural data 3. Benefits eligibility systems for social welfare payments |
6 | Law Enforcement | AI predicting criminal risk, evaluating evidence reliability, profiling individuals in criminal investigations. | 1. Predictive policing tools assessing recidivism risk 2. Lie-detection or polygraph-equivalent AI tools 3. Facial recognition used in post-event crime investigation |
7 | Migration, Asylum & Border Control | AI assessing migration risk, verifying documents, processing asylum applications or visa decisions. | 1. Automated visa-application risk-scoring systems 2. AI reviewing authenticity of travel documents 3. Border control systems assessing irregular migration risk |
8 | Administration of Justice & Democratic Processes | AI assisting judicial authorities in interpreting facts or law; AI influencing election outcomes or voter behaviour. | 1. Legal research tools directly informing judicial rulings 2. AI used in alternative dispute resolution 3. Systems designed to predict or influence electoral behaviour |
Source: Regulation (EU) 2024/1689, Annex III - official text, 13 June 2024 | artificialintelligenceact.eu/annex/3/
8 Sectors in Annex III | 35–45% Companies already using AI in hiring (an Annex III §4 use case) | 10 years Retention period for Annex IV technical documentation |
The Classification Decision Process - Four Questions
The classification decision follows a structured logic that resolves every AI system into one of the four tiers. Working through these questions in sequence - and documenting your reasoning for each - produces both the classification outcome and the audit trail regulators expect.
Question 1: Is the AI practice listed under Article 5?
Article 5 lists AI practices that are prohibited outright. Review the specific sub-paragraphs, not just headings. Emotion recognition software in a workplace, for example, is prohibited under Article 5(1)(f) - regardless of whether HR teams consider it a productivity tool. If the answer is yes to any Article 5 condition, deployment must cease. There is no compliance pathway to unlock a prohibited practice.
Question 2: Is the use case listed in Annex III?
If the system is not prohibited, assess whether your specific use case falls within any of the eight Annex III sectors. Focus on the use case as you have actually configured and deployed the tool - not on the vendor's intended use. An AI system performs profiling of natural persons? The AI Act mandates it must always be treated as high-risk (Article 6(3), third sub-paragraph), regardless of the sector analysis.
Note also Article 6(3): even within Annex III, an AI system is not high-risk if it (a) does not pose a significant risk of harm; (b) performs narrow procedural tasks; (c) does not materially influence a decision outcome; or (d) performs only preparatory assessment. Providers invoking this exemption must document their assessment.
Question 3: Does the system interact with users or generate user-visible content?
If the system is not high-risk, determine whether it generates content directed at natural persons - through chat, synthetic images, voice, or video. If yes, Article 50 transparency obligations apply. Users must be informed they are interacting with AI. Synthetic content must be labelled. This applies to the vast majority of chatbots, AI assistants, and generative AI tools deployed in customer-facing contexts.
Question 4: Document the classification and assign ownership
Every classification - including minimal-risk determinations - should be documented. For Annex III systems, Article 6(4) requires the provider to document a non-high-risk assessment before market placement. As a deployer, your classification register (see Section 5) serves as the equivalent record for your deployment decisions. Update the classification whenever the intended use changes.
Deployer-Specific Classification Obligations
The EU AI Act draws a sharp distinction between providers (developers who place AI on the market) and deployers (organisations that use AI in a professional context). For most enterprises, the relevant role is deployer. Your AI governance obligations differ materially from those of the provider - but they are not optional.
The Same Tool, Different Tiers for Different Deployers |
Scenario A: A bank deploys a general-purpose AI model to summarise internal meeting notes. → Minimal Risk. No Annex III use case. No mandatory obligations. Scenario B: The same bank integrates the same model into its credit underwriting workflow to support loan approval decisions. → High Risk (Annex III 5: access to essential services - credit). Full Article 26 obligations apply. The tool did not change. The deployment context and intended purpose determined the classification. |
Article 26 Obligations for Deployers of High-Risk AI Systems
When your classification confirms a high-risk use case, Article 26 of the AI Act sets out what you must do as a deployer. Classification itself is not deadline-dependent - a use case is high-risk or it isn't, regardless of when the corresponding Article 26 obligations become enforceable, and that enforcement timing has shifted since the Act's original text (Annex III deployer obligations now apply from 2 December 2027, following the Digital Omnibus on AI). The classification work below holds either way:
- Use the system strictly in accordance with the provider's instructions for use (Article 26(1))
- Assign and ensure competent human oversight throughout operation - do not over-automate high-risk decisions (Article 26(2))
- Ensure input data is relevant and sufficiently representative where you control data inputs (Article 26(4))
- Monitor system performance and report serious incidents or risks to the provider and relevant authorities (Article 26(5))
- Retain automatically generated logs for a minimum of six months where accessible to you (Article 26(6))
- Inform workers and workers' representatives when high-risk AI is deployed in the workplace (Article 26(7))
- Notify individuals subject to AI-assisted decisions, and cooperate with regulators on enforcement actions (Article 26(9)–(10))
- Conduct a Fundamental Rights Impact Assessment (FRIA) before deployment if you are a public body or if the system falls within certain regulated categories (Article 27)
When a Deployer Becomes a Provider
Article 25 creates an important transition rule. If you modify a high-risk AI system beyond its intended purpose, or develop a new high-risk AI system on top of a general-purpose AI model, you may be treated as a provider - triggering the full Chapter 3 obligations (risk management system, Annex IV technical documentation, conformity assessment, CE marking, EU database registration). Compliance officers should flag any in-house customisation of AI tools for legal review before deployment.
Building a Classification Register
A classification register is the starting point of your EU AI Act compliance programme. It serves the same function that a Record of Processing Activities serves under GDPR, a continuously maintained AI risk classification record that maps your AI tools to their regulatory obligations. For organisations subject to DORA, the classification register should be built as an extension of your ICT Third-Party Risk Register, with AI-specific fields added.
What Montro’s Classification Register Reveals in Practice |
The classification register that Montro produces at the end of a discovery exercise almost always contains tools that have been in production for six to twelve months already. The classification is accurate, but the Article 26 controls were not in place during that period. Classification is supposed to happen before deployment, not after. But in practice it happens when someone from the compliance team decides that it needs to happen, which is usually after the tools are already running. The register closes the gap going forward, but it does not address the exposure that accumulated before the exercise ran. This is not a reason to delay the exercise, but rather a good reason to start the exercise before the next tool goes into production. |
“In every GDPR audit, the first thing a regulator asks for is the Article 30 RoPA. Under the EU AI Act, the first thing they will ask for is evidence of your classification process - how did you determine a tool was minimal risk, and who signed off on it? A register that cannot answer those questions is not a register. It’s a spreadsheet of guesses.” - Namita Razdan, Co-founder, Montro
Classification Register: Template Structure
Field | Description | Connects To |
AI System Name | Tool name, version, vendor | DORA ICT Asset Register |
Intended Use Case | How your organisation actually uses it | GDPR RoPA - processing activity |
Annex III Sector (if any) | Which sector (1–8) applies or N/A | Risk tier outcome |
Risk Tier | Prohibited / High / Limited / Minimal | Compliance workstream trigger |
Classification Rationale | Use-case analysis + Article 6(3) assessment | Annex IV technical documentation |
Provider Documentation | CE marking, conformity docs, Art. 13 instructions | Third-party contract schedule |
Deployer Controls | Human oversight measures, input data governance | Article 26 obligations log |
Log Retention | Auto-generated logs stored ≥ 6 months | DORA incident register |
FRIA Required? | Fundamental Rights Impact Assessment (public/certain deployers) | GDPR DPIA cross-reference |
Review Date | Date of next classification review | Annual governance cycle |
Who Owns the Register?
The classification register should be owned jointly by the DPO (for the GDPR/RoPA alignment), the CISO or IT risk function (for the DORA ICT register alignment), and legal/compliance (for the classification rationale). In practice, the AI Governance lead or a designated AI Officer should be the day-to-day owner responsible for keeping it current.
Connecting to DORA and GDPR
For organisations in scope for DORA (financial entities from January 2025), Article 28 requires documentation of ICT third-party service providers and their dependencies. AI systems from third-party vendors are ICT services; the EU AI Act classification field should be added as a column in your existing DORA register rather than maintained as a separate artifact. Similarly, where an AI system processes personal data, the EU AI Act classification feeds directly into the GDPR Article 30 Record of Processing Activities - the risk tier informs whether a DPIA is required and what measures are documented under your accountability obligations.
Annex IV Documentation Fields - What High-Risk Systems Must Have |
Before classifying a system as high-risk and proceeding to deployment, confirm the provider has supplied documentation covering the nine Annex IV mandatory sections:
Source: Annex IV, Regulation (EU) 2024/1689. Retain documentation for 10 years (Article 18). |
Frequently Asked Questions
Can the same AI tool have different risk classifications for different use cases within the same organisation?
Yes, and this is one of the most common classification errors in practice. The EU AI Act classifies AI systems by their intended purpose in a specific deployment context, not by the tool itself. A large language model used for internal document summarisation is minimal risk. The same model used to screen job applications is high risk under Annex III category 4. If your organisation uses one AI platform for multiple purposes, each use case requires its own classification assessment. A single register entry covering all uses of one tool is not sufficient.
What happens if a vendor classifies their tool as minimal risk but we use it in a way that would make it high risk?
The EU AI Act places the classification obligation on the entity responsible for the specific use, and as a deployer, you are responsible for assessing whether your use case brings the tool within Annex III, regardless of how the vendor has classified or marketed it. If your use falls within a high-risk category, Article 26 obligations apply to you from the moment the system is in live use. The vendor's classification does not transfer compliance responsibility for how you have chosen to deploy the system.
What is the Article 6(3) exemption and when does it apply?
Article 6(3) allows a provider to document that an Annex III AI system is not actually high risk if it meets one of four conditions, it does not pose a significant risk of harm, it performs only narrow procedural tasks, it does not materially influence a decision outcome, or it performs only preparatory assessment. In practice, Article 6(3) assessments are typically made and documented by providers rather than deployers. As a deployer, if a vendor claims the exemption applies to their system, ask for the documented assessment, because if their assessment is wrong and your use case qualifies as a high-risk AI system under Annex III, the EU AI Act compliance gap sits with you in practice.
How does the classification register connect to our existing GDPR and DORA records?
They share the same underlying data requirement - a complete, current inventory of every system processing data or providing ICT services in your environment. For DORA, Article 28 requires documentation of ICT third-party service providers; AI tools from vendors are ICT services and the EU AI Act risk tier should be an additional field in your existing DORA register rather than a separate document. For GDPR, the risk classification informs whether a DPIA is required under Article 35 and what measures are documented under your accountability obligations. Building three separate registers for three frameworks is the least efficient approach, one inventory with framework-specific fields serves all three.
