The Question
When a cybersecurity incident occurs, enterprises reach for a playbook that has been refined through decades of practice: isolate the affected system, assess the scope of compromise, notify affected parties, remediate the vulnerability, conduct the post-incident review. The playbook works because cybersecurity incidents have known shapes — a breach has a source, a perimeter, an extent of compromise. The response is containment followed by remediation.
AI governance incidents do not have the same shape, and applying the cybersecurity incident playbook to AI governance failures produces responses that are either insufficient or misdirected. When an AI model provides incorrect information that causes customer harm, the incident did not originate from an external attacker exploiting a vulnerability — it originated from the normal operation of a system that was deployed without adequate governance controls. Taking the system offline may stop further harm, but it does not address the root cause, and it may not even be the right containment response. When a deployed model produces biased outputs in a regulated decision-making context, the incident may have been occurring for months before detection, affecting thousands of decisions, with regulatory notification obligations that bear no resemblance to GDPR breach notification timelines.
The enterprises that respond effectively to AI governance incidents have thought through the response procedures before the incident. The ones that discover their AI IR gap during a live incident learn the lesson at the highest possible cost.
AI governance incident response planning needs to exist before the incident — and the enterprises that discover they have no AI IR procedure during a live incident learn the lesson at the highest possible cost.
Why This Matters Now
The Air Canada chatbot incident is the reference case for AI governance incident response failure. In early 2024, the British Columbia Civil Resolution Tribunal ruled against Air Canada in a dispute where a passenger sought a bereavement fare discount based on guidance provided by Air Canada's customer service chatbot. The chatbot's guidance was factually incorrect — the fare policy the chatbot described did not exist. Air Canada's initial defense, that the chatbot was "a separate legal entity responsible for its own actions," was rejected by the Tribunal. Air Canada was ordered to honor the fare discount the chatbot described.
What made this an AI governance incident response failure rather than simply an AI incident: Air Canada had no documented procedure for handling customer claims arising from chatbot output. The incident was treated as a customer service dispute, then a legal matter, then a public relations problem — each function handling it without an AI governance framework that defined scope, escalation path, or remediation responsibility. The governance failure was not in the chatbot producing incorrect output; that is a known failure mode of large language models. The governance failure was in deploying a chatbot for customer-facing use without an incident response procedure for the known failure modes.
The EU AI Act's serious incident reporting requirements, fully effective for high-risk AI systems from August 2026, require operators to notify relevant market surveillance authorities of serious incidents — defined as incidents causing death, serious injury, or significant disruption — within 15 days of becoming aware. This reporting timeline requires a functional AI incident response procedure to be in place before the incident, not assembled after it.
The NIST AI RMF Playbook, updated in 2024, introduced specific guidance on AI incident response that distinguished AI governance incidents from cybersecurity incidents — formally establishing that the two require different response procedures even when they overlap.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Governance CURVE™ Report evaluated vendors and frameworks against AI-specific incident response capabilities, including detection mechanisms, notification workflow support, and post-incident audit trail requirements.
Vendors with the strongest AI governance incident response support included IBM OpenPages (which supports AI incident tracking integrated with enterprise risk and compliance workflows), ServiceNow AI Governance (which provides AI incident case management with regulatory notification workflow support), and Credo AI (which offers model behavior monitoring that supports detection of model drift and output quality degradation before they produce customer harm).
The report found that most AI governance platforms lag significantly on the detection side of incident response — they support documentation and response workflows but do not provide the behavioral monitoring needed to detect AI governance incidents before they are reported by customers or regulators. Vendors including Arthur AI and WhyLabs, focused specifically on model monitoring, scored highest on detection capability but showed weaker integration with the governance workflow tools needed for the response phases.
The gap between detection-focused monitoring vendors and governance workflow vendors is a significant architectural challenge for enterprises building AI incident response capabilities. Few enterprises have integrated these two categories into a unified AI IR capability.
The full vendor rankings are in the 2026 Stackcurve AI Governance CURVE™ Report — free to download.
The Gap Most Buyers Miss
Most enterprise incident response programs are built around cybersecurity incidents and have not been extended to cover AI governance incidents. The categories are different, the detection mechanisms are different, the notification requirements are different, and the remediation options are different. Treating AI governance incidents as a subtype of cybersecurity incident produces responses that address the wrong problem.
The four types of AI governance incidents:
Model output incidents — Hallucination causing customer harm, biased output in a regulated decision, factually incorrect information in a high-stakes context (medical, legal, financial). The Air Canada case is the archetype. Model output incidents may affect thousands of interactions over an extended period before detection, making scope assessment significantly more complex than a point-in-time cybersecurity breach.
Data incidents — Unauthorized use of customer data for model training, data exposure through model output (a model that was trained on sensitive data and reproduces it in outputs), training data breach affecting model integrity. Data incidents in the AI context may have regulatory notification requirements under GDPR, CCPA, and sector-specific regulations even when no cybersecurity breach occurred.
Compliance incidents — Discovery that a deployed model meets the EU AI Act's high-risk AI system classification without the required conformity assessment, bias audit failure triggering regulatory inquiry, regulatory investigation of AI system operation. Compliance incidents are often discovered through external inquiry rather than internal monitoring, making the first notification the trigger for the incident response process.
Operational incidents — Model drift causing systematic decision quality degradation, unauthorized model update changing system behavior, model performance failure in production that affects business operations. Operational incidents are the most detectable through monitoring but are frequently not connected to AI governance incident response procedures — they are treated as engineering incidents rather than governance incidents, and the governance implications (documentation updates, regulatory notification assessment, affected decision review) are missed.
The AI IR framework — phase by phase:
Detection — How does the organization learn about an AI governance incident? The three detection paths are: customer complaint or media report (reactive), automated behavioral monitoring alert (proactive), or regulatory or legal inquiry (forced). Most enterprises currently rely almost entirely on the first and third paths. Building monitoring capability for model output quality, bias metrics, and behavioral drift is the investment that shifts detection from reactive to proactive.
Containment — Unlike cybersecurity incidents, AI governance incident containment does not always mean taking the system offline. Containment options include: disabling specific features (a model capability that is producing problematic outputs), routing affected query types to human review, adding output disclaimers, reducing scope of deployment (removing access from certain user groups or use cases), or full system suspension. The right containment response depends on the incident type, severity, and the operational cost of each option.
Assessment — Scope quantification is the most complex phase of AI governance incident response. How many decisions were affected? Which customers, over what time period? What was the business impact — financial liability, regulatory exposure, reputational harm? For model output incidents with extended timelines, scope assessment may require log analysis covering months of operation.
Notification — Regulatory notification requirements for AI governance incidents are different from cybersecurity breach notification. EU AI Act serious incident reporting: 15-day timeline, market surveillance authority. GDPR breach notification: 72-hour timeline for breaches affecting personal data. Customer notification: determined by harm assessment and legal counsel. Board notification: determined by materiality threshold established in board AI risk reporting procedures. Each notification stream has different content requirements and audiences.
Remediation — Model retraining or replacement, output filter deployment, process redesign to add human review, governance control updates, policy revision, vendor remediation if the model is third-party. Remediation for AI governance incidents frequently requires changes to governance processes as well as technical fixes — the model behavior is a symptom; the governance gap that allowed the deployment without adequate controls is the root cause.
Questions Your Buying Team Should Be Asking
1. Do we have documented AI incident response procedures, separate from our cybersecurity incident response procedures?
If the answer is no, this is the highest-priority gap to close before any AI governance incident occurs. The procedures need not be comprehensive on day one — a documented detection path, a defined escalation chain, a regulatory notification assessment process, and a basic containment decision tree are sufficient to avoid the worst failure modes of undocumented response.
2. How would we detect an AI governance incident today — and how long would it take?
Walk through each of the four incident types and identify your current detection path for each. For most enterprises, the honest answer for model output incidents and compliance incidents is "we would find out from a customer or regulator." That is a detection gap with measurable business risk. Automated behavioral monitoring for the AI systems with the highest potential for customer harm is the targeted investment that addresses this gap.
3. Who is the designated AI incident response owner, and what is the escalation chain?
AI governance incident response requires coordination across functions — engineering, legal, compliance, HR, communications, and business operations depending on incident type. A designated owner with clear authority to convene the right functions and make containment decisions is required. The owner is typically the AI governance committee chair or a delegated incident commander role.
4. What are our regulatory notification obligations for AI governance incidents, and have we mapped them to specific incident types?
EU AI Act serious incident reporting, GDPR breach notification, sector-specific requirements (financial services, healthcare), and state AI legislation notification requirements all apply to different incident types with different timelines. Legal counsel should have produced a regulatory notification matrix for AI incidents before the first incident occurs, not during it.
5. Have we conducted a tabletop exercise for an AI governance incident in the last 12 months?
Tabletop exercises for cybersecurity incidents are standard practice. Tabletop exercises for AI governance incidents — working through a scenario where a deployed model produces harmful output and the response team must execute detection, containment, assessment, and notification — are rare. The first tabletop exercise reliably surfaces gaps in procedure, ownership, and tooling that are much cheaper to fix in a tabletop than in a live incident.
The Stackcurve Take
AI governance incident response is the governance function that most enterprises have not built and most urgently need. The detection-to-remediation sequence is more complex than cybersecurity incident response, the regulatory notification requirements are different and less familiar, and the scope assessment for model output incidents that have been occurring undetected for months is analytically demanding in ways that point-in-time breach analysis is not.
The Air Canada case, the Samsung incident, and the growing number of AI-related regulatory inquiries in financial services and healthcare share a common feature: they were all foreseeable incident types that the affected organizations had not built response procedures for. The investment in AI incident response planning is the investment in not discovering your governance gaps during a live incident with a regulatory clock running.
The 2026 Stackcurve AI Governance CURVE™ Report covers AI incident response frameworks, model behavioral monitoring platforms, and the AI governance incident case management tools that enterprises are using to build detection and response capability before the incident. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.