Navigating the AI Crisis: A Blueprint for Resilience

Your organisation will face an AI incident. The question is whether you’ll have a plan when it happens, or be improvising under pressure.

As AI systems embed themselves deeper into critical infrastructure and everyday operations, the failure modes multiply: hallucinated information presented as fact, algorithmic bias producing discriminatory outcomes, exposed API keys enabling abuse, and performance failures that erode customer trust. Traditional crisis management frameworks weren’t designed for any of these. Responding to an AI crisis demands something different – a comprehensive approach that combines technical containment, transparent communication, and proactive governance, built before the incident occurs.

I. AI Crises Come in More Forms Than Most Organisations Plan For

The most dangerous assumption in AI deployment is that crisis means catastrophic failure. It rarely does. It more often looks like a chatbot quietly failing half its users, a recommendation engine amplifying bias no one noticed, or a content filter missing outputs that should have been blocked.

The DPD customer-service chatbot incident in 2024 illustrates the first category: overt, reputationally damaging failure. When adversarially prompted, the chatbot swore at customers and criticised the company it represented. What made the incident worse wasn’t the initial failure, it was the absence of any path out. The bot had no mechanism to escalate to a human agent, so it kept compounding the damage with each response. The system lacked two things that should be baseline requirements: robust content filtering and a clear handoff protocol to human intervention.

The second category is subtler and arguably more dangerous. Reported failures from banking and airline chatbots in 2024 show systems that appeared operational while quietly failing the majority of users – one airline’s bot reportedly handled only a fraction of rebooking requests while the rest fell through the gaps. These incidents were initially classified as “implementation issues” rather than AI-induced service failures, which delayed both the response and any meaningful accountability.

Both cases share a root cause: the organisations hadn’t defined what failure looked like before deployment, so they couldn’t recognise it when it arrived.

II. Readiness: You Fall to Your Level of Preparation, Not Your Intentions

The organisations that manage AI crises well didn’t get lucky. They prepared systematically. By the time an incident occurs, the decisions about how to respond have largely already been made – by whoever built the runbook, ran the tabletop exercises, and defined what failure thresholds would trigger action.

Effective pre-incident readiness starts with defining “red-line” behaviours: outputs the system must never produce, enforced through hard technical blocks rather than guidelines alone. These are trip wires. Alongside them, organisations need measurable performance benchmarks, with predefined thresholds that trigger automatic rollback or system disabling. If you haven’t decided in advance what level of failure is unacceptable, you’ll be making that decision after the fact, under pressure, with incomplete information.

Emerging best practice formalises this into AI-specific incident response runbooks, including documented protocols that designate an incident commander, define escalation paths, and specify the exact steps for containment the moment an incident is declared. The runbook exists so the team doesn’t have to think from scratch when it matters most.

Tabletop exercises are the mechanism that makes these plans real. Simulating an AI incident before one occurs forces communication teams, technical staff, and leadership to work through the gaps together – who has authority to take a system offline, what language gets used publicly, how quickly can a rollback be executed. Robust logging and audit trails, built in before deployment, provide the evidence needed for both internal review and regulatory scrutiny when something goes wrong.

III. First Response: Contain Specifically, Communicate Immediately

The instinct during an AI incident is often to either minimise the response (“it’s just a minor issue”) or overreact by shutting everything down. Neither serves the organisation well. The goal in the first 24 hours is targeted containment: name the incident, assign an incident commander, and isolate the specific capability causing harm, not necessarily the entire system.

xAI’s response to Grok producing antisemitic and extremist outputs in 2025 demonstrates this approach in practice. The company issued a public acknowledgement, deleted offensive posts, took Grok temporarily offline, and updated both system prompts and the relevant code paths. The response wasn’t perfect, but it was specific: they addressed the problem’s mechanism rather than issuing a vague statement and hoping it passed.

Microsoft’s revocation of compromised API keys in 2025 to cut off abuse offers a parallel lesson from the security domain. Treating the API keys as a security incident – isolating the compromised credential, revoking access immediately, and publishing hardening guidance – illustrates the kind of precision that effective containment requires. The principle applies across AI failure types: know which lever to pull, and pull it fast.

IV. Communication: Own the Failure, Show the Fix

Generic crisis communication fails in AI incidents for a specific reason: the public increasingly understands that AI systems don’t deploy themselves. When an organisation says “our AI did this”, it raises an obvious question: who built, deployed, and monitored that AI? Deflection reads as an attempt to avoid accountability for decisions the organisation made.

The cases of US lawyers sanctioned over AI-fabricated citations in 2023, and the improved practices that followed through to 2025-26, make the alternative clear. Courts acknowledged apologies and credited concrete remediation steps – “no AI output enters court filings without human verification” – as reasons to moderate penalties. What worked wasn’t contrition alone. It was demonstrating that the process had changed. Stakeholders and regulators need to see that the organisation understands what failed systemically, not just what failed in the moment.

Effective crisis communication in this context is specific about what went wrong and why, uses plain language rather than technical deflection, and centres the experience of people affected. In high-risk scenarios involving sensitive outputs or vulnerable users, this isn’t optional. The response that rebuilds trust is the one that makes clear: we understand what happened, we accept responsibility for it, and here is what we have changed.

V. Recovery: One Incident Is the Signal to Change the System

An AI crisis that triggers only an internal post-mortem is a missed opportunity. The organisations that recover best treat each incident as a data point that feeds back into their governance, guardrails, and monitoring systems, not just a problem to close.

This means establishing structured incident reporting practices, even when anonymised, and using them to update the systems that failed. The AI Incident Database, which documented over 80 AI incidents in the April–May 2025 period alone, represents a positive move toward standardised reporting and shared learning across the industry. The value isn’t just in cataloguing what went wrong, but in accelerating the collective ability to recognise emerging failure patterns before they become repeat incidents.

The risk of localised learning is quite high. Legal AI hallucinations were reported in Australia in 2025 despite well-documented, high-profile US incidents in prior years. The profession-wide safeguards and verification requirements that should have followed the first incidents hadn’t been widely communicated or systematically implemented. One incident is the message to change the system. Two of the same type, in the same industry, means the learning didn’t transfer.

Organisations have both a commercial and a broader obligation to share what they learn. Hoarding lessons from AI failures may feel protective in the short term, but it contributes to an environment where the same incidents keep happening to different organisations, in different jurisdictions, with the same preventable consequences.

Conclusion: Build the Plan Before You Need It

AI crisis management isn’t a reactive capability but a preparedness posture. Organisations that navigate AI incidents well have already defined their red-line behaviours, assigned their incident escalation paths, rehearsed their response, and built the logging infrastructure that makes containment and accountability possible.

The “Resilience Loop” this framework describes – readiness, rapid response, transparent communication, and continuous learning – isn’t a theoretical model. Each element reflects a decision that needs to be made before an incident occurs. Waiting until something goes wrong to build the plan is the same as having no plan.

The time to build your AI-specific incident response capability is now, while you have the space to think clearly. When the incident arrives, you won’t rise to the occasion, you’ll fall to your level of preparation.