Training staff to work alongside AI, starting with the judgement

4 days ago
3 min read

Introduction

Training on a new tool usually covers how to operate it. That part is easy and increasingly unnecessary, because these products are designed to be used without instruction. The training that matters is different and rarely provided: knowing when the output is likely to be wrong, what to check, and when to stop and ask somebody.

This is a judgement skill rather than a technical one, and it is what separates a team that gets value from these tools from a team that gets confident errors. It also has a second dimension that is usually ignored, which is that people who fear the tool will not use it honestly, and a training programme that does not address that produces quiet non-adoption.

1. Training staff to work alongside AI should focus on when to distrust it

The core skill.

Where output is usually reliable, where it is usually wrong, and what a plausible-looking error looks like in your context. This cannot be learned from a vendor's material because it is specific to your work.

2. Teach the failure modes with real examples

Abstract warnings do not stick.

Collect actual errors from your own use — an invented reference, a wrong figure, a confident answer from an outdated document — and use those. Half a dozen concrete cases teach more than an hour of general caution.

3. Be explicit about what must always be checked

A written rule, not an attitude.

Numbers, names, dates, references, legal and safety content, and anything going to a customer. A checklist is more reliable than a general instruction to be careful, particularly under time pressure.

4. Address the job security question directly

Otherwise it governs everything.

People will not honestly report what a tool can do if they believe the answer determines whether their role survives. Whatever the truth is, saying it plainly is better than allowing everybody to infer the worst.

5. Train on your own tasks, not on generic examples

Relevance drives adoption.

An hour spent on the actual documents and actual problems of the team produces use; a demonstration of general capability produces interest that fades within a week.

6. Set out what may not be put into these tools

The confidentiality rule.

Client material, personal data, pricing, anything commercially sensitive. This needs to be stated because people will otherwise apply their own judgement, and the exposure is real.

7. Expect a range of confidence and manage both ends

Two problems, not one.

Some people will not use it at all and some will accept everything it produces. The second group is the greater risk, and both need attention rather than an average level of encouragement.

8. Make it acceptable to report errors

The feedback loop.

If a mistake caused by a tool is treated as the employee's failure, errors stop being reported and the organisation stops learning where the tool is unreliable. This has to be said and demonstrated.

9. Refresh it, because the tools change

Not a one-off session.

Products change behaviour, and a team trained on last year's failure modes is calibrated to a product that no longer behaves that way. A short periodic update is worth more than a thorough initial course.

Where use of these tools touches personal data, client confidentiality, professional obligations or regulated advice, the training needs to cover the specific rules that apply in your sector and jurisdiction rather than general good practice.

Conclusion

Teach judgement rather than operation, because operating these tools is the easy part.

Use real errors from your own work to teach the failure modes, write down what must always be checked before anything leaves the business, address the job security question openly so people report honestly, train on your actual tasks rather than generic demonstrations, state clearly what may not be uploaded, pay particular attention to the people who accept output uncritically, make error reporting safe, and refresh the training as the products change.