EU AI Act Compliance Checklist: Risk Tier Playbook 2026

The EU AI Act compliance checklist by risk tier is the operating artefact that turns a sprawling regulation into a workable program. Four tiers — unacceptable, high, limited, minimal — set the obligation depth; a separate stack covers general-purpose AI models. Classifying a system to the right tier is the cheapest decision in the entire program and the one teams most consistently get wrong in both directions.

The regulation applies extraterritorially. Providers and deployers located outside the European Union are still in scope when the output of an AI system is used in the EU, when the system is placed on the EU market, or when EU residents are subject to its decisions. That covers a substantial share of US, UK, and APAC-headquartered SaaS, agency, and enterprise platforms. The practical question is not whether you are in scope — for most companies serving any EU customer, you already are — but which tier each system lands in and what the resulting control set looks like.

This guide walks the four-tier classification, the high-risk obligation stack that drives roughly thirty of the fifty checklist items, the lighter-touch limited-risk transparency rules, the separate general-purpose AI obligations that affect foundation- model providers, a decision tree for correct tier assignment, and the consolidated 50-point checklist sorted by tier. The audience is the cross-functional team — legal, security, product, engineering — that has to operate the program rather than the team that has to brief the board.

The EU AI Act is the first comprehensive horizontal regulation of AI in any major jurisdiction. It applies a risk-based framework with tiered obligations, civil penalties that scale to a percentage of worldwide turnover, and an enforcement architecture that includes a new EU AI Office plus member-state market- surveillance authorities. For most teams the first question is whether the regulation applies at all — and the answer is yes far more often than vendors expect.

Three triggers bring a non-EU provider into scope. First, placing an AI system on the EU market — the same surface that triggers CE-marking obligations on physical goods. Second, the output of an AI system used in the EU — which covers cross-border SaaS where the model itself runs outside the EU but its decisions land on an EU resident. Third, AI systems used by EU-established deployers regardless of where the system was built. The combined surface is large enough that most B2B SaaS with any European footprint should assume in-scope and reason from tier.

The penalty structure is what makes classification matter. Unacceptable-tier violations attract the highest fines — up to seven percent of worldwide annual turnover or thirty-five million euros, whichever is higher. High-risk obligations attract up to three percent or fifteen million euros. Misleading information to authorities sits at one and a half percent or seven and a half million. The penalty curve is steep enough that mis-classifying a low-risk system as high-risk produces wasted spend, while mis-classifying a high-risk system as limited produces fine exposure that dwarfs the saved control cost by an order of magnitude.

The enforcement timeline phases in obligations across roughly three years from entry into force. Prohibited-practice provisions are the earliest enforced; high-risk obligations phase in over a longer window to give industry time to build conformity-assessment pipelines; GPAI obligations have their own timeline. The phased approach is helpful for planning but cuts both ways — by the time the latest obligations bind, the earliest have been in force long enough that “we are still preparing” is no longer a defensible posture. A quarterly compliance cadence anchored to the enforcement-date roadmap keeps the program moving with the deadlines rather than against them.

For deeper context on the legislative architecture and US implications specifically, our earlier EU AI Act primer for US businesses and the broader European business compliance guide cover the legal and operational background. This playbook assumes the reader has decided the regulation applies and is scoping the control program.

The classification model is the spine of the Act. Every AI system in scope falls into one of four tiers, and the tier determines whether the system can be placed on the EU market at all, what obligations attach if it can, and what evidence the provider must maintain to demonstrate compliance. The four tiers cover an enormous range of capability — from a banned social-scoring system at one end to a spam filter at the other — and the right classification is rarely obvious for systems that fall in the middle band.

The matrix below summarises the obligation depth at each tier. Read it as a scoping tool: locate the system in the matrix, then expand the controls in the sections that follow.

Two structural points get lost in summaries of the four-tier model. First, the classification is per-system, not per-vendor — a single vendor may operate systems across all four tiers and must run the appropriate program for each. Second, the tier depends on intended purpose plus deployment context, not on the underlying model technology. The same large language model can power a tier-4 spam summariser and a tier-2 employment screening tool; the system, not the model, is classified.

The classification mistake teams most consistently make is collapsing limited-risk into high-risk out of caution. A customer-support chatbot that answers questions about order status is a tier-3 limited-risk system with a transparency obligation — “you are chatting with an AI assistant” — and effectively no further high-risk apparatus. Running a full thirty-control program against it burns budget that should go to systems that genuinely sit in tier 2. The classification tree in Section 06 is designed to keep these from creeping up the tier ladder by default.

High-risk obligations are the heaviest stack in the Act and the section where most compliance budget actually lands. Five operational pillars structure the work: risk management, technical documentation and record-keeping, human oversight, accuracy and robustness, and post-market monitoring. Each pillar maps to a cluster of controls; together they make up roughly thirty of the fifty checklist items in Section 07.

The grid below summarises the five pillars and the artefact each one produces. Treat the artefact column as the evidence a market-surveillance authority would request — if you cannot produce it on a week's notice, the pillar is not yet operational.

Two procedural milestones bracket the operational pillars. Before a high-risk system is placed on the market or put into service, the provider must complete a conformity assessment — internal control for most Annex III systems, third-party notified-body assessment for biometric identification systems and certain product-safety cases. The assessment produces an EU declaration of conformity and authorises the CE marking. The system is then registered in the EU database for high-risk AI systems, a publicly searchable register run by the Commission.

After deployment, the obligation surface continues. The provider maintains technical documentation for ten years after the system is placed on the market. The post-market monitoring plan runs for the operational life of the system. Serious incidents and malfunctions that constitute a breach of EU fundamental-rights law obligations must be reported to the relevant authority, with timelines that vary by severity. The deployer, separately, carries duties around fundamental-rights impact assessment for certain public-sector and essential-services use cases.

The limited-risk tier covers systems with specific transparency duties but none of the high-risk operational apparatus. Four categories fall here in practice: AI systems intended to interact with natural persons (chatbots, voice assistants), emotion-recognition or biometric-categorisation systems outside prohibited contexts, AI systems generating or manipulating synthetic image, audio, or video content (deep fakes), and AI systems generating or manipulating text published with the purpose of informing the public on matters of public interest.

For each category the obligation is to ensure the affected person knows. A chatbot must disclose that the user is interacting with AI unless the context makes it obvious. Synthetic content must be labelled as artificially generated or manipulated, in a clear and distinguishable manner, with limited exceptions for evidently artistic, satirical, or similar contexts. Emotion-recognition systems must inform the persons exposed to them. The compliance work is substantially lighter than high-risk — but the disclosure has to actually surface in the user experience, not just sit in a terms-of-service page.

The provider-deployer split is sharper at this tier than at high-risk. The provider builds the labelling capability into the system; the deployer operates it in the surface where the user sees the content. A SaaS that generates AI images is the provider and embeds the C2PA-style provenance marker; the agency that uses the SaaS to produce a campaign is the deployer and surfaces the “AI-generated” label in the campaign asset. Both have obligations; the boundary between them gets tested when content leaves one platform and travels to another that strips the metadata.

Pragmatic implementation note: design the disclosure into the user experience early. Retrofitting an “AI assistant” label into a mature chatbot UX is harder than shipping it from the first sprint, and the retrofit invariably sparks UX debates that delay launch. Treat the limited-risk disclosure as a default UX pattern, not an afterthought.

General-purpose AI models — foundation models capable of performing a wide range of distinct tasks regardless of how they are placed on the market — carry their own obligation stack under the Act, distinct from the application-tier classifications above. The stack applies to model providers; downstream deployers that integrate a GPAI model into an application are subject to the application-tier rules for the integrated system in addition to passing through model-level documentation from the provider.

Two GPAI sub-tiers exist. Standard GPAI models — Llama-class and Mistral-class open or closed releases below the systemic- risk compute threshold — carry documentation, transparency, and copyright obligations. Systemic-risk GPAI models, defined today by training compute above ten-to-the-twenty-five floating-point operations, carry the standard obligations plus additional model-evaluation, adversarial-testing, incident- reporting, and cybersecurity duties. The Commission can designate further models as systemic-risk based on capability and reach.

For downstream deployers integrating a GPAI model, the practical workflow is to request the provider's technical documentation package — typically delivered as a model card plus a technical-documentation annex — and to use that documentation as the upstream input to the integrated system's own conformity assessment if the integrated system is high-risk. The Code of Practice for GPAI providers, currently in development under the EU AI Office, is the interpretive guidance that fills in implementation detail ahead of regulatory clarification.

Two operational notes for deployers. First, do not assume the GPAI model provider has cleared every documentation obligation just because the model is on the EU market — some of the highest-profile providers have published model cards substantially less detailed than what the Act's Annex IX anticipates. The deployer's own compliance position depends on the package received from upstream. Second, the training-content summary obligation produces an artefact that most downstream rights-holder requests will reference; the summary is the document the deployer points to when an EU publisher or creator asserts that copyrighted material was used in training.

The decision tree below is the operational tool teams use to assign tiers when scoping a new system or when re-classifying an existing one. Walk the questions in order — the first “yes” lands the tier. The questions are framed to surface the misclassification patterns we see most often in audits: cautious legal teams pushing limited-risk systems up into high-risk, engineering teams under-classifying systems that touch Annex III use cases, GPAI providers ignoring the separate stack because their downstream deployers are doing the application-tier work.

Two procedural disciplines make the tree work in production. First, the classification reasoning is documented and signed — a one-page memo per system that names the tier, walks the tree, cites the relevant article or annex, and identifies the system owner. The memo is what an auditor reads; the tier label alone is not evidence. Second, classifications are revisited at quarterly cadence and on-trigger. The triggers are change of intended purpose, change of deployment context, change of the underlying model, or any material change to the user surface — any of which can push a system between tiers.

The Article 6(3) derogation deserves a flag. For Annex III systems performing narrow procedural tasks or improving the result of previously completed human activity, a derogation from high-risk classification is available — but only with documented justification and registration. The derogation is narrower than vendors hope and the documentation burden is real; default to in-scope unless a qualified legal review agrees the derogation applies on the specific facts.

The consolidated 50-point checklist below sorts the implementation surface by tier-weighted priority. The bars show the cumulative obligation weight at each tier — high-risk absorbs roughly thirty controls, GPAI a further ten, limited- risk five, the program-level governance scaffolding five. The bars are a scoping aid, not a literal control count; the point is the shape of the program, not the exact arithmetic.

Read the bars as a budgeting tool. If the system landed in tier 2 in Section 06, expect to scope thirty controls plus program scaffolding. If the system landed in tier 3, scope five controls plus scaffolding. If you are a GPAI provider as well as an application provider, expect to stack the GPAI block on top of the application-tier block. The fastest way to over-spend on EU AI Act compliance is to scope every system as tier-2 by default; the fastest way to under-deliver is to scope a true tier-2 system at tier-3 depth.

The orange bars mark obligation clusters — the visual aim is to read the shape of the program at a glance and to plan staffing accordingly. The high-risk pillars are where most of the engineering, security, and legal work lands. The program-scaffolding cluster is the meta-governance work that applies whether the portfolio contains one tier-2 system or forty; building this first is what makes the per-system cluster work tractable. Without an AI inventory and a classification memo template, the first thirty-control scoping exercise reinvents that scaffolding for itself and the second redoes the same work for the next system.

For organisations standing up an Act program from cold start, the practical sequence is: inventory → classify → program scaffolding → pillar-by-pillar build for the highest-tier system → roll the pattern to the next system. Trying to lift every system through every pillar in parallel is the anti-pattern; the program drowns in cross-cutting work and never gets the first system audit-ready. The compounding pattern of running a Stage 8 governance loop alongside the Act program — described in our agentic AI governance templates — is the cheapest way to keep the Act program from becoming a parallel-track ceremony detached from operating reality.

A separate dimension that interacts with Act compliance is data residency and processing geography. Several high-risk and GPAI obligations interact with where training data, user data, and model inference physically sit; the architectural choices that make residency tractable also tend to make the Act's documentation easier to maintain. Our AI data residency architecture patterns covers the deployment models that pair best with EU AI Act programs.

For organisations that want the program delivered rather than self-built, our AI transformation engagements include EU AI Act program setup — inventory, classification, scaffolding, pillar build, conformity preparation, and handover to the in-house team for steady-state operation.