From pilot to platform: the 70% nobody demos

Every enterprise AI program produces the same artifact in its first quarter: a pilot that works. The model answers questions about policy documents, drafts responses to customers, or extracts fields from contracts — convincingly, in a controlled environment, in front of an appreciative steering committee. And then the program stalls, because nobody budgeted for the part that comes next.

In our delivery experience, the pilot is roughly 30% of the work of a production system. The remaining 70% has no demo moment. It is evaluation coverage, permission design, observability, cost control, security review, and the operational choreography of failure — and it decides whether the system survives contact with real users, real load, and real auditors.

What the 70% actually contains

• Evaluation harnesses that run on every change, so quality regressions surface in CI rather than in the call center.
• Permission boundaries and human checkpoints matched to risk tier — the difference between a system compliance defends and one it merely tolerates.
• Observability deep enough to answer an auditor’s question from eighteen months ago: which model, which version, which prompt, which data.
• Cost attribution per team and per use case, because a platform whose economics nobody can see is a platform whose budget dies at renewal.
• Failure drills: what happens when the model is wrong, the tool times out, or the vendor has an outage at month-end close.

Why organizations underinvest in it

The incentive structure is honest about this: demos are promotable and infrastructure is invisible. A pilot produces a screenshot for the board pack; an evaluation harness produces a green tick nobody outside engineering will ever see. So the org optimizes for pilots — until the third or fourth one stalls at the same wall, and the pattern becomes impossible to ignore.

The pilot proves the model can do the task. The platform proves the organization can operate the model. These are different achievements, and only the second one compounds.

The sequencing that works

The programs that escape pilot purgatory share a sequence: they pick one use case with a measurable baseline, they build the governance and observability scaffolding around that first use case rather than deferring it, and they treat the second use case — not the first — as the real test. If the second one ships in weeks because the scaffolding exists, the platform is working. If it restarts the whole conversation, you have a portfolio of pilots, not a capability.

The 70% is not a tax on the exciting work. It is the work. Budget for it on day one, staff it with your best engineers rather than your newest, and measure the platform by the marginal cost of the next use case — the one number that tells you whether you are building capability or collecting demos.