A step-by-step EU AI Act compliance checklist in question-and-answer form: scope, deadlines still ahead, risk classification, prohibited practices, GPAI, high-risk conformity, and role-by-role obligations for providers and deployers.
This guide answers the compliance checklist question in the order the questions actually arrive: does the Regulation reach me, what already binds me today, which of my systems are high-risk, what do I have to produce, and what does that cost me if I get it wrong. Every answer is scoped to a legal basis you can cite in an internal memo.
Who has to run this checklist?
Any organisation that develops, deploys, imports or distributes an AI system used in the EU — regardless of where it is established. Art. 2 reaches non-EU providers and deployers whenever the output produced by the system is used in the Union, which is why a US SaaS vendor with European customers is in scope on the same terms as a Frankfurt bank.
Four things determine your obligation set, and you need all four before the checklist means anything:
| Question | Determines |
|---|---|
| Did you build it, or do you use someone else's? | Provider or deployer (Art. 3, Art. 25) |
| Is it an AI system, or a general-purpose AI model? | Chapter III or Chapter V |
| Which Annex III or Annex I category does it fall in? | High-risk or not (Art. 6) |
| Does it interact with people or generate content? | Art. 50 transparency, independent of risk tier |
The last row is the one most inventories miss. Transparency duties attach to systems that are not high-risk at all — a customer-service chatbot on a marketing site carries an obligation today, and carried none of the conformity burden this checklist spends most of its time on.
Which obligations already bind you, and which are still ahead?
Four of the nine application dates have passed; the heavy conformity work lands in December 2027. The dates below follow the deadline dataset this site publishes, which reflects the deferrals made by Regulation (EU) 2026/1744.
| Obligation | Applies from | Status |
|---|---|---|
| Prohibited practices (Art. 5) | 2 February 2025 | In force |
| AI literacy (Art. 4) | 2 February 2025 | In force |
| GPAI model obligations (Chapter V) | 2 August 2025 | In force |
| Transparency obligations (Art. 50) | 2 August 2026 | In force |
| Commission enforcement over GPAI (Art. 101) | 2 August 2026 | In force |
| Marking of pre-existing generative systems | 2 December 2026 | Upcoming |
| Prohibition on generated CSAM / NCII | 2 December 2026 | Upcoming |
| Regulatory sandboxes operational | 2 August 2027 | Upcoming |
| High-risk — Annex III standalone systems | 2 December 2027 | Upcoming |
| High-risk — Annex I embedded systems | 2 August 2028 | Upcoming |
The Digital Omnibus moved four of these dates and rewrote Art. 4; the full before-and-after register is published at /changes/. It removed no obligation and created no exemption, so a programme built on the original dates is still the right programme — it simply has more runway.
Step 1 — Is your AI inventory complete?
Without a complete inventory, nothing downstream is defensible. Create a register of every AI system your organisation touches:
- AI systems you develop and sell or license (you are the provider)
- AI systems you purchase or license and use internally (you are the deployer)
- AI systems embedded in products you manufacture or import
- AI systems accessed via API from third parties (cloud AI, foundation model APIs)
For each: document the system name, function, data inputs and outputs, use context, decision impact, and affected population. Flag systems where you are uncertain of classification — these need legal review rather than an engineering answer.
Two categories are systematically under-counted: AI features shipped inside SaaS tools the business already pays for, and models built by individual teams outside the procurement process. Ask finance for the vendor list and engineering for the model registry; the union of the two is closer to the truth than either.
Step 2 — Is anything you run already illegal?
Check Art. 5 before any risk classification, because a prohibited system cannot be remediated into compliance. Assess each system against the list:
- Subliminal, manipulative or deceptive techniques that materially distort behaviour
- Exploitation of vulnerabilities due to age, disability, or social or economic situation
- Social scoring leading to detrimental treatment in unrelated contexts
- Untargeted scraping of facial images to build recognition databases
- Emotion inference in the workplace or in education
- Biometric categorisation to infer sensitive characteristics
- Real-time remote biometric identification in public spaces for law enforcement
→ Decommission or fundamentally redesign. These prohibitions have applied since 2 February 2025 and sit in the €35 million / 7% penalty tier. The prohibited practices guide covers the narrow exceptions that exist for each.
From 2 December 2026 a further prohibition covers AI systems generating child sexual abuse material or non-consensual intimate imagery.
Step 3 — Do you provide a general-purpose AI model?
If your organisation develops and releases a foundation model, Chapter V obligations have applied since 2 August 2025. Three tests:
- Is the model trained with self-supervision at significant scale?
- Is it capable of competently performing a wide range of distinct tasks?
- Is it made available to others, rather than used purely internally?
If yes, prepare model documentation for the AI Office and for downstream providers, a copyright policy, and a sufficiently detailed public summary of training content. Above 10²⁵ FLOPs of training compute the model is presumed to carry systemic risk, adding model evaluation, adversarial testing, incident reporting and cybersecurity duties. See the GPAI obligations guide for the full split.
Since 2 August 2026 the Commission — not national authorities — enforces this chapter directly, with fines up to €15 million or 3%.
Step 4 — Which of your systems are high-risk?
Classify against Annex III and Annex I, then apply the Art. 6(3) filter and write the result down. Annex III lists eight standalone categories: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice. Annex I catches AI acting as a safety component in products already regulated under EU product-safety law.
The Art. 6(3) exception releases a system that falls in an Annex III category but poses no significant risk — narrow procedural tasks, improving the output of a completed human activity, detecting decision patterns without replacing the human assessment, or purely preparatory work. It never applies where the system profiles natural persons. The assessment must be documented before market placement, and the system still has to be registered.
Classification decisions are the single most audited artefact in this checklist. Record the category considered, the reasoning, the evidence, the date and the person accountable.
Step 5 — Are you the provider or the deployer of each system?
The role determines roughly 80% of the workload, and it is not fixed by procurement. Under Art. 25 you become the provider of a high-risk system you did not build if you put your name or trademark on it, substantially modify it, or repurpose it so that it becomes high-risk. Fine-tuning a vendor model on your own data and shipping it under your own brand is the standard way an organisation acquires provider obligations it never budgeted for.
| Provider | Deployer | |
|---|---|---|
| Risk management (Art. 9) | Required | — |
| Data governance (Art. 10) | Required | Input data relevance only |
| Technical documentation (Annex IV) | Required | — |
| Conformity assessment + CE marking | Required | — |
| EU database registration | Required | Public bodies register their use |
| Human oversight | Design it (Art. 14) | Operate it (Art. 26) |
| Log retention | Enable (Art. 12) | Keep ≥ 6 months (Art. 26) |
| FRIA (Art. 27) | — | Public bodies, credit, insurance |
| Incident reporting | Art. 73 | Notify provider + authority |
The provider vs deployer guide works through the boundary cases, including importers and distributors, who carry verification duties rather than conformity duties.
Steps 6 to 10 — What does the high-risk programme actually produce?
Six artefacts, in dependency order. Each one is the input to the next, which is why a programme that starts with documentation and works backwards to governance stalls.
- Quality management system (Art. 17) — policies, responsibilities, change control, data management, post-market monitoring and incident procedures. The QMS is what a market surveillance authority asks for first.
- Risk management records (Art. 9) — the iterative identification, estimation and mitigation cycle, run across the lifecycle rather than signed off once.
- Data governance evidence (Art. 10) — provenance, representativeness, bias examination and mitigation for training, validation and test sets.
- Annex IV technical file — the document set described in the technical documentation guide, including testing results against the accuracy, robustness and cybersecurity requirements of Art. 15.
- Conformity assessment and declaration — self-assessment under Annex VI, or a notified body where biometrics or Annex I product legislation require it. See the conformity assessment guide.
- Registration, CE marking and post-market monitoring — EU database entry before market placement, CE marking on the documentation, then the ongoing post-market monitoring plan and serious-incident reporting under Art. 73.
Target 2 December 2027 for standalone Annex III systems and 2 August 2028 for Annex I embedded systems. A realistic programme for a single high-risk system runs 12 to 24 months, so a start in late 2026 is inside the window with no slack — and notified-body capacity will tighten as the date approaches.
What if you only use other people's AI?
You are a deployer, and your checklist is short but not empty. Most organisations sit here: no models built, a dozen AI features consumed through SaaS and APIs.
- Art. 4 AI literacy applies now, to every deployer, at every risk tier.
- Art. 50 transparency applies now to what your users see: chatbot disclosure, deepfake labelling, marking of AI-generated text published to inform the public.
- Art. 26 deployer obligations apply from 2 December 2027 wherever the use case sits in an Annex III category — recruitment screening, credit decisions, worker management.
- Art. 25 is the trap: the moment you rebrand or substantially modify, you inherit the provider set.
The practical control is vendor due diligence: obtain the provider's declaration of conformity, instructions for use, and the information Art. 13 requires them to supply. The third-party AI guide sets out what to demand contractually.
What changes by sector?
The obligations are identical; the classification results and the overlapping regimes are not.
- Financial services — credit scoring and insurance pricing are Annex III, and deployers there owe a FRIA under Art. 27. DORA's ICT risk management partly satisfies the AI Act's risk management article but does not cover AI-specific data governance or human oversight. Design one incident workflow that satisfies DORA Art. 19 and AI Act Art. 73 together. See the financial sector guide and the DORA / NIS2 convergence guide.
- Healthcare and medical devices — AI as a safety component of an MDR/IVDR device is Annex I, applying from 2 August 2028. The existing technical file and ISO 13485 QMS are the foundation; they must be extended to Chapter III requirements, and your notified body needs a separate AI Act designation.
- HR and recruitment — Annex III employment category. Bias examination under Art. 10 is the primary exposure, transparency to candidates is a deployer duty, and no final employment decision may rest on the system without a human able to override it.
- Public sector — FRIA is mandatory, and deployers register their use of Annex III systems in the EU database.
The sector guides work through nine industries in the same structure.
What does non-compliance cost?
Three tiers, and the one that matters most for ordinary businesses is the middle one. Art. 99 sets €35 million or 7% of worldwide turnover for the Art. 5 prohibitions, €15 million or 3% for most other obligations — including Art. 50 transparency and the whole high-risk set — and €7.5 million or 1% for misleading information supplied to authorities. SMEs are capped at whichever figure is lower.
The third tier deserves attention out of proportion to its size: it punishes a bad answer to a regulator independently of any underlying breach. Documentation is what converts a defensible position into a demonstrable one. The penalties guide works through the exposure calculation.
What to do in the next 90 days
- Close the inventory gap — finance vendor list ∪ engineering model registry.
- Screen everything against Art. 5. This is the only step with an in-force 7% tier attached.
- Ship Art. 50 disclosures on anything user-facing; the obligation is live, not upcoming.
- Evidence Art. 4 literacy: who was trained, on what, when. The AI literacy guide sets out what the rewritten article now requires.
- Classify the Annex III candidates and write down the reasoning, including the Art. 6(3) calls.
- For each confirmed high-risk system, start the QMS. December 2027 is the constraint, and the queue at notified bodies is ahead of you, not behind.
Working templates for the inventory, risk register, technical file and vendor due-diligence set are in the compliance toolkits; the AI Act Academy covers the same ground as structured training with certification.
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth — including what the AI Act adds on top of an existing DORA programme.
The AI Act for financial institutions ↗ Explore regulation-dora.eu ↗Frequently Asked Questions
It applies to providers, deployers, importers, distributors and authorised representatives of AI systems placed on the EU market or used in the EU, plus providers of general-purpose AI models. Establishment outside the EU does not remove the obligation: Art. 2(1)(c) catches non-EU providers and deployers whenever the output of the system is used in the Union.
Your AI system is in scope if it is an AI system under Art. 3(1) — a machine-based system that infers outputs such as predictions, recommendations, decisions, or content — and it is placed on the EU market or used in the EU. Purely research models not deployed externally are out of scope.
The first step is AI system inventory: catalogue all AI systems your organisation develops, deploys, imports, or distributes. For each system, document what it does, who the provider is, how it is used, and the affected population. Without a complete inventory, risk classification cannot begin.
Three sets are already in force: the Art. 5 prohibited practices since 2 February 2025, the Art. 4 AI literacy duty since 2 February 2025, and the Chapter V obligations on general-purpose AI model providers since 2 August 2025. The Art. 50 transparency obligations — chatbot disclosure, deepfake labelling, machine-readable marking of synthetic content — applied from 2 August 2026 and are live now.
It deferred four application dates and rewrote Art. 4; it created no new obligation and granted no sector or size exemption. Standalone Annex III high-risk systems now apply from 2 December 2027 instead of 2 August 2026, AI embedded in Annex I regulated products from 2 August 2028, regulatory sandboxes from 2 August 2027, and the transitional marking duty for generative systems already on the market from 2 December 2026. Everything already in force stayed in force.
A provider is any entity that develops an AI system and places it on the EU market or puts it into service. A deployer is any entity that uses a high-risk AI system under its authority for a professional activity. A financial institution that purchases an AI credit-scoring tool from a vendor is the deployer; the vendor is the provider. Both have distinct obligations — providers bear the primary conformity burden; deployers bear oversight, monitoring, and transparency obligations.
Yes, and this is the most commonly missed item on the checklist. Under Art. 25 a deployer becomes the provider of a high-risk AI system if it puts its own name or trademark on it, makes a substantial modification to it, or changes its intended purpose so that the system becomes high-risk. Fine-tuning a purchased model on your own data and rebranding the result usually triggers this.
Yes, in part. An AI system 'put into service' covers internal deployment where the system affects people — HR decisions, employee monitoring, internal credit assessment. An AI used solely for backend technical computation with no human-facing output may fall outside scope, but this requires documented legal analysis. Art. 4 (AI literacy) applies to all providers and deployers regardless of scope.
Art. 5 bans subliminal or manipulative techniques, exploitation of vulnerabilities, social scoring by public authorities, untargeted scraping of facial images, emotion inference at work or in education, biometric categorisation to infer sensitive characteristics, and most real-time remote biometric identification in public spaces by law enforcement. These have applied since 2 February 2025. A further prohibition covering the generation of child sexual abuse material and non-consensual intimate imagery applies from 2 December 2026.
There are two routes. Annex III lists eight standalone categories — biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration, and administration of justice. Annex I catches AI used as a safety component of a product already covered by EU product-safety legislation. If neither route applies, the system is not high-risk, and only transparency and AI literacy duties may remain.
Art. 6(3) allows an AI system that falls within an Annex III category to escape high-risk classification if it does not pose a significant risk of harm to health, safety or fundamental rights — for example because it performs a narrow procedural task, improves the result of a previously completed human activity, or is purely preparatory. The exception never applies to profiling of natural persons. You must document the assessment before placing the system on the market and register it in the EU database.
The Annex IV technical file — system description, design specifications, risk management documentation under Art. 9, data governance evidence under Art. 10, testing and evaluation results, human oversight measures under Art. 14, accuracy and cybersecurity evidence under Art. 15, and the post-market monitoring plan. Alongside it you need a quality management system (Art. 17), automatic logs (Art. 12), instructions for use (Art. 13), the EU declaration of conformity (Art. 47) and the CE marking (Art. 48).
For most Annex III systems, no: providers self-assess under Annex VI internal control. A notified body is required for biometric systems where no harmonised standard has been applied, and for Annex I embedded AI wherever the underlying product legislation already demands third-party assessment. Because notified-body capacity is limited, book the slot long before the 2 December 2027 date if third-party assessment applies to you.
Under Art. 26 a deployer must use the system according to the instructions, assign competent human oversight with authority to override, ensure input data is relevant for the intended purpose, keep the automatically generated logs for at least six months, inform workers' representatives before deploying at the workplace, and report serious incidents to the provider and the market surveillance authority. Deployers do not carry the conformity assessment burden — but they do carry the operational one.
A fundamental rights impact assessment under Art. 27 documents the deployment context, affected persons, risks to fundamental rights, human oversight arrangements and the remedies available. It is mandatory for public bodies and for private entities providing public services, and for any deployer of Annex III systems used in creditworthiness assessment or in life and health insurance pricing. It must be done before first use.
You are a deployer, not a provider, so long as you use the tool as supplied and for its intended purpose. Your duties are Art. 4 AI literacy, Art. 50 transparency to the people who interact with or receive output from the system, and — if the use case falls in Annex III — the full Art. 26 deployer set from 2 December 2027. Vendor due diligence is not a legal obligation in itself, but it is the only way to evidence that the upstream provider met its own.
Art. 4 has applied since 2 February 2025 to every provider and deployer, at every risk tier. The Digital Omnibus rewrote it from an obligation of result into an obligation of means: you must take measures to support the development of a sufficient level of AI literacy among staff operating AI systems, and no specific level has to be guaranteed for any individual. Evidence of training design, delivery and coverage is what a regulator will ask for.
Art. 50 has applied since 2 August 2026. Providers must design AI systems so that people are told they are interacting with an AI, and must mark synthetic audio, image, video and text in a machine-readable format. Deployers must disclose emotion recognition and biometric categorisation to the people exposed to them, and must label deepfakes and AI-generated text published to inform the public. Generative systems already on the market before 2 August 2026 have until 2 December 2026 to meet the marking requirement.
Three tiers under Art. 99: €35 million or 7% of worldwide annual turnover for breaching the Art. 5 prohibitions, €15 million or 3% for most other obligations including the Art. 50 transparency duties, and €7.5 million or 1% for supplying incorrect or misleading information to authorities. For SMEs and start-ups the cap is whichever figure is lower, not higher.
For a standalone Annex III high-risk AI system, a realistic compliance programme takes 12–24 months: 3–6 months for gap assessment and QMS design, 6–12 months for technical documentation, data governance, and conformity assessment, and 3–6 months for EU database registration and CE marking. With the deadline at 2 December 2027, a programme starting now is inside the window but has no slack left.
No. The Digital Omnibus introduced no size-based exemption. SMEs get three concessions only: simplified technical documentation under Art. 11(1), priority access to regulatory sandboxes, and the lower-of-the-two fine cap. Every substantive obligation applies in full.
No. A checklist scopes the work and evidences that the assessment was made; conformity is demonstrated by artefacts — the Annex IV technical file, the quality management system, the risk management records, the test results, the declaration of conformity and the post-market monitoring reports. Treat the checklist as the index to a document set that has to exist.
Take compliance further with the AI Act Academy
A free course, a server-graded exam, a verifiable certificate — and the working templates.