Near misses belong in an AI incident review

A reviewer catches an incorrect recipient or a workflow blocks an unauthorised tool call. The control worked, but the event may still identify a recurring failure mode.

Define what should be recorded

Identify events that merit review because of their potential consequence and the controls involved. Keep the process proportionate and protect sensitive information.

Google’s postmortem guidance connects review with understanding contributing causes and preventing recurrence. An AI near-miss process can use that learning orientation without treating every minor correction as a major incident.

An illustrative assistant preparing an external message might include an inappropriate attachment that a human removes. The review should investigate why the attachment was available and selected.

Examine the system not just the final prompt

Review data access, tool permissions, interface design and approval conditions. A stronger instruction may help but should not replace controls that constrain consequences.

Distinguish a healthy expected review catch from a warning that reviewers are repeatedly preventing the same serious failure. The latter can indicate excessive dependence on attention.

Preserve enough evidence to reproduce the relevant conditions through an authorised test.

Assign an improvement and verify it

Record an owner and a way to assess whether the change reduces the risk. Counting review meetings is not evidence that the failure mode improved.

Review whether the preventive control still works after the proposed fix. A near miss can recur through a different input path if the response changes only one prompt example. Use an authorised regression test that targets the underlying permission or workflow boundary rather than memorising the original incident text.

GAT’s enterprise trust coverage asks for credible controls. Near-miss review supplies evidence about how those controls behave before an incident becomes a customer-facing failure.