How to Build AI Champions in Your Organisation

By James Cotton, Founder, iO-Sphere

The real question isn't how many people you can put through AI training. It's who, inside each team, carries the practice forward after the trainer leaves. That's what a champions programme has to answer, and most don't. They appoint an enthusiast, hand over a title, and wonder why nothing changes.

What an AI champion actually does, and why organisations need them

An AI champion is a practitioner with enough hands-on capability to do real work with AI, and enough standing with colleagues that the practice spreads outward from them. They can sit next to a peer and say "here's how I did it, on our data, in our stack" and be believed, because they've actually done it.

Organisations need them because AI adoption doesn't happen at the point of purchase. It happens at the desk, when someone decides that this week they'll draft the report differently, automate the reconciliation, or ask the model to sanity-check the forecast. Tooling makes that possible; a colleague who has already done it is what makes it happen. The trainer who ran the workshop doesn't know your data or your day. A champion does.

One caveat to hold onto: a champion is not a way to avoid training the team. Treat one enthusiast as a substitute for building capability and you get a single overloaded person and a team that never changes. The champion multiplies the capability you've built rather than replacing the work of building it.

The real barrier to AI adoption: capability, not technology

Most AI initiatives fail on adoption, not on tools, and the evidence is now hard to ignore. MIT NANDA's 2025 study found that 95% of generative-AI pilots delivered no measurable P&L return within the pilot window (pilots typically running 3 to 12 months) despite $30 to 40bn of enterprise investment, and named the core barrier as learning, not infrastructure, regulation or talent. RAND's August 2024 analysis put the AI-project failure rate at over 80%, roughly twice the rate of non-AI IT projects, with failure defined as not meeting the primary stated objectives within scope and budget, and named the number-one root cause as a misunderstood or miscommunicated problem. S&P Global found the share of organisations abandoning most of their AI initiatives jumped from 17% to 42% in a single year.

Read those together and a pattern shows: the money went to the supply side (models, platforms, licences) and the demand side went unfunded. The demand side is people who can put any of it to work. Only around 23% of UK businesses were using AI in late September 2025 (up from 9% in September 2023; ONS Business Insights and Conditions Survey, 2 October 2025), which means adoption is still the constraint, not tool availability. The ONS also notes the most common workforce response is upskilling existing staff, not replacement. So "which tool next?" is the wrong question. The right one: why isn't the tool you already bought changing how anyone works?

Our view, from running work-embedded programmes across UK employers, is that adoption is a learning problem and training is the lever. Buy tools last and build capability first. The honest boundary: some initiatives genuinely die on poor data quality or a badly framed problem rather than on skills. But framing a problem well is itself a capability, so the diagnosis usually lands in the same place. A champions programme is how you fund the demand side deliberately instead of hoping it self-organises.

Key figures at a glance

Generative-AI pilots with no measurable P&L return: 95% within the pilot window (pilots typically 3 to 12 months); barrier named as learning, not tools (MIT NANDA, "The GenAI Divide", fieldwork Jan to Jun 2025)
AI-project failure rate: Over 80%, roughly twice the rate of non-AI IT projects; failure defined as missing primary stated objectives within scope and budget; top root cause is misframing the problem (RAND report RRA2680-1, August 2024)
Organisations abandoning most AI initiatives: Rose from 17% to 42% in one year (S&P Global Market Intelligence, Voice of the Enterprise, fieldwork Oct to Nov 2024)
UK businesses currently using AI: ~23% in late September 2025, up from 9% in September 2023; the most common workforce response is upskilling existing staff, not replacement (ONS Business Insights and Conditions Survey, 2 October 2025)

How to identify the right people to become AI champions

Pick champions by pull, not seniority. The person colleagues already drift over to for help is where the practice will spread from, whatever their job title says. Seniority tells you who signs things off. Pull tells you where behaviour actually travels.

That reframes the selection question. You're looking for the informal node in each team's network: someone with credibility and curiosity in roughly equal measure. Three practical filters:

Existing pull: do people already ask this person how to do things? Trust is the thing you can't train, so start from where it already exists.
Genuine appetite: they're curious about the work, not just the technology. Someone who loves the demo but won't change their own workflow makes a poor champion.
Proximity to real, repeatable work: someone close to the team's recurring tasks has something concrete to practise on and something concrete to demonstrate.

Suitability here mirrors how we think about fit for our programmes generally: it turns on the substance of the role and the work, not a title. Data and AI run through most jobs long before anyone's title says "analyst", so far more of your people are viable champions than the org chart suggests.

What to actually teach: applied AI skills, not awareness training

Teach applied skills on real work. Awareness training (the hour-long "intro to AI" video, the town-hall deck) tells people AI exists. It does not make them able to do anything on Monday morning. The capability that changes behaviour is built by doing the work, coached by someone who's done the job, on the kind of task the person actually faces.

This is the method, not a preference. People get good at data and AI by doing the work, coached by practitioners, rather than by studying it in the abstract. On our AI-focused programmes that means learners practise on genuine data in a safe environment. Our flagship proof of this is Prism, a simulated e-commerce company built on 500M+ rows of real data, where learners work like a practitioner without any risk to live systems. Real data, simulated company: the sandbox is the safety.

In a champions context, the two cohorts learn different things. Your depth cohort learns to frame a problem, prepare and interrogate data, build a working solution with AI, and judge the output critically, using their team's own recurring work as the material. The broad cohort learns working fluency: enough to use the AI assistants their workplace runs confidently and safely, to spot where AI helps and where it misleads, and to hand work to and from the champion. Neither group needs a lecture on transformer architecture. Both need reps.

Structuring a champions programme: cadence, coaching, and cross-team spread

Pair depth for a few with breadth for the many, and give the depth cohort a mandate and protected time. This is the shape that makes a champions programme stick, and it's a change-management design more than a training plan.

Depth for a few. A small number trained to genuine capability through sustained, coached doing: the apprenticeship-shaped route, where practice compounds over months rather than dissipating after a workshop. Depth takes time: external "AI practitioner" programmes advertise durations like 14 months for a Level 4 route (bestpracticenet.co.uk, 2026-05-29), a reported single-source example rather than a fixed rule, but a useful marker that real capability is a programme, not an afternoon. Our own AI Transformation apprenticeship (the Level 4 IS Business Analyst standard, ST0117) runs as 15 months of training plus a 3-month end-point assessment, assessed on real work through a portfolio and professional discussion rather than in an exam hall.

Breadth for the many. Around each champion, colleagues with working fluency from shorter courses, so the champion has people to hand work to and somewhere new practice can stick.

Why the ratio matters more than the numbers. The failure modes are symmetrical, and worth naming because most programmes stumble into one of them. Train everyone to the same shallow depth and you get a thin layer of awareness with no-one capable of answering a colleague's real question. The "intro to AI" glow fades and behaviour doesn't move. Train a few to depth but leave the surrounding team with no fluency and the opposite happens: the champion becomes a bottleneck, fields every question personally, and burns out inside a few months while the practice never propagates. In our experience the smallest unit that actually spreads is one depth-trained champion per team surrounded by colleagues with at least working fluency: enough shared vocabulary that work can travel back and forth without routing through one exhausted person. Depth-for-a-few is not elitism or cost-cutting; it's the only ratio where breadth has somewhere to anchor.

Cadence and coaching. Cascading slide decks is not the model; cascading practice is. Build a rhythm: regular coached sessions where champions work on real problems, then a forum where they demonstrate to their teams. Peer demonstration lands where external training can't, because "here's how I did it on our data" collapses the distance between the course and the day job.

The non-negotiable: a mandate and protected time. Champions fail when they're appointed rather than resourced. A title with no protected hours turns your most motivated person into your most frustrated one: they carry the expectation and none of the capacity. Put the time in their calendar, back it visibly from leadership, and treat it as protected the way off-the-job learning is protected on an apprenticeship. Without that, the programme quietly dies and everyone blames "AI adoption" rather than the design.

On vendor-run alternatives. You don't have to build champions through an apprenticeship, and the only route doesn't run through us. Vendor enablement tracks (Microsoft Copilot adoption programmes, Google Cloud training and the like) are legitimate and often the fastest way to get a team fluent in a specific tool. Their limit is exactly that: they train for the vendor's stack, not for your team's actual work or your own data. Our approach is deliberately work-embedded and tool-agnostic, which matters when the goal is capability that survives a change of tooling rather than proficiency in one product. Use vendor tracks for tool-specific fluency; use a work-embedded programme when you need people who can frame and solve the problem whatever the tool.

Measuring impact: the adoption signals that show champions are working

Measure adoption, not attendance. Course completions and headcount trained tell you people showed up; they tell you nothing about whether work changed. Judge the programme by who's using AI on Monday morning and what they're doing differently.

Useful signals, roughly in order of how much they matter:

Changed workflows: specific, named tasks now done with AI that weren't before. This is the whole point; everything else is a proxy for it.
Work travelling to and from champions: colleagues bringing real problems to champions, and champions handing solved patterns back. Pull inside the team is the clearest sign the network is forming.
Time reclaimed or quality improved on recurring work: measured on the actual tasks the team owns, not a generic productivity claim.
New practice originating outside the champion: the strongest signal of all. Someone who isn't a champion adopting a technique because a peer showed them. That's spread, and spread is the goal.

Set a baseline before you start: a light read of where each team's data and AI maturity sits today, so you can see movement rather than assert it. Vanity metrics like licences issued or videos watched will flatter you and mislead your board.

Who this model isn't right for

The depth-for-a-few, breadth-for-the-many shape is the right one for most employers trying to make AI stick team by team. It is not right for everyone, and it's worth being honest about when to look elsewhere before you spend a budget on it.

If your real blocker is data or infrastructure, fix the pipeline first. RAND's finding that a misunderstood or miscommunicated problem is the number-one cause of AI project failure applies here, and poor data quality often sits underneath that. If your teams can't get clean, trustworthy data to the desk, a champions programme won't unstick that. Sort the plumbing, then build the people.
If you need shallow fluency across hundreds of people in weeks, this is the wrong shape. A depth-first cohort model moves at the speed of coached practice, not a mass rollout. If the immediate goal is baseline confidence across 500 staff quickly, start with a broad short-course rollout and come back to depth once fluency is the floor.
If you're a small employer with no levy account and a constrained training budget, weigh the overhead honestly. The apprenticeship route carries real cost beyond fees: protected off-the-job hours, end-point assessment, months of managed time. At small scale that overhead can outweigh the funding benefit, and a shorter, self-funded route may serve you better. Genuine capability is still worth paying for; just be clear-eyed about the shape that fits your size.

Common pitfalls that stall AI champion initiatives

Most champions programmes stall on three predictable design errors, and all three are avoidable if you name them at the start.

The all-at-once rollout. Everyone trained identically and shallowly, so nobody ends up deep enough to coach anyone else. You get a thin layer of awareness across the whole organisation and no capability anywhere.

Champion as messenger. Treating the champion as a relay for leadership's AI messaging, cascading decks downward. Messaging doesn't change behaviour; demonstrated practice does. If your champions are presenting rather than pairing, you've built a communications function, not a capability one.

Title without resource. The most common failure: appointing champions without protecting their time. Motivation curdles into frustration fast when the expectation arrives and the capacity doesn't.

A note on apprenticeship units, since they're new and sometimes pitched as a quick capability fix: from April 2026 the Growth & Skills Levy (formerly the Apprenticeship Levy) also funds short apprenticeship units, and the AI leadership units are Level 5, 30 to 140 delivery hours. Our honest view is that the funding is small and the format constrains depth, so a unit suits an employer who needs a fully-funded, narrow, short intervention and cannot fund more. It is not what we'd recommend where the genuine capability a champion needs is the goal. For that, a fuller programme earns its cost.

FAQ

What's the difference between an AI champion and AI awareness training?

An AI champion is a person who does real work with AI and spreads the practice to colleagues; awareness training is content that tells people AI exists. The distinction matters because awareness rarely changes behaviour on its own: 95% of generative-AI pilots delivered no measurable P&L return within the pilot window (MIT NANDA, 2025), with learning named as the barrier. A champion closes the gap awareness leaves open, by demonstrating on the team's own work.

How many AI champions does an organisation need?

Fewer than most people expect, trained deeper than most people plan for. The model is depth for a few and breadth for the many: a small number built to genuine capability through sustained coached practice, surrounded by colleagues with working fluency from shorter courses. One well-resourced champion per team, backed by a fluent team, beats a dozen thinly-trained ones with no depth to draw on. Get the ratio wrong the other way, depth with no surrounding fluency, and the champion becomes a bottleneck who burns out.

How do you choose who becomes an AI champion?

Pick by pull, not seniority: the person colleagues already go to for help is where the practice will spread from. Look for existing informal trust, genuine curiosity about the work rather than just the technology, and proximity to real recurring tasks they can practise on and demonstrate. Job title is a poor guide; where behaviour already travels in the team is a good one.

How long does it take to build practitioner-level AI capability internally?

Genuine capability is a programme, not a workshop. External Level 4 "AI practitioner" routes advertise durations around 14 months (bestpracticenet.co.uk, 2026-05-29, a single-source example), and our own AI Transformation apprenticeship runs 15 months of training plus a 3-month assessment. Working fluency for the broader team is much faster, via focused short courses. The mistake is expecting depth from an afternoon; the design fix is pairing the two timescales deliberately.

Can we fund an AI champions programme through the apprenticeship levy?

Yes. You can fund the depth cohort through approved data and AI apprenticeship standards using your Growth & Skills Levy (formerly the Apprenticeship Levy) account, and a non-levy SME can fund them at little or no cost: fully funded for under-25 starts, 95% co-funded otherwise, or free where a levy transfer covers the cost. The exact split depends on employer type and learner age under the 2026 to 27 funding rules. The standards are owned by Skills England, which replaced the Institute for Apprenticeships and Technical Education (IfATE) on 2 June 2025. The ST0117 standard itself is unchanged, but check the current funding rules and standard against Skills England rather than older IfATE documentation. Funding is the plumbing, though; the reason to run the programme is capability, not the funding.

Can we build champions through a vendor programme instead of an apprenticeship?

You can, and for tool-specific fluency it's often the fastest option: Microsoft Copilot adoption programmes and Google Cloud training, for example, are legitimate routes. Their limit is that they train for the vendor's stack rather than for your team's actual work and data. If you need people who can frame and solve the problem whatever the tool, a work-embedded, tool-agnostic programme fits better; if you mainly need a team confident in one product, a vendor track may be all you need.

Why do AI champion initiatives fail?

They fail on three design errors: rolling training out identically and shallowly so nobody's deep enough to coach; treating champions as messengers who cascade decks rather than demonstrate practice; and appointing champions with a title but no protected time. The last is the most common: a mandate without capacity turns a motivated person into a frustrated one. Resource the role, don't just name it.

If you're a transformation, HR or L&D lead working out how to make AI adoption stick team by team, the honest first step is a scoping conversation: what your teams need to be doing differently in six months, and which routes fit. Our AI Transformation apprenticeship builds the depth a champion needs, data fluency courses give the surrounding team its breadth, and we help employers blend routes around the work rather than the catalogue. Talk to us →