Embedding AI Across an Organisation
Lessons from a year of Copilot adoption across four NHS trusts, and the foundations that need to be in place for it to work.
I've spent the last year leading AI adoption across four NHS trusts and two thousand staff. Everyone expected plug-and-play: buy the licences, switch on the tool, watch the productivity arrive. What we actually got was uneven adoption, ungoverned experiments, pilots that impressed in the demo and died in deployment, and a benefits line that never quite showed up.
I don't read that as a failure story, because the gap between the promise and the reality is where the real opportunity lives. Once you accept that the foundations have to come first, you can build something that compounds rather than something that looks impressive for a quarter and falls over. What we've learned is that the gap doesn't close by picking better tools. It closes by building a system around the tools. The areas below are the ones that have emerged most clearly from the work so far, and the list will grow as our understanding does.
What people can safely do with AI scales with maturity, and most organisations don't know where they sit because they've never tried to measure it. We certainly didn't when we started. Maturity has two dimensions: individuals climbing a ladder defined by the tools they've actually got, and the organisation's own readiness in infrastructure, control and the distribution of capable people. Assess both continuously and you get the number that gates everything else, the level of solution you can currently support and where you can safely test the next one.
Implementations fail when the centre owns the solution. We've seen this across our own programme: a good idea gets handed to a central team, they build it, and the thing collapses on contact with deployment because nobody in the function can carry it. The subject matter expert has to scope it, own every output, and increasingly build it themselves, because without that ownership the solution becomes a central-team dependency that erodes with every handover.
We delivered nearly two thousand training attendances across the programme and captured over three hundred use cases. The training that shifted behaviour wasn't the tool walkthrough. It was mapping the feature set to maturity levels and training the climb, so people learn what unlocks their next step rather than being shown everything at once. Run it that way and the training doubles as a diagnostic, because capturing where people sit as they progress gives you a live map of where capability sits across the organisation.
Most governance debates sit between blocking everything and letting it run, and both fail for the same reason: they treat governance as a single dial rather than two distinct tiers. The working answer is a permissive tier where exploration runs under baseline controls, and a controlled tier that engages when a solution looks viable or could scale. The gate asks one question: can we support this at scale, given where we are?
Wide access guarantees uneven adoption, because some people will always move far faster than the pack. Left alone they drift into private workflows and ungoverned solutions, which means their capability compounds privately instead of organisationally. The control is empowerment: give them a role teaching and codifying what they do, so their ceiling becomes the next cohort's floor.
Transformation used to be something done to a department by a central team. The tools are now inside every team and change happens with or without a plan, which means the person who can steer it is the leader, not the centre. Leaders don't need deep technical skill. They need a lightweight weekly rhythm that catches ideas, scopes them lightly, and feeds the governance pipeline.
The system needs a team to hold it. I'd build it as a lab rather than a Centre of Excellence, because a lab is where the organisation learns what works rather than where standards get handed down. The method is the one you'd use on wet concrete: lay a slab, walk on it, see if it's steady, adjust, lay the next.
We've already seen teams skip the foundations, ship something ambitious, and watch it become unsustainable within months. Then they come back and do the groundwork anyway. Both paths end at the foundations, and one costs far more. The foundations are non-negotiable regardless of the size of any single opportunity, because the risk has to be controlled either way.
- The Maturity LadderAssessing individual and organisational readiness against the feature set of the tools you actually have.
- Solution Scoping and OwnershipWhy every solution needs a subject matter expert who can scope it, own it and sustain it after the build.
- Building Capability, Not Just Rolling Out ToolsWhy 'here is the tool' training fails, and what it looks like to build a structured capability climb that also tells you where your organisation actually sits.
- Governance That EnablesTwo governance tiers that allow safe experimentation while controlling what reaches production and scale.
- Harnessing Pockets of CapabilityChannelling early adopters into organisational learning before they drift from the system.
- Leadership EnablementA lightweight weekly framework for team-level AI evaluation that feeds the governance pipeline.
- The LabA team that tests solutions, builds controls and develops organisational capability simultaneously.