# EU AI Act — 25-point readiness checklist

**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.

---


## 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.

- [ ] **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.


## 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.

- [ ] **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.

- [ ] **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).

- [ ] **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.

- [ ] **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.

- [ ] **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.


## 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.

- [ ] **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.

- [ ] **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.


## 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.

- [ ] **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.

- [ ] **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.


## Oversight

- [ ] **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.


## Risk

- [ ] **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.


## Documentation

- [ ] **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.


## Oversight

- [ ] **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.


## 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.

- [ ] **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.

- [ ] **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.


## 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.

- [ ] **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.


## Documentation

- [ ] **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.


## 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.


---

## 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.

---

*From the [Open Data & AI Governance Kit](https://lsdeva.github.io/governance-kit/). Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — free to use, adapt, and share with attribution.*

***Not legal advice.** Adapt to your jurisdiction, sector, and risk appetite, and have qualified counsel review anything material.*