The AI Readiness Checklist: 25 Checks Before You Fund an AI Project
Read Time 19 mins | Written by: Vinayak Bhagat
What should you check before funding an AI project? Twenty-five things, in five groups: the problem (is this worth solving), the data (can it be solved here), the workflow (will anyone actually use it), the economics (does it survive the invoice), and the control (can you defend it later). Every group has to be green before the money moves. A project that fails one group does not need a smaller budget; it needs a different plan.
Most AI projects are not killed by the model. They are killed six months later by something that was knowable on day one: the data lives in a system nobody owns, the people who were supposed to act on the output have no room in their day, or the unit cost quietly triples the moment usage becomes real.
None of that requires a pilot to discover. It requires a list, and the discipline to run it before the budget is approved rather than after. What follows is the list we run with mid-market clients at the funding decision. It is deliberately unglamorous, and it is the cheapest hour anyone spends on an AI programme.
The Five Green Lights
Twenty-five checks, five to a group. Treat each group as a light rather than a score: it is green, or it is not. The point of the structure is that the groups fail differently and are fixed by different people, so a red light tells you who to go and talk to.
| Green light | The question it answers | Who fixes it when it is red |
|---|---|---|
| 1. The Problem | Is this worth solving at all? | The business owner |
| 2. The Data | Can it be solved here, with what we have? | Data and platform engineering |
| 3. The Workflow | Will anyone actually use the output? | The operating team and their manager |
| 4. The Economics | Does it survive contact with the invoice? | Finance, with engineering |
| 5. The Control | Can you defend it in twelve months? | Legal, security and the accountable owner |
If you want to know how ready the organisation is rather than how sound a single project is, that is a different exercise: our seven-dimension readiness scorecard scores the enterprise across dimensions and bands. This list scores one decision.
The AI Readiness Checklist
The twenty-five checks as a tick-box worksheet you can take into the funding meeting: one page per green light, a write-in box for the evidence each check produced, and a sign-off page for the five owners. Fill in the form and the PDF opens right here, no email round-trip.
The Problem: Five Checks
This is the group most often skipped, because it feels like it has already been answered in the slide deck. It has not. A problem statement that survives these five is specific enough to build against.
| # | Check | Green looks like |
|---|---|---|
| 1 | A named business owner, not a sponsor | One person whose own numbers move if this works |
| 2 | A baseline measured today | The current number, from the current system, written down |
| 3 | A decision that changes as a result | You can name the choice someone makes differently |
| 4 | Value per unit of work, not in aggregate | What one completed task is worth, in money or hours |
| 5 | The cost of doing nothing | A defensible answer that is not "we fall behind" |
The red flag: the problem is described as a capability rather than an outcome. "We want to use AI in customer service" is a budget line looking for a justification. "We want first-response time on billing queries under an hour without adding headcount" is a project.
The Data: Five Checks
Models are rented; data is owned. This group is where most funding decisions should be paused rather than declined, because the fixes are real work with a real schedule. The method behind these checks is in the four-layer data foundation; what follows is only the go/no-go version.
| # | Check | Green looks like |
|---|---|---|
| 6 | A single source of record | One system is authoritative, and everyone agrees which |
| 7 | A working access path | Someone has actually pulled the data, not promised to |
| 8 | Quality controlled at entry, not on a cleanup project | Validation exists where the record is created |
| 9 | Ground truth you can evaluate against | Examples of a right answer exist and someone owns them |
| 10 | The right to use it for this purpose | Contracts and consent cover the use, in writing |
The red flag: check 7 is answered with an architecture diagram. If nobody has pulled a real extract and looked at it, the data question is still open, whatever the diagram says. If you do not yet know what systems hold the data at all, start with a stack audit instead of a funding request.
The Workflow: Five Checks
A model that produces a correct answer nobody sees has produced nothing. This group is about the twenty centimetres between the output and the person who acts on it, and it is where pilots most often die quietly.
| # | Check | Green looks like |
|---|---|---|
| 11 | The output lands where the work already happens | In the CRM, the ticket, the queue — not a new tab |
| 12 | A named role acts on it | A job title, and that person knows it is coming |
| 13 | A defined handoff to a human | The threshold where it stops and asks is written down |
| 14 | A failure path that is not "email someone" | Wrong output is detectable, reversible and attributable |
| 15 | The change to the day job is costed | Someone has said what stops, not only what starts |
The red flag: the rollout plan is training. Training is what you do when the workflow already fits; it is not a substitute for making it fit. If the honest answer to check 15 is "they will do this as well as everything else", the project is asking a team to absorb work it has no capacity for.
The Economics: Five Checks
AI spend is usage-shaped, which means the pilot invoice tells you very little about the production one. Price the unit, not the licence. The mechanics of controlling it once it is live are in our FinOps guide for AI workloads.
| # | Check | Green looks like |
|---|---|---|
| 16 | Cost per completed task, modelled at real volume | A number, with the assumptions visible |
| 17 | Retries and human review are inside that number | The tasks that fail twice are priced too |
| 18 | An owner for the run rate | A named budget holder who sees the bill monthly |
| 19 | A unit-cost trigger to stop or re-scope | Agreed in advance, in writing, by that owner |
| 20 | Build versus buy answered on this workload | Not answered by preference or by what is on the roadmap |
The red flag: the business case is expressed only as total savings. Aggregate savings survive scrutiny for exactly one quarter. Unit cost is what tells you whether the thing gets cheaper or more expensive as it succeeds, and that is the number that decides whether it lives.
The Control: Five Checks
These are the questions that are cheap to answer now and expensive to answer under pressure. None of them requires a policy programme; all of them require a name and a written line.
| # | Check | Green looks like |
|---|---|---|
| 21 | One accountable owner for the outcome | A person, not a committee and not the vendor |
| 22 | An evaluation set you own | Your examples, your scoring, portable if you leave |
| 23 | Logging good enough to reconstruct a decision | Inputs, outputs and the version, retained and searchable |
| 24 | A written answer on where your data goes | Retention, residency and training use, in the contract |
| 25 | An exit path, priced | You know what you take with you and what breaks |
The red flag: checks 22 to 25 are answered by pointing at a vendor's documentation. Documentation is a description of intent; a contract is a commitment. If a vendor is in the frame, the longer version of this conversation is the eight questions we ask before deploying an agent.
One more thing belongs here even though it is not on the list: before you fund anything new, find out what is already running. Teams adopt AI tools faster than procurement records them, and an unfunded project usually already exists in some form. Shadow AI is not a compliance footnote here; it is free evidence about what people actually need.
Three Ways Teams Fail This Checklist Politely
Marking a check green because someone is confident
Confidence is not evidence. Every green should point at an artefact: an extract, a contract clause, a named person who has agreed in writing. If the only artefact is a person's certainty, the light is amber.
Deferring a whole group to "the pilot will tell us"
A pilot is a good way to answer questions about model behaviour. It is a very expensive way to discover that nobody owns the data or that the team has no capacity. Pilots should test the uncertain part, not the knowable part.
Running the list after the budget is approved
Once money is committed, red lights get renegotiated into amber ones. The checklist only has teeth before the decision. Run it in the room where the decision is made, with the people who would have to fix each group.
What a Red Light Should Actually Trigger
A red group is not a rejection. It is a re-sequencing instruction, and each group re-sequences differently.
| Red group | Do this instead of funding |
|---|---|
| The Problem | Send it back. There is no version of this that a budget fixes. |
| The Data | Fund the data work as its own project, with its own outcome. |
| The Workflow | Redesign the process first, at zero software cost. |
| The Economics | Shrink the scope until one unit is provably worth it. |
| The Control | Fix it now. It is the cheapest group to close and the worst to inherit. |
If you would rather run the twenty-five checks on paper with the people who own them, the tick-box worksheet version is free to download.
AI Readiness Checklist: Frequently Asked Questions
How is an AI readiness checklist different from an AI readiness assessment?
A checklist gates one project at one moment: the funding decision. An assessment scores the organisation across dimensions and tells you where you are as a whole. You can pass this checklist while the organisation still scores poorly overall, and you can score well overall and still have a specific project that should not be funded. If you want the organisational view, use the seven-dimension scorecard.
How long does it take to run 25 checks?
About ninety minutes, if the right five or six people are in the room, and considerably longer if they are not. Most of the time is spent on the data group, because it is the only one where the honest answer often requires someone to go and look. Do not run it asynchronously: the value is in the disagreement between the business owner and the person who knows the data.
Do all 25 checks have to be green?
All five groups do. Within a group, one amber check with a named owner and a date is workable; two amber checks in the same group means the group is red. The structure exists so that you are making a decision about a coherent risk rather than counting ticks.
Does this apply to buying an AI product as well as building one?
Yes, and groups four and five matter more when you are buying, because the answers are contractual rather than technical. The vendor-specific version of those questions, with the good answer and the red flag for each, is in the agentic AI buyer's checklist.
Run the 25 checks on your next AI project
We run this list with mid-market leadership teams as a short working session, and we are candid when the answer is "not yet, and here is what to fund first". If you would rather have the organisational picture, that is our AI readiness assessment; if you already know the project and want help building it, that is our generative AI practice.