Enterprise AI Readiness: Five Checks Before You Fund the Pilot

Most enterprise AI programmes are funded before anyone asks whether the organisation is ready to absorb one. The pilot gets a budget, a vendor, and a deadline, and the readiness question surfaces nine weeks in, when it is expensive.

MIT's Project NANDA put numbers on the outcome in its July 2025 report The GenAI Divide: State of AI in Business 2025: across 52 executive interviews, surveys of 153 leaders, and 300 public deployments, 95% of generative AI pilots produced no measurable profit and loss impact. Read that precisely, because the headline gets misquoted. It does not say the technology failed. It says the value did not reach the books, which is an organisational result, not a model result.

Five checks separate the programmes that reach production from the ones that produce a demo and a slide. Each has a concrete pass test, and each has a specific remedy when the answer is no. Run them before the funding decision rather than after it.

Check 1: Is there a named decision, with an owner, that the AI changes?

Pass test: you can name the decision, the person accountable for it today, and how often it is made.

"Improve customer service with AI" is not a decision. "Whether this refund is approved without a human review" is. The difference matters because a decision has an owner, a frequency, a current cost, and an error rate you can measure before and after. A theme has none of those, which is why theme-shaped programmes cannot prove value even when the technology works.

If you fail this check: the work is not an AI project yet. Spend two weeks with the operating team turning the theme into a list of decisions, then rank them by frequency times cost of being wrong. That list is the actual roadmap, and it usually reveals that the highest-value decision is not the one that prompted the meeting.

Check 2: Does the data exist as a record, and does someone own it?

Pass test: the inputs the decision needs live in a system of record, with an owner who can grant access this quarter.

The failure mode here is subtle. Data usually exists. What is often missing is a record: a single authoritative place where a fact lives, with someone accountable for its accuracy. When the answer to "where does this number come from" is a spreadsheet a team maintains by hand, the AI project has quietly become a data project, and the schedule was written for the wrong work.

If you fail this check: do not proceed and plan to fix the data as you go. Split it. Fund the record first, with its own owner and its own success measure, and let the AI work follow it. Programmes that try to do both at once tend to deliver neither, because the model's errors and the data's errors are indistinguishable from the outside.

Check 3: Can you verify the output without trusting the model?

Pass test: you have a way to tell right from wrong that does not itself depend on the model's judgement.

This is the check that separates a system you can operate from one you can only admire. Sometimes verification is a ground truth set: a few hundred historical cases with known correct answers, held back and scored. Sometimes it is a structural rule the output must satisfy regardless of content, which is the stronger form where it exists, because it holds for cases nobody thought to test.

If the only available check is a human reading the output and forming an impression, you can still proceed, but you are buying a supervision cost rather than an automation saving, and the business case should say so in those words.

If you fail this check: build the evaluation set before the pilot. It is a week of work, it survives every vendor change, and it converts vendor selection from a demo comparison into a measurement.

Check 4: What is the reversal path when it is wrong?

Pass test: you can state what happens after a bad output, who notices, how fast, and what it costs to undo.

Every AI decision has a blast radius, and readiness is largely a question of whether that radius is contained. A misdrafted internal summary is reversible in minutes at no cost. A payment released, a price published, or a customer communication sent is not. The technology is the same in both cases; the readiness threshold is not.

We wrote the longer version of this argument in the executive delegation framework, which sets out reversibility, blast radius, verification cost, and accountability as four tests for any individual decision. For readiness purposes the short form is enough: if nobody can describe the undo, the decision is not ready to be delegated regardless of how good the model is.

If you fail this check: narrow the scope until reversal is cheap. Almost every irreversible decision has a reversible neighbour, and the neighbour is where a first deployment belongs.

Check 5: Who owns this after the outside help leaves?

Pass test: a named internal person, with time allocated, who will own the system in month six.

The MIT NANDA report is direct on this point. External AI partnerships reached deployment roughly 67% of the time, against about 33% for internally built tools. The report notes these are self-reported figures, but the direction is consistent across interviewees and with what implementation teams see: systems that nobody inside owns decay quietly, because the first change in the underlying process breaks an assumption nobody remembers making.

If you fail this check: the honest options are to allocate the person or to reduce the scope to something the organisation can run without one. Buying a system with no internal owner is a decision to rebuild it in two years.

How to read your five answers

Count the passes. The scoring is deliberately blunt, because a nuanced readiness score invites negotiation with yourself.

• Five passes: fund the pilot. Scope it to the single decision from check 1 and hold that scope.
• Three or four passes: fund the remediation, not the pilot. Name the failing checks, give each an owner and a date, and revisit. This is the most common result and the least popular one, because it converts an exciting project into a boring one for a quarter.
• Two or fewer: the programme is not blocked on AI. Something upstream is missing, usually a record with an owner or a decision with a name, and no model will supply it.

The check that fails most often is the second one, and the check that fails most expensively is the fourth.

What readiness is not

Readiness is not model selection, and it is not a platform decision. Both of those are reversible in a way the five checks are not: a model can be swapped in a sprint, while a missing system of record takes a quarter and a missing internal owner takes a hiring cycle. Programmes that spend their planning energy on the reversible choices and inherit the irreversible ones are the ordinary case, not the exception.

It is also not a maturity model. There is no requirement to be ready everywhere. A company can be entirely ready for one decision and nowhere near ready for the next, which is the practical reason to run these checks per decision rather than per organisation.

After the checks pass

Readiness earns you the right to start, not a plan. The sequencing work that follows is covered in our 12-week implementation roadmap, and the control questions that come with deployment are in the non-technical governance checklist. If you want the five checks run against a specific decision with an outside read, that is the kind of engagement our AI-native consulting practice takes on.