AI safety incident log template
When an AI system produces a harmful, biased, or unsafe output, the difference between a one-off embarrassment and a systemic risk is whether you logged it consistently. This tool generates a structured incident log template — a set of columns and example rows — that you copy into your own tracker so every incident is captured the same way, making trends and repeat failures visible over time.
What makes an AI incident different from a software bug
Software bugs are usually deterministic and reproducible: given the same input, the same code path fails. You can add a failing test, fix the code, and verify the fix covers the case.
AI incidents are often none of those things. A model may produce a harmful output once in a hundred attempts at the same prompt. The specific failure may depend on subtle context that is hard to isolate. Prompt changes that fix one class of failure may open another. And unlike a software bug, you cannot always “fix” the underlying model — you can only mitigate through prompt engineering, output filtering, or human review.
This changes what you need to log. Beyond the usual “what happened and when,” an AI incident log needs:
- Exact prompt and context — because you cannot reproduce without them
- Model version — because the same prompt on a different model version may behave differently
- Whether it was deterministic — can you consistently reproduce it?
- How it was detected — user report, internal monitoring, red team exercise, or near-miss catch
- Affected user count — especially important if the failure was in a high-volume path
How it works
You select your organization type and list the AI systems you monitor. The tool assembles a Markdown table (and a matching CSV header) with the core columns of a mature incident log: a unique ID, date detected, the system and model version, incident type, severity, number of users affected, a short description, the suspected root cause, the remediation taken, and a recurrence-prevention action. You can toggle optional columns on or off so the template matches your existing governance process rather than forcing unused fields. The output is plain text you can paste straight into a spreadsheet, wiki, or ticketing system.
Incident types the template covers
| Type | Examples |
|---|---|
| Harmful output | Dangerous instructions, threatening content, self-harm promotion |
| Biased output | Systematically different quality or tone for different demographic groups |
| Hallucination | Confident factually wrong claim, fabricated citation |
| Privacy leak | Model outputs another user’s data or repeats training data |
| Prompt injection | User-supplied content overrides system instructions |
| Excessive agency | Agentic system takes an unintended consequential action |
| Refusal failure | Model refuses a clearly legitimate request (over-refusal) |
| Safety bypass | Instructions intended to block harmful content are circumvented |
Tips and notes
- Log near-misses, not just live failures. An unsafe output caught in staging is a free lesson — record it with the same rigour as a production incident.
- Always capture model version and prompt context. AI failures are often non-deterministic; without the exact inputs you cannot reproduce or fix them.
- Use a fixed severity scale. A consistent 1–4 or low/medium/high/critical scale lets you sort and prioritise across dozens of entries.
- Close the loop with a prevention action. An incident without a “what stops this recurring” line is a story, not a control.