Synopsis
Only 5% of companies capture AI value at scale, and only 26% of executives are rated AI-proficient by their peers. The distance between those numbers and the money being spent is not a technology gap — the models work and the pilots demo beautifully. Then adoption stalls, and the post-mortem finds the same three culprits every time: trust, incentives, and leadership. This document argues that the four answers the market offers all miss the problem. Prompt-pack consultancies assume the blocker is knowledge, when awareness and desire do not add up to action. Design-sprint shops borrow the word “sprint” for a workshop format with no behavioural science underneath. Forward-deployed engineers get one big thing right — build inside the client's workflow — but have no grounding in trust, incentives or organisational dynamics, so adoption remains someone else's problem. And classic change management sits outside the team, delivering communication plans and readiness assessments designed for a go-live date and a stable end-state, neither of which AI has. The thesis is that change leadership must be embedded in the build team rather than communicating about the build from outside it, so that user acceptance and scaling design happen during the build instead of being bolted on afterwards.
Key findings
- Only 5% of companies capture AI value at scale and only 26% of executives are rated AI-proficient by their peers — a gap that is not explained by the technology, since the models work and the pilots demo well.
- Classic change management was designed for a go-live date and a stable end-state. AI has neither — by the time an outside-in programme mobilises, the model has updated twice and the pilot is already dead.
- Forward-deployed engineers get one thing right — build inside the client's workflow — but they are engineers, so adoption is someone else's problem, and that someone never arrives.
- “Low trust” is not a diagnosis: RIST diagnostics run inside the sprint to locate which of the four trust dimensions is failing, and whether the failure is under-trust or over-trust, because each demands a different intervention.
- Scaling is a decision, not a hope. At the scale gate, observed behaviours, calibrated trust and governance settings determine whether a build scales, iterates or stops — and killing a build that should not scale is a success of the method.