The Real Bottleneck in AI Transformation Is Not the Model

In one enterprise AI deployment we observed, the system was judged to be underperforming. The internal conclusion had already formed: the model was not good enough for the work. Investigation found something else entirely. The system lacked the credentials to access the downstream systems it had been asked to operate. The intelligence was intact. The plumbing was not.

I keep returning to that example, partly because it is not unusual and partly because of how nearly it ended in the wrong decision. Permissions, integration and access gaps look exactly like capability limits from the outside. The symptom is identical in both cases: the system does not do the work. An organisation that cannot tell the two apart will abandon initiatives prematurely, and will do so believing it has made a rational, evidence-based call.

A few patterns have become consistent enough across the AI transformations we observe to be worth setting down. The common thread is that velocity is no longer set by model capability. It is set by how quickly an enterprise can remove operational friction, prioritise the right work, and redesign roles and workflows for human-AI collaboration. Six factors do most of that work, and most of them land on the CHRO's desk rather than the CTO's.

Diagnose the real constraint before you judge the model

A significant share of apparent AI failures are not failures of the model at all. They are failures of access. Leaders need a disciplined way to distinguish among five different things: model limitations, data limitations, integration failures, process breakdowns and workforce adoption barriers. Each requires a completely different intervention. A model limitation calls for a different system or a narrower task. A data limitation calls for work on lineage and quality. An integration failure calls for engineering. A process breakdown calls for redesign. An adoption barrier calls for managers, training and clarity about decision rights.

Applying the wrong intervention costs more than the delay. It spends the credibility of the programme, which is the scarcer resource. The practical version of this principle is a standing question in every review: before we conclude the model is insufficient, what evidence do we have that it had the access, the data and the authorisation it needed to complete the task?

Evaluate the economics at the workflow level, not the token

Concern about token consumption has become one of the most common reasons to defer or decline adoption. In many of the conversations I have, it functions less as a genuine economic constraint than as a defensible way to avoid starting. It is an effective objection because it sounds like financial discipline.

Two things are wrong with it. AI economics continue to improve, so a decision anchored to today's unit price is anchored to the least stable number in the calculation. And the comparison itself is misspecified. The relevant question is not what the tokens cost in isolation but what the workflow gains — time, capacity, speed, quality and decision support, measured across the whole path of work rather than at a single step. A workflow-level business case takes more effort to build than a unit-cost objection takes to raise. It is also the only one capable of being right.

Integration readiness is a workforce question, not only an IT one

In complex enterprises, integration rather than intelligence is usually the binding constraint. AI creates limited value when it cannot securely reach the systems, data, permissions and workflows required to complete real work. Readiness therefore has to be assessed at the workflow level: which systems does this task touch, what information and approvals does it require, and what actions must AI be authorised to perform?

For CHROs, this carries a consequence that is easy to miss. Roles cannot be redesigned independently of the technology and process environment around them. A redesigned role that assumes an integration which does not exist is a job description nobody can perform, and the person hired into it will spend their first two quarters discovering that. Enterprises that connect work architecture, workforce data and operational systems move from isolated experiments to scalable adoption considerably faster, because the redesign and the plumbing advance together rather than in sequence.

Start where the legacy systems are not

The fastest near-term gains usually come from tasks that do not depend on complex legacy systems. Where work is human-intensive, already within the capability of available AI, and largely independent of difficult integrations, an organisation can move now without waiting for connectors, permissions or infrastructure changes.

This is a sequencing decision rather than a scope decision. Non-legacy work proceeds immediately while legacy-bound work advances as the integration barriers are resolved. The value of going first where it is easy is not only the value of the work itself; it is the confidence it builds and the internal evidence it produces, which is what funds the slower integration work behind it. Programmes that begin with the most difficult and most strategically visible legacy workflow tend to spend their first two quarters producing nothing anyone can point to.

Build for adaptability, with guardrails

Rigid two-to-three-year transformation plans can become outdated before they are fully implemented. Where capability improves on a quarterly cadence, a three-year plan with no revision mechanism is a commitment to implementing an old idea slowly. Agents, workflows and roles should instead be designed for continuous iteration — solving for today's needs while preserving the ability to adapt as capabilities improve.

That is not an argument against governance, and I would not want it read as one. It means combining shorter redesign cycles with clear accountability, risk controls, human oversight and measurable outcomes. Governance and adaptability are usually posed as a trade-off, and in practice they are not. The organisations that change direction fastest are the ones that know exactly who owns what and how it will be measured. Control is what makes rapid change survivable.

Adoption is an operating discipline, not a downstream exercise

AI creates enterprise value only when employees and managers change how work gets done. That sentence is easy to agree with and expensive to act on. It means pairing every deployment with clear role redesign, updated decision rights, practical skill building and manager-led adoption. It means telling people specifically where AI augments their work, where human judgment remains essential, and how performance expectations will change as a result.

Most organisations treat this as a downstream change-management exercise, funded late and staffed thinly. The ones that scale fastest treat it as a core operating discipline that begins when the deployment is scoped. Decision rights are the component most often skipped, and the most damaging to skip. If an employee cannot answer whether they are permitted to act on what the system recommends, or who is accountable when the recommendation is wrong, adoption stalls no matter how capable the tool is. People default to the old process because the old process has a known answer to that question.

What this puts on the CHRO's agenda

The CHRO's mandate here is to convert AI capability into enterprise performance by redesigning work, roles and skills at speed. That is a concrete mandate with concrete components: which tasks move, which roles change, what decision rights follow, which skills have to be built and how quickly, and what management practice looks like when a manager's team includes agents alongside people.

If you are deciding where to begin, begin with the diagnosis. Take the AI initiative in your organisation currently regarded as disappointing and establish, with evidence, which of the five constraints it actually hit. That exercise is more useful than it sounds. The answer is rarely the one everybody assumed, the interventions are different enough that guessing wrong is worse than doing nothing, and the diagnostic habit is what separates enterprises that scale from those that accumulate abandoned pilots. The winners will not be the organisations with the most advanced models. They will be the ones that translate AI into higher productivity, faster execution, better decisions and stronger growth — and that translation is work architecture, which makes it HR's problem to solve.