Your Incident Response Playbook Almost Certainly Does Not Cover AI Failures. That Is a Problem.

Key points

• 71% of organisations gave AI systems access to core business systems as of the 2026 CISO AI Risk Report, but only 16% govern that access effectively.
• Documented AI incidents rose 56.4% between 2023 and 2024, reaching 233 confirmed cases.
• The Epic Sepsis Model, deployed across hundreds of US hospitals, missed two-thirds of actual sepsis cases according to a 2021 JAMA Internal Medicine study, with no attack involved.
• Air Canada was held legally liable after its chatbot invented a discount fare policy and a customer relied on it.
• 67% of AI incidents trace back to model errors, not outside attackers, yet most security budgets keep funding tools built to stop attackers.

Most security teams have an incident response playbook, which is the documented plan a company follows when something goes wrong digitally. Most organisations also now run AI systems. The assumption that the first document covers the second is, according to practitioners who have tested it, almost always wrong.

CSO Online published a detailed breakdown of this gap earlier this year, drawing on more than a decade of hands-on experience across energy, banking, telecom, and manufacturing sectors. The picture it paints is uncomfortable.

Why does this matter to ordinary people?

Because AI failures already reach patients, travellers, and job-seekers, not just IT departments. When a hospital's sepsis-detection model quietly stopped working at useful accuracy, doctors received floods of false alarms and missed real cases. No one hacked it. The dashboards all showed green. The system was simply doing what it was built to do, just badly.

That distinction sits at the heart of the problem. There are two broad categories of AI failure. The first is a model breaking on its own: poor outputs, bias, or hallucinations (where an AI confidently states something that is simply untrue). The second is an outside attacker deliberately feeding the model corrupted data to manipulate what it does. Most current incident-response frameworks treat these the same way. They should not, because the detection methods, the fix, and the legal consequences differ sharply.

The legal piece is no longer theoretical. Air Canada's chatbot invented a bereavement fare that did not exist. A passenger relied on it. A court held the airline responsible. In the US case Mobley v. Workday, a federal court accepted that an AI hiring platform could carry direct liability for bias in its decisions. Neither event looked like a security breach. Both ended up as legal ones. If your legal team is not listed on your incident response call sheet, your playbook is incomplete before an incident even starts.

The standard security framework known as the CIA triad, which stands for confidentiality, integrity, and availability, also falls short here. When a chatbot invents a policy, nothing was stolen, nothing was altered by an intruder, and nothing went offline. Every traditional alarm stays quiet. The framework has no category for it.

Organisations that are ahead of this problem tend to have four things in place before any incident happens. First, an inventory of every AI system in use, documented like a parts list, covering what data trained it and what it connects to. Second, a plain-language summary for each AI system that a security responder can read at 2am, not a technical document written only for data scientists. Third, a data scientist named on the incident call list with the authority to interrogate the failing model in real time. Fourth, a pre-agreed threshold that defines exactly when a misbehaving model gets switched off or swapped for a simpler backup.

If your organisation uses AI in customer service, hiring, clinical settings, or financial decisions, these are practical questions to ask now. Where is the list of AI systems? Who decides when one gets shut down? What is the backup if it does?

Fix it before you need it.