If you want to know how to train staff on AI, the short answer is this: stop running lectures and prompt sessions, and have each person build a working tool for a real task from their own job, in a small group, in person, with help at the desk. Then give every build an owner and check six weeks later what is still in use. Attendance is not the measure. Changed work is.
I've watched a lot of AI rollouts inside mid-market businesses. The pattern that fails is familiar: a licence rollout, a lunch-and-learn on writing better prompts, a few enthusiasts, and a business that works exactly as it did. People don't learn AI from watching someone else use it. They learn it by making something that does part of their own job. What follows is the playbook I'd use if I were a COO starting from scratch.
People don't learn AI from watching someone else use it. They learn it by making something that does part of their own job.
Why AI training fails in most businesses
The national picture says most firms haven't really started. The ONS reported in July 2026 that only 11% of UK businesses with ten or more employees say more than half their workforce has received AI-related training. Around 35% of those businesses now use at least one AI technology, but only 10% of adopters say they use it extensively. The government's own figures put the share of UK workers who feel confident using AI at work at just 21%.
So there is a training gap. But the businesses that have trained people often see little change either, and I think that comes down to three mistakes.
It teaches the tool, not the job. A session on prompting shows what a chat window can do. It doesn't show a credit controller how her week changes when the chase list builds itself from the aged debt report.
Nothing gets built. People leave with ideas and no working example. Without a first build, the ideas don't survive the inbox on Monday morning.
It's too short and too remote. The free government courses on the AI Skills Hub take as little as 20 minutes, which is fine for awareness and nowhere near enough for changing how someone works. BCG's AI at Work 2025 survey found regular usage is sharply higher for employees who receive at least five hours of training and have access to in-person training and coaching. The same survey found only around a third of employees say they have been properly trained, and that frontline regular use has stalled at 51%.
None of this is a reason to train less. It's a reason to train differently.
What should AI training for employees cover?
Four subjects, in roughly this proportion of time.
- How the tools work (about 10%). Enough about large language models to know when to trust an answer, when to check it and when not to use AI at all. No history of neural networks. Nobody needs it.
- How the tools fail (about 15%). Invented facts stated confidently. Arithmetic that looks right and isn't. Answers based on stale information. Summaries that quietly drop the one clause that mattered. The fastest way to teach this is to give people a document from their own work and let them catch the tool getting it wrong.
- Safe use and data rules (about 15%). What can and cannot go into which tool. Customer personal data, employee records, anything commercially sensitive. Under UK GDPR, what staff paste into a tool is your data processing, whatever the vendor's marketing says. Write the rules down as a single page and have the team agree them in the room, so they're owned rather than imposed.
- Building (about 60%). Breaking a task into steps, connecting the tools you already licence (Copilot, ChatGPT, Claude or Gemini, plus Power Automate, Zapier, Make or n8n) and testing the result on real examples. Prompting lives inside this. It's a small part of the skill, not a course on its own.
Most programmes I see invert that ratio. Two hours of explanation, twenty minutes of "have a go", and no time to get anything working.
How to train staff on AI: a six-step programme
This is the sequence I'd run for an AI training programme for employees in a business of 50 to 500 people. It works for the first cohort and the tenth.
- Pick the tasks before you pick the training. A week or two before, ask every attendee for one repetitive task from their own week, with a real example attached. "I spend Monday mornings pulling three exports into the KPI pack" is a good answer. "I'd like to learn about AI" is not. Discard anything involving data you can't safely use, and swap in realistic samples where you need to.
- Run small cohorts by function. Up to twelve people from one team, so the examples are relevant to everyone in the room and people can borrow each other's builds. One trainer to six people, so nobody sits stuck for long. Mixed-function cohorts sound inclusive and end up generic.
- Build on real work, in person. Most of the day is spent building, in pairs, at the desk, on the tools the business already pays for. In person matters: people get stuck in small, specific ways (a permission, a file format, an odd edge case) that a webinar can't see.
- Give every build an owner and a one-page note. What it does, where the data comes from, what to do when it breaks, who to ask. This is the step that decides whether the build survives a holiday or a resignation.
- Check at six weeks. Book it before the training happens. Which builds are still in use, which broke and why, what people built afterwards on their own, and what to build next. Expect some to have died. That's information, not failure.
- Measure use, not attendance. Count builds still running at six weeks, people who have built a second thing unprompted, and hours returned on the two or three builds that stuck. Attendance and satisfaction scores tell you the room was warm and the lunch was good.
If the leadership team hasn't built anything themselves, start there. A half day where the CEO and directors each build something small on their own work, before anyone discusses strategy, changes the quality of every AI conversation that follows.
What each team might build on day one
The best day-one builds are dull, specific and useful the next morning. These are illustrative, but they're the shape of what a finance, operations, sales, HR or service team can get working in an afternoon.
| Team | Day-one build | What it replaces | Data to be careful with |
|---|---|---|---|
| Finance | Month-end variance commentary drafted from the ledger export | Writing explanations from a blank page | Payroll and individual salary lines |
| Operations | Supplier emails read, delivery dates pulled out and logged, exceptions flagged to a named person | Reading every confirmation and retyping dates | Supplier pricing terms |
| Sales | Call transcripts turned into structured CRM updates and follow-up tasks | Copying notes into the CRM after every call | Customer personal data in transcripts |
| HR | A policy and handbook assistant that answers staff questions with the source shown | Answering the same holiday and expenses question weekly | Any individual employee records |
| Customer service | Incoming tickets classified, routed and given a drafted reply, with sensitive cases held back | Manual triage of the shared inbox | Complaints and vulnerable customer details |
Notice that none of these is "use ChatGPT better". Each one moves a piece of work. Some will need tidying or rebuilding properly by an engineer later, and that's fine. If you want to see what non-developers can safely build and where the limits are, I've written about vibe coding for non-developers separately.
Is in-person AI training for business worth the cost?
It costs more than an online course, so it should be judged on what it produces. Here's an illustrative comparison for a twelve-person team.
An online course might cost little or nothing per head. Say each person spends three hours on it. You get twelve people with a certificate and, on the evidence above, a modest change in behaviour.
A build day for the same twelve, at our indicative price of £5,000, costs about £420 a head plus a day of their time. You get twelve working builds. Suppose only four are still running at six weeks (I'd usually expect more), and each saves its owner two hours a week. That's eight hours a week, or roughly 350 hours over a working year. At an illustrative fully loaded cost of £30 an hour, that's around £10,500 of time returned from the survivors alone, before anyone builds a second tool.
Those numbers are illustrative, and hours returned only become money when something else changes, which I've covered in measuring AI ROI. But the comparison is the right one: training cost against work that changed, not cost per attendee.
How to run an AI upskilling programme beyond the first cohort
One build day proves the approach. A programme spreads it.
After the first cohort, the pattern I'd follow is a four-session build programme over six to eight weeks for one team, focused on a single process that matters to the P&L. The cohort builds it together between sessions and puts it live with an owner and a measured baseline. That turns twelve people who can build small things into a team that has shipped one big thing.
Then repeat by function. Finance first if month end is painful. Operations first if supplier admin is drowning the team. Let the six-week check results decide the order, not the org chart.
Keep a simple register of every build: owner, what it does, what data it touches, status at six weeks. It takes ten minutes to maintain and it's the document a board, an auditor or an acquirer will eventually ask for. If you sell into the EU, a record of who was trained, on what, and what they built also helps show the staff AI literacy the EU AI Act expects; take your own legal advice on whether and how it applies to you.
And watch for the licence trap. If the business has already bought Copilot or ChatGPT seats and usage is thin, training is part of the fix but not all of it. You bought the licences and nothing changed sets out a one-week audit that tells you who is using them and for what, which is a good source of tasks for your first cohort.
Why AI training programmes stall after the first session
Even good training can stall. The causes are predictable.
No time after the day. If people go straight back to a full diary, their build never gets its second iteration. Protect two hours a week for a month.
No permission. People build something useful and then aren't sure if they're allowed to use it. Agree the data rules up front and say clearly which builds are approved to run.
No one to ask. The trainer leaves and the first error message ends the experiment. Name an internal go-to person, ideally one of the keener attendees, and give them an hour a week for it.
Builds that should have been projects. Sometimes a day-one build turns out to be important enough that it needs proper engineering, integration and monitoring. That's a success, not a problem, but it needs a different route. Why AI pilots fail covers what happens when promising prototypes never get that route.
If you'd like your team to learn this way, in person at your offices, with every attendee leaving with a tool that does part of their job, that's what our hands-on AI training is for. We're based in York and run build days, four-session programmes and leadership half days across the UK.
Questions
What is the best way to train employees on AI?
Train in small groups from one function, in person, on tasks from their own job. Ask each person to bring one repetitive task before the session, teach safe use and how the tools fail through short exercises, then spend most of the time building a working tool for that task with hands-on help. Give every build an owner and a one-page note, and check six weeks later what is still in use.
How long should AI training for employees take?
Longer than a lunchtime. BCG's AI at Work 2025 survey found regular use is sharply higher among employees who get at least five hours of training and have access to in-person training and coaching. A full build day clears that bar in one go. A four-session programme over six to eight weeks goes further, because people build between sessions and come back with real problems to solve.
Why does AI training fail to change how people work?
Because it teaches the tool rather than the job. A prompt session shows what a chat window can do, but nobody leaves with a working example on their own task, so the ideas don't survive Monday's inbox. There is usually no owner for what gets built, no agreed data rules, and success is measured by attendance rather than by whether anything is still in use weeks later.
What should an AI upskilling programme cover?
Four things: how the tools actually work and when to trust them, how they fail (invented facts, confident errors, stale information), the business's data rules for what can go into which tool under UK GDPR, and building, meaning breaking a task into steps and connecting the tools you already licence. Prompting is part of building, not a subject on its own, and should take a small share of the time.
