Why Enterprise AI Pilots Stall

The headline that “95% of AI initiatives failed” turned a study of enterprise adoption into a verdict on the technology. The useful question is narrower: why do so many pilots fail to produce a measurable business result?

What the report measured

Project NANDA’s July 2025 report, The GenAI Divide, described most organizations as seeing no measurable return from generative AI, with a small share of integrated pilots producing substantial value.

It was preliminary research: a review of more than 300 public initiatives, interviews with representatives of 52 organizations, and a survey of 153 senior leaders at four industry conferences. Its findings are useful signals, not a representative failure rate for every enterprise AI project.[1]

The report points to a gap between trying a tool and incorporating it into work well enough to change costs, productivity, or revenue.

What the headline cannot tell us

An exploratory pilot may answer a technical question without changing quarterly profit. A production project promising savings should be held to a different standard. Calling both a failure hides the difference.

The report also does not establish that model quality is sufficient for every use case. Integration, reliability, and the task itself all affect the result. Better execution cannot rescue a workflow the model cannot perform well enough.

Where I would look for the gap

These are the execution problems I would investigate when a pilot stalls:

Use-case selection

Visible demos attract attention. A less visible process with frequent exceptions, a measurable backlog, and a clear owner may offer a better starting point.

The reflex to build

A custom system needs a reason to exist. Compare it with a specialist product before committing to ongoing integration, evaluation, and maintenance.

The work after the pilot

A prototype can avoid access controls, deployment constraints, and support arrangements. Production cannot. Include their cost and ownership in the decision to proceed.

The rest of the workflow

A good answer saves little time if someone must copy it between systems, verify every field, and chase approval. Measure the whole task.

Unofficial use

If employees prefer personal tools, investigate what those tools make easier. Convenience, access, and fit with daily work may explain more than another training session would.

Too many pilots

A portfolio of experiments needs decisions. Concentrate resources where there is evidence of value and stop work that cannot meet its threshold.

Define what success means for your project

The report’s successful minority is a reason to investigate specific workflows, not a promise that copying a checklist puts you in the same group. My practical response would be to choose one task, establish its baseline, and test whether the full workflow improves.

A practical starting point

1. Choose a measurable process

Intake triage, document routing, invoice exceptions, and policy checks are candidates. Measure current handle time, rework, errors, and volume before choosing one. Include review time in the target; a faster draft alone is not a saving.

2. Compare buying and building

Buy when an existing product meets the workflow, security, and data requirements. Build when a proprietary process or capability justifies the upkeep. Regulated data is a requirement to evaluate, not an automatic reason to build everything yourself.

3. Price the production requirements

Include identity, permissions, audit logs, data handling, evaluation, and recovery from errors. Assign someone to own each dependency and the ongoing service.

4. Make continuation conditional

Agree on the evidence required to move from a test to limited production and then to broader use. Review the result with the people who own the workflow and its costs. Stop or revise the project when it misses the threshold.

5. Help people use the changed process

Give users examples, clear escalation routes, and time to practice. Investigate mistakes and workarounds. Reward improvements in quality and time saved rather than usage alone.

Make the next decision smaller

You do not need a verdict on all of AI to decide what to build next. You need evidence that one workflow is worth changing, a credible cost estimate, and a way to tell whether the change worked.

Delete the Word AI develops the investment question: name the constraint, price the work, and decide what evidence would make you stop.

Source

[1]: Aditya Challapally, Chris Pease, Ramesh Raskar, and Pradyumna Chari, The GenAI Divide: State of AI in Business 2025, Project NANDA, July 2025. Preliminary report; this link is a hosted copy of the original PDF.