- We just had an AI near-miss — what should we put in place now?
- Three artefacts address the three things a near-miss usually exposes: an incident response playbook (so the next one has a defined process instead of an improvised one), a risk register (so the risk that caused this near-miss — and adjacent ones nobody’s checked — gets documented and owned), and a bias audit framework (because many AI near-misses reveal a fairness or disparate-impact gap that was never actually tested, even when the incident itself wasn’t framed as a bias issue).
- What actually counts as an AI incident that needs a formal response process?
- The Incident Response Playbook classifies incidents across P1-P4 severity tiers — from a P1 event with material harm or regulatory exposure down to a P4 near-miss with no actual impact. The value of a formal process is precisely for the P3/P4 tier: a near-miss with no visible harm is exactly the kind of event that gets dismissed informally and then repeats, because nobody logged it or asked why it happened.
- Should we run a bias audit if the near-miss wasn't about bias or fairness?
- Often yes — a near-miss in one dimension (a data leak, an incorrect output, a missed escalation) frequently indicates that risk coverage generally has gaps, and bias/fairness is the risk category most commonly untested until something goes wrong prompts a closer look. The Bias Audit Framework’s fairness-testing protocol and 34-item checklist give you a documented answer either way, rather than an assumption that "the incident wasn’t about that, so it’s fine."
- Who should own the post-incident response process?
- Typically a CISO or security-team lead owns the incident response process itself, but the playbook’s RACI matrix and the risk register’s named-owner requirement exist precisely so it isn’t left as one person’s informal responsibility. A near-miss with no named accountable owner for the fix is the most common reason the same near-miss recurs.