What to Do When Something Goes Wrong With AI at Your Business
Something will go wrong. A team member pastes client data into Claude on a personal account. A connected integration surfaces information it shouldn’t have. An AI-generated document goes to a client with an error nobody caught. These aren’t hypotheticals — they’re the kinds of situations businesses are already navigating.
The question isn’t whether you’ll face one of them. It’s whether you’ll have anything in place when you do.
Preparation Is the Whole Game
When something goes wrong with AI at your business, your ability to respond clearly depends almost entirely on decisions you made before the incident happened. What data was in scope, who had access, what the usage policy said, what your audit logs show — all of that either exists or it doesn’t. You can’t reconstruct it after the fact.
Businesses that respond well to AI incidents aren’t the ones with the most sophisticated technology. They’re the ones that did the governance work upfront: data classification, usage policies, access controls, team training. When an incident happens, that groundwork tells you exactly what you’re dealing with.
The Business Owner’s Guide to Claude Governance
The First 24 Hours
When something goes wrong, the first priority is understanding what actually happened. That means pulling whatever logs and records are available, talking to the people involved, and getting a clear picture before you start making decisions about how to respond.
Resist the pressure to act immediately on incomplete information. A fast response built on a misunderstanding of the situation can make things worse. Take the time to understand the scope — what data was involved, what systems were affected, who may have been impacted — before you decide what to communicate and to whom.
If the incident involves regulated data — health information, financial records, personal data subject to privacy laws — your response timeline may be governed by compliance obligations. Know those timelines before an incident happens, not during one.
What Good Documentation Looks Like
If you’ve set up Claude Enterprise properly, you have access to usage logs that show what happened and when. That’s a meaningful advantage. You can see which user was involved, what they accessed, and when the activity occurred.
If your team has been using personal AI accounts with no admin controls, you don’t have that. You’re working from memory and self-reporting, which is a much harder position to be in when you’re trying to explain to a client or a regulator what happened.
How to Set Up Claude Enterprise for Your Team
This is one of the clearest practical arguments for a centralized platform. The audit trail it creates isn’t just useful for governance — it’s what lets you respond credibly when something goes wrong.
When a Client Is Affected
If the incident involves client data, the conversation with that client is unavoidable. Have it early and have it directly. Clients who find out about a data issue from you, quickly and clearly, respond differently than clients who find out some other way.
What to communicate: what happened, what data was involved, what you’ve done to address it, and what you’re doing to make sure it doesn’t happen again. You don’t need to have all four answers before you make the call — but you should have at least the first two, and a clear timeline for the others.
What you can’t do is wait until you have a perfect explanation before reaching out. The delay compounds the problem.
Fix the Root Cause
Every AI incident has a root cause. It’s almost never the AI tool itself. It’s a gap in your governance framework — a data category that wasn’t classified, a usage policy that wasn’t specific enough, an access control that wasn’t configured correctly, a workflow your team developed that nobody reviewed.
Find the gap and close it. Update your classification framework, revise your usage policy, adjust your access controls, or add a review step to the workflow. Then communicate the change to your team so they understand what changed and why.
How to Write an AI Usage Policy Your Team Will Actually Follow
An incident that doesn’t produce a change to your governance framework is a missed opportunity. The most useful thing that comes out of an AI incident is a more accurate picture of where your framework had gaps.
Build the Response Framework Before You Need It
The businesses that handle AI incidents well aren’t improvising. They’ve thought through the scenarios in advance — not every possible scenario, but the realistic ones — and they have a rough plan for each.
Who gets notified internally when an incident is identified? Who makes the call on whether to contact a client? Who’s responsible for pulling logs and documenting what happened? What’s the escalation path if regulated data is involved?
Those questions have answers that are much easier to work out before an incident than during one. A one-page incident response outline, written now, is worth more than a detailed framework written under pressure.
Listen to the full podcast episode here.