An escalation path that nobody uses does not exist

There is often already a document titled escalation procedure. It contains a diagram with arrows, a row of names, and a few threshold values. The problem is not that the document is missing. The problem is that nobody opens it at the moment it is needed.

That does not happen out of unwillingness. It happens because there is already a path along which problems move upward: the line manager who reports the IT incident, the compliance officer who talks to the business, the team lead who takes his problem to his own manager. That path exists, is used daily, and works — for the things it is meant for. A new escalation path specifically for AI incidents then becomes a second route alongside a route that is already running. When in doubt, everyone chooses the route they know.

Why the second process loses

An escalation path that stands apart from the existing structure requires the employee to first recognize that something is an AI incident, then remember that a different process applies to it, and then take the trouble to follow that process instead of simply calling his manager. Every step in that chain is a moment at which the path is abandoned.

There is also a second reason, less visible but just as decisive: whoever reports a deviation does not want to end up on the organization's incident form right away. If escalating is equivalent to being held accountable, no one escalates. That applies to an employee who used an AI tool that had not been approved, and it applies to a manager who ran a model without anyone knowing about it. An escalation path that is actually used is a path where the first report is not a judgment, but a signal.

What the document needs to contain

An escalation path that works describes three things, and no more than that.

Whoever notices something — an employee, a customer, an external party — needs to know who they can turn to without first having to figure out whether it is an AI matter or a regular operational matter. The path connects to the reporting point that already exists, with an additional branch at the point where it becomes clear that AI is involved.

Who makes the decision — whether something is halted, adjusted, or reported to a supervisory authority — must be established before the incident occurs. Not as an abstract job title, but as a name, with a substitute. Escalation that stalls at an empty mandate is not escalation.

What happens afterward to the person who reported it must be clear. If a second process consists only of a reporting obligation without clarity about the consequences for the person reporting, it will be avoided. That is exactly where shadow AI hides: not in the systems IT knows about, but in the tools someone started using without reporting it, because reporting felt like confessing.

Connecting instead of adding

The solution is not a thicker document. It is an escalation path that makes use of the structure that already exists — the reporting point, the escalation line, the risk committee — and adds an AI-specific branch to it at the points where it makes a difference. Exactly how that connection works, also for the broader policy and the decision log of the oversight body, is described in how you get an AI policy that gets read because it is embedded in what already exists and in how you get an oversight decision log that fits the existing decision-making rhythm. Both documents touch on the same point: a process that stands next to the organization gets ignored; a process that lies within it gets followed.

This principle applies not only to escalation. It applies to the entire governance structure around AI. Whoever wants to know what that looks like more broadly — how risk classification connects to existing risk categories, how connecting to the existing risk structure prevents a parallel bureaucracy from emerging — will find the underlying principle there. The same applies to reporting upward: a one-page board report only works if the escalations it contains have actually been reported. And without ongoing observation of what is changing, every escalation path becomes outdated within a year; what that means in practice is explained at monitoring that delivers something.

The inventory as starting point

An escalation path can only be written once it is known what can escalate. As long as nobody knows which AI is running within the organization — including what was not approved — the document remains theoretical. The Responsible AI Scan therefore does not begin with the escalation path, but with the inventory: what is running, who uses it, and which risk level fits it. Only on that basis can an escalation path be written that connects to what already exists, rather than to what should exist on paper.

From escalation to takeover