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. The models are capable and the tooling is maturing. Yet many organisations still cannot point to a structural shift in their results from what they have spent. The spend is real, but the earnings line has not moved, and buying more technology will not close that gap. It closes inside the operating model or not at all.
At Ambrose and Bell we keep coming back to one point. AI lands where the operating model is ready to absorb it, and stalls everywhere else. So before any choice of tool, the first question 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 and 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. It is a structural feature of any change that puts jobs in the frame, and no project plan manages it away. 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 all stay 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. Here decision rights, liability, role definitions and the customer experience all move. 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.
Bottom-up adoption is right for the first category. The error is applying it to the second, which is business-model change. Distinguish the two and the adoption design follows.
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 helped to structure and operationalise an enterprise automation function inside a multinational service business, 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 underlying patterns are the same. What has changed is where they show up:
- Procurement. Less bespoke per-project contracting, more standardised terms. The new risk hides in data handling, model versioning, indemnity, and rate limits.
- 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.
- 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 in the same operating model. A model that can reason does not close an accountability gap, and a model that can write code does not fix weak governance. The capability shift is real, and the operating model still decides whether it pays back.
What it looks like when it works
I led the UK turnaround of a group-owned integration business. Revenue grew fourfold and the pipeline grew fifteenfold. 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, because the technology keeps moving. The rewrite builds a standing capability whose job is to absorb continuous change without upheaval every time the tooling moves on.
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 core of the work.
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.