EU AI Act — 25-point readiness checklist¶

Ready · v1.2 · Last reviewed 2026-08-03

Purpose. A fast self-assessment of where your organisation stands against the EU AI Act. Work through it, mark what is true today, and treat every unticked box as a backlog item.

When to use it. As a first baseline, then quarterly, and again whenever you launch or materially change an AI system.

How to use it. Answer honestly rather than optimistically — an inflated baseline produces a plan that fixes the wrong things. Each item names the templates that close it. For a scored version tailored to your role, take the interactive assessment.

The template¶

This checklist is generated from the same question bank as the interactive assessment, so the two can never disagree.

Tick the boxes as you go — your progress is saved in this browser and nothing is uploaded.

Inventory¶

3. We know which role we play for each system — provider, deployer, importer, or distributor.
Build it yourself and put your name on it, you are likely a provider. Use someone else's tool, you are likely a deployer. The obligations differ sharply, and you can be both for different systems. Fine-tuning or rebranding a third-party model can make you a provider.
Evidence: The role determination recorded per system in the AI inventory, with the reasoning.
Fix with: AI System Inventory · AI Governance Framework
4. We have assessed which parts of the Act apply given our EU market exposure.
The Act reaches you if you place a system on the EU market, or if its output is used in the EU — regardless of where you are established. Being outside the EU is not by itself an exemption.
Evidence: A written scope assessment covering EU market placement and where system output is used.
Fix with: AI Governance Framework · Governance Charter
5. Every AI system in use or development is captured in a central inventory.
One list, owned by a named person, covering built, bought, and embedded AI — including AI features switched on inside SaaS you already licence. If you cannot say where the list lives, answer No.
Evidence: The inventory itself, plus evidence of how it is kept current (intake gate, discovery sweep).
Fix with: AI System Inventory · Data Asset Register
6. Each system is classified by risk tier — prohibited, high-risk, limited, or minimal.
Classification is a decision with a date and an owner, recorded against the system. "We think most of ours are low risk" is not a classification.
Evidence: Classification recorded against each system with a date, an owner, and the rationale.
Fix with: AI System Inventory · AI Risk Assessment · AI Governance Framework
7. General-purpose AI models we build or integrate are identified, with their obligations mapped.
Covers foundation models you train and, more commonly, commercial LLMs you build on. Integrating GPAI into a product can pull you into provider duties for the resulting system.
Evidence: A list of GPAI models in use, mapped to the obligations each attracts.
Fix with: AI System Inventory · Third-Party AI Risk Policy · AI Development & Deployment Standard
8. The inventory records purpose, data sources, model or vendor, and lifecycle stage.
A list of system names is not an inventory. The test: could you answer a regulator's "what does it do, on what data, from whom, and is it live?" without going to ask around.
Evidence: Inventory export showing the fields populated for a sample of systems, not just the headers.
Fix with: AI System Inventory · Data Asset Register · Model Card / Model Risk Documentation

Risk¶

9. We have confirmed that no system performs a prohibited practice.
Social scoring, manipulative or exploitative techniques, untargeted scraping of facial images, emotion inference in workplaces or schools, and most real-time remote biometric identification in public. This needed to be true from February 2025.
Evidence: A completed prohibited-practice screen per system, signed off and dated.
Fix with: Acceptable AI Use Policy · AI Risk Assessment · AI Governance Framework
10. We screen new use cases against the prohibited list before development starts.
A gate at intake, not a review at launch. The point is to stop work before money is spent, so it must sit early enough that someone can still say no.
Evidence: The intake process document plus screening records for recent new use cases.
Fix with: Acceptable AI Use Policy · AI Development & Deployment Standard · Decision Rights & Escalation
11. High-risk systems have a documented risk management process across the lifecycle.
Continuous, not a one-off sign-off: identify, evaluate, mitigate, then keep checking once the system is live and its inputs drift.
Evidence: A risk assessment per high-risk system, with review dates that have actually been met.
Fix with: AI Risk Assessment · Risk Register · Control Library & Assurance Map
16. Systems meet expected accuracy, robustness, and cybersecurity levels, with evidence.
Declared metrics with test results behind them, including behaviour under adversarial input and on edge cases. "It performed well in testing" without numbers is a No.
Evidence: Test results with declared metrics, subgroup performance, and adversarial testing evidence.
Fix with: AI Development & Deployment Standard · Model Card / Model Risk Documentation · Control Library & Assurance Map

Documentation¶

12. Data governance for training, validation, and test data addresses relevance, representativeness, and bias.
Do you know where training data came from, whether you may lawfully use it, who it does and does not represent, and what you did when you found a skew?
Evidence: Data documentation covering source, licence, representativeness testing, and bias findings.
Fix with: Data Governance Framework · Data Governance Policy · Data Quality Standard
13. Technical documentation is maintained and current for each high-risk system.
Annex IV sets out what it must contain. The failure mode is not absence but staleness — documentation written at launch and never touched again.
Evidence: Technical documentation per Annex IV, with a version history showing it is maintained.
Fix with: Model Card / Model Risk Documentation · AI Development & Deployment Standard
14. Systems automatically log events sufficient for traceability.
Machine-generated logs, retained long enough to reconstruct what a system did and why on a given date. Application logs often do not capture the model inputs and outputs that actually matter here.
Evidence: Log configuration and a retention policy, plus a sample log proving inputs and outputs are captured.
Fix with: AI Development & Deployment Standard · Control Library & Assurance Map · Issue & Incident Log
17. A conformity assessment route is identified and planned before the applicable deadline.
Know whether your route is self-assessment or a notified body, and how long it takes. Notified-body capacity is finite and the queue will not be shorter closer to the deadline.
Evidence: A conformity assessment plan naming the route, the body if applicable, and the target date.
Fix with: AI Governance Framework · Control Library & Assurance Map
24. Where personal data is involved, a DPIA or equivalent assessment is completed and linked.
AI Act compliance does not discharge GDPR. High-risk AI touching personal data will almost always need a DPIA, and the two assessments should reference each other rather than sit in separate drawers.
Evidence: The completed DPIA, the DPO's recorded opinion, and its cross-reference to the AI assessment.
Fix with: Processing & DPIA Log · Data Classification & Handling Policy · AI Risk Assessment

Oversight¶

1. We have a named executive owner accountable for AI Act compliance.
One person, by name, not a committee and not "the CTO's team". If something went wrong tomorrow, this is who the board would call. If two people would both say "not me", answer No.
Evidence: A board minute, terms of reference, or role description naming the individual and the accountability.
Fix with: Governance Charter · Roles & Responsibilities · RACI Matrix
2. AI governance is a standing agenda item at a committee that minutes its decisions.
A recurring forum with terms of reference, a quorum, and written minutes. Ad-hoc conversations, however senior, do not count — the evidence is the minute, not the meeting.
Evidence: Committee terms of reference plus the last two sets of minutes showing AI decisions taken.
Fix with: Committee Charter (Terms of Reference) · Board Pack Template
15. Human oversight measures are designed in and genuinely operable by real people.
The honest test: can the named human actually understand the output, and do they have the authority, time, and confidence to override it? A reviewer approving 400 decisions an hour is not oversight.
Evidence: Oversight design documentation, override statistics, and the reviewer's training record.
Fix with: AI Governance Framework · Decision Rights & Escalation · AI Risk Assessment
18. Post-market monitoring and a serious-incident reporting process exist.
Someone watches live performance, and there is a defined path — with a clock on it — for reporting serious incidents to the relevant authority.
Evidence: The monitoring configuration and a documented incident reporting procedure with named owners.
Fix with: Issue & Incident Log · Control Library & Assurance Map · KPI / KRI Dashboard

Transparency¶

19. People are told when they are interacting with an AI system.
Clear at the point of interaction, not buried in terms of service. Applies to chatbots and AI-driven assistants unless it is obvious to a reasonable person.
Evidence: Screenshots or UI evidence of the disclosure at the point of interaction.
Fix with: Acceptable AI Use Policy · AI Governance Framework
20. AI-generated or manipulated content is marked or watermarked.
Synthetic audio, image, video, and text intended to inform the public must be machine-readably marked. This includes marketing material your teams generate.
Evidence: Marking or watermarking configuration, plus samples of generated content showing it applied.
Fix with: Acceptable AI Use Policy · AI Development & Deployment Standard
21. Emotion recognition or biometric categorisation, if used, is disclosed to affected people.
If you use neither, answer Not applicable. Note that emotion inference in workplaces and education is prohibited outright, not merely restricted.
Evidence: Disclosure notices, or a documented confirmation that neither technique is used.
Fix with: Acceptable AI Use Policy · Processing & DPIA Log

Third-party¶

22. For GPAI we use, we hold provider documentation and understand training-data transparency expectations.
Do you actually have the model documentation from your vendor, or do you just assume it exists? "It is on their website" only counts if someone has read it and filed it.
Evidence: The provider documentation you actually hold on file, not a link to a vendor website.
Fix with: Third-Party AI Risk Policy · AI System Inventory
23. Vendor contracts flow down AI Act obligations and evidence rights.
Right to obtain documentation, to be told about material model changes, and to audit or receive assurance. Standard SaaS terms almost never include these unless you asked.
Evidence: Executed contracts or amendments containing the AI clauses, for your critical vendors.
Fix with: Third-Party AI Risk Policy · Control Library & Assurance Map

Literacy¶

25. Staff who build, buy, or operate AI have AI literacy appropriate to their role.
A live obligation since February 2025, and one of the few that applies to everyone regardless of risk tier. The 2026 Omnibus softened it: you must take measures to SUPPORT the development of AI literacy, not guarantee any individual reaches a particular level. Proportionate to role — a procurement lead needs different literacy from an ML engineer.
Evidence: Training completion records by role, plus the syllabus showing it is role-appropriate.
Fix with: Acceptable AI Use Policy · Roles & Responsibilities · Governance Charter

Turn gaps into action¶

Every unticked item maps to something in this kit. For a scored, role-specific version of this checklist — with a report you can present to a board or a regulator — take the interactive assessment. Your answers stay in your browser.

Adaptation notes¶

Non-EU organisations: The Act can still reach you where output is used in the EU. Work through the checklist anyway, then confirm scope with counsel — territorial reach is the question most often got wrong.
Deployers rather than providers: Items 11–18 are mostly provider obligations, but you inherit exposure through what you deploy. Focus on 1–10 and 22–25, and press vendors on the rest via Third-Party AI Risk Policy.
Using this with the assessment tool: The interactive assessment covers these 25 points plus role-specific questions, and scores them by severity. This page is the reference; the tool is the working version.

EU AI Act timeline (2026 Digital Omnibus) — Ready
AI System Inventory — Ready
AI Risk Assessment — Ready
Board Pack Template — Ready

Not legal advice

These templates are a head start, not a substitute for professional judgement. Adapt them to your jurisdiction, sector, and risk appetite, and have qualified counsel review anything material before you rely on it.