The pattern is consistent enough to be predictable. A pilot is commissioned. It works. Stakeholders are impressed. A production rollout is approved. Eighteen months later the system is either quietly unused or never shipped, and the post-mortem concludes something vague about change management.
The vague conclusion is usually wrong. In most cases there is a specific missing layer between having intelligence and having it change what the business does.
Why pilots succeed and production fails
A pilot is run on curated data, by motivated people, on a narrow slice of cases, with the team that built it available to fix problems. Every one of those conditions disappears at production.
Real data is messier than pilot data, by a wide margin. Real users are not motivated volunteers. Real case distribution includes the awkward twelve percent deliberately excluded from the pilot to keep it clean. And the builders have moved on to the next initiative.
None of this is a reason not to pilot. It is a reason to design pilots that test the hard part. A pilot proving a model can summarise a well-formed document has proved something nobody doubted. A pilot proving the system handles the malformed documents your operation actually receives has proved something useful.
The missing layer
Between data and action there is a layer most projects underinvest in. It has four parts, and skipping any one produces a recognisable failure mode.
Retrieval that reflects reality
Most enterprise AI now sits on retrieval-augmented generation: find relevant documents, give them to the model, generate an answer. This works well in demos and less well against real document estates.
Real estates contain superseded versions alongside current ones, contradictory guidance from different departments, documents whose meaning depends on context not present in the text, and enormous quantities of near-duplicate material. Retrieval finds passages resembling the question. It has no concept of which document is authoritative, current, or applicable to this specific customer.
The failure mode is confident answers citing outdated policy. It is particularly dangerous because the citation makes it look verified.
Integration with systems of record
Answering questions is a fraction of the work. Completing it means reading and writing to the systems where the business actually operates. This is where projects encounter the real estate: the platform whose API is read-only on your licence tier, the internal tool with no API at all, the database whose schema nobody fully understands because the person who designed it left in 2014.
This work is unglamorous, hard to estimate and routinely omitted from initial scoping. It is also where the majority of production effort goes.
Human-in-the-loop that people will actually use
Almost every enterprise deployment includes human review. Almost none design it properly.
The common failure is review as a rubber stamp: a queue where a human approves items faster than they can meaningfully assess them, because throughput expectations were set assuming the system is usually right. This produces the appearance of oversight with none of the substance, and it is worse than no review because it manufactures false assurance.
Effective review is selective. Route the cases where the system expressed low confidence, or where consequence is high, or a sampled proportion for quality monitoring. Give reviewers enough context to judge rather than only the output. Above all, set expectations that permit genuine scrutiny.
Observability
When output is wrong six months in, can you determine why? Which documents were retrieved, which prompt version ran, which model, what the tool calls returned? Without this, improvement becomes guesswork and compliance questions become unanswerable.
A diagnostic question for any AI project: if a customer complained today about a decision the system made three months ago, could you reconstruct exactly what happened? If the answer is no, the project is not production-ready regardless of how well it performs.
Organisational causes
Not every failure is technical. Several recur often enough to name.
Solution before problem
Projects beginning with a decision to use AI rather than a process worth fixing tend to produce impressive systems nobody needs. The tell is a business case written after the technology was chosen.
No owner after launch
AI systems require ongoing attention. Models change, source documents change, business processes change. A system with no named owner degrades within months. Frequently nobody is assigned because the project was funded as a capital initiative rather than an operational capability.
Success criteria that avoid the point
When success is defined as adoption rate or queries handled, a project can hit every target while changing nothing. Useful criteria are operational: cases resolved without escalation, hours returned, response time reduced, error rate versus baseline.
Underestimating process archaeology
Automating a process requires knowing how it works. Most organisations have documentation describing how it was designed to work, which diverged from reality years ago. Discovering the real process, including the undocumented workarounds, is often the largest single chunk of project effort and is almost never scoped.
What projects that succeed do differently
Successful deployments are typically less ambitious in scope and more rigorous in execution.
They pick a process with high volume and low variance rather than the most strategically exciting one. They spend disproportionate time on the integration and data quality work before touching the model. They design human review to be genuine. They instrument everything from the first day rather than adding logging after an incident. They name an owner before go-live, with time allocated for the role.
And they accept a narrower initial scope in exchange for something that actually reaches production, because a system handling seventy percent of one process reliably is worth considerably more than an ambitious system handling nothing at all.
The uncomfortable conclusion
Most enterprise AI failure has little to do with AI. It is the ordinary difficulty of changing how an organisation works, with a novel technology attached that makes the difficulty easier to misattribute.
This should be encouraging rather than discouraging. Organisations that are good at operational change tend to be good at deploying these systems, and the disciplines required are ones a business can build deliberately.