A firm with AI projects is not an AI business. The work to become one sits in the operating model, and that is the part most programmes never look at.
The technology mostly works. Models are capable, the tooling is maturing, and the published terms are getting easier to buy. Yet most organisations still cannot point to a structural shift in their results from what they have spent. The spend is real. The earnings line has not moved. That gap does not close by buying more technology. It closes inside the operating model, or it does not close at all.
This is the line we keep coming back to at Ambrose and Bell: AI lands where the operating model is ready to absorb it, and stalls everywhere else. So the first question is not which tool. It is whether the business actually knows how it runs.
You cannot automate what you do not know about
Leadership teams believe they know how the business operates. The process maps exist, the org chart is on a slide, the model is documented. The reality is usually different.
The decisions that actually get made, the workarounds that hold the place together, the unwritten escalation paths, the step a senior person quietly does at the end of every quarter because the system never quite worked, all of that sits outside the documented version. It is the business, and it is invisible.
There is a reason it stays invisible. The people closest to a process have a rational interest in not surfacing it, because surfacing it can threaten the role. That is not a project issue to be managed away. It is a structural feature of any change that puts jobs in the frame. Until the operating model itself offers people a credible place to land, disclosure feels unsafe and the foundation cannot be built.
Process mining and document analysis help. They show what the systems did and what was written down. The work that matters most is still done in the gaps between those two records, by people who have learned not to write it down. Build AI on top of the documented model and you automate a description of the firm that does not exist. Nothing further you do compensates for that.
So the first piece of work is the unglamorous one. Find out how the business actually runs.
Not all AI is the same kind of thing
Treat AI as a single thing and you mis-frame the adoption decision. There are two categories, and they call for two different shapes of adoption.
AI that augments individual work is productivity tooling. A developer using a coding assistant still ships into the same review process and the same accountability. A researcher using an AI tool still owns the citation and the conclusion. The work, the accountability, and the value capture all sit with the individual. This category can adopt from the bottom up, and should. The operating-model intervention is light: usage guidelines, data handling, licence management, training. That is enough.
AI that changes how the business operates is something else. Decisioning at scale, customer interaction without a human in the loop, pricing or underwriting or claims handling where the model is making the call. These are not productivity tools. Decision rights move. Liability moves. Role definitions move. The customer experience moves. The technology function does not have the authority to redraw decision rights, and waiting for productivity-tool momentum to push those changes upward is the slowest route to a structural shift.
The error is not that bottom-up adoption is bad. The error is treating all AI as bottom-up productivity tooling when some of it is business-model change. Distinguish the two and the adoption design becomes obvious. The first category can adopt from the bottom up. The second cannot.
The patterns are old, even when the technology is new
The bottlenecks blocking AI today rhyme with the ones that blocked automation programmes several years ago. I was instrumental in operationalising an enterprise automation capability at scale, and the failures were never the bots. They were governance, sourcing, accountability, the documentation gap before build, and the run model after go-live. The technology was the easy part.
The same kinds of gaps are opening up again, now with bigger budgets and more confidence. The meta-patterns persist. The specific mechanisms have moved:
- Procurement. Less bespoke per-project contracting, more standardised terms. The new risk hides in data handling, model versioning, indemnity, and rate limits. Same pattern, different diligence.
- Cost of ownership. Less a fixed per-licence line, more variable per-use cost that can scale faster than the value if nobody is watching. Same pattern, sharper teeth.
- Run model. The operational craft is scarcer and harder to staff at mid-market salaries. The gap of no run model designed before go-live is the same. The capability to fix it is harder to source.
New capability lands into the same operating model. Accountability gaps do not heal because the model can reason. Governance failures do not heal because the model can write code. The capability shift is real. The operating-model lever holds despite it.
What it looks like when it works
I led the UK turnaround of a group-owned integration business. Revenue quadrupled, EBITDA improved by thirty points, and the pipeline grew several-fold. None of those numbers came from the technology stack. They came from rebuilding the operating model around it: new decision rights, a new commercial cadence, new accountability lines, a clearer service definition. The platform was a precondition. The operating-model rewrite was the engine.
The version of this argument worth retiring is the one that says the operating model can be redesigned once and then reused. That is the wrong horizon. A firm that does the rewrite once and stops is back in catch-up territory inside eighteen months. The technology keeps moving. The rewrite is not a destination. It is the building of a standing capability whose job is to absorb continuous change without re-traumatising the firm every time the tooling moves on. Built once. Maintained always.
This does not require an enterprise-scale restructuring programme. A mid-market firm has less inertia, which is an advantage, and less resource depth, which is not. It cannot copy the largest players move for move. It can run the same discipline at its own scale and pace, and it has to, because the alternative is permanent catch-up. The job is to find the smallest viable version of the discipline and keep it running.
So the choice is simpler than it looks. Run AI as a portfolio of projects on top of an operating model that never changes, and spend the decade catching up. Or build the operating-model capability, keep evolving it, and stop running the same race.
The firms that get the most from AI over the next ten years will be the ones that treat fixing the operating model as the work, not the overhead.
If you are taking this question to the board, the framing of that conversation matters as much as the work itself. We have written about how to have the right board conversation about AI, which sits alongside this piece.