AI Incident Response for Small Businesses: What to Do in the First Hour

Key takeaways

• Most AI incidents fall into four types: sensitive data was entered into a tool, wrong output was acted on, an unapproved tool was used, or an account was misconfigured.
• In the first hour, do three things in order: stop the activity, establish exactly what data or output was involved, and write it down before details are forgotten.
• Deleting the conversation is not containment. Vendor-side copies may persist under retention terms, so record what was exposed rather than assuming deletion resolved it.
• Do not begin with blame. An employee who expects blame reports the next incident later or not at all, which is far more expensive than the incident itself.
• Any incident touching customer, health, financial, or employee data may carry notification obligations — that is the point to involve qualified professionals, not to work it out internally.

---

An AI incident in a small business rarely looks like a breach. It looks like someone pasting a customer's full support history into a chatbot to draft a reply, or a quote going out with a figure the AI invented.

Nobody was careless in any dramatic way. But something is now somewhere it should not be, and what happens in the next hour determines whether this is a contained mistake or an ongoing problem.

The four incident types

Naming the type first makes the response obvious.

Type 1 — Sensitive data was entered into an AI tool. Customer PII, financial records, employee information, credentials, or confidential documents went into a prompt.

Type 2 — Wrong output was acted on. AI-generated content containing errors was sent to a customer, published, or used in a decision. Invented figures, wrong dates, fabricated citations.

Type 3 — An unapproved tool was used for work. Business data went into a tool nobody reviewed, so its data practices are unknown.

Type 4 — An account or setting was misconfigured. A personal account used for work, a shared workspace where conversation history is visible to people who should not see it, or training-on-your-data left enabled.

Severity: how much of a response this needs

Match the response to the exposure, or the process collapses under its own weight.

Low. Internal, non-sensitive information; no external impact. Log it, correct the habit, move on. No escalation.

Medium. Confidential business information, or an error caught before it reached anyone outside. Notify the person who owns AI decisions. Log it. Fix the cause.

High. Customer or employee personal data, financial records, or health information exposed to a tool with unclear terms — or wrong output that reached a customer.

Critical. Credentials or access tokens exposed, or a significant volume of customer records. This is a security incident that happens to involve AI. Rotate credentials immediately.

The first hour

Stop the activity

Whoever noticed stops what they are doing. Do not send the next message, do not continue the conversation, do not "just fix" the output and carry on.

If credentials were exposed, rotate them now — before anything else in this list. An exposed API key is actively exploitable in a way that a leaked draft is not.

Establish exactly what was involved

Be specific, because "some customer data" is not something you can act on:

• Which tool, which account, and which tier
• What exactly went in — how many records, whose, containing what fields
• What came out, and where it went
• When it happened, and whether the conversation history still exists

Deleting the conversation is not containment. Vendor retention terms usually mean a copy persists server-side for some period regardless of what your interface shows. Delete it anyway to limit who can see it in a shared workspace — but record what was exposed rather than treating deletion as resolution. If you do not know the vendor's retention terms, how to read AI vendor terms covers where to find them.

Write it down before the details fade

Six fields, written the same day:

1. Date and time
2. Who was involved (as a fact, not a fault)
3. Which tool and account
4. What data or output was involved
5. What was done in response
6. Whether anyone outside the business was affected

Specifics degrade fast. A log written a week later is a guess.

For High and Critical: escalate outward

For an incident involving personal data of customers or employees, health information, or financial records, notification obligations may apply depending on your jurisdiction, industry, and what was exposed. That determination is not something to reason through internally — bring in a qualified professional, and do it in the first hours rather than after a week of internal discussion, because notification timelines can be short.

Do not open with blame

The instinct is to establish who made the mistake. Resist it for the first hour.

An employee who expects consequences for reporting will report the next one later, or route around the process entirely. The incident you hear about in the first ten minutes is dramatically cheaper than the one you discover in a quarterly review. Whatever you save by making an example of someone, you lose several times over in future silence.

Separate the two conversations: contain the incident today, and if there is a genuine pattern of ignoring clear rules, address that separately, later, as a performance matter.

The review that prevents the next one

Within a week, answer four questions:

Was there a rule covering this? If not, that is the finding — write one. If there was, the next question matters more.

Why did the rule not prevent it? Usually one of: the employee did not know it existed, it was ambiguous in this situation, or following it would have blocked real work with no approved alternative. That third case is the most common and the most fixable — people route around rules that leave them no way to do their job.

Was the tool the problem, or the use? A tool with acceptable terms used for the wrong data is a use problem. A tool with unclear terms is an approval problem — see the AI vendor review checklist.

What one change makes recurrence less likely? One. A review producing twelve action items produces zero completed action items.

Then look across your log periodically. Three incidents of the same type is not three accidents; it is a process gap. The monthly AI usage review covers that cadence.

Preparing before you need it

The point of writing this down in advance is that the first hour is not when you want to be deciding who to call. A one-page procedure — severity bands, who is notified, what gets logged — takes twenty minutes to draft and belongs alongside your AI usage policy. The small business AI governance checklist includes the incident log as one of its 20 items.

Reduce the most common cause

Type 1 — sensitive data entered into a tool — is the most frequent incident by a wide margin, and it is the most preventable. The Prompt Safety Checker scans a draft prompt for credentials, personal data, and internal financial information before it is sent, entirely in your browser with nothing transmitted to any server.

For a complete incident response procedure, an incident log template, and the employee guidance that reduces how often you need them, see the Starter Pack.

This article provides practical operational guidance for AI usage management. It is not legal advice and does not guarantee regulatory compliance. Data breach notification requirements vary by jurisdiction and industry — consult qualified professionals for obligations that apply to your business.