An AI incident evidence playbook using OECD reporting criteria, NIST incident response guidance and AI Incident Database methodology. It separates containment, reconstruction, uncertainty and reporting, with a sourced chart and a practical evidence-package illustration.
At a glance
Key findings
- Connect configuration, context, original output, downstream action, observed consequence and custody in one case record.
- Containment can be justified before causation is settled; record the protective decision separately from claims about confirmed harm.
- The OECD reporting framework narrowed 88 candidate criteria to 29 selected criteria. Those counts describe reporting design, not incident frequency.[1]
- Treat a replay as a new experiment and identify unavailable original state instead of silently reconstructing it.
- Public incident collections have different definitions and collection methods; several reports do not necessarily represent several incidents.[5][7]
Start with what happened and what is still unknown
An AI incident investigation often begins with a fragment: a screenshot of an answer, a user complaint, or an unexpected downstream action. That fragment can justify immediate attention, but it rarely establishes the entire causal chain. Start by recording what was observed, when it was reported, which capability was involved, and what consequence is known. Preserve the original report separately from the team's interpretation. The first record should make uncertainty visible rather than force an incomplete event into a confident technical explanation.
Terminology affects what gets counted and escalated. The OECD's 2024 definitions distinguish actual harm associated with an AI system from a hazard that could plausibly lead to such harm.[2] The AI Incident Database uses its own editorial concepts, including reports, incidents, variants, and issues, and can include alleged harms or near harms.[5] These are useful frameworks with different scopes. Do not assume that a database entry establishes confirmed harm, that several reports are several incidents, or that an internal event label determines an external reporting obligation.
Consider a hypothetical assistant that produces an incorrect account instruction. The response itself is an observation. Whether a person acted on it, whether the application executed it, and whether harm followed are additional questions. The team may need to restrict the capability before all those questions are answered. Containment can be justified by a plausible consequential failure without claiming that every feared consequence occurred. Keep the operational decision and the factual status of the investigation connected but distinct.
NIST SP 800-61 Revision 3 places incident response within broader cybersecurity risk management, while OWASP's GenAI incident response guidance addresses AI-specific preparation and response concerns.[4][3] The practical extension is an evidence plan that follows the whole application. It should connect the configuration, information available to the model, original output, consuming operation, and observed consequence. A saved prompt is one part of that plan, not a complete explanation of what the system did.
Contain the capability while preserving its state
Choose containment according to the affected capability. The team might disable an automatic consumer, stop promotion of a suspect model revision, restrict an input source, or return to a reviewed manual workflow. Record the action, time, scope, and responsible operator. Avoid treating a model shutdown as the only available response when the consequential boundary is a downstream component. Conversely, disabling the visible interface may leave background workers or queued requests active. Identify the paths that can still produce the unwanted effect.
Preserve relevant state before routine changes remove it, when doing so is compatible with immediate safety and access requirements. Capture the application and model identifiers actually available, prompt and policy revisions, deployment configuration, and relevant request or job identifiers. If the service uses a provider alias, record that fact and any response metadata. Do not replace it with an assumed model version. The evidence should describe what the system exposed at the time, including gaps that limit later reconstruction.
Containment itself changes the environment. A rollback may replace configuration, a worker restart may discard memory, and a queue purge may remove pending requests. Those actions can still be necessary. The incident record should state what was preserved, what was changed, and why. OWASP's response guide and NIST's incident-response framework support preparation and coordinated handling; they do not require an investigator to delay urgent containment indefinitely in pursuit of a perfect snapshot.[3][4]
Plan the collection path before an incident. Identify which teams can access provider records, deployment history, application traces, and customer reports. Establish controlled storage for evidence and a working view that avoids unnecessary exposure of sensitive payloads. If volatile cloud state matters, connect the AI plan to the broader forensic procedure. An evidence request that depends on an unavailable engineer or an unknown retention setting may arrive too late, even when the organization has extensive logs elsewhere.
Build the minimum connected evidence package
The illustration below organizes the case around six connected evidence leaves. Configuration identifies the system and policy revision. Context identifies the input and information supplied to the model. Output preserves the original response and available generation record. Action records what the consumer or user did next. Consequence records the observed impact and supporting evidence. Custody records who collected and handled the material. These are conceptual categories for a case package, not a claim that every event will provide all six.
The links matter as much as the contents. A prompt captured from one request and an error from another do not establish a single causal chain simply because they occurred close together. Use stable request, job, session, or correlation identifiers where available, and explain the matching method when they are absent. Preserve original timestamps and their time zones. A reconstructed sequence should distinguish direct linkage from temporal association so later reviewers can assess how much confidence the evidence supports.
For context, retain references to the actual supplied material where authorized and feasible. A document's current contents may differ from the version retrieved during the event. A source identifier without a revision can therefore leave an important gap. For output, preserve the original bytes or an appropriately controlled original record before sanitizing or summarizing them for analysis. A screenshot may help establish what a user saw, but it can omit metadata, truncation, hidden transformations, or the downstream operation.
Treat collected content as untrusted. Model output and retrieved documents may contain executable markup, misleading instructions, or sensitive data. Evidence viewers should not automatically execute or follow that content. Provide safe rendering and restricted access while preserving an authorized original. OWASP's response guidance and research from AI Incident Database editors both emphasize the complexity of AI evidence and uncertainty.[3][6] The package should help reviewers inspect those limits, not turn an incident payload into a new execution path.
The connected evidence package
Conceptual evidence package proposed by Cloud Security Desk. Preserve only authorized evidence and identify unavailable artifacts explicitly.
Source. Cloud Security Desk conceptual synthesis, 2026-08-28, informed by OWASP, NIST, AI Incident Database research authors. [3][4][6]
Method. Conceptual design, not measured data. Unit: process steps or control relationships; no numeric scale. Scope: An incident case linking evidence artifacts and recorded unknowns. Limits: Conceptual evidence package proposed by Cloud Security Desk. Preserve only authorized evidence and identify unavailable artifacts explicitly.
Accessible table and figure data
| Evidence leaf | Minimum identity | Question it supports |
|---|---|---|
| Configuration | Model, application and policy revision | Which system was involved |
| Context | Captured input and retrieval references | What information was available |
| Output | Original response and generation record | What the system produced |
| Action | Consumer operation and result | What happened downstream |
| Consequence | Observed impact and supporting report | What harm is established |
| Custody | Collector, time and access record | How evidence was handled |
| Evidence leaf | Minimum identity | Question it supports |
|---|---|---|
| Configuration | Model, application and policy revision | Which system was involved |
| Context | Captured input and retrieval references | What information was available |
| Output | Original response and generation record | What the system produced |
| Action | Consumer operation and result | What happened downstream |
| Consequence | Observed impact and supporting report | What harm is established |
| Custody | Collector, time and access record | How evidence was handled |
Record what cannot be reconstructed
Some state will be unavailable. A hosted model may have changed, a retrieval source may have been overwritten, or a logging policy may intentionally exclude sensitive prompt content. Record the missing artifact, why it is unavailable if known, and which conclusions the gap prevents. Unknown is a meaningful status. It should not be silently converted into a benign value, an inferred model version, or a reconstructed prompt presented as if it were the original request.
Reproduction is a separate experiment. Replaying a preserved input may help test a hypothesis, but a matching output does not prove that every original condition was identical. A different output does not disprove the report. Sampling, provider behavior, context assembly, configuration, and downstream state can affect the result. Preserve the replay configuration and label its outputs as new evidence. The original event and the controlled reproduction should remain distinguishable in both the timeline and the case narrative.
Training and deployment history can narrow some gaps. If the behavior appears after a fine tuning update, identify the training snapshot and model artifacts involved without assuming that the update caused it. A changed parser, prompt, retrieval source, or evaluator may provide another explanation. NIST's Generative AI Profile emphasizes documenting evaluation context and limitations.[8] Apply the same discipline to the investigation: identify what the evidence supports, what remains plausible, and which hypotheses can be tested safely.
Use the gaps to improve the future evidence plan, with restraint. The answer to missing prompt content is not automatically to log every future conversation. Decide which fields, hashes, revision identifiers, and selectively retained artifacts are necessary for the supported workflow. Weigh that need against privacy, access, and retention constraints. A well-designed evidence record can improve reconstruction without creating an unrestricted collection of sensitive material. Document the tradeoff so investigators understand why a particular artifact may legitimately remain unavailable.
A reporting framework is a selective view of the event
A reporting framework is a selective representation of an event. The OECD's February 2025 report describes an initial pool of 88 criteria and a resulting set of 29 across eight dimensions.[1] The chart below reproduces counts from Table 2.1 and Box 2.2. It compares candidate and selected criteria, not incidents. Incident metadata has 14 candidate and nine selected criteria; harm details has 17 and four. The remaining pairs are shown in the accessible table and downloadable aggregate data.
Those counts do not measure the importance of a dimension, how often information is available, or how much work an investigation requires. The selected data-and-input count of one does not mean that an investigator needs only one artifact from the input path. It reflects the structure of this common reporting framework. Likewise, 29 criteria is not a universal list of legally required fields or a guarantee that a report contains enough evidence to establish causation. Keep the reporting schema separate from the underlying case package.
For an internal implementation, maintain a richer controlled evidence record and produce the appropriate reporting view from it. Each report field should link to supporting evidence or carry an explicit unknown status. If the event date is uncertain, do not substitute the publication date of a news story without saying so. If several sources describe the same event, preserve their relationships rather than incrementing an incident count for each article. The AI Incident Database editor guide makes these distinctions important to its own curation process.[5]
Do not infer population risk from the growth of a public incident collection. The OECD monitor describes media retrieval and classification as part of its methodology, including changes to the collection process.[7] Changes in reporting, indexing, coverage, or classification can affect observed counts. Without a relevant exposure denominator and consistent collection method, a rising database total is not a direct estimate of the probability that a deployed system will cause harm. Use public collections to identify cases and questions, with their methodology attached.
The OECD reporting framework selected 29 criteria
Original adaptation of OECD February 2025 Table 2.1 and Box 2.2. Counts are reporting criteria, not incident rates, risk weights or universal legal requirements.
Source. Source checked 2026-08-28. Towards a common reporting framework for AI incidents. Table 2.1 on printed page 14 (PDF page index 13), Box 2.2 on printed page 16 (PDF page index 15). [1]
Method. Original aggregation by Cloud Security Desk. Source version February 2025 publication, DOI 10.1787/f326d4ac-en. Unit: reporting criteria. Scope: OECD AI Papers No. 34, February 2025, initial pool and resulting common reporting framework. Method: Transcribe eight candidate counts from Table 2.1 and eight selected counts from Box 2.2. Normalize Metadata dimension to Incident metadata and abbreviate Other information about this incident. Validate column totals 88 and 29. No percentages or inferred importance weights. Limits: Schema composition, not incidents, compliance coverage, risk severity, field burden or frequency of harm. Selected criteria are not a universal list of legally required fields. This is an adaptation of an original work by the OECD. The opinions expressed and arguments employed in this adaptation should not be reported as representing the official views of the OECD or of its Member countries.
Accessible table and figure data
| Reporting dimension | Candidate criteria | Selected criteria |
|---|---|---|
| Incident metadata | 14 | 9 |
| Harm details | 17 | 4 |
| People and planet | 10 | 3 |
| Economic context | 11 | 4 |
| Data and input | 10 | 1 |
| AI model | 15 | 3 |
| Task and output | 5 | 2 |
| Other information | 6 | 3 |
| Reporting dimension | Candidate criteria | Selected criteria |
|---|---|---|
| Incident metadata | 14 | 9 |
| Harm details | 17 | 4 |
| People and planet | 10 | 3 |
| Economic context | 11 | 4 |
| Data and input | 10 | 1 |
| AI model | 15 | 3 |
| Task and output | 5 | 2 |
| Other information | 6 | 3 |
Keep chronology and attribution honest
Build a timeline that distinguishes event time, detection time, reporting time, and collection time. These may differ substantially. Preserve the precision the evidence actually supports: a date-only source does not justify an invented minute, and an approximate recollection should remain approximate. When clocks disagree, record the discrepancy and the method used to align events. A clean-looking timeline can be misleading if uncertainty was removed merely to make the sequence fit a narrative.
Separate observation from attribution in the case notes. The application emitted a particular response, a downstream service attempted an operation, and a customer reported an effect are observations with their own supporting records. The claim that the model caused the effect may require additional evidence. Research by AI Incident Database editors discusses uncertainty around causation, harm, and technical details.[6] That uncertainty is a reason to qualify claims and seek better evidence, not to collapse every ambiguous report into either confirmed failure or dismissal.
Severity should follow the organization's established incident process and the observed or credibly threatened consequence. A highly unusual model response may have limited impact if a consumer rejected it. An ordinary-looking response may be consequential if it changed an important record. Preserve both the attempted action and the enforcement outcome. This allows the response team to recognize a prevented event without reporting the prevented consequence as actual harm or overlooking a control weakness because no loss has yet been confirmed.
Use hypothesis notes that can be revised. State the proposed explanation, supporting observations, contrary evidence, and next test. If new information changes the conclusion, retain the earlier version and record why it changed. Public reports and internal summaries should not imply that the first plausible explanation was established from the start. A transparent revision history is especially useful when provider information arrives later or when a reconstructed test reveals that the application, rather than the model, transformed the output in a consequential way.
Share the report without publishing the sensitive payload
Prepare different views for different audiences. Responders may need controlled access to original payloads and technical identifiers. A leadership update may need the affected capability, known consequence, containment status, and unresolved decisions. A public report may need a carefully redacted narrative and reproducible non-sensitive evidence. These views should remain linked to the same case record, but they do not need to expose the same material. Broad distribution is not a substitute for evidence quality.
Redaction should preserve the meaning of the claim. If removing a field changes whether the output appears authorized or whether two events can be linked, explain that limitation in the shared version. Keep an authorized original and a record of the transformation where policy permits it. Do not publish credentials, personal information, or an executable payload merely to make an incident vivid. A safe synthetic illustration can explain a failure class, provided it is clearly labeled and never presented as the original event evidence.
External reporting decisions require the applicable organizational, contractual, and jurisdictional process. The OECD framework supports common terminology and structured reporting; it does not determine every obligation for a particular organization.[1][2] Route those decisions to the responsible personnel and record the basis for what is shared. This article supplies an evidence design, not a legal reporting deadline or a classification that overrides the organization's established process. The technical team should provide accurate facts and limits for that decision.
When citing a public incident collection, follow the report back to its underlying sources. A database entry can organize allegations and related coverage without independently confirming every technical detail. Preserve the source date and status, and distinguish a later correction from the original account. The OECD monitor and AI Incident Database document different collection and editorial methods.[7][5] Their records can inform investigation and learning, but the case narrative should not erase those methods or turn an indexed claim into stronger evidence than the source provides.
Require evidence before restoring the affected capability
Restoring the capability requires evidence about the proposed operating state. Identify which boundary failed or remains uncertain, what changed, and how the change was evaluated. If the original cause is unresolved, the team may choose a restricted mode whose enforced limits remove the consequential path. A return to service should state that narrower scope. It should not imply that the investigation established a root cause merely because operations needed a workable recovery decision.
Carry the incident into release acceptance. Add a regression case that represents the observed failure where appropriate, but also examine the assumption that allowed it. A missing output validator needs an enforcement change. A model alias that changed without notice may need a different review trigger or operating restriction. A lost evidence link may require instrumentation. NCSC's lifecycle guidance treats operation and maintenance as continuing security responsibilities, and NIST's Generative AI Profile supports evaluation in the actual use context.[9][8]
Verify the recovery path itself. A fallback model, manual process, or disabled consumer can alter permissions, data destinations, and user expectations. Confirm that the approved restrictions are implemented and that monitoring can detect departures from them. Preserve the recovery configuration and test evidence in the case record. The team should be able to explain why this operating state is acceptable even if it cannot reconstruct every detail of the original event. That explanation is more useful than a generic incident-closed label.
Close the evidence loop by recording unresolved questions, retained artifacts, access responsibilities, and review triggers. A later provider disclosure or related event may change the interpretation, so keep the case discoverable under the relevant system and revision identifiers. The final record should connect what was observed, what was done, and what supports continued operation. It does not need to manufacture certainty. Its value is that another responder can inspect the chain, recognize its limits, and use it when the next event challenges the same capability.
Method and provenance
Reviewed the OECD 2024 definitions and February 2025 reporting framework, NIST SP 800-61 Revision 3, OWASP GenAI incident response guidance, AI Incident Database editorial methodology and lifecycle guidance on August 28, 2026. The chart transcribes Table 2.1 and Box 2.2 of the OECD reporting paper and validates totals of 88 and 29. The evidence-package illustration is an original conceptual design. The official OECD definitions PDF was verified accessible after its landing page returned an error.
No named incident was investigated and no production evidence was collected for this article. The account-instruction scenario is hypothetical. Reporting-criteria counts do not measure incident rates, risk severity or legal compliance. The source tables were inspected through the web PDF reader; no local source-file hash is claimed. Reporting obligations require the applicable organizational and jurisdictional process.
AI assistance. AI assisted source research, drafting, the checked transcription of published aggregate counts and original visual preparation. Definitions, source scope and uncertainty statements were checked against the cited evidence.
Published under the Cloud Security Desk organizational byline. Read the practitioner guide policy.
References
- Towards a common reporting framework for AI incidents OECD. Accessed .
- Defining AI incidents and related terms OECD. Published . Accessed .
- GenAI Incident Response Guide 1.0 OWASP. Published . Accessed .
- Incident Response Recommendations and Considerations for Cybersecurity Risk Management NIST. Published . Accessed .
- AI Incident Database Editor Guide AI Incident Database. Accessed .
- Lessons for Editors of AI Incidents from the AI Incident Database AI Incident Database research authors. Published . Accessed .
- Overview and methodology of the AI Incidents and Hazards Monitor OECD.AI. Accessed .
- Generative Artificial Intelligence Profile NIST. Published . Accessed .
- Guidelines for secure AI system development UK NCSC and international partners. Published . Accessed .