AI incident response template generator
When an AI system misbehaves in production — a biased recommendation, a harmful generation, a leaked record, or a hard failure — the worst time to design your response is during the incident. This generator produces a structured incident-response runbook tailored to the type of AI incident you select, so you can open a clean checklist instead of improvising under pressure.
The four incident types and their distinct responses
Bias finding — a systematic unfairness in the AI’s outputs has been discovered, often from user complaints, an audit, or a media report. The immediate risk is reputational and regulatory. The response involves: quantifying the scope of the affected population, pulling in responsible-AI and legal leads, deciding whether to disable or down-weight the affected feature, and preparing external communication. This incident type does not always have a “fix” — sometimes the model is not fixable within an acceptable timeframe and the feature must be suspended.
Harmful output — the model generated content that caused or could cause harm to a specific user or a class of users. The response involves: preserving the input/output for analysis, activating trust and safety review, adding a hard content filter or temporary disable on the affected path, and assessing whether affected users need to be notified.
Data leak — the system exposed personal data it should not have. This may trigger GDPR’s 72-hour breach notification window. The response involves: identifying what data was exposed, to whom, and for how long; engaging your DPO immediately; logging the first moment of awareness (the notification clock starts there); and preparing a breach notification if required.
Model failure — the AI system failed technically (timeouts, wrong outputs, provider downtime). This is the most operationally familiar incident type and maps closely to classic software incident response, with the addition of graceful-degradation and fallback considerations.
How it works
Pick an incident type and the tool loads a profile for it: a default severity level, the stakeholders who must be notified, and a remediation checklist specific to that failure mode. Add a one-line system description and an estimate of affected users, and the runbook fills those into a five-phase structure — triage, notification, containment, remediation, and post-incident. Everything is assembled in your browser as plain Markdown that you can copy straight into your incident channel or ticket.
Tips and notes
- Contain before you root-cause. Phase 3 exists on purpose: disable, filter, or gate the failing path before you start the deep investigation.
- Watch the breach clock. For data leaks, the GDPR 72-hour notification window can start the moment you become aware — confirm your duties early.
- Add a regression test. The post-incident phase asks for an eval or test that would have caught the issue; that is what stops a repeat.
- It is a template, not advice. Severity defaults and notification lists are reasonable starting points, not a legal determination for your situation.