Why AI pilots stall before production — and the six checks that predict which ones ship

The most cited number in enterprise AI right now is uncomfortable: an MIT NANDA study of enterprise generative AI adoption reported that around 95% of the pilots it examined produced no measurable profit-and-loss impact. Coverage of the report focused on the headline, but the interesting part is the diagnosis — the study attributes the gap to workflow integration and learning, not to model quality.

That matches what we see when a client asks us to rescue a stalled programme. The demo usually works. What is missing is everything around it: whose budget owns the outcome, what the process cost before AI touched it, and what evidence would justify a rollout.

The six checks

• 01A named owner with budget. Not a steering committee. One person whose numbers improve if this works.
• 02A measured baseline. Current cost per case, current cycle time, current error rate — captured before the pilot, not estimated afterwards.
• 03One workflow, end to end. A narrow slice that reaches a real outcome beats a broad assistant nobody is accountable for.
• 04A written production gate. The threshold that turns the pilot into a rollout, agreed in advance, in writing.
• 05Access resolved on day one. Systems, credentials, sample data and a security review scheduled before the kick-off, not discovered in week three.
• 06An evaluation harness you keep. Golden cases and scoring that survive the pilot and gate every later change.

None of these are technical. All of them are cheaper to fix before a pilot than after one.

Why the gate matters more than the demo

A demo answers 'can this work?'. A gate answers 'will we roll this out?'. Without the second question written down, a successful pilot still needs a fresh business case, a fresh budget cycle and fresh political sponsorship — and that is where momentum dies. Writing the gate first also disciplines scope: if the threshold is 'ninety per cent of invoices posted without human touch at under nine cents each', nobody wastes three weeks on a chat interface.

What a stalled pilot usually looks like

Sequencing that avoids the trap

We run two weeks of discovery — data access, baseline, gate, risk classification — then a fixed-fee pilot against that gate. The discovery output is useful even if you stop: you know what the process costs today and what would have to be true to change it. That is the artefact most stalled programmes never produced.

Regulated or safety-relevant workflows need the risk classification during discovery, not after the pilot. Retro-fitting logging, human oversight and documentation into a working system is the single most common cause of a delayed go-live we see.