Nothing Broke, And That Is The Problem

Incident response frameworks share an assumption so basic it is rarely written down: that somebody will notice. An alert fires, a system returns errors, a customer complains, a process stops. The characteristic failure of an AI workflow in a finance function satisfies none of those conditions, and an organisation that has copied a security incident playbook has copied a structure whose first step does not occur.

The Declaration Problem

The gap this article exists to name, and it precedes everything in a conventional playbook. This section is our own analysis, building on findings developed elsewhere in this series.

Security incident response begins at detection. Something triggers, and the process starts. Every subsequent step, containment, eradication, recovery, review, presupposes a moment at which the organisation became aware.

Now consider the failure modes this publication has described in the preceding articles. Quiet degradation, in which a system becomes slightly worse without producing errors. Faithfulness hallucination, in which a summary contains a clause that was not in the document. Silent provider updates, in which behaviour changes with no artefact in the organisation's records. Automation bias, in which the human reviewer accepts outputs that appear normal.

None of those generates a detection event. There is no alert, no outage, no failed transaction. A finance function running an AI workflow badly for four months and one running it well look identical from the outside, and frequently from the inside.

So the first thing an organisation needs is not a response procedure but a declaration rule: a definition of what constitutes an AI incident in the absence of anything breaking. Candidates include a scheduled evaluation falling below a threshold, a drift signal correlating with a performance drop, a downstream error traced to an AI-produced input, and an external party identifying a defect in delivered work.

Without such a rule, the incident response programme will only ever handle the small subset of AI failures that happen to look like conventional IT failures, which is not where the risk in a finance workflow sits.

The Four Artefacts

What an investigation actually requires, and the most operationally useful sentence we found in the practitioner literature.

AI forensics is described as the discipline of collecting, preserving, and analyzing AI-specific evidence, being prompt logs, model state, retrieval context and tool call history, in order to reconstruct what an AI system did and why during an incident[1].

Those four categories are worth taking individually, because a finance function can audit its own position against them in an afternoon.

Prompt logs. The actual input sent to the model, including the system prompt and any assembled context, not merely the user's typed question. Without this an investigator cannot distinguish a model failure from a prompt construction failure.

Model state. Which model, which version, and which inference parameters were in effect. This is the configuration record that the drift discussion in this series identified as usually absent, and without it the question of whether a provider update caused the failure cannot be answered.

Retrieval context. Which documents were retrieved and supplied to the model. For a grounded finance workflow this is often the decisive artefact, because an output can be perfectly faithful to a wrong document, and that failure is invisible unless you know what was retrieved.

Tool call history. Which systems the workflow queried or acted upon, with what arguments and what returns.

Our observation is that most Canadian finance functions retain the output and nothing else. The output is the one artefact that cannot, on its own, explain itself, and an investigation possessing only the output is reduced to inference about a system whose behaviour is not deterministic.

Retention Cannot Be Retroactive

The point that makes the preceding section urgent rather than merely informative, and it is our own analysis.

Financial records have a comfortable property: they persist by default. An invoice from three years ago exists because invoices are kept, and an auditor can request one without anyone having anticipated the request.

AI execution artefacts do not behave that way. Prompt assembly is transient, retrieval results are typically discarded after the response is generated, and inference parameters are runtime configuration rather than recorded data. If logging was not enabled at the time, the information is not recoverable from anywhere, because it never existed in a durable form.

Two consequences follow that finance leaders should weigh explicitly.

Every day an AI workflow runs without instrumentation is a day that cannot later be investigated. That is a different risk shape from most control weaknesses, which can be remediated going forward and tested retrospectively.

And the retention decision has to be made by people who will not be the ones investigating. The finance leader deciding whether logging is worth its storage cost is deciding, on behalf of a future investigator, whether an answer will be available. Framed that way the cost comparison usually resolves quickly, since storage is cheap and the alternative is an unanswerable question in front of a client, an auditor or a regulator.

A qualification worth stating: logs of this kind may contain client confidential information, personal information and privileged material, so the retention design has to satisfy privacy and confidentiality obligations rather than simply maximising capture. That is a design constraint, not a reason to retain nothing.

A Single Prompt, Thousands Of Decisions

The characteristic that breaks the timing assumptions in a conventional playbook.

Practitioner guidance frames the requirement as playbooks that operate at AI-speed, where a single prompt can produce thousands of bad decisions in seconds, rather than at the ticket-queue pace a traditional security operations centre was built to handle[1].

The finance translation is about blast radius rather than latency. A defective prompt template, a wrongly configured threshold or a corrupted retrieval index does not produce one bad output. It produces every output the workflow generates until someone stops it, and in a batch process that can be an entire period's transactions.

Two implications, offered as our own analysis.

The containment action for an AI workflow is usually suspension rather than repair, because the alternative is continuing to generate defective work while the diagnosis proceeds. That decision needs a named owner and pre-authorisation, since asking permission is itself a delay measured in the same units as the damage.

And the scope question, meaning which outputs were affected, requires the ability to identify every item processed under a given configuration between two timestamps. That is a query most finance systems cannot answer, because they record who approved an item rather than what produced it. Recording the configuration identifier on each output makes the scoping question answerable in minutes rather than weeks.

Which Taxonomy Actually Covers Reality

The most rigorous evidence available in this area, and it addresses a question practitioners have been answering by preference rather than data.

A study notes that the transition from generative to agentic AI has produced a rapid proliferation of failure taxonomies, with three now dominant: the OWASP Top 10 for Agentic Applications 2026, the Microsoft AI Red Team taxonomy of failure modes in agentic AI systems, and the NIST AI Risk Management Framework. It observes that practitioners, regulators and researchers choosing among them lack empirical evidence about how well each characterizes the failures observed[2].

The authors coded 131 agent-related incidents drawn from the AI Incident Database, spanning 2014 through 2026, against all three frameworks independently. The frameworks jointly cover 96.9 percent of the sample but differ substantially in per-framework coverage, at 79.4 percent, 93.1 percent and 96.2 percent respectively, with intra-rater reliability in the substantial to near-perfect range at Cohen's kappa values of 0.703, 1.000 and 0.954[2].

Three things make this worth attention.

The seventeen-point spread between the lowest and highest coverage is material. An organisation adopting the least comprehensive of the three has, on this sample, a framework that fails to characterise roughly one incident in five.

The reliability statistics matter methodologically. Coding incidents against a taxonomy is a judgment exercise, and a kappa in the substantial to near-perfect range indicates the coding was reproducible, which is what distinguishes this from an opinion about which framework seems better.

And the joint coverage figure of 96.9 percent, exceeding every individual framework, means the frameworks are complementary rather than substitutable. An organisation using one is not merely using a smaller version of another; it is missing categories the others capture.

The Three Percent

The residue, which we think is the more interesting finding.

If three frameworks jointly cover 96.9 percent of a coded sample[2], then roughly three percent of real, documented agent incidents were not characterised by any of the three dominant taxonomies.

We are careful here: we have the abstract's coverage figures but not the paper's discussion of what the uncovered incidents involved, and we will not speculate about their content.

What can be said is structural. A classification framework is built from known failure modes, so novel failures are the ones least likely to be covered, and novelty is exactly the property that makes a failure dangerous. The uncovered remainder is therefore not a rounding error to be ignored but the category most likely to contain the failures an organisation has not anticipated.

The practical instruction that follows is that an incident classification scheme needs an explicit unclassified category that is reviewed rather than forced into the nearest available bucket. An organisation that requires every incident to map to a framework code will produce a clean taxonomy and lose exactly the signal it most needs, because the pressure to classify converts a novel failure into a familiar-looking one.

The Incident Database And Its Thin Layer

The shared evidence base, and an important caveat about its depth.

The AI Incident Database, maintained by the Responsible AI Collaborative, catalogs over 3,000 AI incidents, providing a growing evidence base for understanding AI failure patterns and developing response strategies[3].

Within it, the Goals, Methods and Failures taxonomy classifies the same underlying incidents but focuses on failure cause analysis by interrelating the system's goals, its methods, and their technical causal factors for the observed failure events[4].

The caveat is scale. At the time of the cited writing, 188 incidents in the database contained classifications in that taxonomy[4], against a catalogue exceeding three thousand.

So the resource that offers genuine causal analysis covers a small minority of recorded incidents, and the remainder are catalogued rather than analysed. The same source notes that the efforts behind cataloguing incidents and applying these taxonomies present operational challenges beyond the scope of producing research papers[4], which is a candid acknowledgement that the analysis is labour-limited.

For a Canadian business the practical reading is that the public incident record is broad and shallow. It is useful for establishing that a category of failure occurs, and considerably less useful for establishing how often or why, which are the questions a risk assessment actually needs.

Confidence Modifiers

A methodological device from the incident literature that finance functions should borrow.

The taxonomy's structure and methodology encourage considering what is known or observed of the system's goals, methods and causal factors, along with what is potential or likely, guiding how to apply and interpret expert technical knowledge about AI failures in the presence of uncertainty. These confidence modifiers are described as relevant when the incidents in question are based on public but incomplete third-party reports[4].

The idea is that a classification records not only a conclusion but the epistemic status of that conclusion: this is what we observed, this is what we infer, and these are distinguished in the record.

The application to an internal post-incident review is direct and, in our assessment, underused. Most incident reports read as narratives of established fact, because a report expressing uncertainty feels incomplete. But an AI incident investigated without full artefacts, which per the retention discussion above will often be the case, contains a great deal of inference.

A report that distinguishes observed from inferred is more useful later, particularly if the same failure recurs, because the second investigation can test the first one's inferences rather than inheriting them as facts. It is also more defensible if the report is ever read by a party with an interest in what the organisation actually knew.

The Public Record Is Biased

A methodological disclosure from one retrospective that generalises to the whole evidence base.

One published retrospective states its inclusion criteria explicitly: incidents counted are public AI failures with at least one of a disclosed regulator report, a press article in a major outlet, a vendor postmortem, or a responsible-disclosure publication. Private incidents, including ones the authors' team directly observed, are excluded by design, on the reasoning that counting only reportable events keeps the sample comparable across quarters and avoids weighting toward what any single observer happened to see[5].

That is a defensible methodological choice and the transparency is creditable. It also means the resulting distribution describes incidents that became visible, not incidents that occurred.

The selection pressure runs in a specific direction, and this is our own analysis. Failures that are dramatic, that affect consumers, that involve identifiable harm, or that occur at organisations large enough to attract press coverage are over-represented. Failures that are quiet, internal, commercially embarrassing, or that occurred at a mid-sized private business are systematically absent.

The second description matches the profile of AI failure in a Canadian finance function almost exactly. A firm that discovers its classification workflow has been mildly wrong for a quarter will not issue a press release, and the incident will not enter any database.

The conclusion is that a finance function cannot calibrate its own risk from published incident data, because the population it belongs to is the one the published data excludes. Internal incident recording is therefore not merely good practice; it is the only source of information about the failure modes that actually apply.

The Distribution Moves Faster Than Your Risk Cycle

An observation about cadence that has a direct governance consequence.

The same retrospective publishes on a quarterly cadence because the failure-mode distribution shifts faster than the annual reporting cycle classical risk frameworks assume, noting that categories which were negligible in the second half of 2025, specifically tool misuse and agentic prompt injection, are now meaningful shares of the dataset, while categories that dominated consumer narratives, such as chatbot personality drift, have largely receded. It concludes that a team operating on a one-year update cadence is making risk decisions on a model of the world that is already wrong[5].

We note this comes from a consultancy that sells incident response programmes, and the argument conveniently supports more frequent engagement. We report it because the underlying claim is checkable in principle and because the specific categories named are consistent with the direction of the broader literature.

The governance implication for a Canadian business is about the annual risk assessment, which is the standard cadence in most finance functions and is inherited from a world where the risk landscape moved slowly. An annual assessment of AI risk will spend much of its life describing a distribution that has moved.

The practical adjustment is not necessarily quarterly full reassessment, which most mid-sized firms cannot resource. It is a lighter quarterly review of whether the categories in the assessment still match observed reality, with full reassessment triggered when they do not.

The Cybersecurity Precedent

The comparison the incident literature itself draws, and what it suggests about where this is heading.

Incident reporting is a practice common in many other fields, from aviation to environmental monitoring, and the field with established incident reporting practices most relevant to AI is cybersecurity, as both are rooted in monitoring widespread digital technologies where software is associated with both tangible harms, such as compromised autonomous vehicle systems resulting in accidents, and intangible harms, such as compromised data storage resulting in disclosure of private information. Importantly, there exists a widely adopted practice to handle potential incidents shared by research, industry and government actors alike, realised in the Common Vulnerabilities and Exposures programme[4].

The CVE comparison is instructive because of what that programme provides: a shared identifier, so that two organisations discussing a vulnerability know they mean the same one, and a shared record that accumulates across the industry.

AI incident reporting has no equivalent in general use. There is a database, but no universal identifier scheme with the adoption CVE achieved, which means organisations cannot easily determine whether a failure they experienced has been seen elsewhere.

For a Canadian business the near-term consequence is isolation. When something goes wrong with an AI workflow, there is generally no way to check whether other users of the same model or vendor encountered it, which removes a diagnostic channel that exists as a matter of routine in software security. That argues for asking vendors directly whether a behaviour has been reported by others, and for treating a vendor's inability or unwillingness to say as itself informative.

A Disagreement About Timing

A conflict among sources that we report rather than resolve, because the disagreement is itself informative.

One source recommends blameless retrospectives within 48 hours of containment[6]. Another recommends a blameless post-incident review within one to two weeks of incident resolution, on the reasoning that AI incidents often have complex root causes spanning data, models, infrastructure and human processes, requiring thorough analysis[3]. A third specifies 100 percent post-incident report completion within five business days of incident closure, with blameless root cause analysis using a five-whys method[1].

Forty-eight hours, five business days, and one to two weeks are materially different commitments, and all three are presented as best practice.

Our reading, offered as analysis, is that they are answering different questions. A rapid retrospective captures recollection while it is fresh and identifies immediate corrective action, and its value decays quickly. A longer review permits actual root cause analysis of the kind the second source describes as necessary given causes spanning data, models, infrastructure and human processes.

The sensible resolution for a finance function is probably both: a short factual capture within days, recording what was observed while people remember it, and a considered analysis afterwards. That also fits the confidence-modifier discipline, since the early record is observation and the later one is inference.

What a firm should not do is adopt a 48-hour commitment it cannot meet, because a missed deadline in a documented procedure is worse evidence than a realistic deadline met.

Blameless, And Why It Matters More Here

A principle every source shares, with a reason specific to AI that we would add.

All three of the cited practitioner sources specify blameless review[1][3][6]. The general rationale is familiar from software reliability practice: if attributing fault to individuals is a possible outcome, people report less, and an organisation that learns less about its failures experiences more of them.

The AI-specific reason, which is our own argument, follows from the human factors literature this publication has examined. Automation bias and complacency occur in expert participants and cannot be prevented by training, and complacency arises from attentional conditions rather than from individual diligence.

That means an incident in which a reviewer accepted an incorrect AI output is, on the research, a predictable consequence of the system design rather than a failure of that person. A review that identifies the reviewer as the root cause has misidentified it, and will produce a corrective action, typically retraining or a reminder, that the literature indicates does not work.

So blamelessness here is not only a cultural preference that encourages reporting. It is a condition of getting the analysis right, because assigning cause to the individual terminates the inquiry before it reaches the attentional and design factors that actually produced the outcome.

The Metrics That Separate A Programme From An Email Thread

The measurement discipline, including one metric worth adopting verbatim.

One source specifies 100 percent post-incident report completion within five business days of closure with blameless root cause analysis, and zero repeat incidents with the same root cause across two consecutive quarters, observing that a repeat incident signals the prior review's corrective action was never implemented, and that trending such numbers quarterly is what separates an incident response program from a response email thread[1].

The repeat-incident metric is the one we would single out. Most incident programmes measure activity: how many incidents, how quickly closed, how many reports written. Those measure the process rather than its effect.

Repetition of the same root cause measures whether the process changed anything. It is difficult to game, it requires the causal classification to be recorded consistently, and it fails loudly when corrective actions are agreed and not implemented, which is the most common way incident programmes decay.

For a mid-sized Canadian firm this is achievable without tooling. A simple register recording each incident, its assigned cause, its corrective action, and whether that action was completed, reviewed quarterly for repeats, delivers most of the value.

The Regulatory Position

Where obligations sit, stated with care about jurisdiction.

Sources report that the EU AI Act requires providers of high-risk AI systems to report serious incidents to competent authorities, and that the NIST AI Risk Management Framework's Manage function includes incident response as a core activity, the framework being organised across four functions of Govern, Map, Measure and Manage[3][6]. Compliance obligations named alongside these include GDPR and ISO 42001[1]. Related resources include a knowledge base of adversary tactics and techniques targeting AI and machine learning systems modelled after an established security framework, and an open security project with several hundred pages of guidance on AI security threats, controls and privacy practices[3].

We report these as the sources state them and have not verified them against the instruments themselves, and note that both named regimes are foreign to Canada.

The Canadian position is that no general AI incident reporting obligation applies to most businesses, and that federally regulated financial institutions operate under OSFI's model risk expectations, which this publication addresses separately. The NIST framework is voluntary and is nonetheless the most commonly adopted reference structure in North American practice, which makes it a reasonable organising choice for a Canadian firm wanting a recognised framework without a regulatory mandate.

The forward-looking observation is the same one made in the drift article: commercial expectation tends to precede regulatory requirement. Clients, insurers and auditors are the parties most likely to ask a Canadian firm about AI incident handling in the near term.

Severity For A Finance Workflow

Adapting severity classification to the finance context, offered as our own analysis since the sources address security severity rather than professional work product.

Conventional severity scales are built around availability and confidentiality: how many users affected, how long, what data exposed. A finance workflow's severity turns on different axes.

Did defective output leave the organisation? An error caught internally is materially different from one embedded in a filing, a client deliverable or a statutory submission, because the latter engages correction and disclosure obligations rather than only rework.

Is the affected population identifiable? This returns to the scoping capability discussed above. An incident whose extent cannot be determined is more severe than one of known size, because the response must assume the maximum.

Is the output relied upon by a third party? Client, lender, regulator or auditor reliance changes the obligation profile substantially.

Is the period closed? An error discovered in an open period is a correction; the same error in a filed return or issued statement is a different matter with its own procedures and deadlines.

One source recommends treating regulatory exposure as a first-class component of the severity model rather than a downstream consequence[5], which is consistent with the above and worth adopting.

A Worked Case: The Incident Nobody Declared

A Canadian firm whose AI workflow extracts figures from client-supplied statements. The reconstruction illustrates the mechanisms rather than reporting a specific engagement.

In February a retrieval index is rebuilt. In May a client queries a figure in a deliverable. The figure is wrong, and on investigation the source document supplied to the model was the prior year's statement.

Nothing in the intervening three months constituted a detection event. No error was returned, no alert fired, no process stopped. On the declaration analysis above, there was no moment at which a conventional playbook would have started.

The investigation requires knowing which document was retrieved for each affected output, which is the retrieval context artefact[1]. If retrieval results were not logged, that information does not exist anywhere and cannot be reconstructed.

The scoping question, being which of the outputs produced between February and May are affected, requires identifying every item processed under the post-rebuild configuration. If outputs do not record a configuration identifier, the answer is every item in three months, and the response must assume the maximum.

Several deliverables have gone to clients, so on the severity axes above this is not an internal rework matter. And the reviewer who approved each output was, on the human factors research, behaving as the literature predicts rather than negligently, so a review naming the reviewer as root cause would misidentify the cause and prescribe a remedy the evidence says does not work.

Every difficulty here was determined months before the failure surfaced, by decisions about what to log and what to record.

What To Do

Write a declaration rule first. Define what constitutes an AI incident when nothing has broken: an evaluation below threshold, a drift signal with correlated performance drop, a downstream error traced to an AI input, or an external party finding a defect.

Enable the four artefacts now. Prompt logs, model state, retrieval context, tool call history. They cannot be captured retroactively, and every uninstrumented day is permanently uninvestigable.

Design retention against privacy and confidentiality obligations. These logs may contain client and personal information, which shapes the design rather than excusing the absence.

Stamp a configuration identifier on every output. It converts the scoping question from a three-month worst case into a query.

Pre-authorise suspension. Containment for an AI workflow is usually stopping it, and permission-seeking is a delay measured in the same units as the damage.

Keep an explicit unclassified category. Three frameworks jointly missed about three percent of coded incidents, and novel failures are the least likely to fit and the most important to see.

Record incidents internally regardless of severity. Published data excludes exactly the quiet internal failures a finance function experiences, so your own register is the only calibration source available.

Separate observation from inference in the report. Borrowing the confidence-modifier discipline makes the record testable later rather than inherited as fact.

Track repeat root causes quarterly. Repetition measures whether anything changed, which activity metrics do not.

Review category fit quarterly, not annually. Failure-mode distributions have shifted materially within single quarters.

The Limits Of This Analysis

Several caveats matter. The strongest source, the taxonomy coverage study, is a preprint on a research platform that had not completed peer review at the version accessed, and we have its abstract rather than its full methodology; we report its coverage and reliability figures as stated and did not examine its coding protocol or its discussion of uncovered incidents. Most remaining sources are commercial publications from vendors of security, incident response or AI transformation services, and one explicitly markets its own programme alongside the analysis we cite; all have an interest in organisations concluding they need such services. The AI Incident Database figures, the GMF classification count and the CVE comparison come from a preprint whose publication date precedes several developments discussed here. Regulatory characterisations of the EU AI Act, NIST AI RMF, GDPR and ISO 42001 are reported from secondary sources and not verified against the instruments, and the two named regimes are foreign to Canada. The declaration rule argument, the retroactivity analysis, the blast radius and scoping implications, the visibility bias argument, the blamelessness reasoning drawn from human factors research, and the finance severity axes are our own analysis rather than findings in the cited work. This article does not address prompt injection defence, red teaming, adversarial testing, vendor contractual notification terms, professional obligations on correcting issued work, or Canadian breach notification requirements where personal information is involved, several of which this publication treats separately. Nothing here is legal advice or a substitute for professional guidance on incident handling in a specific environment.

Related Reading

AI & Automation In Finance You Validated A System That No Longer Exists The monitoring that produces the detection signal this article's declaration rule depends on. AI & Automation In Finance The Records Exist But Cannot Be Joined A production AI system constantly creates a record of itself. Whether those records can be read together when an audit begins depends on a correlation... Compliance & Reporting The Log Is The Obligation: Privacy Breach Reporting Under PIPEDA And Law 25 The Canadian recording duty that applies where an incident involves personal information.

Frequently Asked Questions

Why can't I just use my security incident playbook?

Because its first step is detection, and the characteristic AI failure in a finance workflow produces no alert, no error and no outage. You need a declaration rule defining what constitutes an incident when nothing has broken, such as an evaluation falling below threshold or a downstream error traced to an AI-produced input.

What do I need to keep in order to investigate?

Four artefact classes: prompt logs, model state, retrieval context and tool call history. Most finance functions retain only the output, which is the one artefact that cannot explain itself. None of the four can be captured retroactively, because they are transient runtime information rather than records that persist by default.

Which failure taxonomy should I adopt?

Research coding 131 agent incidents found per-framework coverage of 79.4%, 93.1% and 96.2%, with joint coverage of 96.9%. The seventeen-point spread means the choice matters, and the joint figure exceeding every individual one means the frameworks are complementary rather than substitutable. Keep an explicit unclassified category for the residue.

Can I calibrate my risk from published incident data?

Not reliably. Published retrospectives exclude private incidents by design, counting only failures with a regulator report, major press coverage, a vendor postmortem or a disclosure publication. That systematically omits quiet internal failures at mid-sized private businesses, which is precisely the profile of AI failure in a Canadian finance function.

How quickly should the post-incident review happen?

Sources disagree: 48 hours from containment, five business days from closure, and one to two weeks from resolution are all presented as best practice. They likely answer different questions. A short factual capture while recollection is fresh, followed by considered root cause analysis, satisfies both, and a realistic deadline met is better evidence than an ambitious one missed.

What single metric is worth tracking?

Repeat incidents with the same root cause across consecutive quarters. Most programmes measure activity, which describes the process rather than its effect. Repetition measures whether corrective actions were actually implemented, and it fails loudly when they were agreed and forgotten, which is the most common way incident programmes decay.

References

1. PurpleSec. (2026, April 21). 23 AI Incident Response Terms Every Business Must Know, on AI forensics comprising prompt logs, model state, retrieval context and tool call history; playbooks operating at AI-speed where a single prompt can produce thousands of bad decisions in seconds; post-incident report completion within five business days with blameless five-whys analysis; the zero-repeat-root-cause metric; and named compliance regimes. Note: published by a security services vendor. purplesec.us/resources/ai-security-glossary/ai-incident-response
2. Coverage and Complementarity of Three Agentic AI Risk Taxonomies Across 131 Real World Incidents. Research Square preprint rs-10425736/v1, on the three dominant taxonomies, the absence of empirical evidence for choosing among them, the coding of 131 incidents from the AI Incident Database spanning 2014 to 2026, joint coverage of 96.9% against per-framework coverage of 79.4%, 93.1% and 96.2%, and Cohen's kappa values of 0.703, 1.000 and 0.954. Note: a preprint not peer reviewed at the version accessed; we accessed the abstract rather than the full methodology. researchsquare.com/article/rs-10425736/v1
3. AI Safety Directory. (2026, March 27). AI Incident Response: Planning and Playbooks for AI System Failures, on blameless post-incident review within one to two weeks given causes spanning data, models, infrastructure and human processes; the AI Incident Database maintained by the Responsible AI Collaborative cataloguing over 3,000 incidents; EU AI Act serious incident reporting; the NIST AI RMF Manage function; and related security knowledge bases. aisecurityandsafety.org/en/guides/ai-incident-response
4. Lessons for Editors of AI Incidents from the AI Incident Database. arXiv preprint 2409.16425, on incident reporting practice in aviation, environmental monitoring and cybersecurity, the Common Vulnerabilities and Exposures programme comparison, the Goals Methods and Failures taxonomy and its confidence modifiers, and the count of 188 incidents carrying that classification. Note: preprint; the counts predate later developments discussed here. arxiv.org/pdf/2409.16425
5. Digital Applied. (2026, May 11). AI Incidents H1 2026 Retrospective: Failure Modes Analysis, on inclusion criteria excluding private incidents by design, the quarterly cadence rationale, the shift of tool misuse and agentic prompt injection from negligible to meaningful shares and the recession of chatbot personality drift, the claim that an annual cadence produces decisions on an outdated model of the world, and treating regulatory exposure as first-class in severity. Note: published by a consultancy marketing incident response programmes alongside the analysis. digitalapplied.com/blog/ai-incidents-h1-2026-retrospective-failure-modes-analysis
6. UnderDefense. (2026, April 24). AI-Powered Incident Response: Use Cases, Frameworks, Tools, and Implementation Playbook, on blameless retrospectives within 48 hours of containment, the compliance considerations of explainability, automated decision accountability and audit trails for autonomous containment, and the NIST AI RMF four functions of Govern, Map, Measure and Manage. Note: published by a security services vendor marketing its own deployment offering. underdefense.com/blog/ai-incident-response

This article discusses incident response practice and is provided for general informational purposes. Its strongest source is an unreviewed preprint accessed at abstract level, and most remaining sources are commercial publications by vendors of related services. Regulatory characterisations are reported from secondary sources, unverified, and concern jurisdictions outside Canada. Nothing here is legal advice or a substitute for professional guidance on incident handling.