Checklist: rolling out an AI incident-triage assistant safely

A triage assistant can save the on-call engineer the first 15 minutes of every incident: gathering alerts, recent deploys, error logs and the relevant runbook. Roll it out in stages.

#Stage 1: Read and summarise (no actions)

• Data sources listed and approved: alerts, metrics, logs, deployments, CMDB, runbooks.
• Access via read-only service identities, scoped to the systems needed.
• Logs sent to the model are filtered for secrets and personal data (tokens, passwords, customer PII).
• Output always shows sources: links to the alerts, dashboards and log queries it used.
• Clear label in the ticket: "AI-generated summary, verify before acting".
• Data stays in the approved region; the provider doesn't use it for training (check the contract).

#Stage 2: Suggest actions

• Suggestions come from approved runbooks, quoted with links, not invented commands.
• Each suggestion states the confidence and the evidence ("error rate jumped 2 minutes after deploy 4711").
• Engineers can mark suggestions useful / wrong; feedback is reviewed weekly.

#Stage 3: Execute low-risk actions (optional)

• An allow-list of actions (for example: scale out a stateless service, restart one pod, clear a CDN cache path).
• Every action needs a named human approval in the incident tool, with the exact command shown.
• Blast-radius limits: one service, one environment, rate-limited.
• Automatic stop if metrics get worse after the action.
• Full audit log: who approved, what ran, result.
• Never: deleting data, changing security groups or IAM, failing over databases, production schema changes.

#Evaluation before go-live

• Replay 30–50 past incidents and compare the assistant's summary and suggestions with what really happened.
• Measure: correct root-cause hint rate, harmful or wrong suggestion rate, time to first useful summary.
• Test prompt injection via log lines and ticket text.

#Operations

• Kill switch that disables the assistant without a deploy.
• Model and prompt versions recorded with every output.
• Cost per incident monitored, with a budget alert.
• The assistant's own failures (timeouts, provider outage) never block the normal incident process.

Warning

During a major outage, your model provider or network path to it may also be impaired. Engineers must be able to work exactly as before without the assistant.

Tip

Measure success as time to mitigate and engineer feedback, not number of AI actions. A good assistant often just puts the right graph and runbook in front of the right person.