Rules, Evidence and Common Failure Modes

The first lesson was about what a leader does personally. This one is about what a leader sets up around that behaviour, and the ways it tends to go wrong.

Make the rules visible by following them

Staff learn the real rule from the most senior person's behaviour. If a director pastes a confidential paper into a free public chatbot because the approved tool is slow, the written rule has just been replaced by a different one. The leader's own conduct on sensitive data is therefore the first test of the policy: use only approved tools for sensitive material, say aloud when you decide not to use a tool because of what is in the document, and ask for approval before adopting a new tool rather than after. Exemptions for urgent work are the usual way this erodes. If an urgent exception is truly needed, route it to the person who owns the approval and record the answer.

When a use falls between the categories of approved, needs approval and off limits, treat it as needing approval. Send it to the named approver, record the answer and update the guidance, so the next person does not have to ask.

Make it safe to report errors

AI errors will happen, and the organisation learns about them only if people say so. A leader who criticises someone publicly for a mistake with an AI tool will find that reports stop, and a monthly dashboard showing no incidents will look reassuring when it means the opposite. Respond to a report by thanking the person, logging what happened and asking which check would have caught it sooner. Keep the reporting route short, such as a form or channel that takes a few minutes, and show what changed afterwards. Avoid league tables of errors and rewards for zero reports, which both push errors out of sight.

Keep hype out of your messaging

AI-washing means describing a tool as more intelligent, more proven or more transformative than the evidence supports, or calling ordinary automation "AI" because the label sounds good. It misleads staff about what to expect and misleads customers about what they are getting. Describe the tool as what it is, say what has been observed, and say what is still untested. A sentence such as "two teams found faster first drafts; claims handling is still under evaluation" is less exciting than "AI is transforming how we work", and far more useful.

Keep your judgement and sign-off

A tool can recommend a supplier, flag a payment or draft a risk report, but the decision and the signature stay with a named person. Sign-off that takes thirty seconds because the draft looks right is not oversight. Define what the approver must verify, such as sources, unusual items and anything the draft cannot support, and record what was checked. Do not let a tool decide which of its own outputs need human review. Where an error would be costly, such as an understaffed ward, keep a named person approving. Test any automatic approval on low-stakes cases first.

Ask for evidence, and keep a log

When a team says that everyone loves the pilot, ask what was measured, against what baseline, over what period, and what the results do not show. Staff-reported savings without a baseline should be described as exactly that. A vendor's claim is a claim to test on documents like your own. Alongside this, keep a simple decision log: the decision, who made it, the evidence considered, the conditions agreed and a date for review. A few lines at the time are worth more than a long memo reconstructed later. If an entry is written afterwards, mark it as written afterwards rather than backdating it.

Speak with one voice, and earn credibility from practice

If one director tells staff that AI drafting is welcome and another warns it may lead to discipline, staff will follow whichever message is safer for them. Leaders should agree the facts, the rules and the open questions, and then be free to express different views within that frame.

Finally, a general course certificate shows that someone completed a course. It does not show that they can judge AI output in your context. Credibility comes from demonstrated practice: using approved tools on live work, showing the corrections you made, and discussing failures openly. A certificate can support that, but it cannot replace it.

Worked example

Pennant Freight Services, an invented firm, introduced an approved assistant for drafting customs queries. The managing director announced it as "an AI revolution in our back office", while the head of compliance told her team that using it on client files could lead to disciplinary action. Staff asked the sponsor, Ines, which message was right. She did not pick a winner. She acknowledged the mismatch, met both leaders, and agreed one message: the assistant may draft from templates, client data may not be entered, and uses outside that list need approval from compliance. She wrote the decision, owner and review date into the log, and the managing director dropped the word "revolution" from the next note.