Section 1
A licence is not a skill, and a course is not either
Tool training ages badly. The interface changes, the vendor changes, the capability moves, and a curriculum built around which buttons to press expires with it. Worse, tool-shaped training teaches people to produce output rather than to evaluate it, which is precisely the wrong instinct when the output is confident and occasionally wrong. There is a second failure that is quieter. Training delivered without changing anyone's workload produces no practice. People return to a full inbox and use the new skill for nothing, and within a fortnight it is gone. And a third: training that is not connected to a role change reads as decorative. Staff correctly infer that nothing is expected to change, and behave accordingly.
Section 2
The four capabilities that hold their value
Problem definition. Describing what the work is, where it waits, what a correct result looks like, and what the exceptions are. This is the skill research on failed projects keeps pointing back to, and it is not a technical one. Data literacy. Knowing where a number came from, what it excludes, and why two systems disagree. Automation multiplies the consequences of a misunderstood field. Evaluation. Judging whether an output is correct, on what evidence, and knowing what a plausible-sounding wrong answer looks like in your domain. This is domain expertise applied to review, and it is the capability that rises in value as production gets cheaper. Exception handling and process design. Deciding what happens to the cases the system cannot manage, and redesigning the workflow rather than patching around it. None of the four is tied to a vendor. All four transfer when the tools change.
Section 3
Build the curriculum from your own exception log
The best training material in your company already exists in the queue of things your automations could not handle and the corrections your staff made to the outputs. The model below turns that log into a syllabus with real cases and known correct answers. On the roles this reshapes, see [The Future of Work: Preparing Your Team for AI Automation](/blog/the-future-of-work-preparing-your-team-for-ai-automation).
Section 4
Running it without stopping the business
Attach the learning to live work rather than to a calendar. One workflow, one small group, real inputs, and an outcome the business needed anyway. People learn the evaluation skill by evaluating things that matter, not by completing exercises. Protect the time explicitly. Two hours a week, in the diary, with the workload adjusted. Unprotected learning time is the first thing sacrificed to a client deadline, and the message that sends is louder than the announcement that launched the programme. Pair people rather than teaching cohorts. Someone with domain depth and someone comfortable with the tooling, working on the same workflow, transfer knowledge in both directions faster than either would in a classroom. And make one output mandatory: a written note on what the system got wrong and how they knew. That artefact is the evidence the skill exists, and it improves the automation at the same time.
Section 5
The conversation about roles that you owe people
Reskilling programmes carry an unspoken question, and refusing to address it does not make it quieter. If this works, is my job different, smaller, or gone? Answer it in specifics. Which tasks are leaving the role. What is being added, and whether it is genuinely more skilled work or simply more oversight. What happens to someone who does not take to it. Whether pay or grade changes with the role. Be honest where the answer is uncomfortable. A role that shrinks to reviewing machine output all day is a worse job than the one it replaced, and pretending otherwise costs you the trust you need for the next change. If that is the direction, say so and design the role deliberately, with rotation and with the interesting work distributed. And keep decisions about employment with named humans. Using an automated assessment to shape who gets trained or retained is the fastest way to lose the room.
Section 6
How to tell the training worked
Not completion rates, and not certifications. Four signals that are harder to fake: the share of automated outputs corrected before they reach a customer, the number of errors staff report voluntarily, how many workflow improvements were proposed by the people doing the work, and whether new starters are trained by colleagues rather than by an external course. One behavioural test is worth more than any of them. Give someone a plausible but wrong output from a system they use, and see whether they catch it. If they do, the capability is real. If they do not, you have taught people to operate a tool and called it readiness. The wider context is in [Top AI Automation Trends for 2026 and Beyond](/blog/top-ai-automation-trends-for-2026-and-beyond).