EU AI Act Compliance Checklist: Risk Tier Playbook 2026

Four EU AI Act risk tiers — unacceptable, high, limited, minimal — set the obligation depth, and a separate stack covers general-purpose AI models. After the Digital Omnibus, the dates are: prohibited practices since 2 February 2025, GPAI duties since 2 August 2025, Article 50 transparency since 2 August 2026, and high-risk duties from 2 December 2027 or 2 August 2028. 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, 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, a table of which date applies to which system, 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 a horizontal regulation of AI across every sector of the EU market. 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. Article 99 sets prohibited-practice violations at the highest fines — up to seven percent of worldwide annual turnover or thirty-five million euros, whichever is higher. Other obligation breaches attract up to three percent or fifteen million euros. Supplying incorrect or misleading information to notified bodies or competent authorities sits at one percent or seven and a half million. For SMEs the lower of the two figures applies, and the Digital Omnibus extended that to small mid-cap companies for the three-percent and one-percent tiers (new Article 99(6a)). 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 Act entered into force on 1 August 2024, and Article 113 staggers the application dates. Prohibited practices have applied since 2 February 2025 and GPAI model obligations since 2 August 2025. The general date, 2 August 2026, brought in the Article 50 transparency duties and the Commission's power to fine GPAI providers.

The high-risk dates moved. The Digital Omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026, rewrote Article 113. The high-risk requirements now apply from 2 December 2027 for Annex III systems (originally 2 August 2026, a 16-month delay) and from 2 August 2028 for AI that is a safety component of a product under Annex I (originally 2 August 2027, a 12-month delay). The delay is not a reason to pause: by the time the latest obligations bind, the prohibitions will have applied for three and a half years, and “we are still preparing” will not be a defensible posture.

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. They are not yet in application: under Article 113 as amended by Regulation (EU) 2026/1744, they apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product components. Five operational pillars structure the work: risk management, technical documentation and record-keeping, human oversight, accuracy and robustness, and post-market monitoring.

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 once the high-risk provisions apply. 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. Article 73 sets the serious-incident reporting limits: no later than 15 days after the provider becomes aware, 10 days where a person has died, and two days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. Article 73 sits outside the sections the Digital Omnibus deferred, but it applies to providers of high-risk systems, and the Article 6 rules that make a system high-risk now apply from the later dates; plan incident reporting to go live with them. 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. Article 50 names four categories: 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. These duties have applied since 2 August 2026.

The second category needs care. Annex III point 1(c) lists emotion recognition as high-risk, and point 1(b) lists biometric categorisation by sensitive or protected attributes where it is not banned outright. For those systems the Article 50 disclosure is an extra duty on top of the high-risk stack, not a substitute for it.

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 General-Purpose AI Code of Practice, which the Commission published in July 2025 according to its AI Act policy page (updated 3 August 2026), is the voluntary route providers use to show how they meet these duties. GPAI models placed on the market before 2 August 2025 have until 2 August 2027 to comply (Article 111(3)).

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 XI 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 tier tells you what to build; it does not tell you when. Since the Digital Omnibus, two systems in the same tier can face dates more than a year apart, and some dates depend on when the system first reached the market. The table maps each situation to its date and the article that sets it. Find every row that matches a system, then record the earliest date in the register next to its tier.

A worked example shows how the rows combine. Take an agency with three AI systems in EU use (an illustrative portfolio, not a client). System A is a customer-support chatbot launched in 2025. System B is an image generator the agency built and released to clients in March 2026. System C is a CV-screening tool it sells to EU employers, first placed on the market in January 2026.

System A falls under Article 50(1). That duty has applied since 2 August 2026 with no transition. If the chat window does not yet tell users they are talking to an AI, and that is not obvious from context, the agency is already out of compliance, and Article 99(4) puts Article 50 breaches in the €15 million or three-percent tier.

System B carries two duties with two dates. As provider, the agency must mark outputs in a machine-readable format under Article 50(2). Because B was on the market before 2 August 2026, Article 111(4) gives it until 2 December 2026. As deployer of B's images in client campaigns, it must label any deep fake under Article 50(4) now; the December extension covers only the marking duty.

System C is Annex III point 4 (recruitment and selection), so the high-risk stack applies from 2 December 2027: 16 months after the original 2 August 2026 date. Because C's type was on the market before that date, amended Article 111(2) applies. The high-risk obligations attach only if C's design changes significantly from 2 December 2027. A major new version shipped in 2028 needs conformity assessment, registration and the rest of Section 03 before release. If any customer is a public authority, full compliance is due by 2 August 2030 whatever happens to the design.

The result for this agency: two of its three systems have duties that apply before the end of 2026, and the one high-risk system is triggered by its own release plan after December 2027, not by the calendar alone. That is why the register records the date and its basis beside the tier, and why a planned major release of a high-risk system is a trigger for the quarterly review.

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 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.