Who gets paged when the AI misbehaves

What makes an AI alert different?

Conventional alerting assumes a broken thing. The service is down, the queue is backed up, the disk is full. Someone is paged, they fix the thing, the alert clears.

AI systems fail while working. The endpoint is healthy, latency is normal, and the answers are wrong, or the spend has quietly tripled, or a document reached someone who should not have seen it. Nothing is down, so nothing pages, and the failure continues until a person notices.

The second difference is ownership. A degraded answer is a product problem. A runaway spend is an engineering problem. An exposure is a security problem. A conventional on-call rotation covers one of those.

The rule worth adopting

Before a threshold is switched on, it names three things: the person who receives it, the hours they are expected to cover, and the action they are expected to take. If any of the three cannot be filled in, the threshold is not ready, and switching it on anyway produces the failure mode that matters most — an alert nobody acts on, which trains everyone to ignore the next one.

This is standard site-reliability practice rather than an AI-specific idea. Google’s own guidance on actionable alerting makes the same argument from the other direction: a page that cannot be acted on is noise with a pager attached.

What is actually a page, and what is a queue?

Most AI signals are not pages. Treating them as pages is how a team burns out in a fortnight.

Spend deviation is a page, because the damage accrues by the minute and the action — cap the key, then investigate — is fast and reversible. A confirmed data exposure is a page, because the clock on any notification obligation starts at assessment. A model or tool appearing without approval is a working-day queue item. A weekly quality score moving is a queue item and a conversation, unless it falls off a cliff.

Signal	Who	When	First action
Spend deviating from the trailing baseline	Engineering on-call	Immediate	Cap the key, then find the loop
Suspected data exposure	Security lead	Immediate	Contain, preserve evidence, start the assessment clock
Refusal rate or answer quality moving	Product owner	Working hours	Compare against the weekly set; decide whether to roll back a prompt
New model or tool in traffic	Platform owner	Working hours	Approve it or block it, and record which

The runbook matters more than the alert

The question at two in the morning is not what happened. It is what may be switched off, by whom, and what breaks when it is.

A usable AI runbook answers that before the incident: who is called, how a model or a tool is disabled within minutes, what is preserved for the investigation, who tells the customer, and who decides whether the whole feature comes down. Written once and filed, it is a document. Rehearsed once a quarter, it is a capability, and the rehearsal is usually where the team discovers the off switch had never been tested.

Three AI-specific additions

Mapping an AI runbook onto a standard incident framework works, with three additions. An incident taxonomy that has somewhere to put behavioural failures, so they do not all land in “other”. A containment decision tree that separates what may be done automatically from what needs a human. And an evidence standard: who was affected, what data was in scope, what was done, and who approved it.

That last one is what turns an incident into something an organisation can explain afterwards, to a customer, a board or a regulator.