They rarely fail loudly. There is no moment where somebody declares it over. The pilot goes well, the rollout happens, and then usage drifts down over a few months until the licences are renewing for a tool that four people open occasionally.
Nobody calls that a failure, which is precisely why it repeats. The patterns are consistent enough to be worth naming, and every one of them is visible before the money is spent.
It started with the tool, not the problem
The most common origin story is a demonstration. Someone sees a capability, it is genuinely impressive, and the question becomes “where could we use this?”
That question has no honest answer. It produces a search for a problem to fit a solution, and the problems found that way are always the ones nobody was actually bothered by.
The version that works starts from a complaint. Something that takes too long, costs too much, or is done wrong often enough to matter. Then the question is what fixes it, and quite often the answer turns out not to involve AI at all.
The pilot proved the wrong thing
Pilots are usually run by the people who wanted it, on examples they chose, with time set aside to make it work.
That proves the technology functions. It proves nothing about whether it survives contact with a normal Tuesday: an ordinary member of staff, under time pressure, with a messy real case rather than a clean example, and no appetite for a second attempt when the first is disappointing.
A pilot worth trusting uses the awkward cases and the least enthusiastic people. If it holds up there, it will hold up everywhere. If it only works with the champions, you have measured the champions.
It made the work longer
This is the quiet killer, and it is almost never noticed in advance.
A tool drafts something in seconds. Then someone reads it, checks the facts, fixes the tone, and reworks the ending. Total time saved, once you count honestly: none. Sometimes less than none, because editing someone else’s draft is harder than writing your own.
Staff work this out within about two weeks and quietly stop, and they are usually right. Measure the whole task, including verification, not the generation step. If the honest figure is not meaningfully better, the tool is not helping regardless of how impressive the demo was.
Nobody owned it
Software with no owner decays. This is true of everything, and more true of AI tools, because they need prompts refined, boundaries adjusted and cases reviewed as the work changes.
Very often the owner is whoever championed it, in addition to their actual job, with no time allocated. That lasts roughly one busy period.
An owner with two hours a month is enough. An owner with nothing is the same as no owner, and it is the state most rollouts are in by month four.
The data was never in shape
Anything answering questions about your business needs access to reliable information about your business.
If the current position lives across four systems, three spreadsheets and one person’s memory, no tool resolves that. It will answer from whatever it can reach, which will be the out-of-date copy, confidently.
Two wrong answers in front of a customer and trust is gone permanently. This is the failure that a spreadsheet quietly running the business guarantees, and it is a data problem wearing an AI costume.
It was bought for everyone
Licences for the whole company, announced at a meeting, with training available on request.
Adoption in that model is close to zero outside the people who would have found the tool anyway. Everyone else has a job to do and no specific reason to change how they do it.
Buying for a named group with a named task works considerably better, and it is cheaper. Expand when that group asks for more seats, which is the only honest signal of value there is. It is also the difference between a controlled cost and a bill that grows without anyone deciding.
The check worth running before you spend
Five questions. Any no is worth resolving first.
- Can you name the task, and roughly how often it happens?
- Does someone specific complain about it today?
- Counting checking and correction, is it genuinely faster?
- Is there a named owner with actual time?
- Is the information it needs in one reliable place?
Five yeses is not a guarantee. Any no is a very reliable predictor.
The honest summary
These projects rarely fail on technology. They fail on a problem nobody had, a saving that did not survive counting, an owner who did not exist, or data that was never in shape.
All four are visible beforehand, and all four are cheaper to find now than in month six.
If something is underway and drifting, that is recoverable and usually worth doing rather than abandoning. Describe where it has got stuck and you will get an honest read on whether it is worth continuing.
Common questions
What is the single most common reason these fail?
Starting from the tool rather than a problem. A demonstration is impressive, the question becomes “where could we use this”, and the problems found that way are the ones nobody was bothered by.
How do we tell whether ours is drifting?
Count who opened it last month against who has a licence. Quiet drift shows up as licences renewing for a tool four people use occasionally, long before anyone calls it a failure.
Can a stalled project be recovered?
Usually, and it is normally worth doing rather than abandoning. Most stalls trace to a missing owner or a saving that did not survive being counted honestly, and both are fixable without starting again.