EU AI Act compliance checklist

Most of the work in the EU AI Act happens before any requirement applies to you. Until you know which systems you have, whether you are a provider or a deployer of each, and which risk tier each falls into, no obligation can be assigned to anyone. Teams that start with the requirements list stall; teams that start with the inventory move.

Work this checklist in order. Steps 1 to 3 are the whole game.

1. Inventory every AI system

• List systems you build, systems you buy, and AI features inside software you already licence — the last category is where the surprises live, because nobody procured them as AI.
• Include general-purpose models accessed through an API, and anything a team stood up without going through procurement.
• For each, record purpose, who is affected by its output, whether a person reviews that output, and whether it is used in the EU or its output is used in the EU.
• Note the supplier and the contract, since your role often turns on what the contract says you may do.

2. Fix your role for each system

Obligations attach to roles, and the same organisation is frequently a provider of one system and a deployer of another.

• Provider — you develop an AI system or have it developed and place it on the market or put it into service under your own name or trademark. The heavy obligations sit here.
• Deployer — you use an AI system under your own authority. Lighter, but real: human oversight, use in line with instructions, input data relevance, log retention, and informing affected people in defined cases.
• Importer, distributor, authorised representative — relevant where the supply chain crosses into the EU.
• Watch the role flip. Putting your name on a third-party system, or substantially modifying one, or changing its intended purpose, can make a deployer into a provider. This is the single most consequential misclassification.

3. Classify by risk tier

• Prohibited — practices such as untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and education outside safety and medical grounds, social scoring, and certain biometric categorisation and predictive policing uses. Check this tier first; it is a stop, not a control.
• High risk — either AI as a safety component of products already covered by EU product legislation, or the listed use cases including employment and worker management, education access, essential private and public services including creditworthiness, certain insurance pricing, law enforcement, migration, and administration of justice.
• Transparency obligations — systems interacting with people, generating synthetic content, deepfakes, and emotion recognition. Disclosure duties, machine-readable marking of synthetic output.
• Minimal risk — everything else. No mandatory obligations beyond AI literacy and any voluntary codes you adopt.

4. If anything is high risk, work these requirements

For providers of high-risk systems:

• Risk management system running across the whole lifecycle, not a one-time assessment.
• Data and data governance — training, validation and testing sets that are relevant, sufficiently representative and examined for bias.
• Technical documentation sufficient to demonstrate conformity, prepared before the system is placed on the market.
• Record keeping — automatic logging over the system's lifetime.
• Transparency and instructions for use that let a deployer interpret output and use the system properly.
• Human oversight designed in, so a person can actually intervene rather than nominally supervise.
• Accuracy, robustness and cybersecurity appropriate to purpose, including resistance to attempts to manipulate the system.
• Quality management system, conformity assessment, EU declaration of conformity and CE marking, registration in the EU database, post-market monitoring and serious incident reporting.

Deployers of high-risk systems have their own shorter list: use according to instructions, assign competent human oversight with authority to act, ensure input data is relevant, keep logs, and inform affected persons where required. Public bodies and some private deployers additionally face a fundamental rights impact assessment.

5. General-purpose AI models

• Providers of GPAI models owe technical documentation, information to downstream providers, a copyright policy, and a sufficiently detailed summary of training content.
• Models presenting systemic risk carry additional evaluation, adversarial testing, incident reporting and cybersecurity duties.
• If you fine-tune a model, check carefully whether you have become a provider in your own right.

6. AI literacy and the dates

The obligation that applies to nearly everyone: providers and deployers must ensure a sufficient level of AI literacy among staff dealing with AI systems, taking account of their technical knowledge and the context of use. It is broad, cheap to satisfy, and easy to evidence with training records — do it.

The Act applies in stages: prohibitions and AI literacy first, then general-purpose AI model obligations, then the bulk of the high-risk regime, with product-embedded high-risk systems last. Because these dates are staged and subject to guidance, confirm the current position against the official timeline before you plan a programme around them.

The most common planning error is treating the whole Act as a single future deadline. Prohibitions and AI literacy already apply; the high-risk conformity work is the long project.

Key takeaways

• Inventory, role and classification come before any requirement — do them first.
• Check the prohibited tier before anything else; it is a stop, not a control.
• Rebranding, modifying or repurposing a system can turn a deployer into a provider.
• AI literacy applies broadly, is inexpensive, and is easy to evidence.