EU AI Act Compliance Checklist: Phase-by-Phase Checkbox Template
Phase-by-phase EU AI Act compliance checklist. Checkbox items for inventory, classification, high-risk build, FRIA, Article 50, and post-market monitoring.
Print this checklist and work through it system by system. Each phase maps to the articles that govern it. For a full explanation of what each obligation requires and how to interpret the classification rules, see the EU AI Act compliance checklist guide — that page unpacks the reasoning; this one is the working artifact you tick off.
Scope: Regulation (EU) 2024/1689. Deadlines current as of June 2026 (Digital Omnibus political agreement, 7 May 2026). High-risk = 2 December 2027 (Annex III stand-alone) / 2 August 2028 (Annex I product safety components).
Phase 1 — Inventory every AI system
Before any classification is possible, you need a complete register of what you have.
- Every AI system the organisation builds, deploys, imports, or distributes is logged in a central inventory
- Each entry records the system name, version, intended purpose, and the business function it supports
- Third-party AI tools used in a professional capacity are included (off-the-shelf SaaS, APIs, embedded models)
- AI components embedded in products or workflows — not just standalone tools — are captured
- The inventory is assigned an owner and a review cadence
Phase 2 — Classify each system and confirm your role
Classification under Article 6 (read with Annex III) determines which phases below apply. Role determination under Articles 16 and 26 determines who owes the obligations.
2a — Screen for prohibited practices (Article 5)
Article 5 prohibitions have been in force since 2 February 2025. There is no deadline extension here.
- Each system is checked against the Article 5 list: subliminal manipulation (5(1)(a)); exploitation of vulnerabilities (5(1)(b)); social scoring by public authorities (5(1)(c)); predicting offending solely on profiling (5(1)(d)); untargeted facial scraping (5(1)(e)); emotion recognition in workplaces or education (5(1)(f)); sensitive biometric categorisation (5(1)(g)); real-time remote biometric identification in public spaces for law enforcement except permitted exceptions (5(1)(h))
- Any system that matches an Article 5 description has been withdrawn or discontinued
2b — Classify as high-risk (Article 6 + Annex III)
- Each system is checked against the eight Annex III headings: biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services (including creditworthiness / credit scoring, and life/health insurance risk and pricing); law enforcement; migration, asylum, and border control; administration of justice and democratic processes
- For any Annex III match, the Article 6(3) filter is applied: does the system perform only a narrow procedural task, improve a previously completed human activity, detect decision patterns without influencing human assessment, or carry out purely preparatory work? If yes — and the system does not profile natural persons — the Art 6(3) exemption may apply and must be documented
- Systems that are safety components of regulated products listed in Annex I (e.g., machinery, medical devices) are flagged for the Annex I product route (deadline: 2 August 2028, not 2 December 2027)
- Classification decisions — including any Art 6(3) exemption claims — are documented with the reasoning recorded
2c — Classify as limited-risk (Article 50)
Article 50 transparency obligations apply from 2 August 2026.
- Each system is checked for Article 50 scope: AI systems that interact with natural persons (chatbots); systems that generate or manipulate image, audio, or video content (deepfakes, synthetic media); emotion recognition or biometric categorisation systems; AI-generated text on matters of public interest
- Systems in scope are flagged for Phase 6 (Article 50 transparency)
2d — Confirm your role for each system
- For each system: is the organisation the provider (Article 16) — i.e., it developed the system and placed it on the market or into service under its own name/trademark?
- For each system: is the organisation the deployer (Article 26) — i.e., it uses the system under its own authority in a professional context?
- For each system: is the organisation an importer (Article 23) or distributor (Article 24)?
- Article 25 role-shift is checked: does the organisation rebrand, substantially modify, or change the intended purpose of a third-party system? If yes, provider obligations (Article 16) are triggered
- Role assigned for each system, with rationale documented
Phase 3 — AI literacy (Article 4)
In force since 2 February 2025. Applies to all AI, not only high-risk.
- Staff who operate, oversee, or make decisions using AI systems have received AI literacy measures proportionate to their role
- Literacy measures cover what the relevant AI systems do, their limitations, and the human oversight required
- The organisation can demonstrate, if asked, that literacy measures exist and are kept current
- No mandatory certification is required — but evidence of proportionate training should be retained
Phase 4 — High-risk provider build checklist
Deadline: 2 December 2027 (Annex III stand-alone) / 2 August 2028 (Annex I products).
Complete this phase for every system classified as high-risk where the organisation is the provider. Work through the articles in order — each one feeds the next.
Risk management system (Article 9)
- A risk management system is established and maintained as an iterative, ongoing process throughout the system's lifecycle
- Identification and analysis of known and reasonably foreseeable risks under intended use and foreseeable misuse is documented
- Evaluation of risks from post-market monitoring data is built into the process
- Risk management measures are adopted and their effectiveness verified
- A residual risk assessment is documented showing residual risks are acceptable
Data and data governance (Article 10)
- Training, validation, and testing datasets are subject to documented data governance practices
- Dataset relevance, representativeness, and freedom from errors are examined
- Potential biases — and how they are addressed — are documented
- Data provenance and collection methodology are recorded where applicable
Technical documentation — Annex IV (Article 11)
- Technical documentation covering all nine areas of Annex IV is prepared before market placement
- Documentation includes a general description; description of design and development process; information on monitoring, functioning, and control; risk management documentation; changes made during lifecycle; applicable standards and conformity assessment basis; Declaration of Conformity
- Documentation is kept up to date when the system changes materially
- Documentation is available to market surveillance authorities on request and retained for at least 10 years (Article 18)
Logging and record-keeping (Article 12)
- The system is designed to enable automatic logging of events throughout operation
- Logs cover at least the operational period of each use
- Logs are stored securely and retained as required
Transparency to deployers (Article 13)
- Instructions for use are drawn up for deployers, covering: the system's intended purpose; capabilities and limitations; performance metrics and accuracy levels; human oversight requirements and the technical means to exercise oversight; risks to health, safety, and fundamental rights; maintenance and care requirements
Human oversight (Article 14)
- The system is designed so that natural persons assigned to oversight can fully understand its outputs and their limitations
- Oversight persons can disregard or override the system's output
- Oversight persons can intervene in or halt the system's operation
- Oversight measures are identified and built into the technical design — not left solely to procedural controls
Accuracy, robustness, and cybersecurity (Article 15)
- The system achieves an appropriate level of accuracy for its intended purpose; accuracy metrics are documented
- The system is resilient to errors, faults, and inconsistencies, including from third-party inputs
- Cybersecurity measures proportionate to the deployment context are implemented and documented
Quality management system (Article 17)
- A QMS is established covering: regulatory compliance strategy; system design techniques and procedures; data management; testing, validation, and monitoring; human oversight implementation; incident reporting; post-deployment monitoring
- The QMS is proportionate to the size of the organisation
Conformity assessment (Article 43)
- The applicable conformity assessment route is determined: Annex VI internal self-assessment (most Annex III categories); Annex VII notified-body route (Annex III point 1 biometrics, where harmonised standards are not applied)
- The conformity assessment is completed and results are documented
- Assessment is repeated or updated if the system is substantially modified (Article 3(23))
EU Declaration of Conformity (Article 47)
- An EU Declaration of Conformity is drawn up containing all information required by Annex V
- The Declaration is signed by an authorised representative of the provider
- The Declaration is kept current and updated on material system changes
- The Declaration is made available to deployers and authorities on request
CE marking (Article 48)
- CE marking is affixed to the system or its documentation only after successful conformity assessment
- CE marking requirements specific to any overlapping product regulation are also met
Registration in the EU database (Article 49)
- The system is registered in the EU database for high-risk AI systems (Article 71) before being placed on the market
- Registration information is complete, accurate, and kept up to date
- Any Article 6(3) exemption claim is also registered under Article 49
Phase 5 — Fundamental Rights Impact Assessment (Article 27)
Applies to certain deployers only — not all. Check carefully.
Article 27 FRIA is mandatory for: public bodies deploying high-risk AI; private entities providing public services; and deployers of systems in Annex III categories 5(b) (creditworthiness/credit scoring) or 5(c) (life/health insurance risk and pricing). It does not apply automatically to private employers or most B2B deployers.
- The organisation has determined whether it falls within the Article 27 scope
- If in scope: a FRIA is conducted before deployment, covering the relevant fundamental rights, affected persons, and mitigation measures
- If in scope: the FRIA is registered with the relevant market surveillance authority
- If in scope: the FRIA is updated when the deployment context changes materially
- Where a DPIA under GDPR Article 35 exists, the FRIA is coordinated with or built on it (Article 27(4))
Phase 6 — Article 50 transparency (limited-risk)
Applies from 2 August 2026.
- Systems that interact directly with natural persons (chatbots, conversational agents) disclose to the user that they are interacting with an AI, unless the context makes this obvious
- Systems that generate synthetic audio, image, video, or text content mark that content as artificially generated or manipulated in a machine-readable format
- Emotion recognition or biometric categorisation systems inform the persons subject to them
- AI-generated text on matters of public interest (elections, public health) is labelled as AI-generated
- Disclosure obligations are met at the time of first interaction, clearly and in accessible form
Phase 7 — Post-market monitoring and incident reporting
Post-market monitoring (Article 72)
For providers of high-risk systems. Begins at deployment; no single deadline — it is an ongoing obligation.
- A post-market monitoring plan is in place before the system is deployed
- Data from deployed systems is actively collected and reviewed against the plan
- Monitoring findings feed back into the Article 9 risk management system
- Monitoring intensity is proportionate to the risk level of the system
Serious incident reporting (Article 73)
For providers. The deployer's duty is to flag incidents to the provider and relevant authority under Article 26.
- A process for identifying serious incidents is defined and operational before deployment
- Reporting timelines are understood and followed: no later than 15 days from awareness (general serious incidents); 2 days for a wide-scale or serious and irreversible disruption to critical infrastructure; 10 days where a person has died (Article 73(2)–(4))
- Reports to the market surveillance authority of the member state where the incident occurred are filed promptly; an incomplete initial report is permitted and then completed (Article 73(5))
- Serious incident records are maintained
High-risk deployer checklist (Article 26)
For organisations that are deployers of a third-party high-risk AI system, rather than (or in addition to) being providers.
- The system is used only for its intended purpose as specified by the provider
- A natural person is assigned to human oversight with the competence and authority required
- The provider's instructions for use are followed
- The system is monitored during deployment; anomalies, risks, or malfunctions are identified
- Serious incidents and malfunctions are reported to the provider; serious incidents that represent a risk are also reported to the relevant market surveillance authority
- Where the system is used in an employment context, affected workers or their representatives are informed before use
- Logs are retained for at least 6 months
- Phase 5 (Article 27 FRIA) is assessed for applicability to this deployment
How Confir helps
Confir's rule-based engine runs this checklist as a guided workflow. It inventories your AI systems, classifies each under Articles 5 and 6 using Annex III logic, and derives your role. It then drives a structured assessment across four compliance areas — risk classification (AIRC), data and technical robustness (AITR), transparency and oversight (AITO), and governance and post-market monitoring (AIGM) — and generates the Annex IV technical documentation pack and the Article 47 Declaration of Conformity.
The output is a live checklist view for every system in your portfolio, showing what is complete, in progress, or outstanding. No spreadsheets. Deterministic, reproducible, audit-defensible.
[Start your free assessment at confir.eu →]
Frequently Asked Questions
When do these obligations actually apply? Article 5 prohibitions and Article 4 AI literacy have been in force since 2 February 2025. GPAI obligations (Articles 51–55) apply from 2 August 2025. Article 50 limited-risk transparency applies from 2 August 2026. For high-risk AI, the Digital Omnibus political agreement of May 2026 sets 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for high-risk AI embedded in regulated products (Annex I).
Does this checklist apply if we only use third-party AI tools? Phase 1 (inventory), Phase 2d (role determination), Phase 3 (Article 4 AI literacy), and Phase 6 (Article 50, if applicable) apply regardless. If you deploy a third-party high-risk AI system professionally, the Article 26 deployer checklist applies. Providers bear the heavier Phase 4 build obligations; most companies using off-the-shelf tools are deployers.
What is the difference between this page and the EU AI Act checklist guide? This page is the printable, checkbox-driven artifact — phases and items to tick off. The EU AI Act compliance checklist guide explains what each obligation requires, how the classification logic works, and what the common mistakes are. Use both: read the guide to understand; use this template to track progress.
Do I need a notified body for conformity assessment? Only for Annex III point 1 (biometrics) where harmonised standards have not been applied — that requires the Annex VII notified-body route. All other Annex III categories use Annex VI internal self-assessment. High-risk AI embedded in Annex I products follows the integrated product conformity assessment route.
What are the penalties for non-compliance? Three tiers under Article 99: €35,000,000 or 7% for Article 5 violations; €15,000,000 or 3% for most other obligations including the high-risk requirements; €7,500,000 or 1% for supplying incorrect or misleading information to authorities. For SMEs and start-ups, the fine is the lower of the percentage or the fixed amount (Article 99(6)).
Does a FRIA replace a GDPR DPIA? No. A GDPR DPIA (GDPR Article 35) covers data-protection risk and is led by the Data Protection Officer. A Fundamental Rights Impact Assessment under AI Act Article 27 covers the broader range of fundamental rights. Article 27(4) allows the FRIA to build on an existing DPIA, but they are not interchangeable.
What is the Article 6(3) exemption and how do I use it? A system in an Annex III area is not high-risk if it satisfies any one of four conditions: it performs only a narrow procedural task; it improves a previously completed human activity; it detects decision patterns without influencing human assessment; or it carries out preparatory work. Any system that profiles natural persons is always high-risk. Providers must document the assessment and register the claim under Article 49.
Related guides
- general-purpose AI obligations
- importer and distributor requirements
- public sector AI compliance guide
- deployer obligations under 2024/1689
- provider versus deployer distinctions
- Article 23 compliance requirements
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →