The EU AI Act: Risk Tiers and Conformity Requirements
Deliberate Academy Editorial Team
Reviewed for accuracy and professional relevance
Enjoying the course?
Sign up free to track your progress and earn a verified certificate when you pass.
- Explain the EU AI Act's risk-tier structure and correctly classify a described AI system into the appropriate tier
- Identify the categories of use that trigger high-risk classification, and distinguish these from limited-risk transparency obligations
- List the core conformity obligations that attach to a high-risk AI system and explain what each is designed to demonstrate
- Apply appropriate hedging when describing implementation timelines and enforcement specifics for a regulation still in phased rollout
The EU AI Act is the first comprehensive, horizontal AI regulation from a major regulatory body, and it is the reference point most enterprise compliance teams are being asked to operationalize first. Its central organizing idea is proportionality by risk: the regulatory burden a system carries should scale with the potential for harm to individuals and society, not with how sophisticated or expensive the underlying model is. Understanding the tier structure precisely — and being able to place a real system into the correct tier — is the single most consequential skill this course teaches, because every other compliance obligation in this course follows from that classification.
The Risk-Tier Structure
The Act organizes AI systems into four tiers.
Unacceptable risk (prohibited). A defined list of AI practices considered to carry risks so severe that they are banned outright, regardless of sector or claimed benefit. This tier is covered in detail in the next lesson.
High-risk. Systems used in specified sensitive domains — broadly, biometric identification and categorization, management of critical infrastructure, education and vocational training, employment and worker management, access to essential public and private services, law enforcement, migration and border control, and the administration of justice — or systems that function as a safety component of a product already regulated under existing EU product-safety law. High-risk systems are not banned, but they carry the Act's most extensive set of conformity obligations, covered later in this lesson.
Limited risk (transparency obligations). Systems that carry specific disclosure duties short of the full high-risk regime — most notably, systems that interact directly with people (such as chatbots) must generally make clear that a person is interacting with an AI system, and systems that generate or manipulate image, audio, or video content resembling real people, places, or events (synthetic or "deepfake" content) generally carry labeling obligations.
Minimal risk. The large majority of AI systems in typical enterprise use — internal productivity tools, most recommendation engines, spam filters, and similar applications — fall here. The Act does not impose mandatory obligations on this tier, though it encourages voluntary codes of conduct.
Treat the tier descriptions above as a structural map, not a verbatim legal text. The Act's phased implementation means different obligations become enforceable at different points after the regulation's entry into force, and the Act and accompanying guidance continue to be clarified by the European Commission, the AI Office, and national market surveillance authorities. Before you rely on a specific compliance deadline or a precise definitional boundary in a real classification decision, verify it against current official guidance or your legal counsel — do not rely on this lesson's tier descriptions as a substitute for the current regulatory text.
What Actually Triggers High-Risk Classification
The most common classification error compliance teams make is treating "high-risk" as a subjective judgment about how sophisticated or impactful an AI system feels, rather than the specific, enumerated-domain test the Act actually applies. A relatively simple AI tool that automates candidate ranking in recruitment is high-risk because of the domain it operates in — employment decisions — not because of how advanced its underlying model is. Conversely, a highly sophisticated AI system used purely for internal engineering productivity, with no bearing on decisions about individuals, is very likely minimal-risk, however impressive its capability.
Zest AI, a real credit-underwriting platform used by lenders to score loan applications, is a useful illustrative example: whatever model architecture sits underneath it, its use case — determining or materially influencing access to credit — is what places tools in that category into the high-risk domain of access to essential private services. The lesson for a compliance team is structural: classify by use case and decision domain first, and treat model sophistication as a secondary, largely irrelevant factor to the tier question.
Build your classification process around a decision tree, not a checklist of examples. Ask, in order: (1) Does this system's function fall on the prohibited-practices list? If yes, stop — it cannot be deployed in this form. (2) Does this system operate in one of the enumerated high-risk domains, or serve as a safety component in an already-regulated product? If yes, the high-risk conformity regime applies. (3) Does this system interact directly with individuals, or generate synthetic media? If yes, transparency obligations apply. (4) If none of the above, the system is very likely minimal-risk. Document the answer to each question, not just the final tier — the documented reasoning is what an auditor will actually ask to see.
A hospital deploys an AI tool that analyzes chest X-rays and flags likely abnormalities for a radiologist's review before the radiologist makes any diagnosis. Applying the decision-tree approach from this lesson, which classification is correct and why?
Select one answer.
The Conformity Obligations That Follow a High-Risk Classification
Once a system is classified as high-risk, a defined set of obligations applies. These are the components a compliance team must actually build and maintain — and each is designed to answer a specific question a regulator or auditor will ask.
Risk management system. An ongoing, iterative process — not a one-time assessment — that identifies and evaluates known and foreseeable risks the system could pose to health, safety, or fundamental rights, and defines mitigation measures. Answers the question: what could go wrong, and what are you doing about it?
Data governance. Requirements covering the quality, relevance, and representativeness of the data used to train, validate, and test the system, with particular attention to identifying and mitigating potential biases. Answers the question: is the data this system was built on fit for purpose, and have you checked for bias?
Technical documentation. A structured file describing the system's intended purpose, design choices, capabilities, limitations, and performance characteristics — typically referred to informally as the "technical file." Answers the question: what is this system supposed to do, and what do you know about how well it actually does it?
Record-keeping and logging. Automatic logging of the system's operation sufficient to trace its outputs and support post-deployment monitoring and, where necessary, investigation. Answers the question: can you reconstruct what this system actually did, after the fact?
Transparency and instructions for use. Clear information to the deploying organization about the system's capabilities, limitations, and appropriate conditions of use. Answers the question: does the organization actually operating this system understand what it is and is not reliable for?
Human oversight. Design and organizational measures that allow a human to meaningfully understand, monitor, and where necessary override or halt the system's output — not a nominal review step that rubber-stamps AI recommendations. Answers the question: can a human actually intervene, and is that intervention real?
Accuracy, robustness, and cybersecurity. Technical requirements that the system perform to an appropriate level of accuracy for its stated purpose and be resilient against errors, faults, and adversarial manipulation. Answers the question: does this system actually work reliably, and can it be attacked?
Conformity assessment and registration. A formal assessment — in some cases a self-assessment against the Act's requirements, in others requiring the involvement of an independent "notified body" — that must be completed before the system is placed on the market or put into service, generally accompanied by registration in an EU database and CE marking to indicate conformity.
Classifying and Documenting a Loan Underwriting Tool — Mid-Size Consumer Lender
Context
A consumer lender used a machine-learning underwriting tool, built partly on a licensed third-party credit-scoring model, to generate an approve/decline recommendation for personal loan applications under €25,000. A loan officer reviewed each recommendation before a final decision, but the review took an average of 40 seconds per application across a sample the compliance team pulled — far too short to constitute a substantive independent assessment on anything but the most obviously anomalous cases.
Action
The Chief Compliance Officer ran the tool through the domain classification and confirmed high-risk status on the basis of its function in determining access to credit. She then commissioned a gap assessment against each of the core conformity obligations. The data governance review found that the training data underrepresented applicants from two of the four countries the lender operated in, creating a plausible unrepresentativeness gap. The human oversight review found that the 40-second average review time was inconsistent with a genuine oversight function, and redesigned the workflow so that borderline-scored applications — not just outlier ones — were routed to a loan officer with a structured checklist and a minimum review-time expectation.
Outcome
The technical file, data governance remediation plan, and redesigned human oversight workflow together closed the four most material conformity gaps identified in the assessment. The compliance team also implemented log-based monitoring that could reconstruct, for any given application, which score the model produced, what the loan officer's review recorded, and what the final decision was — creating the audit trail that had not previously existed. The Chief Compliance Officer's assessment was that the technical work of closing these gaps took roughly ten weeks with a small cross-functional team, once the classification itself was correctly established.
General-Purpose AI Models Sit Alongside, Not Instead Of, This Framework
Foundation or general-purpose AI models — the kind of large language models that power tools like ChatGPT, Claude, and Microsoft Copilot — carry a separate set of obligations under the Act aimed at the organizations that build and release those models, covering matters like technical documentation of the model itself and, for the most capable models, systemic-risk assessment. For most compliance teams reading this course, the more immediate and frequent question is not "are we a general-purpose AI model provider" but "are we a deployer building a specific application on top of one" — and deployer obligations are generally driven by the use case's own risk tier, exactly as described above, regardless of which underlying model powers it. A customer-service chatbot built on a general-purpose model is still assessed, as a deployed system, against the same tier structure — most commonly landing in the limited-risk transparency tier because it interacts directly with people.
A company builds an internal tool on top of a general-purpose AI model to summarize long documents for its own staff, with no external users and no role in any decision about an individual. According to the framework in this lesson, what is the most likely risk-tier classification, and why?
Select one answer.
Exercise
Your Task
Take three AI systems from your organization (or a plausible organization) and run each through the four-question decision tree from this lesson: (1) prohibited-practices check, (2) high-risk domain or regulated-product safety-component check, (3) direct interaction or synthetic-media check, (4) default minimal-risk. For each system, write one sentence documenting the answer to each question and the resulting tier. For any system you classify as high-risk, list which of the eight core conformity obligations are already in place and which are gaps.
Success looks like
- Each system has a documented answer to all four decision-tree questions, not just a final tier label
- At least one system is correctly identified as high-risk with a specific domain justification, not a vague sense that it "seems important"
- For the high-risk system, the gap list names specific missing obligations (e.g. "no technical file exists" or "human oversight review time is not tracked") rather than a general statement that "more governance is needed"
Watch out for
- Classifying a system as high-risk or minimal-risk based on how advanced or well-known its underlying model is, rather than its use-case domain
- Treating "a human reviews the output" as automatically satisfying the human oversight obligation without checking whether that review is substantive
- Skipping the documentation of your reasoning — an undocumented classification decision provides no audit value even if the final tier happens to be correct
Hint
Start with any system involved in employment, credit, insurance, benefits eligibility, or biometric processing — these are the domains most likely to produce a high-risk classification and the most valuable ones to practice the full conformity gap analysis on.
- The EU AI Act organizes systems into four tiers — unacceptable/prohibited, high-risk, limited-risk (transparency), and minimal-risk — with obligations scaling to the tier, not to how sophisticated the underlying model is.
- Classification is driven by use-case domain, not model capability — a simple tool used in employment, credit, or biometric decisions can be high-risk, while a highly capable tool used for internal productivity is very likely minimal-risk.
- A high-risk classification triggers eight core categories of conformity obligation: risk management, data governance, technical documentation, record-keeping, transparency to deployers, human oversight, accuracy/robustness/cybersecurity, and conformity assessment with registration.
- Human oversight must be substantive, not nominal — a review step that takes seconds per decision and never overrides the AI recommendation does not satisfy the obligation, and is one of the most common conformity gaps compliance teams find.
- Deployer obligations for tools built on general-purpose AI models such as ChatGPT, Claude, or Copilot follow the tier of the specific deployed use case — always run the same decision tree regardless of which underlying model powers the application.