Reviewed October 2026. A working document: print the twelve questions, answer them as a leadership team, and the answers tell you where to start.
Contents: What readiness is · Leadership · Access · Data · Knowledge · Governance · Skills · Scoring · What the pattern tells you · What readiness does not require · The hour-long version
Most AI readiness assessments produce a maturity score and a radar chart, and neither tells you what to do on Monday. Readiness is better understood as a short list of conditions, each of which either holds or does not, and each of which, when it does not hold, points at a specific first move. These twelve questions are the ones we ask at the start of every engagement. A leadership team can answer them in an hour; the pattern of answers is the plan.
What readiness is
A business is ready for AI when a well-chosen first project will reach production and be used, rather than stall as a pilot. That depends on six things: whether leadership has decided and will stay the course; whether staff can use AI tools at all; whether the data the first projects need exists, is reachable and is trusted; whether the knowledge the business runs on is written down; whether there is enough governance that nobody has to invent it mid-project; and whether anyone knows how to build, buy or operate the thing. Each has two questions below, give or take, and each question has a plain answer.
What readiness is not: a technology stack, a data lake, a Chief AI Officer, or a culture programme. Businesses with all four stall; businesses with none of them ship.
Leadership: questions 1 to 3
1. Has the leadership team agreed what AI is for in this business, in one sentence? “Reduce the cost of serving a customer”, “protect margin as volumes fall”, “let the engineers spend their time engineering”, “win work we currently cannot bid for”. If the sentence exists, every opportunity can be tested against it. If it does not, the programme will chase whatever the loudest function wants. If no: the first move is a half-day leadership session, not a project.
2. Is there a named owner with time? Not a sponsor who turns up to steering meetings; an owner whose job now includes this, with a day a week freed to do it. Programmes without one drift within a quarter. If no: name one before spending anything.
3. Can the business fund a first phase without a business case for the whole programme? The first phase is discovery and a pilot. If every pound needs a five-year return calculated first, the programme will spend its first six months modelling returns it cannot yet know. If no: agree a bounded first-phase budget with a decision gate at the end.
Access: questions 4 and 5
4. Do staff have sanctioned access to an enterprise AI assistant, with terms that protect the business’s data? Copilot, Claude, ChatGPT Enterprise or equivalent, on business terms, with the no-training clause, in the tools people already use. If the answer is “we’ve blocked it”, staff are using personal accounts and the business cannot see what is being pasted where. If no: this is the cheapest and fastest move on the list; see governed access.
5. Does anyone know how AI is actually being used today? A short survey, an honest one, usually finds that a third of staff are using AI tools, that most of the use is drafting and summarising, and that a few people have built something useful and told nobody. Those people are your early adopters and your first pilot team. If no: run the survey; it takes a week and it is the start of the inventory the EU AI Act asks for anyway.
Data: questions 6 to 8
6. For the two or three use cases people talk about most, does the data exist, and does anyone know where? Not “do we have good data” in general; nobody does. For the specific use cases: is the service history in one system or four, does the quote archive go back far enough, are the drawings indexed, are the support tickets tagged? If no: a data-readiness check against the specific use cases, which takes days, not a data strategy, which takes a year.
7. Is the data reachable without a project? An API, an export, a database someone can query, a document store with permissions. Data that exists but sits in a system whose vendor charges for every export, or in a legacy application with no interface, is not ready. If no: the first technical work is an extraction path, and it should be scoped as such.
8. Does the business trust its own numbers? If two reports disagree and nobody is surprised, any AI built on that data will be disbelieved the first time it contradicts someone’s instinct. If no: start with a use case where the ground truth is unambiguous (documents, tickets, drawings) rather than one that depends on contested figures.
Knowledge: question 9
9. Is the knowledge the business runs on written down somewhere, in any form? Manuals, SOPs, past proposals, support macros, engineering notes, wiki pages, email threads that answer the same question for the fortieth time. It does not have to be tidy; retrieval-grounded systems cope with mess. It has to exist. If the answer is “it’s in Dave’s head”, the first AI project is a knowledge-capture project, and that is a good first project. If no: capture before you automate.
Governance: questions 10 and 11
10. Is there an AI usage policy, one page, that staff have read? What is sanctioned, what must never be pasted into any tool, what needs a human check before it leaves the building, who to ask. One page, because nobody reads twelve. If no: write it in a week; a template takes an afternoon to adapt.
11. Does the business know which of its AI uses the EU AI Act would call high risk, if any? For most businesses, none; for some (recruitment screening, credit, safety components in products, education), one or two. Knowing is the difference between a programme that can move fast on everything else and one that treats every idea as a legal question. If no: the classification exercise takes a morning; see the EU AI Act guide.
Skills: question 12
12. Is there anyone in the business who can evaluate an AI system’s output against the truth, in the domain it serves? Not an AI engineer; a domain expert with the patience to mark a few hundred answers right or wrong. Every AI system that reaches production does so because someone built an evaluation set, and that person is almost always an expert in the business, not in AI. If no: identify the expert and the hours before scoping any build.
Scoring your answers
Count the yeses. The number matters less than the pattern, but as a rough guide:
| Yeses | Reading |
|---|---|
| 10–12 | Ready. Run discovery, prioritise, pilot the top opportunity this quarter. |
| 7–9 | Nearly ready. Fix the specific noes first; most take weeks, not months. Discovery can run in parallel. |
| 4–6 | Foundations first. A leadership session and governed access are the first two moves; discovery after. |
| 0–3 | Start with the conversation. One leadership session, then this checklist again. |
What the pattern tells you
The noes cluster, and each cluster has a first move.
Leadership noes (1–3). Nothing else will stick. A half-day leadership session that produces the one sentence, the owner and the first-phase budget is the whole of the first move. This is the most common pattern in businesses that have “tried AI” and have a shelf of pilots to show for it.
Access noes (4–5). Fastest to fix and the highest immediate return. Governed access to an enterprise assistant, a one-page policy and a survey can be done in a month, and they produce the base layer of the Opportunity Pyramid on their own.
Data noes (6–8). The pattern that most often sinks pilots. The fix is specific, not general: a data-readiness check against the top use cases, an extraction path where one is missing, and a first project chosen where ground truth is clean. Do not let it become a data-strategy programme.
Knowledge no (9). Common in engineering, professional-services and specialist businesses. The first project is knowledge capture, and it is one of the most valuable projects a business can run with or without AI.
Governance noes (10–11). Rarely the blocker on its own, but the cause of slow programmes: every idea becomes a risk meeting. A week of policy and a morning of classification clears it.
Skills no (12). The hidden one. Businesses assume they need AI skills; what they need first is a domain expert with hours, and that is a scheduling decision, not a hiring one.
What readiness does not require
A list of things businesses believe they need first, and do not:
- A data warehouse or lake. Useful for some integrated-layer projects; irrelevant to the base and specialist layers, which run on documents and the systems already in place.
- A data science team. Most first projects are built by engineers with the modern tooling, not by data scientists, and the domain expert matters more than either.
- Clean data. Retrieval-grounded systems work on messy documents; what they cannot work on is absent documents.
- A completed digital transformation. Businesses mid-transformation often have the best AI opportunities, because the pain is visible and the systems are being touched anyway.
- Certainty about return. The first phase is designed to produce it; demanding it before the first phase is circular.
- A Chief AI Officer. An owner with time, from question 2, is enough for the first year.
The hour-long version
Put the twelve questions on one page. Give the leadership team the page a day before the meeting. In the meeting, go round the table on each: yes, no, or disagree. The disagreements are the most useful answers, because they show where the leadership team has different pictures of the business, and that is worth knowing before any programme starts. Count the yeses, read the pattern, and leave with the first move written down and owned.
If the first move is discovery, the Converge Methodology is how we run it; the discovery workshops service covers the checklist, the data check and the leadership session as a single short engagement. If the first move is a leadership conversation, we are happy to have it.