Fortune ran a piece today by Alexei Oreskovic on a pattern most enterprises now recognize. An AI project does well in its pilot, gets approved for a wider rollout, and then either stops working properly or fails to move any business number that matters. The reporting draws on a roundtable at Fortune Brainstorm Tech with leaders from Amgen, Salesforce, and Thomson Reuters, and its central point is one we have been making for a while. The problem is rarely the technology. It is the planning, the processes, and the expectations set around the work.
We agree with almost all of it. Back in October we wrote about the same gap in Why Most AI Projects Fail, citing the MIT finding that roughly 95 percent of generative AI pilots never deliver measurable business value, and we argued that the fix starts with defining success before anyone writes code. Fortune's panel adds useful texture to that argument, and we want to build on it.
Where Fortune gets it right
Many experiments, few bets
Encourage a lot of experiments while governing tightly which ones get greenlit. Lots of ideas, a short list of bets, and a clear-eyed view that not every pilot earns a rollout.
Start from the outcome
Begin with the business outcome, not the features. A model that demos well but moves no metric is a cost, not a result. And agentic AI needs a documented workflow underneath it - one many companies find was never written down.
Data access is the wall
Information scattered across silos under different privacy and security rules. Map the data requirements and bring the right stakeholders in early, before the build starts.
All of this matches what we see in the field. We would add five points that sit underneath these, because each one quietly sinks projects that otherwise looked ready.
What we would add
Sometimes the answer is not AI at all
The most expensive AI project is the one that should never have been an AI project. We have called this an AI hammer looking for a nail. A team starts with the technology and goes hunting for a problem to attach it to. Often a rules engine, a cleaner database, or a small piece of workflow automation solves the same problem faster and cheaper, with far less to maintain. The discipline that protects you here is the willingness to say no. A well-reasoned no is worth more than a marginal yes that consumes a year of budget and attention.
The knowledge no one ever wrote down
Fortune's panel points to missing workflow documentation. We would push the point further. In a lot of organizations, the rules that run a process do not exist on paper at all. They live in the heads of a few experienced people who apply judgment hundreds of times a day without ever stating the rule out loud. The pilot works because one of those experts is in the room. The rollout fails because the system was never given the knowledge the expert carries around without thinking about it. Before you build, you have to draw that tacit knowledge out and write it down, and that is usually harder, and more revealing, than wiring up the data pipes.
A demo is not a deployment
Many pilots are built in a sandbox with no plan for how they reach production. There is no answer for how the thing integrates with the systems of record, who signs off on security and privacy, how it gets deployed into your cloud or VPC, or how it gets monitored once it is live. So the demo impresses, the rollout stalls, and the project dies in the gap between the two. The path to production has to be mapped before the build starts, not discovered after the demo lands. We scope every use case as a thin vertical slice through the whole stack, just enough data, model, and application to reach production quickly, so that gap never opens in the first place.
Most failures happen after launch, not at it
Even a system that ships well does not stay good on its own. Models drift as the underlying data shifts. Costs creep. Providers release new models and retire old ones. Demand spikes around events and news cycles. A system that quietly degrades stops moving the metric it was built for, and if no one owns it after go-live, no one notices until the business result has already slipped. We call this Day Two, and planning for it from the start is the difference between a system that keeps earning and one that ages out in place. Monitoring, evaluations, guardrails, and cost controls belong in the first release, not bolted on a quarter later.
Choosing what to build first
Every failure point above is easier to avoid when you have picked the right use case to begin with. That means scoring candidate opportunities on two axes, the business value they create and the difficulty of building them, and starting with the quick wins that sit high on value and low on difficulty. It also means checking, before any code is written, whether the data exists, whether there is a real path to production, and whether the solution can actually influence behavior. Get the first choice right and the first slice returns value early, which funds and de-risks the next one.
From roadmap to running
The reason these five points show up so often is that they fall between roles. Picking use cases is strategy. Building to production is engineering. Keeping a live system healthy is operations. When those three hand off to each other through slide decks, work gets dropped in the seams.
AI Primer
Scores and sequences opportunities and surfaces the data and knowledge gaps before any build begins.
AI Assembly
Takes the top opportunity to production - with Day Two operations and evaluations in place from the first release, not added later.
AI Day Two
Keeps the live system accurate, available, and improving after launch.
We built our engagements to close those seams. Each step captures what it learns into a context layer the next step reuses, so the second project starts further ahead than the first.
Fortune's panel is right that the technology is rarely the thing that fails. As we put it in October, you would not start building a house without blueprints. The work that decides whether an AI project scales happens before and after the model, in the choices made around it. That is the work worth getting right.
“The technology is rarely the thing that fails. The work that decides whether an AI project scales happens before and after the model, in the choices made around it.
Ready to pick the use case that will actually scale?
Schedule an AI Primer and turn a prioritized business problem into a live result - with the data, knowledge, and path-to-production gaps surfaced before any build begins.
Schedule an AI Primer