Practical checklist
EU AI Act Readiness Checklist for Organizations
An EU AI Act readiness checklist is a governed work plan for identifying relevant AI systems, establishing the organisation's role for each system, screening classification questions, mapping applicable requirements, assigning owners, and assembling evidence. It supports system-specific legal analysis; it does not by itself determine applicability or prove compliance.
Direct answer
Readiness is an operating capability, not a legal label
EU AI Act readiness means an organisation can identify its relevant systems, explain their intended and actual uses, determine which facts affect its role and classification, translate confirmed requirements into operating controls, and produce the evidence needed for review. A checklist is useful when it exposes unanswered questions and dependencies instead of converting incomplete information into a green status.
A broader EU AI Act readiness assessment tests how this practice fits the organization's wider ownership, control, and evidence baseline.
This guide focuses on the enterprise work needed before and around system-specific legal analysis. The parent readiness assessment provides the broader diagnostic route. Legal conclusions should be based on Regulation (EU) 2024/1689, current authoritative guidance, the organisation's activities, and the facts of each system; qualified legal advice may be required.
First control
Start with the systems and uses that require a decision
Readiness fails early when the organisation starts from a list of flagship projects. The population must also consider purchased applications, embedded AI features, configured vendor products, APIs, general-purpose models, employee tools, pilots, and local automation. Record the system and use case separately when one capability supports materially different purposes.
The implementation detail belongs in the EU AI Act AI system inventory guide, including the facts needed for role, classification, and change review.
Analysis discipline
Determine role and classification from verified facts
Provider, deployer, importer, and distributor are not interchangeable labels. The relevant role depends on what the organisation does with the system, including whether it develops or has it developed, places it on the market, uses it under its authority, imports it, distributes it, makes a substantial modification, or changes an intended purpose. The readiness record should preserve the facts and the approved conclusion separately.
Classification should follow a controlled decision path rather than a single risk dropdown. Screen the intended use and actual context for prohibited-practice questions, then examine high-risk possibilities, transparency provisions, general-purpose AI dependencies, and other role-dependent requirements that may be relevant. Record why a branch applies, does not apply, or remains open. This preserves useful reasoning when a supplier changes a feature or a business team proposes a new use.
Use the official text of Regulation (EU) 2024/1689 and current European Commission material as the authoritative starting point. Record the source version, reviewer, assumptions, unresolved supplier information, and any question referred for qualified legal review.
Readiness analysis and compliance conclusions serve different purposes
| Readiness work | Legal or compliance conclusion |
|---|---|
| Identifies systems, uses, owners, missing facts, evidence, and workstreams | Determines how the law applies to a defined system and organisational activity |
| Can record an open role or classification question | Requires an approved interpretation supported by current sources and facts |
| Prioritises operational remediation and dependencies | Determines applicable duties and the basis for a compliance position |
| May be coordinated by governance, risk, or programme teams | Should involve appropriately qualified legal or compliance authority |
A readiness checklist is successful when it routes the right question to the right owner with enough evidence to decide it.
Operating model
Map confirmed requirements to owners, controls, and evidence
Once role and classification questions are sufficiently resolved, create a requirements-to-operations map. Depending on the system and role, work may involve risk management, data governance, technical documentation, record keeping, transparency, human oversight, accuracy, robustness, cybersecurity, post-market monitoring, incident processes, instructions for use, supplier evidence, or AI literacy. Not every item applies to every organisation; the map must show the basis for inclusion or exclusion.
Readiness workstream sequence
Use this after the population and analysis governance are established.
- 01
Confirm the population
Reconcile internal development, procurement, vendor features, employee use, and business workflows; retain candidates and exclusions.
- 02
Validate intended purpose and actual use
Record users, affected people, data, outputs, geography, autonomy, modifications, and business dependency.
- 03
Approve role and classification analysis
Separate facts from conclusions, cite current sources, record assumptions, and escalate uncertainty.
- 04
Map requirements and capabilities
Connect each applicable requirement to a system owner, enterprise capability, procedure, control, and evidence source.
- 05
Close supplier dependencies
Track instructions, technical material, contractual rights, change notices, incident information, and unresolved gaps.
- 06
Validate operation and change
Test evidence, reopen analysis after material change, and report overdue or blocked work to accountable leadership.
The output should be a system-specific work queue and enterprise capability roadmap, not a single readiness percentage.
Where the main weakness is control design, continue with the AI control library framework. Where the weakness is evidence, use the AI governance evidence checklist to define what operating records must be retained.
Ongoing readiness
Treat regulatory readiness as a maintained state
A system can leave its original readiness basis when its intended purpose, users, model, data, integration, autonomy, supplier, geographic deployment, or organisational activity changes. Change management should identify which role, classification, risk, documentation, control, and evidence decisions must reopen. A release note or vendor announcement is only a trigger; an accountable reviewer must decide its effect on the governed use.
Manage enterprise capabilities and system obligations at different levels. AI literacy, inventory standards, supplier governance, incident coordination, and reporting may be shared capabilities, while instructions, oversight design, monitoring, or technical records may be specific to one system and role. Linking the two levels prevents every project from inventing its own process while keeping system owners accountable for evidence in their context.
Sequence work according to the decision it unlocks. An unresolved role may block the requirements map; missing intended-purpose evidence may block classification; missing supplier material may block control design. Record those dependencies explicitly and avoid marking downstream tasks complete on assumptions. This makes the checklist useful to programme leaders because it shows the critical path, not just the number of activities underway.
Management reporting should separate confirmed completion, work in progress, unresolved legal questions, missing supplier evidence, accepted dependency, and overdue remediation. This makes uncertainty governable and prevents a portfolio average from hiding one material system with no defensible basis.
For deeper analysis of one decision branch, use the EU AI Act risk-classification guide; for documentation ownership and provenance, continue to the governance-documentation guide.
FAQ
Frequently asked questions
Does an EU AI Act readiness checklist prove compliance?
No. It organises systems, facts, role and classification questions, requirements, owners, controls, and evidence. Compliance is a legal conclusion based on applicable provisions and system-specific circumstances; a readiness exercise should state its limitations.
Which AI systems should enter readiness screening?
Begin broadly with internally developed systems, purchased products, embedded features, configured services, APIs, general-purpose models, pilots, and material employee uses. Candidate systems can later be excluded with an owned, documented rationale.
How should an organisation determine whether it is a provider or deployer?
Document what the organisation actually does with each system, including development, commissioning, branding, market placement, use under its authority, modification, and changes to intended purpose. Route the verified facts to qualified legal or compliance authority for the conclusion.
What evidence should a readiness programme retain?
Retain inventory sources, intended-purpose records, role and classification analyses, cited legal sources, approvals, requirement mappings, supplier documents, control procedures, operating evidence, incidents, changes, open questions, and remediation closure.
What changes should trigger reassessment?
Material changes to purpose, users, affected people, model, data, integrations, autonomy, supplier, geography, organisational activity, or authoritative guidance should reopen the affected analysis and controls.
How should missing supplier information be handled?
Record the missing item, why it matters, responsible supplier and internal owner, due date, interim restriction or compensating control, escalation threshold, and the decision that cannot yet be completed.
Should every readiness task be managed centrally?
No. Central governance should define standards, coordinate dependencies, and report portfolio exposure. System, business, product, data, security, procurement, and control owners should remain accountable for work within their authority.