Why write it down
Every AI tool will eventually produce something wrong. A reminder goes to the wrong person, a summary leaves out a key point, a classifier flags a harmless message or a chatbot gives a customer a bad answer. The mistake itself is often less damaging than the confusion that follows: nobody is sure who is responsible, whether it should be reported or what to do next.
An escalation path is a short, written plan that answers those questions in advance. It says what counts as a problem, who is told, who decides what to do and how the lesson gets back into the system. It matters most in the sensitive uses covered in this section, where errors can affect health, employment, legal standing or security.
The parts of a useful path
1. What triggers escalation. Define the signs that something has gone wrong, in terms people can recognize. Examples might include: an output that contradicts a source document, a complaint from an affected person, a result that could not be explained, a system that took an action nobody approved, or a possible exposure of personal data. Include “I am not sure” as a legitimate trigger.
2. Severity levels. Not every mistake deserves the same response. A simple scale of three levels is often enough:
| Level | Meaning | Typical response |
|---|---|---|
| Low | Minor, caught internally, no one affected | Fix and log |
| Medium | Someone affected or could be, but correctable | Notify the owner promptly, correct, tell those affected |
| High | Potential serious harm, privacy breach or legal exposure | Pause the tool, notify senior staff immediately, involve specialists |
The labels and thresholds should fit your organization, and borderline cases should be treated as the higher level until clarified.
3. Named roles. Write down who does what, using roles and not only names so it survives staff changes. Typically this includes the person who spots the issue, the tool’s owner who investigates, a decision maker with the authority to pause the tool, and contacts for privacy, legal, security or clinical leadership where relevant. Each role needs a backup for holidays and illness. The question of who bears responsibility is explored in accountability.
4. Timing. Say how quickly each level should be reported and answered. “As soon as possible” is not a plan. Choose realistic timeframes and make sure someone is actually available to meet them.
5. A stop button. Decide in advance who can switch the automation off, and how. If stopping a tool requires three approvals, it will not be stopped quickly. Also have a manual fallback, so the work can continue while the tool is paused.
6. Communication. Decide who tells affected people, customers or patients, and what is said. Plain, honest statements are better than vague ones. In some situations, such as a breach of personal data, laws or contracts may require notification within certain deadlines; consult a qualified professional to learn what applies to you.
7. Record keeping. Log what happened, what was found, what was done and when. Keep the original output, the input and any human edits where privacy rules allow. This is part of good compliance records.
8. Learning. After an incident, ask what failed: the tool, the instructions, the data, the review step or the training. Then change something. Update the instructions, add a check, adjust the scope or retire the tool if it is not suitable. See tool retirement for when that is the right call.
Making it work in practice
Keep it short. A one- or two-page document that people will actually read beats a long policy nobody opens. Put it where staff can find it, and include it in staff training.
Make reporting safe. If people fear blame, mistakes will be hidden. Treat early reports as helpful, and focus on fixing the process rather than finding a culprit.
Test it. Run a drill with an invented scenario, clearly labeled as hypothetical. Does everyone know who to call? Does the contact list work? Does the stop button exist? Testing reveals gaps cheaply, much like workflow testing for the automation itself.
Build it into review. The path works together with human review, which is how many errors are caught in the first place. Reviewers should know that they can escalate and what happens next.
Tie it to your policy and risk work. The path should be consistent with your AI use policy and with items in a risk checklist. Different tools may need different paths. A scheduling tool and a tool that supports clinical documentation do not carry the same risk.
Review it regularly. People change roles, tools change and new uses appear. Revisit the path at least when a new tool is added and after any significant incident.
A short example structure
Here is a skeleton you can adapt. It is an outline, not a legal or professional standard.
- Tool covered and its owner
- What counts as a mistake (triggers)
- Severity levels and examples
- Who to notify at each level, with backups
- Who can pause the tool, and the manual fallback
- Who communicates with affected people
- Where incidents are logged
- How and when the path is reviewed
Having this in place does not prevent every error. It means that when one occurs, people know what to do, and the organization can respond calmly and learn from it.