Risk Classification Under the EU AI Act: A Practical Guide

Regulators and enterprise buyers ask three questions in the same order: what does this AI system do, which risk tier does it fall under, and what obligations follow. Your answer to the second question — the risk tier — anchors everything that comes after: what documentation the file needs to contain, what engineering controls to build, whether enterprise procurement teams require further evidence, and what the penalty tier is if the answer is wrong. This guide covers the two-step test, the four risk tiers with real consequences for each, the borderline cases that do not land cleanly in any single bucket, and what a documentation record looks like that an audit team can work through without a follow-up call.

Timeline

The Act applies in phases. The deadline that matters depends on which tier the use case lands in.

August 2024 — The Act entered into force.

August 2, 2025 — GPAI model governance (Articles 53 and 55): technical documentation, copyright policy, training data summary. Commission fines up to 3% of global turnover or €15M. This is already live. If your company uses or fine-tunes a foundation model, the documentation must be produced before the model is made available on the EU market. The obligation applies regardless of whether a document exists yet.

August 2, 2026 — AI literacy requirements, transparency obligations (chatbot disclosures, deepfake labeling), logging, and basic deployer obligations.

August 2, 2027 — The full Annex III package: risk management framework, data governance controls, technical documentation, CE marking, EU Declaration of Conformity, registration in the EU AI database. €35M or 7% of global turnover, whichever is higher, is the penalty band for violations at this tier.

If your product is a safety component in a regulated product — a medical device, a vehicle control system, machinery, toys, aviation, marine — the obligation flows from the EU product safety framework and the deadlines differ from the Annex III schedule above.

The two-step test

The framework layers four risk tiers against two roles. The interaction determines the obligation set. The test has two steps.

Step one — find your role. A provider develops an AI system and places it on the market under their own name — building it in-house, fine-tuning a foundation model, or white-labeling an existing system. A deployer uses an AI system made by someone else in their professional operations. A single company can hold both roles across different AI systems simultaneously. An AI product offered to customers carries provider obligations. The same company running an internal AI tool for its own operations carries deployer obligations for that tool. They are separate records.

Annex I safety components — AI inside a medical device, for example — follow the EU product safety structure and do not use the Annex III numbering. Annex I timelines differ from Annex III.

Step two — find your tier. Using your role and your actual use case, determine whether the system falls into prohibited use, high-risk, limited-risk, or minimal-risk within the meaning of the Act. The common mistake is treating this as a binary question — “am I high-risk or not?” — when it produces an obligation set, and the set depends on which role maps to which part of the value chain.

Prohibited

Social scoring by public authorities, real-time biometric identification in public spaces, emotion recognition in workplaces or schools, manipulation through subliminal techniques, untargeted facial image scraping for building recognition databases. The Act prohibits all of these directly. There is no governance process, no supplementary data protection document, no risk mitigation plan that makes them tenable in the EU market. Do not deploy them.

High-risk

The full conformity assessment is required before the system goes to market. The Act splits high-risk into two buckets.

Annex I safety components. Medical devices, machinery, vehicles, toys, aviation, marine — if AI is used as a safety component, the obligation follows the EU product safety framework and applies on the Annex I schedule. The Annex III dates do not apply here.

Annex III use cases. Biometric identification and categorisation, critical infrastructure management, education and vocational training, employment and worker management decisions, access to essential services, law enforcement and crime prevention, migration and border control, and justice administration.

Most AI companies building products that touch any of these use cases are not prepared for what the assessment package requires. A language model used to pre-screen job candidates. A loan model used to approve or deny applications. A clinical decision support tool used alongside a clinician’s review. Each of these carries a conformity assessment obligation before the system goes to market.

For most Annex III categories, a self-assessment is permitted. A smaller subset requires assessment by a notified body — a third-party auditor accredited by an EU member state. Know which applies to your category before you write the document.

If you deploy or fine-tune a foundation model to produce a domain-specific product, you inherit documentation obligations under Article 25 that run separately from the upstream provider’s file. The upstream documentation covers their model. It does not cover your deployment.

Limited-risk

Chatbot interfaces, emotion detection outside the workplace and school prohibition, AI-generated images, audio, video, and deepfakes. The requirement is disclosure: users need to know they are interacting with a machine before they do. For generative AI video and audio, the signal needs to be visible at point of consumption. For most teams, this is interface work that ships with the first EU release — not a documentation exercise finished after launch.

Minimal-risk

Spam filters, inventory automation, video game AI, recommendation engines that do not influence decisions about people, internal tools used only inside your own company. No binding requirements. Spend ten minutes documenting the classification rationale anyway — if the use case shifts, you can update the document rather than rebuild it from scratch.

Borderline cases

The tier labels do not always land cleanly. These four patterns come up most often in practice.

An internal tool that crosses categories. A product with a customer-facing AI feature and an internal analytics dashboard is two systems from a classification standpoint. A copilot that summarizes customer communications — with nothing in the chain making decisions about people — is unambiguously minimal risk. The same copilot summarizing internal communications where the output feeds a performance review workflow is high-risk. One codebase, two obligation sets. The response “it’s internal, nobody will ever check” is also the answer that produces a regulatory request for documentation three months after the product ships.

Fine-tuning a foundation model. If you take a domain-specific version of an existing foundation model — a legal analysis tool, a clinical documentation assistant, a customer support copilot — and place it on the market under your own name, you are a provider under Article 25 and you carry your own documentation chain. The upstream model documentation covers their system. It does not cover your deployment context. The two files are separate.

A genuinely borderline Annex III use case. A tool that produces advisory outputs in an essential services context — a model that analyzes applicant materials but produces only a recommendation flag for a human reviewer — is genuinely harder to classify than most teams expect. The August 2027 deadline means you have room to resolve this before the compliance clock is running against you. Engagement with a national competent authority’s regulatory sandbox before launch, or a written opinion from counsel grounded in the Act, is the kind of evidence a procurement team accepts without further argument.

Separating advisory from the decision trigger. The line between “this output is advisory and a human reviews it” and “this output is the signal a human signs off on” is not self-evident from the UI. Regulators test whether the human reviewer is making an independent judgment or rubber-stamping the AI’s output. If you are designing a product in an Annex III use case, build the oversight UX so that the reviewer sees the confidence interval, has an override path, and produces a structured record. A file built to that design standard reads differently to an audit team than a file assembled from internal emails and logs after a request arrives.

Classification documentation

A classification record needs to survive a procurement review or an audit without needing a follow-up call. The minimum structure:

For providers. System name, your role (provider), the Annex III category or none, the obligation set that applies, whether any exception or reduced assessment basis applies, the risk management record — what the system does not produce, what harms it addresses and how, the technical documentation file reference, and an internal attestation. An out-of-date classification document is not useful. Update it when the use case changes.

For deployers. System name, upstream provider, your role (deployer), the Annex III category or none, the actual and intended deployment use case, confirmation that the provider’s technical file is available, documented human oversight steps — who implements them and what the escalation path is — and an incident log running in production with access on request.

Most teams build the incident log under pressure. Audit teams examine it first. Build it from the start: model versions, timestamps, input and output pairs per inference, confidence scores, and any human reviewer action. Structured and accessible.

The 15-day serious incident reporting window under Article 72 means a routine incident needs to produce an auditable record when the clock starts, not six weeks later when the deadline for response has already passed.