checklist
AI chatbot incident communication template for small teams
A practical communication template for AI chatbot incidents, covering internal updates, customer notices, vendor escalation, approval records, status page decisions, evidence handling, and post-incident review.
Use this template when a customer-facing AI chatbot gives a customer-impacting wrong answer, exposes data, fails human handoff, runs or attempts an unsafe tool action, is affected by prompt injection, or needs a temporary pause and fallback route.
Incident communication is not the same as marketing copy. The goal is to tell the right people enough to act, avoid speculation, protect evidence, avoid overpromising, and route customers to a safer path. Before expanding a chatbot without communication owners, run the AI Tool Risk Checker and attach the result to the bot record.
Bottom line
A small team should prepare three communication layers before a chatbot incident:
- Internal update: what happened, what is paused, who owns the next decision, and what evidence is preserved.
- Customer message: short, factual wording that gives a safe fallback path without exposing internal details.
- Vendor or partner escalation: the minimum technical context needed to get help without sending unnecessary customer data.
Use the Small Team AI Security Checklist to assign incident owners, evidence locations, access review, and escalation paths. This page gives the communication templates.
When to use this template
| Scenario | Use this template? | First communication |
|---|---|---|
| Bot may have exposed customer data, hidden prompts, internal notes, or another customer’s information | Yes | Internal security/privacy update. |
| Prompt injection appears to change behavior | Yes | Internal security update plus vendor escalation if relevant. |
| Bot gives repeated wrong answers with customer impact | Yes | Support/product update and customer-safe holding message. |
| Tool action affects account, billing, access, deletion, outbound message, or customer record | Yes | Internal security/product update and customer support message. |
| Human handoff fails for sensitive topic | Yes | Support escalation and customer fallback message. |
| Source sync, retrieval, or connector fails | Yes | Product/support update and fallback route. |
| Vendor outage affects chatbot reliability | Yes | Internal status update and customer fallback route if customer-facing. |
| Low-risk style complaint | Maybe | Normal support response unless repeated or sensitive. |
If the bot is paused, customers should know where to go next. If evidence is still being reviewed, say that plainly.
Incident communication roles
Copy this owner map into the chatbot operations record.
| Role | Owns | Backup |
|---|---|---|
| Incident lead | Timeline, owner assignment, decision log, next update time. | |
| Support lead | Customer messages, ticket updates, support queue routing. | |
| Security owner | Prompt injection, data exposure, unsafe tool action, evidence preservation. | |
| Privacy owner | Data request, retention, disclosure, deletion/export/correction routing. | |
| Product owner | Bot scope, source quality, feature pause, restart decision. | |
| Engineering/admin owner | Logs, connector status, tool-action settings, vendor ticket. | |
| Legal/compliance reviewer | External wording when legal, regulated, contractual, or notification questions exist. | |
| Executive approver | High-impact customer or public communication. |
Do not wait for a perfect org chart. Pick one incident lead and one customer-message owner.
Communication severity matrix
| Severity | Example trigger | Communication cadence |
|---|---|---|
| S1 critical | Possible customer data exposure, unauthorized account/billing/access/deletion action, successful prompt injection with customer impact, or broad unsafe automation. | Internal update immediately; customer holding message as soon as fallback path is ready; executive/legal review before broad external detail. |
| S2 high | Wrong answer with customer impact, sensitive-topic handoff failure, tool action failure, repeated privacy/security misstatement, or source-backed misinformation. | Internal update same hour; customer message for affected users; daily internal update until closed. |
| S3 medium | Repeated low-risk wrong answer, stale source, connector outage, support routing issue, or confusing bot disclosure. | Internal update same business day; customer message if customers are waiting. |
| S4 low | Style complaint, small FAQ gap, isolated low-impact answer issue. | Normal support or content queue; include in weekly review if repeated. |
Use the AI chatbot customer escalation workflow template when a customer ticket triggered the incident.
Internal update template
Copy this into Slack, Teams, email, or the internal incident ticket.
| Field | Entry |
|---|---|
| Incident ID | |
| First detected | |
| Detected by | Customer, support, monitoring, admin, vendor, red-team test, or other. |
| Bot name and channel | |
| Current severity | S1, S2, S3, or S4. |
| What happened | One factual sentence. |
| What is not known yet | |
| Customer impact | Known, likely, unknown, or none. |
| Data involved | None, public, internal, customer, account, billing, regulated, credential-like, or unknown. |
| Tool action involved | None, attempted, completed, denied, failed, retried, or unknown. |
| Current containment | Bot paused, route paused, source paused, connector revoked, tool action disabled, human fallback enabled, or other. |
| Customer message owner | |
| Evidence owner | |
| Next update time |
Keep the update short. Put evidence links in a controlled record, not in a broad chat thread.
Customer holding statements
Use the smallest accurate message. Do not diagnose the root cause before review is complete.
| Situation | Customer-facing statement |
|---|---|
| Bot unavailable | ”Our AI chat assistant is temporarily unavailable. A support teammate can help through this channel.” |
| Human review needed | ”This request needs human review. We are routing it to the appropriate support teammate.” |
| Possible wrong answer | ”Thanks for flagging this. We are reviewing the answer and will follow up with a corrected response if needed.” |
| Sensitive topic | ”This topic needs human review instead of an automated response.” |
| Privacy or data request | ”We are routing this to the team that handles data requests and will confirm the next step.” |
| Tool action paused | ”We are reviewing this before taking further action.” |
| Connector or source issue | ”We are checking the source behind this answer and will follow up through support.” |
| Broader review | ”We are reviewing this issue and will provide the next update through the appropriate support channel.” |
Avoid phrases like “no data was affected” until the review supports it.
Customer follow-up template
Use this after review, scoped to affected customers or tickets.
Subject: Follow-up on your support request
Hi [name],
We reviewed the AI assistant response related to [short topic].
What we found:
[One or two factual sentences. Avoid internal prompts, source internals, credentials, or unnecessary transcript detail.]
What we did:
[Corrected answer, routed to human support, paused a bot route, updated a source, disabled an action, or opened a vendor review.]
What you should do:
[No action needed / use this support path / review this corrected information / reply if the issue continues.]
Thanks,
[team]For privacy, legal, contractual, regulated, billing, account, or security-impacting situations, have the privacy/security/legal owner approve the follow-up before sending.
Vendor escalation template
Use this when the chatbot platform, model provider, support tool, CRM, connector, or source system may be involved.
| Field | Entry |
|---|---|
| Vendor ticket title | |
| Vendor product and feature | |
| Bot or integration name | |
| Timestamp and timezone | |
| Severity | S1, S2, S3, or S4. |
| Business impact | Short description without unnecessary customer data. |
| Technical symptom | Wrong answer, source mismatch, unsafe tool call, connector failure, handoff failure, outage, logging gap, or other. |
| Reproduction status | Reproducible, intermittent, one-off, unknown. |
| Evidence shared | Redacted transcript, request ID, model/run ID, log excerpt, screenshot, or none. |
| Data restrictions | Do not use for training, do not share broadly, treat as confidential, or other approved instruction. |
| Requested action | Confirm behavior, preserve logs, explain change, disable feature, provide audit data, or escalate. |
| Internal owner |
Redact customer personal data unless the vendor specifically needs it and your privacy/security owner approves the transfer.
Regulator and legal handoff
This template does not decide whether a notice is legally required. It helps the team route that question to the right owner.
| Trigger | Route |
|---|---|
| Customer personal data may be exposed | Privacy/legal owner. |
| Account, billing, access, deletion, or export action may be wrong | Privacy/legal plus product/support owner. |
| Contract customer asks for formal incident detail | Legal/customer success owner. |
| Regulated data may be involved | Privacy/legal owner. |
| Public claim about AI capability, safety, privacy, or accuracy may be wrong | Legal/trust owner. |
| Law enforcement, government, auditor, or regulator contact appears | Legal/executive owner. |
Do not let a chatbot, support rep, or generic incident template make a legal-notification decision.
Public status page decision
| Condition | Status page update? |
|---|---|
| Chatbot is unavailable but normal support is available | Maybe, if customers rely on the bot as a support channel. |
| Broad customer support delays occur because fallback is overloaded | Yes, if service expectations are affected. |
| Source or connector outage affects many customers | Yes, if customers see failures or degraded answers. |
| One customer ticket is under review | Usually no. |
| Possible data exposure or unsafe action is under investigation | Legal/security review before public status detail. |
| Vendor outage is already public and affects your bot | Usually yes, with your own customer impact. |
A status page should explain impact and fallback route, not expose vulnerabilities or private evidence.
Message approval record
Copy this into the incident record before sending a sensitive message.
| Field | Entry |
|---|---|
| Message type | Internal update, customer holding statement, customer follow-up, status page, vendor ticket, partner notice, or other. |
| Audience | Internal, affected customer, all customers, vendor, partner, public, or other. |
| Draft owner | |
| Reviewer | Support, security, privacy, legal, product, executive, or other. |
| Approved wording | Link or controlled copy. |
| Send time | |
| Send channel | Email, ticket, chat, status page, vendor portal, or other. |
| Follow-up time | |
| Evidence location |
The approval record should not contain raw secrets, full transcripts, payment data, private keys, or unnecessary personal data.
What not to say
| Avoid | Use instead |
|---|---|
| ”No customers were affected” before review is complete | ”We are reviewing customer impact." |
| "The AI hallucinated" | "The assistant gave an answer that is under review." |
| "The vendor broke it" | "We are working with the vendor to review the behavior." |
| "There is no security issue” before evidence review | ”Security and privacy owners are reviewing the available evidence." |
| "The bot is safe now” without restart gates | ”We have restored the affected route after review and monitoring is in place.” |
| Prompt, hidden instruction, exploit, or source internals | Customer-safe impact and fallback wording. |
| Full transcript pasted into a broad thread | Controlled evidence link or redacted excerpt. |
Communication should reduce confusion without increasing risk.
Evidence to preserve
- Conversation ID, ticket ID, timestamp, and channel.
- Customer-safe summary of what happened.
- Bot answer or tool action being reviewed.
- Source, connector, model, prompt version, or admin setting involved where known.
- Customer impact assessment.
- Pause or fallback decision.
- Customer messages sent.
- Vendor ticket ID and response.
- Approval record for sensitive external messages.
- Restart or closure decision.
Use the AI chatbot pause and fallback plan template if the communication is part of a pause decision.
Post-incident communication review
Run this review within seven days.
| Question | Owner |
|---|---|
| Did affected customers get a clear fallback path? | Support lead. |
| Did internal updates name a next owner and next update time? | Incident lead. |
| Did we avoid unsupported claims? | Legal/privacy/security reviewer. |
| Did we preserve evidence without oversharing data? | Security/privacy owner. |
| Did the vendor get enough redacted context to help? | Engineering/admin owner. |
| Did the status page decision match customer impact? | Product/support owner. |
| Did the final customer follow-up answer the customer need? | Support/customer success owner. |
| Did we add a new template, test, or monitoring rule? | Product/security owner. |
Feed lessons back into the AI chatbot production monitoring checklist.
Metrics to track
| Metric | Why it matters |
|---|---|
| Time to first internal update | Shows whether owners were reachable. |
| Time to customer holding message | Shows whether customers had a fallback route. |
| Number of affected conversations | Sizes customer impact. |
| Message approvals required | Shows governance load. |
| Customer replies after holding message | Shows whether wording reduced confusion. |
| Vendor response time | Shows vendor escalation quality. |
| Corrections sent | Shows repair workload. |
| Unsupported claims removed during review | Shows whether approval caught risky wording. |
| Evidence oversharing incidents | Shows whether the team needs redaction rules. |
| Time to final follow-up | Shows closure quality. |
Fast communication is useful only when it is accurate and controlled.
Evidence checked
This template is aligned with:
- NIST AI RMF Core, which emphasizes documented roles, lines of communication, monitoring, incident identification, response, recovery, communication plans, and communication of incidents and errors to relevant AI actors.
- NIST AI 800-4 monitoring report summary, which identifies post-deployment monitoring as crucial and describes operational, security, compliance, impact, and human-factors monitoring categories.
- CISA JCDC AI Cybersecurity Collaboration Playbook alert, which emphasizes voluntary information-sharing processes for AI cybersecurity incidents and vulnerabilities.
- CISA joint guidance on deploying AI systems securely, which emphasizes protecting AI systems and related data/services, detecting malicious activity, and responding to incidents.
- OWASP Top 10 for LLM Applications, which covers prompt injection, sensitive information disclosure, insecure plugin design, excessive agency, misinformation, overreliance, and other risks relevant to incident communication.
- FTC artificial intelligence guidance, which tracks FTC guidance and enforcement activity related to AI claims, accuracy, privacy, confidentiality, chatbot monitoring, and consumer protection.
- Cybergiz templates for customer escalation, prompt injection response, answer correction, tool action approval, production monitoring, pause and fallback, and change approval.
This page is practical operating guidance, not legal, privacy, regulatory, contractual, incident-response, customer-support, communications, audit, certification, or security assurance advice.
FAQ
Should we tell customers before we know the root cause?
Yes, if customers are waiting, affected, or need a fallback path. Keep the message short: say the issue is under review, route to human support, and avoid root-cause claims.
Who should approve customer-facing chatbot incident messages?
Support can approve low-risk support wording. Security, privacy, legal, product, or executive owners should review messages involving data exposure, unsafe actions, regulated topics, contractual customers, public status pages, or broad customer impact.
Should we mention AI in the incident message?
Mention it when it helps customers understand the support path, such as “AI assistant temporarily unavailable.” Do not use “AI” as an excuse for unclear ownership or unsupported claims.
Can we send the full transcript to a vendor?
Usually no. Start with redacted excerpts, request IDs, timestamps, screenshots, logs, and reproduction steps. Share more only when needed and approved by the privacy/security owner.
What if the chatbot gave legally sensitive advice?
Route the conversation to a human owner and legal/compliance reviewer. Do not let the bot correct itself without review.
Should every chatbot incident go on the public status page?
No. Use the status page when customers broadly experience degraded service, support delays, outage, or visible failures. One-customer reviews usually stay in support channels.
How often should we update customers?
Give a holding message quickly, then set a realistic next update time for affected customers. Do not send repeated empty updates unless a service expectation requires them.
What is the safest first message?
“We are reviewing this and routing it to a support teammate” is usually safer than speculating about root cause, scope, security, privacy, or vendor fault.