User and operator signals
Reports of incorrect, harmful, inaccessible, privacy-sensitive, or unexpected behavior; repeated overrides; unexplained refusals; suspicious tool actions; or new workflow friction.
Updated September 2026Incident evidence & containment
Respond to AI failures as operational incidents—not as mysterious model behavior.
Use a practical incident process that preserves the model and workflow context, contains harmful behavior, coordinates suppliers and internal owners, evaluates reporting obligations, and feeds lessons back into evaluation and governance.
The 2026 revision removes obsolete M-24-10 and “24-hour AI reporting” claims. Reporting duties depend on the system, role, jurisdiction, incident type, and other applicable security, privacy, safety, sector, and contract rules.
Incident definition
Define the event in terms of impact and control failure.
An AI incident can originate in the model, the surrounding application, retrieval data, a tool integration, user behavior, supplier change, or ordinary infrastructure. Avoid creating a separate AI incident universe that competes with cybersecurity, privacy, safety, accessibility, records, legal, fraud, or service-management processes. Instead, define AI-specific facts that existing response teams need to capture.
Examples include harmful or materially incorrect output used in a consequential workflow, unintended disclosure of sensitive information, unauthorized external action by an agent, persistent prompt-injection success, model or retrieval changes that invalidate an approved use, failure of required human oversight, discriminatory or inaccessible behavior, unexplained quality degradation, supplier incidents affecting the service, or a model update that causes a critical workflow to fail.
M-25-21 uses the concept of high-impact AI for federal agency uses where AI output serves as a principal basis for decisions or actions with significant effects on rights or safety. That classification can raise the importance of an incident, but it does not replace other incident definitions or reporting regimes. Organizations should route an event according to all applicable obligations.
Maintain a severity model that considers harm, scope, reversibility, data exposure, external action, affected people, duration, legal/reporting implications, and whether the issue can recur. A spectacular hallucination with no downstream effect may need a product defect ticket; a subtle error that changes eligibility or triggers an external action may warrant immediate containment and escalation.
Detection
Monitor the failure modes you are prepared to act on.
NIST's 2026 work on deployed-AI monitoring emphasizes that post-deployment monitoring is important but fragmented and difficult. Build a focused signal set instead of pretending one dashboard observes every AI risk.
System signals
Task-success drift, retrieval failure, policy violations, tool errors, duplicate actions, latency spikes, cost anomalies, security alerts, data-loss controls, or changes in model/version/configuration.
Supplier signals
Model deprecation, provider incident notices, new subprocessors, changed data terms, security advisories, materially changed behavior, service outages, or revised model documentation.
Preserve a low-friction reporting channel. Employees should not need to decide whether an AI problem is “technically an incident” before raising it. Intake can classify the event later. Suppressing weak signals makes it harder to identify systemic failures.
Containment
Know how to stop the harmful behavior before the incident happens.
Containment options depend on architecture. They may include disabling a feature, removing a tool permission, revoking a credential, switching to a previous model, blocking a retrieval source, disabling automated actions, forcing human confirmation, changing routing, restricting a user group, falling back to a manual process, or taking the application offline.
Document the fastest safe control for each material AI use case. A team should not discover during an incident that it cannot identify the current model version or disable an agent without shutting down an unrelated service.
Preserve evidence before changing state where it is safe to do so: model/service identifier, configuration, prompt or triggering input, retrieval context, tool calls, outputs, logs, user actions, timestamps, affected records, provider notices, and screenshots or artifacts. Follow existing legal, privacy, security, and records requirements for evidence handling.
Containment is not the same as root-cause correction. A prompt change may reduce visible symptoms while the underlying issue remains in permissions, retrieval, data quality, orchestration, supplier behavior, or workflow design.
Investigation
Reconstruct the whole AI-enabled workflow.
Start with timeline and impact. Identify when the behavior began, how it was detected, which versions and configurations were active, who or what was affected, what decisions or actions occurred, whether data left an expected boundary, and whether the issue remains reproducible.
Separate model behavior from system behavior. Ask whether the model produced the output, retrieval supplied wrong context, the application failed to enforce a permission, a tool executed incorrect parameters, a user bypassed a process, or a provider-side change altered behavior. More than one factor may contribute.
Reproduce carefully in an isolated environment where possible. Preserve the original case, then create controlled variants to test hypotheses. Avoid contaminating evidence by repeatedly editing the production system without recording changes.
Include supplier evidence early when the model or service is hosted externally. The contract should identify the provider's incident contact, notification expectations, evidence access, log availability, retention, and support path. The AI Procurement Governance Guide addresses those controls before award.
Reporting
Determine the applicable deadline from the actual obligation—not from a generic AI runbook.
AI incidents can trigger multiple regimes at once. The response record should show who evaluated each potential reporting path.
For high-risk AI systems in the EU, the consolidated AI Act Article 73 sets serious-incident reporting rules for providers. The general outer limit is 15 days after awareness, with reporting expected immediately after establishing the causal link or reasonable likelihood of a link. The article has shorter limits for specified cases: not later than two days for a widespread infringement or the serious-incident category referenced in Article 3(49)(b), and not later than 10 days in the event of death, alongside immediate-reporting language tied to established or suspected causality.
Those AI Act deadlines should not be copied into every organization's internal severity table as universal rules. The exact duty depends on role, system category, applicability date, incident facts, and jurisdiction. Privacy-breach, cybersecurity, safety, financial, healthcare, labor, consumer-protection, contractual, or sector reporting may have different triggers and clocks.
For U.S. federal agencies, M-25-21 should be read together with existing federal information-security, privacy, records, agency, and sector obligations. It does not create a universal private-sector “AI incident within 24 hours” rule. The White House's 2025 cybersecurity order also directed relevant federal agencies to incorporate AI software vulnerability and compromise management into existing vulnerability and incident processes, reinforcing the value of integration rather than a disconnected AI-only response channel.
Assign reporting analysis to named legal/compliance/security owners and record the decision, including why a notification was or was not required. Where the facts are incomplete, preserve the option to make an initial report and supplement it when the governing regime allows that approach.
Communication
Tell each audience what it needs without inventing certainty.
Internal leadership needs scope, current impact, containment status, decision points, reporting risk, customer/public impact, and what help is needed. Technical teams need versions, evidence, hypotheses, reproduction status, and ownership. Users need actionable guidance if behavior is unsafe or unreliable. Regulators, customers, or partners may need facts defined by law or contract.
Distinguish confirmed facts, current hypotheses, and unknowns. AI incidents are especially vulnerable to premature explanation because model behavior can appear intuitive while the actual cause sits elsewhere in the system.
Coordinate supplier communications so public statements do not conflict with provider evidence or ongoing investigation. Preserve communications as part of the incident record when they influence decisions.
Learning loop
An AI incident is not closed until the evaluation and governance systems learn from it.
Convert the incident into new test cases. Add the triggering input, failure pattern, tool sequence, retrieval condition, or affected workflow to the evaluation suite where appropriate. The AI Model Evaluation Operations Guide provides a structure for versioning those cases and rerunning them after model or system changes.
Update governance records when the incident changes the risk picture: new limitation, revised approval condition, restricted use, supplier condition, monitoring signal, workforce training, or a decision to retire the system. Link those changes back to the incident.
Review whether procurement or architecture created avoidable response friction. Missing logs, unclear ownership, inaccessible provider evidence, weak change notice, non-portable data, or inability to rollback are procurement and design findings as much as incident findings.
Close with a dated decision: what happened, impact, root or contributing causes, containment, remediation, evidence preserved, notifications, supplier actions, new controls, validation results, residual risk, and owner. Schedule a later effectiveness check for material corrective actions.
Tabletop starter
Exercise the response before a real event.
- A production AI assistant begins generating materially incorrect recommendations after a silent provider model update.
- One output is used in a consequential workflow before a reviewer notices the pattern.
- The team can see the current product name but cannot immediately determine the exact model identifier used for the affected request.
- The provider has not declared an outage and support initially requests reproduction steps.
Ask: who declares the incident, how is the feature contained, what evidence is preserved, which users or decisions are reviewed, who contacts the provider, which reporting regimes are evaluated, how is rollback performed, what communication is needed, and what new regression test must pass before restoration?
Primary sources and current references
- Consolidated EU AI Act — Article 73 serious-incident reporting
- OMB M-25-21 — current federal AI use/governance framework
- NIST — Challenges to the Monitoring of Deployed AI Systems
- NIST AI Risk Management Framework
Last substantive review: September 2, 2026. Confirm incident-reporting obligations with qualified legal, security, privacy, safety, and regulatory owners for the specific system and event.
Put this guide to work
Turn AI Incident Response and Resilience Guide | Zeph Tech into a decision-ready next step.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.