EU AI Act Readiness Checklist

0. How to read this page

The EU AI Act entered into force on August 1, 2024. Obligations phase in across three staggered dates - February 2, 2025 (prohibitions and AI literacy), August 2, 2025 (GPAI obligations, governance, penalties for some breaches), and August 2, 2026 (the bulk of the high-risk and transparency duties). A final tranche, mostly Annex I high-risk product integrations, runs to August 2, 2027.

Each row below is tagged BINDING (in force now), BINDING 2026-08-02, BINDING 2027-08-02, or TBD (the Article applies, but secondary instruments - implementing acts, harmonised standards, Commission guidance - are not yet finalised; treat the substance as known, the exact conformity method as in motion).

Use this page to triage. Map your AI systems to the Articles that bind them. Decide which obligations you address inside your existing risk-management programme, which need a new control, and which need counsel review before the deadline.

1. Article-by-Article status (as of May 2026)

Grouped by chapter. Status reflects the current state of secondary instruments and harmonised standards work as of 2026-05-29.

Chapter I - General provisions

Chapter II - Prohibited practices

Chapter III - High-risk AI systems

Chapter IV - Transparency obligations

Chapter V - General-purpose AI models

Chapters VI-XII - Governance, market surveillance, penalties, final provisions

2. August 2, 2026 - the obligation trigger map

This is the date the bulk of the operational EU AI Act duties become enforceable. If you provide, deploy, import, or distribute an AI system that the Act classifies as high-risk under Annex III, or you operate any AI system that triggers Article 50 transparency, these duties bind you from {August 2, 2026} onward.

• Art. 6-7 - your system either lands in Annex III or it does not. Make the classification call now.
• Art. 8-15 - if high-risk, the seven design-and-build requirements bind: risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy/robustness/cybersecurity.
• Art. 16-22 - provider-side QMS, conformity assessment, EU declaration, CE marking.
• Art. 26-27 - deployer duties bind even if you only USE a third-party high-risk system. FRIA required for public bodies and for credit/insurance use.
• Art. 50 - transparency for chatbots, synthetic content, emotion recognition, biometric categorisation, deep fakes (see Section 3).
• Art. 72-73 - post-market monitoring and serious-incident reporting to national competent authorities.
• Art. 74-84 - market surveillance and complaints.
• Art. 99 - administrative fines bite: up to EUR 35 million or 7% of global annual turnover for prohibited-practice breaches; up to EUR 15 million or 3% for most other obligations; up to EUR 7.5 million or 1% for supplying incorrect information.

Annex I product-integration duties (high-risk AI inside regulated products like medical devices, in-vitro diagnostics, machinery, toys, lifts, pressure equipment, radio equipment, etc.) trigger one year later, on August 2, 2027.

3. Article 50 transparency punch list

Article 50 binds nearly every consumer-facing AI system. It is the most common obligation people miss because it applies regardless of risk classification. Run through this list for every user-facing AI surface you operate.

4. GPAI deployer duty primer

The Act regulates providers of general-purpose AI models (Art. 53-55) heavily, but most companies are deployers of GPAI - they integrate a third-party foundation model into a product or workflow. Deployer duties for GPAI are layered:

• If you use the GPAI to build a high-risk AI system (Annex III), you become a provider of a high-risk system. All of Chapter III binds you, not just the deployer subset. This is the trapdoor most teams miss.
• If you significantly modify a GPAI (fine-tune for a new purpose, materially alter its capabilities), Art. 25 treats you as the provider of the modified system.
• If you rely on the GPAI provider's documentation (the Art. 53 package: model card, capability and limitation description, training-data summary, copyright policy), you must retain it and pass relevant parts downstream. Build the muscle to consume and curate this material - it is your evidence base.
• Art. 50 still applies to your front-end. The GPAI provider's compliance does not discharge your transparency duty. If your chatbot uses GPT-X or Claude-Y, you owe the user the Art. 50(1) disclosure.
• Art. 4 AI literacy bites now. Staff designing, deploying, or using AI systems must have a level of AI literacy proportionate to their role. This is a current obligation, not a 2026 one.
• Art. 26 deployer duties if your GPAI use lands you in a high-risk category: use per instructions, human oversight, log retention (minimum 6 months), informing affected workers and worker representatives.
• Art. 27 FRIA for public bodies, private operators delivering public services, and operators using high-risk AI for credit-worthiness scoring or insurance pricing on natural persons.

The practical implication: read the provider's Art. 53 package as if you were the regulator. Treat its gaps as your gaps. If the model card does not address a use case you rely on, document why you rely on it anyway, or pick a different model.

5. NIST AI RMF cross-walk

If you already operate the NIST AI Risk Management Framework (AI RMF 1.0, plus the Generative AI Profile, NIST AI 600-1), you have a head start. The mapping is not one-to-one, but it is close enough to reuse most of the artefacts. Headline alignments:

Caveat: NIST AI RMF is voluntary and risk-based; the EU AI Act is regulatory and prescribes specific evidentiary outputs. The cross-walk reuses the substance, not the legal status. You still need the Act's artefacts: the technical documentation under Art. 11 and Annex IV, the EU declaration of conformity under Art. 47, registration in the EU database under Art. 49 and Art. 71.

6. Working checklist - what to do by August 2, 2026

1. Inventory every AI system you provide, deploy, or distribute. Include shadow AI - the LLM features your teams added without telling procurement.
2. Classify each system: prohibited (Art. 5), high-risk (Art. 6-7 + Annex III), GPAI (Art. 51), Art. 50 transparency-only, or out of scope.
3. For each Art. 50 surface, draft the disclosure copy now and decide the trigger point (mount, first message, on hover). Ship it.
4. For each high-risk system, choose the conformity path: internal control (Annex VI) or notified-body assessment (Annex VII). Most Annex III systems use Annex VI; biometric systems and some others use Annex VII.
5. Stand up the Article 9 risk management system as a continuous, iterative process - not a one-off document. Hook it into your existing change management.
6. Assemble the Annex IV technical documentation: system description, development process, monitoring and control, risk-management documentation, changes through lifecycle, harmonised standards applied, EU declaration of conformity, post-market monitoring plan.
7. Stand up logging (Art. 12). Default retention: 6 months minimum for high-risk systems; longer where sector law requires.
8. Define human oversight (Art. 14)- measures, capacity, training, the "stop" control.
9. Run FRIA (Art. 27) where required. Template will arrive from the AI Office; in the interim, base your draft on national DPIA practice plus the fundamental-rights catalogue.
10. Register in the EU database (Art. 49 and Art. 71) when it opens.
11. Wire incident reporting (Art. 73) into your existing incident response. The formal written report to the relevant market-surveillance authority is due no later than 15 days after the provider (or, where applicable per Art. 26(5), the deployer) becomes aware of a serious incident as defined in Art. 3(49); this shortens to 10 days where the incident involves the death of a person, and to 2 days where the incident constitutes a widespread infringement or a serious and irreversible disruption of critical infrastructure. An immediate notification path runs alongside the written report - design both into the runbook.
12. Train your people (Art. 4 AI literacy) - already binding. Document who has been trained, on what, and how it is refreshed.

7. The WARRANT Standard reference

The WARRANT Standard is a public open specification for autonomous agent authorisation, aligned with NIST AI RMF and the EU AI Act. Lucian Lungu is a co-author. It addresses a specific gap the Act surfaces but does not solve in detail: how an autonomous agent provides cryptographically verifiable evidence of who authorised it to act, for what bounded purpose, and under what constraint envelope- so the deployer's Art. 14 human oversight, the Art. 12 record-keeping, and the Art. 26 use-per-instructions duties are technically enforceable, not just policy aspirations.

If you are building or buying agentic systems and you need an architectural answer for the Article 14 / Article 26 / Article 50 stack at the protocol layer, WARRANT is one of the working specs to track.

References to the WARRANT Standard on this site reflect Lucian's co-authorship. They do not imply endorsement of these services by other co-authors, affiliated organisations, NIST, or any EU body.