Skills and transformationPillar article
Training your team to use AI in industry: what actually works on the shop floor
Why AI training fails in technical teams, and the sequence that works when people are on shift, in the field, and nowhere near a desk.
The large consultancies have produced a considerable body of material on artificial intelligence training over the past three years. It is genuinely useful, and it shares one blind spot: it is written for office populations. A maintenance technician does not work in front of a screen. They work on shift, often rotating three eights, wearing gloves, in noise, and their day is already full. What we know about corporate training does not transpose straight across to the shop floor.
The essentials
An AI training programme fails on the shop floor for a structural reason: it teaches a tool instead of addressing a moment of work. What works follows the opposite order: start from a precise task that costs time today, show what the machine changes about it, and only mention the technology afterwards, if someone asks. The question to ask is not "what do they need to know about AI" but "which action in their day changes on Monday".
What the studies say, and what they leave out
BCG defends a split that has become a reference point in the debate: roughly 10% of the value of an AI project comes from the algorithms, 20% from the technology needed to deploy them, and 70% from redesigning the human work around them. The exact proportions are debatable; the ordering, far less so. The same firm observes that the companies extracting the most value from AI are those with the most ambitious upskilling programmes.
McKinsey makes a neighbouring point: AI upskilling should be treated as change management, not as a training catalogue. An isolated session changes no lasting behaviour.
These findings are sound. They are also established, in the overwhelming majority of cases, on populations of managers and support functions. Three differences make transposing them directly to an industrial environment risky.
The workstation. A technician does not have a session open all day. They have a shared computer in the prep room, fifteen minutes before the round, and a phone in a pocket that is hard to open with gloves on.
The relationship to error. In a support function, a mistake produces a document that has to be redone. In maintenance and inspection, a misreading can lead to leaving in service a piece of equipment that should not be. That asymmetry explains a caution it would be absurd to treat as resistance to change.
The team structure. Training "the maintenance team" means nothing when it is spread across five shifts and two people are always absent from any given session. The format itself has to be designed around that constraint.
Why the generic session produces nothing
The sequence is almost always the same. Half a day is blocked out, a speaker explains what a large language model is, shows convincing examples taken from elsewhere, and answers a few questions. The participants leave interested.
Three weeks later, nothing has changed in the actual work. Not because the session was bad, but because it never intersected a real task. Nobody left knowing what to do differently the next morning, on which file, with which document.
The error is not pedagogical, it is one of design: the team was trained on a technology instead of being trained on a use.
The sequence that works
Choose a moment of work, not a theme
Not "AI for maintenance", but "clearing the backlog of inspection reports before the March turnaround". The moment has to be dated, known to everyone, and painful enough that its disappearance gets noticed.
Measure what it costs today
How many hours, spread across how many people, at what point in the calendar. That figure serves twice: it justifies the effort to management, and it provides the baseline that will make progress visible.
Train on the site's own documents
Never on demo examples. A technician who sees a report they filed themselves last year listens differently. It is also the only way to surface the hard cases: the skewed scan, the report from a contractor in an unusual format, the handwritten annotation.
Have them practise during the session, not afterwards
The useful part of a session lives in the forty minutes where participants handle the thing themselves. Anything heard without being done is forgotten before the next shift.
Name a champion per team, not a champion per site
A single point of contact becomes a bottleneck and disappears on leave. One per team, trained more deeply, lets a question find its answer on the shift where it arises.
Come back at four weeks
A second short session, four to six weeks later, built around the cases encountered in between. That is where the real difficulties get resolved, the ones nobody imagined on day one. Without that second pass, half the initial effort is lost.
Three populations, three distinct needs
Treating "the technical teams" as a single block is the second cause of failure. The expectations differ radically.
| Population | What they need to know | What they do not care about |
|---|---|---|
| Technicians and operators | What changes in their work, how to flag a reading anomaly | How the model works internally |
| Methods and inspection leads | What the tool can and cannot read, how to check a value, what to do with a doubt | The group's AI strategy |
| Technical management | What it costs, what it changes in the plan, how to defend it in an audit | The details of day-to-day use |
Table scrolls horizontally on small screens.
A single session for these three audiences leaves each of them wanting. Three short, targeted formats produce more than one shared day, and often cost less in total time.
What to teach first
One point matters more than all the others, and it is rarely on the agenda: learning to spot when the machine gets it wrong.
A tool that reads inspection reports produces values. Knowing how to use them is trivial. The skill to build is recognising a suspect value: a wall thickness that has increased, a condition monitoring location that does not match the equipment, a date that is inconsistent with the campaign. See calculate a corrosion rate on what these anomalies reveal.
This skill is passed on by example, not by lecture. Show five cases where the automated reading got it wrong, have the team analyse them, ask what should have been done. A team that has watched the machine fail five times trusts it more than a team that has been promised it never fails, because they now know where to look.
- Training on the tool rather than the taskparticipants retain an interface, which will change, instead of a method, which will last.
- Using generic examplesa demo report meets none of the site's hard cases, and it discredits the session at the first precise question.
- A single session, with no follow-upthe bulk of the difficulties appear between the second and sixth week of use, and without a second session they never surface.
- A single champion for the whole sitethey fall ill, go on leave, change roles. The skill has to exist in every team.
- Promising the tool never gets it wrongthe first observed error then destroys all trust. Better to teach from the outset where and how it fails.
- Confusing training with communicationa presentation of the group's AI strategy teaches nobody a single action.
Measuring whether the training served any purpose
The number of people trained measures nothing. Three indicators tell the truth.
The time spent on the targeted moment of work, compared with the figure recorded beforehand. It is the most direct measure, and that is precisely why the baseline has to be established at the start.
The number of anomaly reports raised by the teams. Counter-intuitive: if it rises, that is a good sign. It means people are actually looking at the results instead of accepting them passively.
The share of the team using the tool without going through the champion. That is the autonomy indicator, and the only one that predicts whether the practice will survive a departure.
None of these three can be measured on the day of the training. They are measured at three months, and they assume someone took the trouble to record the starting state.
Sequencing training and deployment
A scheduling error comes up often: train everyone first, deploy afterwards. Several weeks pass in between, and the essential part evaporates.
The order that works is the reverse. You deploy on a narrow scope, train the people in that scope the week they start using it, and extend from there. Each wave of training arrives at the moment it is needed, and the later waves benefit from the cases the earlier ones ran into.
This logic matches the progressive rollout described in deploy a first AI project in 90 days, and it assumes the change management addressed in succeeding at change management on an industrial AI project.
What it changes for line management
One last point, rarely said. Upskilling the teams shifts part of the work of line management: less systematic verification, more arbitration on the cases that get flagged. That shift also requires learning, and it concerns the maintenance manager as much as their teams. See which AI skills for maintenance managers.
A trained team asks more questions, pushes back more, and flags what is wrong. That is exactly the intended effect. An organisation that copes badly with that feedback does not have a training problem, it has a governance problem.
Sources and references
**BCG, AI Transformation Is a Workforce Transformation**, the 10 / 20 / 70 split between algorithm, technology and redesigning human work, and the correlation between the ambition of upskilling programmes and the value drawn from AI. Read the publication
**McKinsey, Redefine AI upskilling as a change imperative**, the argument that AI upskilling belongs to change management rather than to a training catalogue. Read the publication
**BCG, AI at Work 2025: Momentum Builds, but Gaps Remain**, a snapshot of use and training in the workplace. Read the publication
How much time should be devoted to training?
Less than people think, but spread differently. Two short sessions four to six weeks apart produce more than one full day in a single go. The total duration matters less than the content: the second session has to address cases genuinely encountered.
Should everyone be trained, or only a few people?
Both, at different depths. A short baseline for the whole team concerned, and in-depth training for one champion per team. Training only a few people creates a dependency that stalls at the first absence.
How do you convince a team that sees no point in it?
By starting from what annoys them. A team sceptical about "AI" is almost never sceptical about "never reopening forty PDFs before the turnaround". The scepticism is about the general promise, not the concrete relief.
And if the tool changes within a year?
That is likely, and it is one more reason to train on the method rather than the interface. Knowing how to recognise a suspect value, verify a data point by returning to the source document and document a correction stays valid whatever the software.
Written by Adama CamaraAI Consultant · Industry · view profile
Published on July 21, 2026
Skills and transformation
Change management for an industrial AI project: what really kills adoption
Why a technically successful AI tool still goes unused, and what actually changes that: the unspoken fear, the local referent, and proof drawn from real work.
Skills and transformation
The industrial maintenance manager: the skills that actually matter today
What is changing in the industrial maintenance manager's role, the skills that genuinely carry weight, and how to build them without a budget.
AI and maintenance
Delivering a first AI project in maintenance: a 90-day roadmap
How to run a first AI project in industrial maintenance without spreading yourself thin: the scope to pick, the first 90 days, and the traps that sink it.
Skills and transformation
Freelance industrial AI consultant: how to choose the best
How to choose the best freelance industrial AI consultant: the profiles compared, the criteria that matter, and how to spot the one who ships a tool.