Stop, tell, fix, learn

Something will go wrong. A tool will send a summary to the wrong people, a draft will promise something nobody approved, someone will paste the wrong spreadsheet. The guardrails so far make that rarer. This one decides what happens next, and above all, how quickly you hear about it.

The problems you don't hear about

The damage from most incidents grows with time. The longer a mistake runs unseen, the more data it exposes and the more decisions it touches. And the evidence is that most organisations aren't set up to hear quickly.

The usual reason isn't a missing system. It's fear. If the person who notices a problem expects to be blamed for it, or for the tool they were using, the rational move is to fix it quietly or say nothing. The problem goes on, out of sight.

Four steps anyone can follow

Stop, tell, fix, learn is a no-blame path for when AI goes wrong. Anyone who sees it going wrong does four things.

1. Stop it, if they can do so safely. Switch the feature off, pause the agent, recall the email. Nobody needs permission to stop something that's causing harm.
2. Tell, within one working day. Tell the person who runs the loop. If it's sensitive, such as personal or regulated data, or someone's own disclosure, tell the disclosure custodian instead: the person outside the management chain you named with the promises.
3. Fix it. The owner of the tool or workflow contains it and puts it right: tells whoever was affected, undoes what can be undone.
4. Learn from it. A short, blameless note goes on the friction list: what happened, why the work allowed it, what changes. It records the work, never the person.

What counts as AI going wrong

People hold back when they aren't sure something is worth reporting. So say what counts. Anything like these:

• Output that reached someone it shouldn't, or said something that isn't true, to a client, a patient or a colleague.
• Data that went into a tool the data map doesn't allow.
• An agent, or a feature a vendor switched on, doing something nobody expected.
• A result that treats people unfairly, such as a screening tool that keeps rejecting one group.
• A spending alert nobody can explain.

Near misses count too: the wrong figure caught just before a board pack went out, the client file almost pasted into a personal account. Aviation reporting counts near misses because they show where the next accident could come from, before anyone is hurt. Make telling as easy as possible: one contact, one channel people already use, and a note of two lines is enough.

Why it has to be blameless

You made this promise in module 1: a disclosed mistake is handled through stop, tell, fix, learn, as coaching rather than discipline. That holds even if the mistake exposed regulated data or caused harm. Only wilful or criminal conduct falls outside it. And breaking that promise is itself an incident.

It can feel too generous. It's the opposite. Aviation has run on this idea since 1976: the Aviation Safety Reporting System gives pilots and controllers limited protection when they report their own mistakes and near misses, and the reports catch problems before they become accidents. Punishing a report doesn't make the next mistake less likely. It makes the next report less likely.

Blameless doesn't mean nothing changes. The fix is real, and the note on the friction list goes into the next loop. What changes is the work: the setting, the template, the check that was missing. That's also why the note goes on the friction list and not in a personnel file.

Name the contacts

The steps only work if everyone knows who to tell, without looking it up. Your answers from module 1 are filled in where you gave them. Check them, and add how to reach each person the same day.