Most AI pilots stall after the demo, not before it

The gap after the demo

A proof of concept answers one question: can a model do this task on a sample of data? Production asks several more. Who owns the result when it is wrong, what happens to the transactions the model cannot handle, how the output reaches the system of record, and what each completed task costs once review and rework are counted.

The evidence suggests most programs stall on those later questions. S&P Global Market Intelligence surveyed more than 1,000 IT and business professionals in North America and Europe and found that the share of companies abandoning most of their AI initiatives rose to 42 percent in 2025, from 17 percent the year before. The average organization scrapped 46 percent of proofs of concept before they reached production.¹

Gartner had anticipated the pattern. In July 2024 it predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs and unclear business value.³ None of those four is a modeling problem.

Use is broad, value is narrow

Adoption is no longer the constraint. Stanford’s AI Index reports that 78 percent of organizations used AI in 2024, up from 55 percent the year before.⁴ McKinsey’s 2025 survey puts regular use in at least one business function at 88 percent.²

The same survey shows how little of that use reaches the income statement. Nearly two-thirds of respondents say their organizations have not begun scaling AI across the enterprise. Only 39 percent report any effect on enterprise-level EBIT, and most of those attribute less than 5 percent of EBIT to AI.²

Adoption is no longer the constraint. The constraint is everything that happens after a model returns an answer.

Where pilots fail

The same failure points recur from one program to the next. They are listed here in the order in which they usually surface, which is also roughly the order of their cost to fix.

Data

The pilot ran on a curated extract. Production needs a pipeline that delivers the same fields, at the same quality, every day, and an alert when it does not.

Integration

A prediction has value only when it changes a record or a decision. Writing results back to an ERP, ticketing system or ledger is usually more work than the model.

Exceptions

Every model has inputs it handles badly. Without a defined path for those cases, staff stop trusting the output and quietly redo the work.

Ownership

A data science team can build a model. It rarely owns the business outcome, the support rota or the budget for running costs.

Cost

Inference, review time and monitoring scale with volume. A pilot priced on a few hundred items says little about the cost at a few hundred thousand.

McKinsey’s high performers are about three times more likely than other respondents to say they have fundamentally redesigned workflows when deploying AI.² That is the clearest single signal in the data. Value comes from changing how the work is done, with the model as one component, not from inserting a model into an unchanged process.

Choosing the least complex system

Many pilots should not become AI systems at all. If a validation rule, a lookup table or a database constraint resolves most cases deterministically, it will be cheaper to run and easier to audit than a model. The model then handles the residual cases where judgment is genuinely needed, and its output is checked against the same rules.

This ordering also makes failure visible. A deterministic check that rejects a record leaves a reason. A model that is wrong with confidence leaves nothing, unless the system was designed to compare its output with something it can be held to.

Five tests

We apply five tests before recommending that a pilot move into production.

1. 1A named owner of the outcomeA business owner accountable for the metric the system is meant to move, not only for the model.
2. 2A baseline measured before buildCurrent cycle time, error rate and cost per item, measured on real work, so improvement can be shown rather than asserted.
3. 3A production data pathThe same inputs, delivered by a monitored pipeline, with the failure behavior defined when a feed is late or malformed.
4. 4A defined exception routeLow-confidence and rule-breaking cases go to a person or a deterministic fallback, and the volume of those cases is tracked.
5. 5A unit cost per completed taskInference, review and running costs divided by tasks actually completed, compared with the baseline.