EU AI Act Compliance Checklist: Every Phase, Every Obligation

The EU AI Act attaches obligations to specific risk tiers and specific roles. This checklist works through all of them in sequence — inventory, classify, determine your role, then execute the high-risk stack. Each item cites the article that creates the obligation.

Deadlines: Article 5 prohibitions and Article 4 AI literacy have applied since 2 February 2025. Stand-alone Annex III high-risk systems must comply by 2 December 2027 (deferred under the Digital Omnibus, May 2026; the original August 2026 date no longer applies). High-risk AI embedded in Annex I regulated products: 2 August 2028. Article 50 limited-risk transparency: 2 August 2026.

Want a print-ready version? See the EU AI Act compliance checklist template.

---

Phase 1 — Inventory every AI system

• List every AI system the organisation builds, licenses, or uses in a professional capacity — including embedded SaaS features and third-party model APIs.
• For each system, record: name, vendor (if any), intended purpose, data inputs, outputs, and the business process it supports.
• Flag which team controls the system's purpose and deployment — that determines your role (Phase 3).
• Identify any system that was substantially modified after acquisition; Article 3(23) defines "substantial modification" and converting a deployer into a provider is a common trap.
• Prioritise systems that process biometric data, make decisions affecting individuals' employment or credit, or interact with individuals in real time — the most likely high-risk candidates.

You cannot register in the EU database (Article 49) or meet any downstream obligation without knowing what you are operating.

---

Phase 2 — Classify each system

Step 2a: Prohibited practices (Article 5) — check these first

In force since 2 February 2025. If a system matches any item below, it cannot be placed on the market.

• Subliminal, manipulative, or deceptive techniques that distort behaviour harmfully → Prohibited (Art 5(1)(a)).
• Exploiting vulnerabilities of a specific group to distort behaviour harmfully → Prohibited (Art 5(1)(b)).
• Social scoring that causes detrimental treatment unrelated to the data context → Prohibited (Art 5(1)(c)).
• Predicting offending based solely on profiling or personality traits, without objective facts → Prohibited (Art 5(1)(d)).
• Untargeted facial-recognition scraping to build or expand a database → Prohibited (Art 5(1)(e)).
• Inferring emotions in the workplace or educational institutions → Prohibited (Art 5(1)(f)). Hard ban; no exemption.
• Biometric categorisation to infer race, politics, religion, sexual orientation, or other sensitive characteristics → Prohibited (Art 5(1)(g)).
• Real-time remote biometric identification in publicly accessible spaces for law enforcement (outside narrow statutory exceptions) → Prohibited (Art 5(1)(h)).

Fines for Article 5 breaches: €35,000,000 or 7% of total worldwide annual turnover, whichever is higher (Article 99(3)).

Step 2b: High-risk classification (Article 6 + Annex III)

Work through each Annex III area:

• Point 1 — Biometrics: non-real-time remote biometric identification; biometric categorisation inferring sensitive attributes (where not already prohibited); emotion recognition outside the workplace and education.
• Point 2 — Critical infrastructure: AI as a safety component in digital infrastructure, road traffic, or utilities.
• Point 3 — Education: AI determining access, assigning students, evaluating learning outcomes, or monitoring for exam misconduct.
• Point 4 — Employment: AI for recruitment, CV screening, promotion/termination decisions, task allocation, or performance monitoring.
• Point 5(b) — Creditworthiness: AI assessing creditworthiness or credit scores (fraud detection is excluded).
• Point 5(c) — Life/health insurance: AI assessing risk or setting pricing for life or health insurance.
• Point 5 (other) — Essential services: emergency dispatch; public-benefits eligibility.
• Point 6 — Law enforcement: risk-of-offending/re-offending assessment (supporting human judgment grounded in objective facts); polygraphs; evidence reliability.
• Point 7 — Migration and asylum: visa/asylum eligibility; document verification; risk assessment of persons at borders.
• Point 8 — Justice and democratic processes: AI assisting judicial authorities; AI influencing elections or referenda.

Article 6(3) filter: a system in an Annex III area is not high-risk if it satisfies any one of these conditions: it performs a narrow procedural task; it improves a previously completed human activity; it detects patterns without influencing human decisions; or it performs only preparatory work. But any system that profiles natural persons is always high-risk — the exemption does not apply.

• Claiming Art 6(3): document the assessment in writing, retain it, and register the system in the EU database (Art 49) noting the exemption.

Deadline for Annex III stand-alone systems: 2 December 2027.

Step 2c: Limited risk — Article 50 transparency (from 2 August 2026)

• Chatbots (Art 50(1)): inform users they are interacting with an AI system at first interaction.
• Synthetic content (Art 50(2)): AI-generated images, audio, and video must be machine-readable marked.
• Emotion recognition / biometric categorisation (Art 50(3)): inform persons exposed to the system.
• Deepfakes and AI-generated public-interest content (Art 50(4)): label that content was artificially created.
• Accessibility (Art 50(5)): disclosure must be timely and accessible.

Step 2d: Minimal risk

If none of the above tiers applies, document why — that rationale is the evidence that you assessed the system.

---

Phase 3 — Determine your role

• Provider (Article 16): developed the system and places it on the market or puts it into service under your own name or trademark. Heaviest obligations.
• Deployer (Article 26): uses a third-party high-risk system in a professional context, under your own authority.
• Importer (Article 23): brings a high-risk system from outside the EU into the EU market under your name. Must verify conformity, CE marking, DoC, and registration before placing it on the market.
• Distributor (Article 24): makes a high-risk system available on the market without modifying it. Must verify CE marking and DoC.
• Article 25 role-shift: you become a provider if you put your name on a high-risk system, substantially modify it (Art 3(23)), or change its intended purpose into a higher-risk category.

Most companies deploying SaaS AI tools are deployers. SaaS companies shipping AI features under their own brand are providers.

---

Phase 4 — High-risk providers: the compliance stack (Articles 9–17)

Risk management system (Article 9)

• Establish a documented risk management system covering the full lifecycle: design, development, testing, deployment, post-market.
• Identify foreseeable risks to health, safety, and fundamental rights — including from reasonably foreseeable misuse.
• Define and implement mitigation measures; evaluate residual risks.
• Set up a mechanism to update the risk assessment continuously as the system evolves.

Data and data governance (Article 10)

• Document data governance practices for training, validation, and test datasets.
• Assess datasets for biases that could affect fundamental rights or lead to discrimination.
• Document provenance, collection methods, and preprocessing steps.
• Ensure training data is relevant, representative, and free from errors that would impair performance.

Article 10 is about data governance, not staff training — that is Article 4 (AI literacy), in force since 2 February 2025.

Technical documentation (Article 11 / Annex IV)

Annex IV specifies nine content areas for the technical file:

• General description: name, version, intended purpose, deployer instructions.
• System elements and development process: architecture, training methods, design choices.
• Training and testing data: characteristics, acquisition, preparation, statistics.
• Risk management system outputs (Art 9).
• Changes and version control.
• Monitoring, functioning, and control of the system.
• Accuracy, robustness, and cybersecurity performance (Art 15 metrics).
• Instructions for use to deployers.
• Post-market monitoring plan (Art 72).

Retain the technical file for 10 years from placing the system on the market (Article 18).

Logging (Article 12)

• Implement automatic logging of operation to the extent inherent in the system's purpose.
• Logs must capture the period of use, the reference database (if applicable), input data leading to each output, and the identity of persons involved in verification.
• Ensure log integrity — logs must not be modifiable by the system operator.

Transparency and information to deployers (Article 13)

• Prepare instructions for use that explain capabilities, limitations, accuracy levels, known risks, and input requirements.
• Where the system affects decisions about individuals, explain the logic in terms that permit meaningful human review.

Human oversight (Article 14)

• Design the system so oversight persons can understand its capabilities and limitations and monitor operation in real time.
• Ensure the system can be paused, overridden, or interrupted.
• Where outputs affect individuals (employment, credit), a human must be able to review and correct them before they take effect.
• Document who holds oversight responsibility, their training, and how override decisions are recorded.

Accuracy, robustness, and cybersecurity (Article 15)

• Document accuracy levels for the intended purpose, including performance across demographic groups.
• Implement technical measures for robustness under adversarial conditions, input errors, and unexpected inputs.
• Address cybersecurity risks: adversarial attacks, data poisoning, model vulnerabilities.

Quality management system (Article 17)

• Establish a QMS covering compliance strategy, development methodology, testing and validation, post-market monitoring, and documentation procedures.
• ISO/IEC 42001:2023 certification supports the Article 17 QMS and contributes evidence to the technical file. It is voluntary; it does not substitute for the Article 43 conformity assessment.

---

Phase 5 — Fundamental Rights Impact Assessment (Article 27)

The FRIA applies to specific deployers, not to all.

• Public bodies or entities providing public services deploying a high-risk system: FRIA is mandatory before deployment.
• Deployers of creditworthiness AI (Annex III point 5(b)) or life/health insurance AI (5(c)): FRIA is mandatory.
• Note: private employers deploying recruitment AI (Annex III point 4) do not automatically owe a FRIA. The trigger is public-body status or the specific service categories above.
• The FRIA must cover: description of deployment processes, duration and frequency, categories of persons affected, specific risks to fundamental rights, proportionality, and oversight measures.
• Article 27(4): the FRIA may build on an existing GDPR DPIA (Art 35 GDPR). They are complementary — the DPIA covers data-protection risk; the FRIA covers fundamental rights broadly.

---

Phase 6 — AI literacy (Article 4) — already in force

• Ensure staff who operate, oversee, or make decisions on the basis of AI systems have sufficient literacy for their role — understanding of capabilities, limitations, data requirements, and potential for bias.
• No formal certification is required. Document the measures you have put in place: training sessions, role-specific guidance, awareness materials.
• Revisit literacy requirements whenever a new system is deployed or a significant update changes capabilities or risks.

---

Phase 7 — Conformity assessment, Declaration of Conformity, CE marking, registration

Conformity assessment (Article 43)

• Annex III point 1 (biometrics): where harmonised standards are not applied, the Annex VII notified-body route applies.
• Annex III points 2–8: the Annex VI internal self-assessment route. No notified body required.
• Annex I (regulated products): follow the existing product-legislation conformity route. Deadline: 2 August 2028.
• Document the assessment procedure and outcome.

EU Declaration of Conformity (Article 47)

• Prepare a DoC identifying the system, the provider, the conformity assessment procedure, and any notified body involved.
• Sign by an authorised representative of the provider.
• Make the DoC available to national authorities on request; retain for 10 years (Article 18).

CE marking (Article 48)

• Affix the CE mark after the conformity assessment is complete and the DoC is signed — not before.

EU database registration (Article 49)

• Register the high-risk system in the EU database (established under Article 71) before placing it on the market.
• Providers claiming an Article 6(3) exemption must also register, noting the exemption.
• Keep registration data current following substantial modifications or withdrawal.

---

Phase 8 — Post-market monitoring (Article 72) and incident reporting (Article 73)

Post-market monitoring (Article 72)

• Establish a post-market monitoring plan (forms part of Annex IV technical documentation).
• Monitor real-world performance against documented accuracy, robustness, and fairness metrics.
• Feed findings back into the Article 9 risk management system and update technical documentation.
• Deployers must assist: Article 26 obliges them to monitor performance in their deployment context and report anomalies to the provider.

Serious incident reporting (Article 73)

Providers report to the market-surveillance authority of the member state where the incident occurred. Timeframes are statutory:

• 15 days from awareness — standard window (Art 73(2)).
• 2 days — widespread infringement or serious, irreversible disruption of critical infrastructure (Art 73(3)).
• 10 days — where a person has died (Art 73(4)).
• An initial incomplete report is permitted; complete it as soon as practicable (Art 73(5)).

"Serious incident" is defined in Article 3(49). Deployers flag incidents to the provider under Article 26; the formal reporting obligation to authorities belongs to the provider under Article 73.

---

How Confir helps

Confir runs this checklist as a guided workflow. You answer plain-English questions about each system; the deterministic, rule-based engine resolves the Article 5 check, the Article 6 / Annex III classification, and your role. Same intake, same finding — reproducible and audit-defensible. It then drives the structured assessment across four compliance areas (AIRC, AITR, AITO, AIGM) and generates the Annex IV technical documentation pack, the Article 47 Declaration of Conformity, and the Article 27 FRIA where applicable. Self-serve, from €600/year.

---

Frequently asked questions

What is the real deadline for high-risk AI Act compliance?

For stand-alone Annex III systems: 2 December 2027, deferred from the original August 2026 date by the Digital Omnibus agreed in May 2026. For high-risk AI embedded in Annex I regulated products: 2 August 2028. Article 5 prohibitions and Article 4 AI literacy have been in force since 2 February 2025. Article 50 limited-risk transparency applies from 2 August 2026.

What is the difference between a provider and a deployer?

A provider (Article 16) develops the system and places it on the market under its own name. A deployer (Article 26) uses a third-party system in a professional context under its own authority. If you built it and branded it, you are a provider. If you licensed it and use it, you are likely a deployer — unless you put your name on it or substantially modified it, in which case Article 25 converts you into a provider.

Which obligations apply specifically to deployers?

Deployers of high-risk systems must: follow the provider's instructions for use; ensure human oversight in their specific context; monitor performance and report anomalies to the provider; retain logs for at least 6 months (Article 26); notify workers' representatives before deploying AI in the workplace; and conduct a FRIA (Article 27) where required. Deployers do not carry out conformity assessments, affix CE marks, or register in the EU database — those are provider duties.

Does the Article 6(3) exemption require satisfying all four conditions?

No — only one of the four conditions is needed: narrow procedural task; improving a previously completed human activity; detecting patterns without influencing decisions; or preparatory work only. The exemption does not apply to any system that profiles natural persons — those are always high-risk regardless.

Is the FRIA (Article 27) mandatory for all high-risk deployers?

No. It is mandatory for public bodies deploying high-risk AI, and for private deployers using systems for creditworthiness (Annex III point 5(b)) or life/health insurance pricing (Annex III point 5(c)). Private employers deploying recruitment AI (point 4) do not automatically owe a FRIA under Article 27.

What are the penalty tiers under Article 99?

Three tiers, each "whichever is higher" of a fixed amount or a percentage of total worldwide annual turnover: €35,000,000 or 7% for Article 5 prohibitions (Art 99(3)); €15,000,000 or 3% for most other obligations including high-risk requirements and provider/deployer duties (Art 99(4)); €7,500,000 or 1% for supplying incorrect or misleading information to authorities or notified bodies (Art 99(5)). For SMEs and start-ups, Article 99(6) caps fines at the lower of the percentage or the fixed amount. GPAI-provider fines are separate under Article 101.

How long must records be kept?

Providers retain technical documentation and the Declaration of Conformity for 10 years from placing the system on the market (Article 18). Deployers retain logs for at least 6 months (Article 26). Serious-incident reports and post-market monitoring data are retained as part of the ongoing technical file.

---

Related guides

• Articles 6–11 risk classification
• risk assessment methodology
• EU AI Act compliance guide for companies
• compliance software comparison
• Article 6 high-risk classification
• Article 3 definitions
• EU AI Act fundamentals
• Article 26 deployer obligations
• EU AI Act compliance checklist template