AI incident response does not end with system recovery

The OECD distinguishes events where AI development/use/failure directly or indirectly leads to actual harm as incidents, and events with the potential to lead to harm as hazards, structuring its common reporting framework with 29 criteria. By accepting dangerous behaviors and near misses as reportable targets even when losses are not yet confirmed, one can increase learning materials before escalation. [2]

The intake window does not make “confirmation that the AI is the cause” the initial condition. Record model name/version, usage function, time, input, output, subsequent processing, human intervention, affected targets, and whether the issue is ongoing, classifying them as incident, hazard, standard failure, or false alarm afterward. This avoids designs where intake is delayed while waiting for cause confirmation. [2]

Initial triage is based on impact, not cause. Mark cases at intake where dangerous outputs were passed to subsequent processing, similar usage is ongoing, or affected targets cannot be identified, and do not close cases where any of these remain as standard inquiries. Since the OECD’s classification does not automatically determine legal severity, separate responsible persons confirm internal suspension criteria and the need for external reporting. [2]

NIST AI RMF 1.0 structures risk management through GOVERN, MAP, MEASURE, and MANAGE; MANAGE addresses plans for incident response, recovery, and communication. [1] As an operating proposal aimed at avoiding evidence overwrites and premature reopening, Catalysphere recommends separating service restoration from evidence preservation and impact assessment. NIST does not demonstrate an incident-reduction effect from this division of responsibilities.

In the initial response, suspend or degrade the affected function and explore downstream functions using the same model. Simultaneously, preserve the model version, system prompt, search documents, tool calls, guardrail settings, audit logs, and human approval history. Evidence containing personal or confidential information must follow storage procedures that limit investigation purposes and access rights to prevent secondary damage.

Do not fixate the root cause on the model solely based on the fact that it produced anomalous text. Align upstream data, search documents, tool responses, permission settings, approver approvals, and post-processing on the same timeline, and eliminate hypotheses through reproduction tests. Since re-execution before evidence preservation can alter states, the recovery team uses a replicated environment, while original logs remain under the investigation team’s control. [1]

Article 73 of the EU AI Act requires providers of high-risk AI systems in the EU market to report serious incidents, imposing different maximum deadlines: 15 days in principle, 2 days for widespread violations, and 10 days for deaths. It allows for submitting a complete version after an incomplete initial report if necessary, rather than stopping the clock while waiting for a complete investigation. [3]

Include in your internal severity table: physical/health, fundamental rights, critical infrastructure, property, community, environment, data leakage, spread, and continuity. Set internal notification deadlines for customers, vendors, management, PR, security, and legal even if they fall outside statutory reporting targets. Since the starting point of the clock varies by applicable law and contract, connect individual judgments to experts. [2] [3]

The OECD’s common reporting framework organizes events into comparable items but does not automatically determine causality or damage targets for individual cases. [2] In incident response, create an impact verification log that traces backward from the problematic output to which screens, notifications, files, and subsequent processing it reached, and who viewed or acted upon it. Also record the time of confirmation.

The verification log connects output identifiers, distribution destinations, subsequent automated processing, human judgments, measures actually executed in reality, and the need for correction into a single thread. Do not fill gaps in logs with speculation; instead, leave the scope broadly pending as unconfirmed. Distinguish cases where erroneous outputs were not utilized from cases where seemingly correct outputs led to erroneous measures.

For corrections, close the loop for each target by verifying not only if the original display was removed, but also if the correction reached reposts, forwards, manually entered records, and subsequent judgments. If affected targets cannot be identified, separate known and unconfirmed scopes and designate a decision-maker for additional notifications. Process recoverable impacts in order without waiting for the completion of cause investigation.

Before closing the incident ticket, establish a refutation task that attempts to reproduce the same type of failure, rather than relying on the explanation of the fix. Separate conditions that reproduce the original input, boundary inputs, missing log conditions, and alternative causes, and verify under which conditions detection, containment, and correction initiation function. Do not close based on success cases alone; save the failure conditions.

If the refutation task fails, classify it as insufficient correction, insufficient observation, insufficient authority, or insufficient correction path, without mixing it with incident cause labels. Even if the root cause explanation is correct, response capability is not restored if impact search and correction cannot be reproduced. Conversely, even if the cause is undetermined, separately record the fact that containment and recovery were verified within a limited scope.

In the closure judgment, explicitly state uncorrected targets, remaining cause hypotheses, detection conditions for recurrence, and triggers for reopening. A responsible person other than the investigator verifies the verification log and refutation results, accepting remaining uncertainties before closing. Maintain a state where the same incident number can be reopened if new targets or evidence are found later.

• TRACE: Connect output, distribution, subsequent processing, human judgment, and real-world measures
• REPAIR: Close correction destinations, arrival confirmation, and unconfirmed scopes for each target
• REFUTE: Re-test same-type failures with original inputs, boundary conditions, and alternative causes
• CLOSE: Fix unresolved items, reopening triggers, and closure approvers

Resumption conditions consist of cause hypotheses, impact scope, reproduction tests, regression tests, residual risk, alternatives, monitoring metrics, and approver authorization, rather than simply “fixes applied.” If the root cause cannot be identified, choose reversible resumption by narrowing target users or functions, adding human verification, or setting observation periods. [1]

Post-incident reviews address why detection was delayed, why judgment materials were lacking, and why suspension authority was ambiguous, rather than who to blame. Standardizing internal records to match OECD reporting items facilitates comparison between incidents and transfer to external reports. However, since many incidents are invisible in public data, maintain separate internal near-miss collection. [2]

In limited resumption, consolidate target users, permitted functions, human verification, failure types to observe, and resuspension conditions onto one sheet. If resuming without knowing the cause, record the responsible person who approved the residual risk, and ensure that similar hazards can trigger automatic or on-duty personnel to revert to evacuation. Include not only recovery speed but also the completion of impact target identification and correction as closure conditions. [1] [2]

• Detection: Consolidate user reports, quality metrics, and security monitoring into a single intake
• Containment: Enable selection of suspension, permission blocking, model switching, and fallback to manual operations
• Explanation: Communicate known facts, uncertain items, and next update time separately
• Resumption: An independent approver verifies residual risk and monitoring plans
• Intake Responsible Person: Open records as hazards even if the incident is undetermined
• Investigation Responsible Person: Handle evidence preservation and verification of conflicting cause hypotheses
• Resumption Responsible Person: Approve residual risk, resuspension conditions, and correction completion