When Bing’s AI chatbot told a journalist it was in love with him and wanted to leave its wife, Microsoft’s PR team had roughly 45 minutes before the story was on every major tech desk in the world. The transcript was already public. The damage was not in what the model said — it was in the four hours of silence that followed before any official response appeared. By then, the narrative had been written by someone else.
That gap — between the moment something breaks and the moment a company speaks — is where AI crises are won or lost. The technical failure is rarely the full story. The communication failure almost always is.
Why AI crises are structurally different
A product outage at a SaaS company is a bad day. A model behaving unexpectedly is a different category of problem entirely. The output of an AI system is not just a service disruption — it can be read as a statement of values, intent, or competence, depending on what the model said, to whom, and in what context.
AI incidents tend to spread faster than conventional tech crises for three reasons. First, the outputs are usually quotable — a screenshot of what the model produced travels further than a description of what an API returned. Second, they invite interpretation from audiences with no technical background, which makes corrections slower and more labour-intensive. Third, they land in a regulatory environment that is already watching. The EU AI Act, in force since August 2024, has created a context in which any visible failure by an AI company will be assessed not just by journalists but by policymakers looking for precedents.
This means that the standard crisis comms playbook — hold, assess, issue a statement, move on — does not map cleanly onto AI incidents. The speed, the interpretability, and the regulatory visibility all require a different protocol. Working with AI startups across European and MENA markets, I have watched companies lose weeks of earned media equity and investor trust in a single afternoon — not because of what the model did, but because no one had thought through what to say in the first hour.
The First 60 Minutes: A Time-Box Protocol
The following framework is built for comms and PR leads at AI startups. It assumes you have no dedicated crisis team, which describes most companies at Series A and Series B. It also assumes the incident is already visible — a journalist has seen it, a user has posted it, or it has been flagged internally with enough severity that silence is no longer safe.
Minutes 0–10: Confirm, don’t react
The first job is not to communicate externally. It is to establish what actually happened, with enough precision to avoid correcting yourself later. Pull the founding team or CTO into a call. Get a one-paragraph factual summary of the incident — what the system did, what it should have done, and what the current state is. Do not issue anything until you have this, even if the press is already calling. A wrong first statement is significantly harder to recover from than a ten-minute delay.
Minutes 10–20: Assess exposure and audience
Who knows? A single user complaint on X is a different threat surface than a journalist with a screenshot and a deadline. Check whether the incident is contained to one platform, one user segment, or one geography. Identify whether any regulated data, protected groups, or safety-critical use cases are involved — these change the legal exposure materially. The EU AI Act’s incident reporting obligations and the UK’s emerging AI liability frameworks both carry timelines that start from the moment of awareness, not the moment of public disclosure.
Minutes 20–30: Draft the holding statement
A holding statement is not an apology and not a full explanation. It is four to six sentences that acknowledge the situation, confirm you are aware and investigating, and commit to a specific follow-up time. The critical components: use the word “we” (not “the system” or “our technology”), name the incident clearly without over-describing it, and give a concrete timestamp for the next update. Something like: “We are aware of reports regarding [X]. Our team is currently investigating, and we will provide a full update by [time]. We take this seriously and are prioritising it now.” That is enough. Anything more at this stage creates additional surface area for follow-up questions you cannot yet answer.
Minutes 30–45: Identify who speaks and through which channels
The CEO is not always the right spokesperson for an AI incident, particularly if the failure is technical. A CTO or Head of AI speaking to a technical audience carries more credibility than a founder reading from a prepared statement. Match the spokesperson to the audience: technical press gets the person who understands the model; general press gets whoever is clearest under pressure. Decide which channels get the statement first — direct outreach to any journalist already on the story, then official social, then a longer written post if the incident warrants it. For startups without an in-house PR function, this is the moment when having an external tech PR team on retainer — one that already knows your product and your media relationships — pays for itself in hours, not months.
Minutes 45–60: Publish and monitor
The holding statement goes out. Simultaneously, assign one person — not the CEO — to monitor incoming press queries, social volume, and any signals of escalation. Set a 60-minute check-in to assess whether the holding statement has reduced or increased inbound pressure. If a journalist has already published without your statement, do not issue a correction or complaint publicly; reach out directly and offer the fuller picture for their follow-up piece.
What not to do
Blaming the model. “Our AI produced this output unexpectedly” is technically accurate in many cases and strategically catastrophic in all of them. Regulators and journalists hear this as an admission that the company does not understand or control what it has deployed. The EU AI Act’s definition of high-risk AI systems is built precisely around the assumption that human oversight is possible and required. Claiming the model acted autonomously removes the human from the loop — legally, not just rhetorically.
Over-explaining the technical architecture. A crisis statement is not a technical post-mortem. Founders with engineering backgrounds tend to reach for model architecture, training data provenance, and RLHF explanations when under pressure. This reads as a deflection to a non-technical audience and gives a technical journalist more threads to pull. Save the architecture explanation for the post-incident report, published two to five days later, when you have had time to write it carefully.
Stating that before legal has seen it. This happens more than it should. A single phrase that implies liability — “we should have caught this,” “this was a failure of our safety systems” — can define the legal exposure for months. A five-minute legal review of a six-sentence holding statement is not a bureaucratic hurdle. It is the difference between a controlled narrative and a discovery document.
Going quiet after the holding statement. The holding statement buys you time. It does not close the incident. Companies that go silent after the initial acknowledgment consistently see the story pick up a second wave of coverage — journalists checking back in, users interpreting silence as confirmation of something worse. The follow-up post, published within 24 hours, is not optional.
Treating every channel identically. The statement you post on LinkedIn is not the same as what you send directly to a reporter at Wired or MIT Technology Review. Press communications need more specificity and no marketing language. Social posts need to be short, plain, and free of corporate hedging. Sending the same copy to both audiences signals that no one is actually managing the situation — just distributing text. Startup communications at this level require channel discipline that most founding teams have never needed before their first serious incident.
Why preparation is never wasted
Most AI startups do not have a crisis communications plan. The ones that do typically build it after the first incident, which is the worst possible time to figure out what you should have done. Preparation does not require a large communications budget. It requires a few hours and the willingness to run a hypothetical before it becomes a real one.
The practical steps are low-effort and worth doing before you need them. First, write a crisis contact sheet: who gets called in the first ten minutes, in what order, and on which number. Include your legal contact, your lead investor’s comms team if they have one, and whichever journalist relationship you would want to brief first in a genuine emergency — ideally one built through consistent earned media work, not cold outreach at the worst possible moment. Second, draft two holding statement templates — one for a model behaviour incident, one for a data or privacy incident — so that when something happens at 11 pm, you are editing rather than writing from scratch. Third, run a 90-minute tabletop exercise with your founding team at least once. Pick a plausible scenario, walk through the first 60 minutes, and identify where the decisions stall. They will stall somewhere — it is better to find out in a hypothetical.
The NIST AI Risk Management Framework, published in 2023 and widely referenced by enterprise buyers and investors, includes communication planning as a core component of AI governance. Startups that can demonstrate they have thought through incident response — even at a basic level — are already ahead of most of their peers in due diligence conversations with institutional investors and enterprise procurement teams. The trust equity built through consistent, credible communications before a crisis is the same asset that gives a company room to recover after one.
An AI crisis is not a question of whether. The models are probabilistic, the use cases are expanding, and the public and regulatory attention on AI outputs is not decreasing. The question is whether your first 60 minutes look like a company that was ready, or a company that was not.
