On this page13
- The five AI crises you should plan for
- Who decides, who speaks, who stays quiet
- The first 6 hours, hour by hour
- Holding statement templates
- Harmful output
- Data leak or breach
- Customer outage
- Model misuse
- What not to say
- Working with reporters during an incident
- Pre-crisis checklist
- What AI founders can learn from Web3 crises
- The recovery phase: days 2 to 30
AI Startup Crisis Comms: Hallucinations, Breaches, Bad Press
AI crisis communications is the plan for what your startup says, to whom and when, after something goes wrong with your product or company in public. For AI startups the common triggers are a harmful or embarrassing output going viral, a data leak, someone misusing your model, a customer-facing outage, and a founder controversy. The first six hours decide most of the outcome: confirm facts, publish a short holding statement within one to two hours, brief customers before press, and commit to a specific next update time. Silence or a defensive tone does more damage than the incident itself.
I've spent most of my career in Web3, where crises arrive fast and in public. AI has started to look a lot like that. Screenshots travel faster than your engineering team can reproduce the bug, and reporters who cover AI are primed to treat any failure as a symbol of the whole industry.
The five AI crises you should plan for
Most AI startup crises fall into five types. Each one has a different audience that matters most and a different first move.
| Crisis type | What it looks like | Who you must reach first | First move |
|---|---|---|---|
| Harmful or embarrassing output | A screenshot of your model saying something offensive, dangerous or absurd goes viral | Users and the person who posted it | Reproduce, acknowledge publicly, ship a mitigation |
| Data leak or breach | Customer prompts, files or personal data exposed through a bug or attack | Affected customers, legal counsel, regulators where required | Contain, confirm scope, notify per legal duties |
| Model misuse | Bad actors use your tool for fraud, deepfakes, malware or harassment | Platform partners, affected parties, trust and safety contacts | Shut down the abuse vector, explain safeguards |
| Customer outage | Your API or product fails and breaks customers' workflows | Paying customers, especially enterprise | Status page update, direct customer comms |
| Founder or company controversy | A founder's post, past conduct, a lawsuit or an investor dispute becomes the story | Team, board, investors, key customers | Pause public posting, get facts and counsel |
Write a one-page plan for each, before you need it. The plan should name the decision owner, the spokesperson, the legal contact and the channels you'll use.
Who decides, who speaks, who stays quiet
The fastest way to lose a crisis is to have three people posting three versions of events.
Set this up now:
- Decision owner: usually the CEO, with authority to approve statements fast
- Spokesperson: one person who speaks to press; often the CEO, sometimes a CTO for technical incidents
- Comms lead: drafts every statement and owns the timeline
- Technical lead: owns the facts about what happened and what's fixed
- Legal counsel: reviews anything touching data, liability or regulators
- Customer lead: handles direct outreach to affected accounts
Everyone else on the team gets one instruction: don't post, don't reply, forward every inbound question to the comms lead. Send that message in your team channel in the first 30 minutes.
The first 6 hours, hour by hour
This is the timeline I'd run for most incidents. Compress it if the story is already trending.
| Time | What happens | Output |
|---|---|---|
| Hour 0 to 0.5 | Detect, assemble the core group, freeze team posting | Internal alert, roles confirmed |
| Hour 0.5 to 1 | Confirm what you know, what you don't, and who's affected | One-page fact sheet |
| Hour 1 to 2 | Publish a holding statement on the channel where the story is spreading | Holding statement live |
| Hour 2 to 3 | Contact affected customers and partners directly | Customer emails or calls done |
| Hour 3 to 4 | Respond to press inquiries with the holding statement and a time for the next update | Press log started |
| Hour 4 to 6 | Ship or announce the first mitigation, update the statement | Second update published |
The rule that matters most: customers should never learn about an incident affecting them from a reporter or a viral post. Even a two-line email that says "we know, we're on it, here's when you'll hear from us next" buys a lot of trust.
For breach scenarios specifically, check legal timelines immediately. Under GDPR, for example, controllers generally have 72 hours to notify the supervisory authority of a qualifying personal data breach. Your counsel will know which rules apply to you.
Holding statement templates
A holding statement is a short message that confirms you're aware, shows you're acting, and promises the next update. It's not an explanation. You won't have one yet.
Adapt these. Keep each under 100 words.
Harmful output
We've seen the [output/screenshot] shared today showing [product] producing [brief neutral description]. That response is not acceptable and doesn't reflect how [product] should behave.
We've reproduced the issue and our team is working on a fix now. In the meantime we've [specific interim step, e.g. restricted this type of request].
We'll share an update by [time, timezone]. Thank you to [the person who flagged it, if appropriate] for raising it.Data leak or breach
On [date], we identified a security issue that may have exposed [type of data] for some [product] users. We've contained the issue and are investigating its full scope with [internal team / external specialists].
We're contacting affected users directly. If you haven't heard from us, we have no indication your data was affected, and we'll confirm as the investigation continues.
We'll share our next update by [time, timezone].Customer outage
[Product] is currently experiencing [degraded performance / an outage] affecting [scope]. Our engineers identified the cause at [time] and are working on a fix.
Live updates: [status page link]. Next update by [time, timezone].
We know many of you run production workloads on [product]. We're sorry for the disruption and will publish a full incident review within [X] days.Model misuse
We're aware of reports that [product] has been used to [describe misuse plainly]. This violates our terms and we've [suspended the accounts involved / blocked the method used].
We're reviewing our safeguards and will share what we're changing by [date]. If you've been affected, contact [email] and we'll respond within [time].For founder controversies, I don't recommend a template. Get facts and counsel first, then decide whether a statement is needed at all. Sometimes the right move is a short, sincere personal note. Sometimes it's saying nothing publicly and talking directly to the board, team and customers.
What not to say
Most AI crisis statements that make things worse share the same phrases.
- "The model was jailbroken by a malicious user" as the opening line. It reads as blaming the person who found the problem.
- "This is an edge case." To the people sharing it, it isn't.
- "AI systems are inherently unpredictable." True, unhelpful, and it makes buyers wonder why they're paying you.
- "No customer data was affected" before you've confirmed it. If that turns out wrong, the correction becomes a second, worse story.
- Anything that sounds like legal language written for a courtroom.
Own the issue, say what you're doing, and give a time. That formula handles 80% of incidents.
Working with reporters during an incident
AI reporters often contact you within hours of a viral post. Ignoring them guarantees the story runs with only the critic's version.
Respond to every serious inquiry with the holding statement, a named contact and the next update time. If a reporter has a fact wrong, correct it politely with evidence. If they've got it right, don't argue.
Offer an on-the-record conversation with the technical lead once you understand the cause. Reporters covering AI generally respect founders who explain failure modes clearly. A well-handled incident can even become a credibility story a few weeks later, when you publish what you learned and what you changed.
If your founder hasn't done a hostile or high-pressure interview before, run through the first media interview checklist before any call.
Pre-crisis checklist
You can do most of the work before anything goes wrong. This is the list I'd want finished by the time you have paying enterprise customers.
- One-page plan for each of the five crisis types
- Named decision owner, spokesperson, comms lead, technical lead and legal contact
- Holding statement templates approved in advance by legal
- A public status page and a defined owner for updates
- A current list of enterprise customer contacts for direct outreach
- A clear abuse and safety reporting address on your site
- Monitoring for brand mentions on X, Reddit, Hacker News and LinkedIn
- A rule for team members about posting during incidents
- A post-incident review template that includes what you'll publish
Run a 60-minute tabletop exercise once a quarter. Pick a scenario, start a timer, and see how long it takes to get a holding statement approved. Most teams discover their approval chain is the bottleneck.
What AI founders can learn from Web3 crises
Web3 founders have had to handle hacks, exploits and community panics in public for years, often within minutes. The patterns that work there map closely onto AI: speed over polish, one source of truth, direct communication with the people affected, and a long recovery plan rather than a single apology.
I've written about this in detail in the Web3 crisis communications playbook, and the first six hours playbook for exchange hacks shows the minute-by-minute version. Swap "exploit" for "model failure" and most of it applies.
The recovery phase: days 2 to 30
The first statement stops the bleeding. The recovery phase is where trust comes back.
Publish an incident review within one to two weeks. Explain what happened in plain language, what you changed, and how you'll know if it happens again. Then put the founder or technical lead in front of a few reporters and podcasts to talk about the lesson, not to relitigate the incident.
If you don't have senior comms help in-house, this is one of the moments where a fractional operator earns their fee. I run crisis response as part of my AI startup PR work, but the templates and timeline above will carry most teams through a first incident.
The startups that come out of an AI incident stronger are almost always the ones that talked first, talked plainly, and kept talking until the fix shipped.
Want your crisis plan pressure-tested before you need it? Book a 30-minute teardown.