An employee discovers that an AI assistant exposed information from a restricted document. A customer reports a harmful answer. An agent sends the wrong message to hundreds of contacts. A model update changes output quality overnight. A public-sector team learns that an automated summary omitted evidence that changed a decision.
These events may involve uncertain outputs, sensitive data, human decisions, external vendors and connected systems. Waiting until one occurs to decide who owns it is a predictable failure.
This guide provides a practical AI incident response plan for small and mid-sized businesses, technical project managers and public-sector teams. It includes severity levels, roles, first-hour actions, an incident record and a tabletop exercise.
Important: This is an operational template, not legal, cybersecurity, privacy or regulatory advice. Reporting obligations depend on the incident, data, contracts, sector and jurisdiction. Involve qualified professionals where required.
Why a Normal IT Incident Plan Is Not Enough
Existing cybersecurity and service-management processes remain the foundation, but AI adds questions a conventional outage playbook may miss:
- Was the AI the target, source or merely part of the incident?
- Was an output shown, used in a decision or converted into an action?
- Which model, prompt, knowledge source, connector and permissions were active?
- Did the system expose protected information or continue acting?
- Must affected people, vendors, insurers or authorities be notified?
The NIST Generative AI Profile recommends establishing roles and procedures for communicating generative-AI incidents, assembling incident-response teams suited to the incident type and ensuring responders have appropriate skills. On May 14, 2026, NIST also convened a dedicated Workshop on AI Incident Management to inform future guidance and improve ecosystem readiness.
These are verified facts. The workflow and templates below are AIXYZ recommendations for turning those principles into a manageable business process.
What Counts as an AI Incident?
Do not restrict the definition to a data breach. An AI incident is any event involving an AI system that causes, or could plausibly cause, material harm, unauthorized action, policy violation or loss of control.
The OECD AI Incidents and Hazards Monitor distinguishes an incident involving actual harm from a hazard that could plausibly lead to harm. Your internal process should capture both. A near miss is cheaper to investigate than a repeated failure.
Examples include:
- Confidential data appears in an output or reaches an unapproved service.
- An answer causes an incorrect payment, decision or customer commitment.
- An agent acts outside its approved scope.
- Prompt injection overrides instructions or exposes information.
- Retrieval returns records the user cannot access.
- Biased output affects a person or group.
- Fabricated facts enter an official deliverable.
- A vendor or model change breaks an approved control.
A quality issue becomes an incident when impact or credible risk crosses your defined threshold. A typo in an internal draft may be a routine correction. The same system inventing a safety instruction for the public is not.
Use Four Severity Levels
Severity should reflect impact, scope, sensitivity, reversibility and ongoing exposure—not how dramatic the output looks.
| Level | Typical condition | Initial target |
|---|---|---|
| SEV-1 Critical | Immediate risk to safety, rights, critical operations or large-scale sensitive data; uncontrolled high-impact actions | Activate incident lead immediately; contain now; engage executives and specialists |
| SEV-2 High | Material customer, legal, security, financial or operational impact; limited but confirmed sensitive-data exposure | Respond urgently; contain affected capability; notify accountable owners |
| SEV-3 Moderate | Contained incorrect output, policy breach or near miss with limited impact and no continuing exposure | Assign an owner the same business day; preserve evidence; correct and review |
| SEV-4 Low | Minor quality issue with low impact, easy correction and no sensitive data or external action | Log, trend and address through normal improvement work |
Do not let a single score override judgment. A low-volume event can still be critical if it affects a vulnerable person, public safety, legal rights or protected data.
The Five-Stage AI Incident Response Process
1. Detect and report
Make reporting simple enough that employees actually use it. Provide one intake channel, such as a service portal form or monitored email address, and explicitly state that good-faith reporting will not be punished.
The initial report should capture:
- What happened and when it was observed
- System, feature, agent or vendor involved
- User, customer or process affected
- Input and output, where safe to collect
- Action taken by the AI or a person relying on it
- Data types involved
- Whether the behaviour is continuing
- Screenshots, links, record IDs and error messages
Do not ask employees to reproduce a potentially harmful event in production. The response team should decide whether controlled reproduction is safe.
2. Contain the impact
Containment limits further harm before the root cause is known. Select the smallest action that reliably stops exposure, but do not preserve business continuity at the expense of people, data or control.
Possible actions include:
- Disable the AI feature, agent, connector or affected workflow.
- Revoke tokens, service-account access or delegated permissions.
- Switch the system to read-only or draft-only mode.
- Require approval for every proposed action.
- Block a prompt pattern, document source, tool or output channel.
- Roll back a configuration or model version when supported.
- Remove affected content from publication or distribution.
- Pause automated decisions and route work to a manual process.
For agentic systems, emergency shutdown is not optional. Before deployment, use the AIXYZ AI Agent Security Checklist to confirm that access can be revoked and in-flight work can be stopped.
3. Assess severity and obligations
Once active harm is limited, establish a cross-functional view of impact. Ask:
- People: Could anyone face safety, financial, employment, service-access or rights-related harm?
- Data: What data entered, left or appeared through the system? Who owns it?
- Actions: What did the AI recommend, decide or execute? Can the action be reversed?
- Scale: How many users, records, messages, decisions or transactions may be affected?
- Duration: When did the behaviour begin, and could it still be happening?
- Control: Was a required human approval bypassed or ineffective?
- External duties: Do law, policy, contract, insurance or vendor terms require notice or preservation?
The incident lead should record the provisional severity and revisit it as evidence changes. Privacy, security, legal, records, communications, accessibility and subject-matter specialists should join according to the event—not by default for every typo.
4. Eradicate, recover and validate
Recovery is not simply turning the feature back on. Identify the contributing causes, remove them and prove that the system can operate within the approved boundary.
AI incidents often have several causes at once, including:
- ambiguous rules, excessive permissions or unsafe prompts;
- outdated or misclassified knowledge sources;
- missing validation or inadequate human review;
- vendor changes, weak logs or use outside the approved purpose.
Test the fix against the original case, related variants and known failure scenarios. Confirm data access, approval gates, rate limits, logging and rollback. Use a limited rollout and enhanced monitoring before restoring full access.
If the system takes actions, pair this process with an AI agent approval matrix so automated, approval-required and prohibited actions are explicit.
5. Communicate and learn
Communicate accurately and proportionally. Separate known facts, working hypotheses and pending questions.
After recovery, review:
- Timeline, causes, impact and affected processes
- Controls that worked, failed or were missing
- Corrective actions, owners and deadlines
- Similar systems that may share the weakness
- Policy, training, vendor and monitoring changes
Near misses belong in this process. Trend analysis can reveal recurring prompt-injection attempts, one unreliable data source or a team using AI beyond its approved scope.
The First-Hour Checklist
Use this when an incident may be significant. It is a practical target, not a regulatory timeline.
- Open one incident record and name an incident lead.
- Confirm immediate safety, service and data risks.
- Stop or constrain the affected AI capability.
- Preserve prompts, outputs, logs, timestamps, model and configuration details.
- Revoke or limit tool and connector access if actions may continue.
- Record known facts separately from assumptions.
- Assign a provisional severity level.
- Engage privacy, security, legal or operational specialists as indicated.
- Identify the manual fallback and communicate it to affected users.
- Set the next decision time and communication owner.
Do not delete evidence, casually paste sensitive evidence into another AI tool or let multiple teams run uncontrolled reproduction tests.
AI Incident Record Template
Copy these fields into your case system or project repository.
| Field | What to record |
|---|---|
| Incident ID and status | Unique number; open, contained, monitoring or closed |
| Detected at / occurred at | Use separate timestamps if known |
| Reporter and incident lead | Named people and contact information |
| System and owner | Product, use case, business owner and technical owner |
| AI configuration | Provider, model/version, system prompt, retrieval sources, tools and key settings |
| Description | Observable facts in plain language |
| Impact and scope | People, data, decisions, transactions and services affected |
| Severity and rationale | Current level plus evidence supporting it |
| Containment actions | What was disabled, revoked, limited or removed, and by whom |
| Evidence preserved | Logs, screenshots, outputs, record IDs, configuration and vendor notices |
| Notifications | Internal and external recipients, decision, time and owner |
| Root and contributing causes | Technical, process, data, human and vendor factors |
| Recovery validation | Tests completed and approval to restore |
| Corrective actions | Owner, due date, status and verification method |
Minimize copied personal or confidential information. Link to protected evidence rather than duplicating it throughout tickets and email.
Assign Roles Before the Incident
Small organizations may combine roles, but accountability must remain clear.
| Role | Core responsibility |
|---|---|
| Incident lead | Coordinates decisions, timeline, severity and closure |
| Business owner | Assesses operational impact and approves fallback or restoration |
| Technical owner | Contains the system, preserves technical evidence and validates fixes |
| Security/privacy lead | Assesses unauthorized access, exposure and required controls |
| Legal/compliance contact | Advises on obligations, privilege, notices and records |
| Communications owner | Coordinates messages to staff, customers, leadership and the public |
| Vendor contact | Escalates provider issues and obtains logs, findings or remediation |
Your AI acceptable use policy should tell employees how to report an AI concern. Your shadow AI audit should identify systems that need to be added to the incident inventory.
Run a 60-Minute Tabletop Exercise
Test the plan before a high-impact system goes live and when major capabilities, connectors or responsibilities change.
Use a realistic scenario: an AI customer-service agent sends incorrect refund confirmations and exposes another customer’s order details. Then walk the team through four prompts:
- Minute 0: A customer reports the problem. Who receives it, and what evidence do they request?
- Minute 10: Logs suggest 40 conversations may be affected. Who can disable the agent and preserve service?
- Minute 25: The vendor reports a recent model change. What facts are needed before assigning cause or communicating externally?
- Minute 45: A fix is available. Who approves restoration, what tests are required and how will affected people be supported?
Finish with gaps found, named owners and dated corrective actions. Disagreement often reveals missing decision rights.
Common Mistakes to Avoid
Do not classify every bad answer as a breach—or dismiss every one as harmless. Contain credible harm before certainty, preserve configuration as well as screenshots, examine permissions and workflow instead of blaming only the model, and validate the failure class before restoration. Record near misses. AI may organize approved evidence, but accountable people must verify findings and decisions.
Verified Foundation vs. AIXYZ Analysis
Verified foundation
- NIST’s Generative AI Profile recommends organizational procedures, roles, communications and trained personnel for generative-AI incident response.
- NIST held an AI Incident Management workshop on May 14, 2026; its materials distinguish information sharing, incident reporting and incident response.
- CISA’s AI Cybersecurity Collaboration Playbook, published January 14, 2025, supports voluntary coordination and information sharing for AI-related cybersecurity incidents and vulnerabilities.
- The OECD maintains definitions and a monitor for AI incidents and hazards to support shared learning.
AIXYZ analysis
Most small organizations should extend their existing incident process. Add AI-specific intake fields, severity questions, evidence, permissions and roles, then test the process.
The essential capability is to stop the system, name an accountable owner, preserve evidence and protect affected people while facts emerge.
Frequently Asked Questions
What is an AI incident response plan?
It is a documented process for detecting, containing, assessing, recovering from and learning from harmful, unauthorized or unexpected events involving AI systems.
Is an inaccurate AI answer always an incident?
No. Use impact, scope, sensitivity, reversibility and ongoing risk. A minor draft error may be handled through quality improvement; an inaccurate answer used in a consequential decision may require formal response.
Who should own AI incident response?
Assign one incident lead and named business and technical owners. Bring in security, privacy, legal, communications and specialist roles according to the incident.
Should we create a separate AI response team?
Usually not at first. Extend existing cybersecurity, privacy, service-management and business-continuity processes with AI-specific fields, roles and scenarios. Larger or high-risk programs may need dedicated capability.
What evidence should we preserve?
Preserve timestamps, prompts, outputs, logs, user and service identities, model and version, system instructions, retrieval sources, tools, permissions, configuration, actions and relevant vendor notices. Protect sensitive evidence appropriately.
When can an AI system return to service?
After the cause and impact are understood enough to manage risk, containment is durable, fixes pass representative and adversarial tests, required owners approve restoration, and enhanced monitoring is active.
Start Before Something Goes Wrong
Choose one AI system this week. Name its business and technical owners, confirm how to disable it, add the incident intake fields and run the 60-minute scenario. If the team cannot stop the system or identify who decides, the system is not operationally ready.
Use the AIXYZ AI readiness assessment to identify wider governance gaps, then test changes through a controlled 30-day AI pilot.