The problem with your
AI strategy isn't the AI.
95% of enterprise AI pilots never reach the P&L. The reason is almost always structural.
Most senior leaders have now run AI pilots.
Some are impressive in isolation. A process that took days now takes hours. A report that needed a team now needs a prompt. Then somewhere between the demo and the quarterly review, the returns flatten. The pilots that impressed don't scale. The investment keeps growing. The results don't.
The bottleneck is the operating model the technology was dropped into.
The pattern repeats every technology cycle
When a new technology arrives, the first decade or two is almost always spent grafting it onto existing systems rather than redesigning around it. Steam-powered factories replaced water wheels with the same layouts and the same machinery, a different power source driving them. Steam locomotives replaced horses on roads and rail. The technology changed. The underlying process didn't. It took decades before the system itself was redesigned around what steam actually made possible. Electrification, computing and the internet all played out the same way.
AI is no different. Most organisations are asking how to use AI to speed up what they already do. That is the application layer, with incremental gains, a moved bottleneck, and the nagging worry that the competition is doing exactly the same thing.
The harder, more valuable question is this: if you were designing your organisation today, knowing what AI can actually do, what would you build differently?
.png)
Application layer versus system layer
Your AI experts are brilliant at the application layer. That is what they were hired for: prompt engineering, model selection, tool integration. But optimising at that level produces optimised cost on broken processes. You spend less doing the wrong things faster.
The economic return comes from redesigning the system those applications sit inside, not from squeezing more out of the application layer. That is a different question, and most organisations never reach it because the people in the room aren't equipped to ask it.
1. Approvals move slower than the work
You can prototype in days. Then it enters a release process built for quarterly change: risk review, architecture board, change advisory, each with its own calendar. None of it is wrong. It was designed for a world where building was the slow part. AI removed that, and left the process untouched, so the queue is now the whole cost.
2. Funding is set once a year and locked
AI needs small bets and fast reallocation. Annual budgets were fixed before anyone knew what the pilot would reveal. Your real strategy isn't on the slide. It's where the money actually goes, and when it's allowed to move.
3. Decisions sit too far from the work
Insights expire in days. Sign-off takes weeks. By the time the decision is made, the window that made the insight valuable has closed. Most enterprises are full of capable people waiting for permission.
4. Reporting arrives too late to act on
Reporting shows progress. Reality surfaces too late to act on. The dashboard goes green and the learning stops. An organisation that learns slower than its market changes cannot compound an advantage from AI, however good the pilots look.
AI drops the cost of building to near zero. It exposes the governance you were winging at scale.
The cost is already on your P&L
Reengineering sounds expensive, and it is worth being honest about that. But the cost of your current architecture is already on your P&L: in pilots that never reached production, in senior teams allocated to initiatives that stalled, and in decisions that arrived after the window closed. You're already paying for it. It just isn't labelled as an AI problem on any invoice.
The answer is re-optimisation, not transformation
You don't need a two-year programme. Enterprises are already highly optimised, just not for what leaders think. Most are optimised for control and risk containment rather than speed and learning. The work is to re-optimise toward a different objective, starting with one bounded area where the new logic can be proven before it is scaled. That is faster, cheaper and far less risky than another transformation.
The firms that get this right first won't just run more efficiently. They'll be structurally different: faster feedback loops, smaller teams producing more, decisions made closer to the work, and capital moving toward what's actually working rather than what was agreed in last year's planning cycle.
​
The window is open. It won't stay that way.
We've done this inside regulated enterprises where getting it wrong has consequences: a post-merger delivery model across 50+ teams, a £13bn platform migration under full FCA compliance. The same work, before anyone called it an AI problem.
