Most AI programmes stall on the data underneath them

There is a pattern that repeats across large organisations. A team builds a proof of concept, it works, everyone is encouraged, and then the thing never reaches production. Six months later the programme is quietly rescoped.

The post-mortem usually blames the model, the vendor or the change management. In our experience the cause is almost always further down: the data the pilot ran on was hand-assembled, and nothing in the organisation can produce that same data reliably, at scale, on a schedule, with an owner attached to it.

A pilot hides the work a rollout exposes

A proof of concept is allowed to cheat. One analyst pulls an extract, cleans it in a notebook, resolves the ambiguities by asking a colleague which of the three customer tables is the real one, and gets on with the interesting part. None of that is wrong. It is the correct way to test whether an idea has legs.

The problem is that the cheating is invisible in the result. What gets presented is the output, not the forty hours of quiet reconciliation that made the output possible. So the decision to scale is taken on the assumption that the hard part is done, when in fact the hard part has not started.

Every judgement call an analyst made by hand during the pilot becomes, at production scale, a rule someone has to own.

What readiness actually means

Readiness is not a maturity score. It is a set of concrete, checkable conditions, and they are specific to the use case rather than to the company:

• Definitions. The entities the use case depends on have one agreed definition, written down, that the people who will be held accountable for the output recognise as correct.
• Lineage. You can trace any figure the system produces back to the systems it came from, without a person reconstructing it from memory.
• Reproducibility. The dataset the pilot ran on can be regenerated on a schedule by a pipeline, not by an analyst.
• Ownership. Someone is named, and knows they are named, for each input that matters.
• Sensitivity. You know which fields carry personal or commercially sensitive data, and what that permits.

None of these are exotic. What makes them hard is that they cut across teams, and they surface disagreements that the organisation has been comfortably avoiding. Two departments have been reporting different revenue figures for years and both have been fine with it, because neither number was ever put in front of a system that had to pick one.

The useful sequence

Start from a decision, not a capability. Pick the specific thing the AI is meant to change: which decision, made by whom, how often, and what it costs today when it goes wrong. That narrows the data in scope from everything the company holds to a list you can write on one page.

Then assess that list against the five conditions above and be blunt about the result. It is far cheaper to say "this use case needs three months of groundwork first" than to discover the same thing after the vendor contract is signed.

Then do the groundwork as a deliverable in its own right, with its own outcome. Not as a preamble buried inside the AI project, where it will be the first thing cut when the timeline slips.

Groundwork is not a tax

The reflex objection is that this delays the interesting work. It is worth noticing what the groundwork actually produces: agreed definitions, traceable numbers, reproducible pipelines and named owners. Those are the things every other data initiative in the organisation has also been quietly missing.

The AI use case is a good forcing function, because it makes the absence impossible to ignore. But the value of fixing it does not belong to the AI programme alone, and it should not be accounted for as if it does.