The AI Incident Playbook: 6 Failure Modes a Non-Technical Business Will Hit and the 60-Minute Response for Each

It's a Tuesday afternoon. Your company's AI chatbot has just told a prospective client that your firm offers a specific compliance guarantee it absolutely does not offer. The client is already sending a follow-up email referencing that guarantee. Your legal team is asking how it happened. Your customer success rep is asking what to tell the client. And you, the business owner, are Googling "AI gave wrong information to customer what do I do" while simultaneously trying to figure out if this constitutes a misrepresentation. Nobody trained you for this. No playbook exists on your shelf. This paper is that playbook.

Every existing guide on AI for business covers the front end: choosing a tool, scoping a pilot, measuring ROI, building a governance policy. The back end, the moment when AI fails in front of a real customer or a real decision, gets about two paragraphs in most guides, usually filed under "risks to consider." That is not a runbook. That is a warning label.

This paper is different. It covers six failure modes that non-technical SMB and mid-market operators hit in real deployments, the response you need to run in the first 60 minutes of each, and the controls to put in place before the same thing happens again. It is written for the operator who runs a business, not the engineer who builds the system. You will not need to know what an API is to follow any of the steps here.

1. The function you don't have

Large technology companies have incident response functions: dedicated teams who run structured procedures the moment something breaks. They practice fire drills on systems before they go live. They have escalation trees, communication templates, and designated decision-makers. When something fails at 2 a.m., a person has a job title that includes the words "incident response," and that person's phone rings.

You don't have that. Neither does almost any SMB or mid-market company. What you have is the person who chose the AI tool, a few people who use it daily, and a general understanding that "AI can make mistakes." That understanding does not become useful until the moment of failure, which is precisely when you most need a structured response and least have time to invent one.

The six failure modes below are not theoretical. They are the patterns that show up repeatedly in real deployments at companies your size, in industries including professional services, healthcare-adjacent operations, financial advisory, retail, and manufacturing. For each one, there is a concrete first-60-minutes response and a set of controls to put in place afterward. The controls are not expensive. Most of them are a policy document, a checklist, or a communication template, things that take an afternoon to build.

Read this paper before you need it. Print the six response sequences and put them in your operations folder. The companies that handle AI incidents well are not the ones with better AI; they are the ones that treated incident response as a setup task, not an emergency improvisation.

2. Failure mode 1: a hallucinated claim reached a customer

Your AI assistant wrote a client-facing email, a chatbot response, or a product page that included a claim that is factually wrong. Maybe it cited a statistic that does not exist. Maybe it described a feature your product does not have. Maybe it told a customer they qualify for a discount or guarantee that your company has never offered. The customer believed it. They may have made a decision based on it.

This is the most common AI failure mode for non-technical businesses, and it is the one people are least prepared for because the output looked completely professional. Hallucinated content does not come with error messages. It comes formatted perfectly, in your brand voice, with confident punctuation.

First 60 minutes:

1. Identify the specific output, the exact text the customer received. Locate the original prompt or workflow that produced it if possible.
2. Assess the customer impact immediately: did they take a financial action, sign a document, or make a business decision based on the incorrect claim?
3. Contact the customer directly, by phone if possible, and correct the record plainly. Do not wait. Do not send an AI-drafted correction. Write this yourself. Acknowledge that the information they received was incorrect and tell them the accurate version.
4. Pull any other AI-generated content that used the same workflow or template and flag it for human review before it reaches anyone else.
5. Loop in legal or a senior decision-maker if the incorrect claim involves pricing, compliance, contracts, or warranties.

What to put in place before it happens again: Every AI-generated output that goes to a customer should pass through a human review step before delivery. This does not have to be slow. A checklist with three questions takes 90 seconds: Is every factual claim in this output something I can verify in our actual materials? Does this accurately represent our pricing and terms? Am I comfortable signing my name to this? That review step is the control. Build it into the workflow, not as an afterthought but as the last required step before send.

3. Failure mode 2: confidential data was pasted into a public model

An employee was moving fast. They had a client contract, a financial report, an internal personnel document, or a customer list, and they needed help summarizing, reformatting, or drafting a response. They opened ChatGPT or another public model, pasted the content, and got the help they needed. They didn't think much about it because the tool was right there and it worked.

What they also did: they submitted that confidential content to a third-party model that may use it for training, that is governed by a different privacy policy than your internal systems, and that exists outside any data processing agreement you have with your clients. If your client's contract included a confidentiality clause, you may have just violated it. If the content was health-adjacent, financial, or included personal data of EU residents, the legal exposure is larger.

This failure mode is rarely dramatic in the moment. You find out about it later, often from an audit, a client asking questions, or an employee mentioning it casually. By then the data is already outside your environment.

First 60 minutes:

1. Get the facts without creating a blame atmosphere: what was pasted, into which tool, when, and by whom. You need specifics, not a general sense of the situation.
2. Identify whose data was included. Client data? Employee data? Financial data covered by a reporting obligation?
3. Pull up the applicable contracts: client service agreements, any NDAs, any data processing agreements. Is there a notification clause? Some contracts require notification within 24 to 72 hours of a data handling incident.
4. Review the privacy policy of the model that received the data. Most major public models have a form to submit a data deletion request. Submit it. This does not guarantee deletion, but it creates a record that you acted promptly.
5. Decide within the hour whether legal counsel needs to be involved before any client communication goes out.

What to put in place before it happens again: A one-page AI acceptable use policy that your whole team reads and signs. It needs two things to be effective: a list of what may not be pasted into public AI tools (client data, contracts, personnel files, financial details, anything covered by an NDA), and a clear approved alternative (an internal tool, a model with a signed data processing agreement, or the instruction to anonymize before pasting). Post this on the wall near the printer if you have to. The rule needs to be known before the moment of temptation, not after.

4. Failure mode 3: a wrong AI number made it into a board deck

Your director of finance, operations lead, or chief of staff asked an AI tool to pull together some figures for an upcoming board presentation. The tool summarized a dataset, calculated a growth percentage, or projected a trend. The number looked right. The deck went out. Three board members already have it. Then someone checks the math.

AI tools, including the best ones, make arithmetic errors. They misread date ranges. They confuse year-over-year with quarter-over-quarter. They apply percentages to the wrong base number. These are not rare edge cases; they are documented, repeating failure patterns that happen most often when the person requesting the output trusted the tool's confident presentation of the result and did not verify the inputs.

A wrong number in a board deck is not just an embarrassment. It is a governance problem. Board members make decisions based on those figures. Investors and lenders may see them. If the number touches revenue, headcount, or legal obligations, the downstream consequences are real.

First 60 minutes:

1. Verify the correct figure from the original source, not from another AI summary of the original. Go to the actual file, the actual system, the actual report.
2. Send a corrected version of the deck immediately to everyone who received it, with a brief note that one figure was updated. Do not minimize it and do not over-explain it. "We found an error in the [metric] figure on slide 4 and have corrected it. The updated deck is attached." That is the whole email.
3. If any board member or investor has already discussed the wrong figure or made a decision based on it, call them. Do not send a quiet deck swap and hope they don't notice. Have the conversation.
4. Identify whether other figures in the same deck were AI-generated and run a verification pass on all of them before the meeting.

What to put in place before it happens again: Establish a rule that any financial figure used in a board-level or investor-level document must be verified against its source by a human before it leaves the building. This is not about not using AI to prepare the deck. It is about having a named person who confirms every number has a source, and who initials the final version. One person, one step, before distribution. That is the entire control.

5. Failure mode 4: biased or inappropriate output in a regulated context

You run a staffing agency, an insurance brokerage, a lending operation, a healthcare-adjacent business, or a real estate firm. You are using AI to help screen applicants, draft communications, summarize cases, or generate recommendations. The output that comes back includes language that tilts toward one demographic group, uses protected characteristics in a way that shouldn't factor into the decision, or says something that would read as discriminatory to a regulator, an employment attorney, or the person receiving it.

This failure mode does not require bad intent. It does not require that you built the AI tool yourself. It only requires that you deployed an AI system that you did not test for the specific ways its outputs interact with your regulatory environment. The agencies that enforce fair lending, equal employment, and fair housing do not care whether a human or a machine produced the output. They care what the output said and what decision it influenced.

First 60 minutes:

1. Stop the specific workflow immediately. If you have an AI tool screening candidates, generating loan summaries, or drafting coverage assessments, pause it. Do not let it continue while you investigate.
2. Pull the specific output and any similar outputs from the same workflow over the past 30 days. You need to understand the scope of the problem, not just the incident that surfaced it.
3. Identify whether any actual adverse decision (a denial, a rejection, a lower offer) was communicated to a customer or applicant based on output from this workflow.
4. Involve your legal counsel before any outbound communication. The sequence of notifications matters in regulated contexts, and you need advice specific to your industry before you talk to the affected person, the regulator, or anyone else.
5. Document everything you found and when you found it. The response timeline is often as important as the content of the response when a regulator reviews the incident later.

What to put in place before it happens again: Any AI workflow that touches a regulated decision, one that determines eligibility, pricing, coverage, or employment, needs to be tested against a set of scenarios that include protected class variations before it goes live. If you have a vendor providing the tool, ask them directly: what testing was done on this output against fair lending, fair housing, or equal employment standards in my state? If they cannot answer, that is your answer. Consider a structured review by an external consultant before redeployment.

6. Failure mode 5: vendor outage in the middle of a client deliverable

It's the morning your team was supposed to deliver a draft to a client. The AI writing tool, the AI research assistant, the AI contract review tool, whichever one your workflow depends on, is down. The status page says "investigating." The ETA is unknown. The client delivery time is known: 2 p.m. The work that was supposed to be AI-assisted now has to be human-completed in a fraction of the time.

Vendor outages are not rare. Every major AI platform has had extended outages. The problem is not that the outage happened; it is that the team's workflow assumed availability and had no fallback. When availability went away, so did the plan.

First 60 minutes:

1. Check the vendor's official status page immediately. Is this a full outage or a partial degradation? Can you work around it with a different feature or a different interface?
2. Assess what part of the deliverable is blocked and what part can proceed without AI assistance. Usually, it is not all of it. Identify the human-completable portions and assign them now.
3. Contact the client proactively if the outage creates a real risk to the delivery commitment. Do not wait until 1:58 p.m. to say you are running late. Early notification gives the client time to adjust and costs you far less relationship capital than a last-minute scramble.
4. Check whether a comparable tool can handle the blocked portion. Most AI categories have two to three providers. If your primary is down, can a backup tool do 80 percent of the job? Use it.
5. If the deliverable must slip, define the new time before you call the client. "We need until tomorrow morning" is a complete sentence. "We're working on it" is not.

What to put in place before it happens again: For every AI tool that is part of a client-facing workflow, name a backup before you need one. This takes 30 minutes. Open a document. List each AI tool your team uses in client work. Next to each one, write the name of the backup tool or the manual fallback. That is your vendor contingency plan. It does not have to be formal. It has to exist and be findable when the primary tool goes dark.

7. Failure mode 6: silent quality drift nobody noticed for weeks

This one is slower and harder to catch than the others. Your team has been using an AI tool for a few months. Early outputs were reviewed carefully. Gradually, as people got comfortable, the review got lighter. The tool started generating content, summaries, or analyses that were subtly off: slightly wrong in tone, occasionally pulling from outdated source material, drifting toward generic phrasing that no longer reflects your standards. Nobody flagged it because nobody was looking as closely. The drift accumulated. By the time someone notices, the last six weeks of output reflect a version of your work product that you would not have signed off on in week one.

Quality drift is an organizational failure, not a technology failure. The tool did not change its behavior without warning. Your oversight did.

First 60 minutes:

1. Pull a sample of recent AI-generated outputs, at least 15 to 20 examples from the past six weeks. Read them without the filter of familiarity. Ask: would I have approved this in month one? Does this accurately represent the quality standard we committed to?
2. Identify the specific pattern of drift. Is it factual accuracy? Tone? Depth of analysis? Length? Naming the problem specifically is the first step toward correcting it.
3. Trace when the review step was dropped or lightened. Who stopped checking, and when? This is not about blame; it is about identifying the gap in the process so you can close it.
4. Set a short-term review cadence: for the next 30 days, every AI output in the affected workflow gets a human review before delivery, even if that slows output temporarily. You are recalibrating, not panicking.
5. Brief the client or internal stakeholder if any of the drifted output actually reached them and the quality gap is material. A proactive conversation is better than a client noticing on their own.

What to put in place before it happens again: Build a monthly quality sampling process into whoever owns each AI workflow. It does not have to be extensive. Pull 10 outputs. Read them against your standard. Score them on a simple three-point scale: meets standard, borderline, does not meet standard. If more than two out of ten are borderline or below, investigate. If you are consistently in the eight-to-ten range, your calibration is holding. The point is that someone is looking on a schedule, not waiting for a client complaint to trigger a retrospective.

8. The pre-incident runbook (what to set up now)

The six response sequences above are all faster and cheaper to execute if three things exist before the incident happens. These are not technology projects. They are documents and decisions that take a half-day to produce and that you put somewhere findable, like a shared operations folder, not buried in a tool none of your team opens under pressure.

A one-page AI acceptable use policy. This document answers four questions: Which AI tools are approved for which categories of work? What types of content may not be submitted to a public model? What is the review requirement before AI-generated content reaches a client or a senior decision-maker? Who do you call first when something goes wrong? One page. Every person who uses AI in your business reads it and acknowledges it once a year. This is the single highest-impact control for failure modes 1, 2, and 3.

A named incident owner for each workflow. For every client-facing AI workflow, one person is the first point of contact when that workflow fails. Not the IT person (you may not have one). Not "the team." One named human. Their job in an incident is to run the 60-minute response sequence, communicate status internally, and decide when to loop in legal or senior leadership. This prevents the 15-minute paralysis that happens when people look at each other trying to figure out who is handling it.

A contact list you can reach in 30 minutes. When an AI incident has legal, client relationship, or regulatory implications, you need to talk to someone who can advise you before you communicate externally. That someone might be your outside counsel, your compliance advisor, or a senior partner. Whoever it is, their number needs to be accessible in 30 minutes on a bad day, not buried in your email history from a pitch meeting six months ago. Put it in the operations folder. Put it in your phone. Put it somewhere you can reach it in an emergency without hunting.

A quarterly review of what AI is doing. Failure mode 6 is preventable by one practice: someone looking at AI outputs on a schedule. Make a 60-minute quarterly review part of your operations rhythm. Pull samples from each active AI workflow. Read them. Decide whether the quality and accuracy are holding. Make adjustments if they aren't. Most companies skip this entirely and discover quality drift the hard way.

None of these setup tasks require a technical background. They require someone deciding they are worth doing and blocking time on a calendar to produce them. The companies that handle AI incidents without drama are the ones that made that decision before they needed to.

9. What to do this week

Pick the failure mode that keeps you up at night and build its prevention control before anything else. If you have deployed AI in any customer-facing workflow, hallucinated claims reaching a customer (failure mode 1) is the most immediate risk and the easiest to address: add a human review checklist to the workflow by Friday. If your team is using public AI tools regularly, the acceptable use policy (failure mode 2) costs an afternoon and prevents a problem that could cost significantly more in client trust or legal exposure.

If you are not sure which failure mode your current AI deployment is most exposed to, that is exactly the conversation the AI Advantage Audit is designed for. The audit surfaces which workflows in your specific business carry the most incident risk, which controls are missing, and which ones you can put in place quickly without slowing down your team. It is a diagnostic, not a sales pitch, and it gives you a prioritized list you can act on the week you receive it.

If you already have a sense of what you need and want to scope an engagement that includes incident readiness as part of a broader AI implementation, the Scope Sketcher walks you through what that looks like at three budget tiers, from a basic policy review to a full workflow audit with controls documentation.

And if you want to talk to someone who has walked non-technical operators through AI incident preparation before, book a call through the contact page. Bring your list of active AI tools and a rough description of which ones touch client-facing work. We will spend 30 minutes identifying your highest-exposure workflows and tell you what a pre-incident runbook looks like for your specific business.

The six failure modes in this paper are not rare. They are the predictable friction points in real deployments at companies your size. The operators who handle them well are not the ones with better AI tools. They are the ones who decided incident readiness was part of the deployment, not an afterthought. Set up the runbook before you need it. The cost is a half-day. The alternative is a Tuesday afternoon like the one at the top of this paper.