A checklist is only useful if working through it changes what you do. This one is built so that every item has a verifiable answer: something you can point at, not something you can feel confident about.
It follows the seven dimensions of AI readiness in order. Work through it with the people who would actually be affected rather than with IT alone, and write the answers down, because the document you produce is the most useful thing about the exercise.
Where an item does not apply to your organization, mark it so rather than skipping it. A checklist with unexplained gaps is worse than one with honest ones.
Before you start
Two ground rules make the rest of it work.
Assess what is, not what is planned. The single most common way this exercise fails is that people answer for the state the organization intends to reach. A project that will deliver central identity management next year does not give you central identity management today, and an AI initiative scheduled against the intention rather than the reality will slip by exactly that much.
Name the owner of every answer. If nobody owns an item, that is itself the finding, and it is usually the most valuable one on the page.
Strategy and leadership
- Name the executive accountable for AI decisions. Confirm they can approve funding and can also cancel work.
- Write down, in one page, the outcomes AI is meant to improve. Name a process, a group of people and a number that would move.
- Identify the budget line, including the cost of running a service after the project closes rather than only the cost of building it.
- Write down what the organization will not use AI for. This is usually more useful than the list of what it will.
- Confirm senior leaders would describe the objective consistently. Ask two of them separately.
- Establish who has to approve before anything is purchased, and what they will want to see.
AI use cases
- List candidate processes by name, not by capability. Each entry should identify a team, a task and a rough volume.
- For each candidate, record where the information it depends on physically lives.
- For each candidate, record what a good outcome would look like and the number you would measure.
- For each candidate, record what a wrong output would affect and who would be harmed by it.
- Score value and feasibility separately. A high value candidate that is infeasible this year belongs on the roadmap, not in the pilot.
- Identify the smallest candidate that would still be worth doing. That is usually where to start.
Sector-specific starting lists are in AI use cases for K-12 school districts and AI use cases for local government.
Data readiness
- Inventory the systems holding records a candidate use case would need. Record the owner of each.
- Classify those records. Three categories is enough to start: public, internal, sensitive.
- Identify which sets have a single authoritative version and which have several that disagree.
- Confirm, in writing and per system, whether data can be retrieved through an export, an API or a query rather than by hand.
- Record the retention obligations that attach to each set, including anything driven by public records law in your jurisdiction.
- Identify the unstructured material a knowledge use case would draw on: policies, procedures, prior correspondence. Record who maintains it and when it was last reviewed.
- Note where institutional knowledge exists only in individual staff judgment. That is a documentation task, and it is worth doing whether or not AI follows.
Technology and infrastructure
- Record what runs where: cloud, on premises, hosted by a supplier.
- Per system in scope, record whether it has a documented interface, a supported export, or neither.
- Confirm whether identity is centrally managed, and whether access can be revoked in one place.
- Establish whether network capacity and endpoints can support the intended usage pattern.
- Model the running cost at realistic volumes rather than pilot volumes. Record what happens if adoption doubles.
- Confirm the estate is stable enough that adding to it is wise. If a core system is mid-migration, that is a sequencing finding.
Cybersecurity and privacy
- Discover which AI services staff are already using. Ask without consequence attached; the answer is usually larger than expected.
- Review access so that an AI service cannot reach more than the person operating it should.
- Decide, in writing, which categories of information may and may not be sent to an external service.
- Establish logging so that use can be reviewed, and confirm somebody would actually look at it.
- Record the privacy obligations attaching to the records in scope, including any contractual ones.
- Identify where data would be processed and stored, and whether that is acceptable under your obligations.
- Add AI-specific risks to your risk register rather than assuming existing entries cover them.
The NIST Cybersecurity Framework and CISA's artificial intelligence resources are the references most public bodies are expected to be aware of. The practical version is in AI cybersecurity risks to assess before deployment.
Governance and compliance
- Name who approves a new AI tool, and give them an explicit route to decline one.
- Write a one-page acceptable-use position and confirm staff have seen it, not merely that it exists.
- Add AI questions to the supplier review you already run: where data goes, whether it trains a model, what happens on termination.
- Decide which outputs require a human review before they take effect, and record that decision.
- Confirm how AI-assisted records are retained and disclosed under your public records obligations.
- Record where accountability sits when an AI-assisted decision is challenged.
- Set a review date for the position. Once a year is usually enough; never is not.
The NIST AI Risk Management Framework is the most commonly requested reference point, and a proportionate version for public bodies is in an AI governance framework for public-sector organizations.
Workforce and adoption
- Identify who will be expected to rely on AI output, and confirm they could recognize a wrong answer in their own subject matter.
- Plan training aimed at specific roles rather than a single general session.
- Talk to affected staff about how the work would change, before launch rather than after.
- Publish a route for questions and problems, and confirm somebody is responsible for answering it.
- Record which roles are materially affected and what that means for them. Silence here is what generates resistance.
- Identify who will own the tool after the project team disbands.
How often to run it
Once, thoroughly, then annually, and again whenever something structural changes.
The annual pass is quick if the first one was honest, because most of what you recorded is still true and you are updating rather than discovering. What forces an out-of-cycle pass is a change to the ground underneath: a core system replaced, a merger or consolidation of services, a new statutory obligation, a significant staffing change in the team that owns any of the answers, or a supplier adding AI features to a product you already run.
That last trigger is the one organizations miss, because nothing announces it. A platform you bought three years ago acquires an AI capability, it is enabled by default, and your data flow has changed without a procurement event or a decision. Add a line to your annual pass asking which existing suppliers have added AI features since the last one, and whether you were told.
Scoring it, if you want a number
Score each dimension out of one hundred and take the plain average for an overall figure. Do not weight the dimensions: which one binds depends on the organization, and weighting encodes a guess about that.
Read the per-dimension scores rather than the average. An organization at seventy overall with one dimension at fifteen is not seventy percent ready, it is blocked in one place, and the average obscures exactly the thing you needed to see.
If you would rather not score it by hand, the AI Readiness Self-Assessment does it in about eight minutes and returns recommendations for your weakest dimensions.
What this checklist does not establish
It is worth being explicit, because a checklist completed in good faith can be mistaken for something it is not.
Working through this does not constitute a security assessment, a privacy impact assessment, an audit, or a determination that your organization complies with any statute, regulation or contract. It is a structured way of finding out what you know and what you have not yet examined. Several items above will point at obligations that need a qualified opinion, and this page is not that opinion and cannot substitute for one.
It is also self-reported. The most common finding in a full readiness assessment is not that an organization was wrong about a dimension but that it was confident about one it had never tested, most often data accessibility and access scoping. If the answers matter enough to be checked rather than believed, that is what an external assessment is for.
If you would like a second reading of a checklist you have already completed, send us what you have and we will tell you what we would want to look at more closely.