AI readiness checklist: questions to answer before a first build

Most organisations that start an AI build have already decided what they want: a chatbot, a forecast, a tool that reads documents. Fewer have checked whether the conditions for it exist. That gap tends to appear later, as a pilot that works in a demonstration and then stalls before production. A short, honest checklist before the first build costs far less than finding the gap halfway through.

An AI readiness checklist is a structured set of questions that tests whether an organisation can support a first AI build: a clear use case and owner, people with time to run it, data that is reachable and trusted, and a plan for how work will change. It turns a vague feeling of readiness into answers you can check.

This guide is for the person who has been handed the AI mandate and needs a defensible starting point. It sets out twenty questions across four areas: strategy, people, data and change. For each question we explain why it matters and what a good answer looks like. We then cover how to score yourself without flattering the result, and what to do when one area scores low.

Our free AI readiness assessment asks sixteen questions across the same four areas and scores you on the spot, with no email gate. Use this article to understand the reasoning behind each area, and use the assessment when you want a score you can share with colleagues.

What AI readiness means

AI readiness is the state in which an organisation can take a chosen use case from idea to a working system in production, and keep it working after launch. It is not a measure of enthusiasm, budget or the number of tools a team has trialled. An organisation can have all three and still be unready, because the data underneath its systems has never been made reliable.

We describe AI as a magnifying glass. Placed over strong foundations, it amplifies gains. Placed over weak foundations, it accelerates failure and exposes risk. A readiness check is the step that tells you which of the two you are about to magnify. The recurring causes of stalled builds, set out in our guide on why AI projects fail and the checks that predict it, are nearly all visible in advance to anyone who asks the right questions.

A readiness check tells you what you are about to magnify.

Readiness is also different from maturity. A maturity model describes how far an organisation has progressed with AI over time, from ad hoc experiments to scaled, governed production. A readiness checklist asks a narrower question, which is whether you can start the next build well. Our guide to AI maturity models and what each stage looks like covers the longer view. The two work together: the maturity model shows where you stand, and the checklist shows what to fix before the next step.

Four areas, and why these four

The checklist groups its questions into four areas. Each one covers a different reason that first builds stall.

• Strategy. Whether there is a specific problem worth solving, an owner for it and an agreed measure of success.
• People. Whether the organisation has the sponsorship, skills and time to deliver the system and run it afterwards.
• Data. Whether the data the use case needs exists, can be reached, is trusted and is governed.
• Change. Whether the people whose work will change are prepared to use the result, and whether the risks are understood.

Technology is not a separate area. Platforms matter, but they rarely decide whether a first build succeeds. Where a technical gap does matter, it shows up under data, as data that cannot be reached, joined or refreshed in time. Some frameworks list five or more pillars, with infrastructure and governance on their own. We fold infrastructure into data, and governance into data and change, because that is where the questions have practical consequences.

Each area below has five questions. Score each one as you go, using the method in the scoring section later in this guide.

Strategy: five questions

Strategy questions test whether the build has a reason to exist that someone will defend when the work becomes difficult. Weak strategy is the most common reason a technically sound pilot is quietly dropped.

• Is there a specific business problem, stated without naming a technology? A good answer describes the problem in the words of the people who have it, such as supplier queries that wait too long for a reply, and does not mention a model or a tool.
• Is there one person who owns the outcome? A good answer names an individual, not a committee, who will decide trade-offs and answer for the result.
• Is there a measure of success agreed before the build starts? A good answer names a metric the business already tracks, its current value and the change that would count as success.
• Is the first use case small enough to ship and valuable enough to matter? A good answer describes a use case that can reach production in months, not years, and that saves time or money someone will notice.
• Does the use case connect to a priority leadership already funds? A good answer links the build to an existing objective, so it does not compete for attention with the work the board is already watching.

If these answers are clear, the next step is a plan for delivery. Our guide to AI implementation strategy, from first use case to live covers how to sequence that work.

People: five questions

People questions test whether the organisation can carry the build through, and whether anyone will look after it once it is live. Many first builds have a capable team on paper and no protected time in practice.

• Is there a sponsor with authority to remove blockers? A good answer names a senior person who can release budget, unblock data access and settle disputes between teams.
• Does someone in-house understand both the data and the business process? A good answer names a person who can explain how the process works and where its data comes from, because no external team can supply that knowledge.
• Do the people on the build have protected time? A good answer states how many days a week each person will give to the build, agreed with their line manager.
• Who will run the system after go-live? A good answer names the team that will monitor it, handle issues and decide on changes, before the build starts.
• Do you know which skills you will buy in and which you will build? A good answer separates the specialist work you will bring in from the skills you need to keep in-house for the long term.

Data: five questions

Data readiness for AI is where most first builds are won or lost. A model can only be as reliable as the data it reads, and data problems are the hardest to fix once a build is under way. These five questions carry the most weight for that reason.

• Do you know where the data for this use case lives? A good answer lists the named systems, the owner of each and how each one can be reached.
• Can the data be reached by a governed route, without manual exports? A good answer describes a repeatable connection, such as a warehouse or a controlled interface, rather than spreadsheets emailed between teams.
• Do the key business terms have one agreed definition? A good answer points to a written definition of terms such as customer, order or active account, held somewhere like a data dictionary.
• Is the quality of the data measured, not assumed? A good answer gives current measures for accuracy, completeness and timeliness. Our guide to data quality dimensions and how to measure them explains each one.
• Is access controlled, with personal data identified? A good answer shows who can see what, where personal data sits and the lawful basis for using it. Our guide on what data governance involves covers the roles behind this.

If several of these answers are weak, the first build is the foundation itself: a cloud data warehouse, with data cleaned in stages from bronze to silver to gold, and a semantic layer that holds one governed definition of your business. That is the work of the data foundation, and it is what makes data AI-ready.

Nothing on top is worth building until the data underneath can be trusted.

Change: five questions

Change questions test whether the result will be used, and whether the organisation understands what can go wrong. A system that works but is ignored delivers nothing.

• Do the people whose work will change know it is coming? A good answer describes how they have been involved, ideally in shaping the use case rather than being told about it at launch.
• Is it clear where a person stays in the loop? A good answer states which decisions the system makes, which it recommends and which a person still takes. Our guide to keeping people in AI decision processes covers the options.
• Have the risks been named, including regulatory ones? A good answer lists the main risks, such as wrong answers, bias and data protection, with an owner for each. An AI governance checklist gives a starting structure.
• Is there a plan for when the system is wrong? A good answer describes how errors are reported, who reviews them and how the system is corrected.
• Will the result be measured after launch, not only at launch? A good answer sets a review date and names the person who will compare the metric against the success measure agreed at the start.

Scoring yourself honestly

A simple scoring method works well. Give each question zero, one or two points. Zero means no, or that you do not know. One means partly, or that the answer depends on a single person. Two means yes, with evidence you could show a colleague. Each area then scores out of ten, and the checklist scores out of forty.

The scoring only helps if it is honest. These rules keep it that way.

• Score "I do not know" as zero. An answer nobody can give is a gap, not a neutral.
• Ask for evidence: a document, a dashboard or a named person. A belief that something is true scores one at most.
• Score the weakest relevant system, not the best one. A use case that needs three systems is limited by the worst of them.
• Ask a second person, ideally from another team, to score separately. Where your scores differ, the difference is worth discussing before the build starts.
• Score the use case you plan to build, not the organisation in general. Readiness for one use case can be high while readiness for another is low.

The total matters less than the shape. An organisation with strong strategy and weak data is in a different position from one with clean data and no owner, even if both totals are the same. Look first at the lowest area, because that is where the build will stall.

If you would rather not score by hand, the AI readiness assessment scores strategy, people, data and change on the spot and shows where your gaps sit.

What to do with a low score

A low score is not a reason to abandon AI. It tells you what the first piece of work should be. The aim is a first win that pays for the second, and that starts with the weakest area.

A low strategy score

Narrow the ambition to one use case and write down its owner and success measure before anything else. If the organisation has several competing ideas, rank them by value and by how ready their data is, and pick the one that scores well on both. Our AI strategy service exists for this stage: a readiness assessment, a sequenced roadmap and a business case, designed by the team that delivers it.

A low people score

Secure a sponsor and protected time before you start. If no one in-house understands both the process and its data, find that person first, because external help cannot replace them. Decide who will run the system after launch, and include that team from the first week.

A low data score

Fix the data before building the AI. Do not start the AI build anyway and plan to clean the data later, because the build will inherit every inconsistency and expose it to users. Start with the data the first use case needs, bring it into one place, agree its definitions and measure its quality. This work also serves every later use case, so it is not lost effort.

A low change score

Bring the affected teams into the design, decide where a person stays in the loop and name the main risks with an owner for each. These steps take weeks rather than months, and they decide whether the finished system is used.

Sometimes the honest answer is that the AI build should wait. We say so when that is the case, and we have turned down work where the plan was to skip the foundations.

Where this leaves you

An AI readiness checklist is useful only if it changes what you do next. Answer the twenty questions for the use case you have in mind, score them honestly and look at the weakest area first. Strong strategy with weak data means the first engagement is the foundation. Good data with no owner means the first step is a decision, not a build.

Done in that order, the first build has a real chance of reaching production and paying for the second. At Smarter Services, AI document processing freed up 1.5 days of admin time each week. Results like that come from building on data that has been made ready, for a problem someone owns.

If you want a score before a conversation, take the free AI readiness assessment: sixteen questions, scored on the spot, with no email gate. If you already know where your gaps are, our AI strategy service turns your answers into a sequenced roadmap and business case, and the data foundation fixes the data before anything is built on it. Talk to us and we will tell you honestly where to start, including when the right answer is the foundation first.

Frequently asked questions