Most enterprise AI programmes don't collapse. They launch, and then they go quiet.
There is a demo that works. There is a steering committee that approves the next phase. Some months later, the workflow it was built to change is running the way it always ran, and the new tool sits beside it, opened by a few people who liked it. Nobody files this as a failure. The budget was spent, the pilot shipped, the slide said complete.
I think the point of failure here is predictable. I also think it is almost never the model, and that a lot of money is being spent looking for it in the wrong place.
The model stopped being the constraint
A few years ago, can it do this at all was a real question, and it was reasonable to organise a programme around answering it. That question is mostly settled for the work most companies want done: reading documents, drafting, triage, classification, pulling structure out of mess. The frontier labs solved it, and they keep solving it faster than any buyer can absorb.
What follows from that is uncomfortable for the way these programmes are usually run. If capability is bought rather than built, then capability is not where your advantage comes from, and it is not where your risk is either. Your competitor can buy the identical model on the identical terms this afternoon. The difference between you and them is what the work looks like around it.
Model selection still gets the attention, because it is the part that feels technical and decisive, and because it can be settled in a meeting. The part that decides the outcome cannot be settled in a meeting.
What breaks instead
In our experience the failure happens in the weeks after launch, when the new way of working meets the old one and the old one wins. Three versions of this come up often enough to name.
The tool arrives before the problem. A platform is chosen, and then the organisation goes looking for work to put on it. A tool selected before anyone has understood the workflow will always find something to do; it will just rarely be something that reaches the bottom line. The tell is that the business case is written after procurement rather than before.
AI is bolted onto a process nobody redesigned. This is the most common one and the hardest to argue against, because it looks responsible. You leave the process intact and add intelligence to one step of it. But a bolt-on inherits every constraint of the process underneath. If approval takes nine days because it crosses four teams, drafting the document in nine seconds instead of ninety minutes does not give you back the nine days. The ceiling was set before the work started, and the measured result comes back as a rounding error that nobody can explain.
The company builds what it should have bought. Undifferentiated capability is cheaper bought than built, and it stays cheaper, because the vendor amortises across every customer and you amortise across one. Build where you are different. Buy the rest and spend the attention you save on the part only you can do.
None of these are model problems. Every one of them is a decision made months before a model was involved.
The honest version of this argument
We spend our days telling companies to become AI-native, which makes the advice cheap unless it has been run against something real. So the test I trust most is the one I ran on myself.
I was not a good investor. I could find good companies. What I could not do was the boring half: write down in advance what would prove me wrong, check the number instead of trusting the deck, then go back later and see how I had fooled myself. AI changed that, not by being smarter than me, but by making the disciplined version of the work cheap enough that I stopped skipping it.
So I built the tool that did it. DealOS started as a prototype in an afternoon. Getting to a system with customers paying for it took 995 commits and five months of nights and weekends.
The prototype was the easy part, and it was the part that looked like progress. Almost none of the work that followed was model work.
It was deciding what the system should refuse to answer. It was what happens when a document is malformed, which is most of the time. It was discovering that the workflow I thought I had was not the workflow I ran, and rebuilding the thing around the real one. It was changing my own habits so I opened it on the days I did not feel like being disciplined, which are the days it is for.
I had every advantage an enterprise programme does not. One user, one decision-maker, no procurement, no change board, complete authority to redesign the process because the process was mine. It still took five months. When a large organisation runs the same distance across four teams, none of whom report to the sponsor, with a process that predates everyone in the room, the honest estimate is not shorter.
Adoption is a redesign problem wearing a training badge
The word "adoption" does a lot of damage, because it sounds like the last step: a rollout, a comms plan, a training day, a dashboard of licence utilisation. Treated that way it fails, and it fails for a reason that has nothing to do with enthusiasm.
People are not declining to use the tool. They are correctly following the process they are measured on. If the workflow, the handoffs, the approvals and the metrics all still describe the old way of working, then using the new tool means doing your job in a way that scores worse. The rational response is the one you are seeing.
Which means adoption is not the last step. It is the redesign of the work, of who decides what, of what gets measured, and the tool is the part of it that happens to be software. That work is slower and less photogenic than the build, it is the part most likely to be cut when a programme runs late, and it is the part that decides whether any of the rest counted.
Digital transformation changed the systems. AI transformation changes the decisions. That is a harder thing to buy, and it is the thing being bought.
What this means if you are about to start one
Two questions are worth more than a model evaluation.
The first: if this works perfectly, what number moves, and who owns that number today? If nobody can answer without a pause, the programme has no destination, and the pilot will succeed on its own terms while changing nothing.
The second: what has to stop? Every AI initiative that lands displaces something — a report, a meeting, a queue, a role's worth of routine judgement. If nothing is scheduled to stop, nothing has been redesigned, and what you have bought is a second way of doing the work in parallel with the first.
Neither question is technical. Both are answerable in a week. Most programmes I see have answered neither, and have already chosen a vendor.
James Guo is the founder of Megaptera Labs, an AI transformation firm in Australia. He was previously a strategist at Bain & Company and Head of Strategy at eBay ANZ. Megaptera Labs builds and runs DealOS, a deal-analysis system for private markets.