An AI incident record should separate evidence from explanation

When a deployed generative AI system produces a harmful, misleading or out of scope result, open an evidence record before the team argues about root cause. Capture the exact system and version, the observed output, the affected workflow, the exposure window, preserved logs, confirmed impact, containment decision and named owners. Put suspected causes in a separate hypothesis field until they are tested.

This article is for United States AI product owners, security teams, risk managers and operations leads who need a usable first record after an alert. It translates voluntary NIST guidance into a completed fictional incident record. The template is an editorial control design, not a NIST form, a legal notification test or proof that every recorded anomaly is an AI incident.

NIST AI RMF 1.0 is a voluntary framework. Its Manage function connects risk treatment with response, recovery and communication, while its Measure function calls for production monitoring and ways for users and affected communities to report problems and appeal outcomes. The Generative AI Profile adds suggested actions for incident monitoring, response plans, escalation, remediation, after action review and retention. S1 S2

The profile describes AI incidents in terms of AI development, use or malfunction contributing directly or indirectly to specified harms. An internal alert may not yet meet that description. Waiting for classification, however, can allow logs to rotate, prompts to disappear, index versions to change and affected records to become harder to find. The practical answer is to open a record at the signal stage, label its status honestly, and update it as evidence arrives.

An incident record should make a later reader able to reconstruct what was known at each decision point. Observed facts belong in one column. Explanations, even plausible ones, belong in another. This distinction reduces confirmation bias and protects the record when the first theory is wrong.

The record should not copy every prompt or user message into a widely accessible ticket. Preserve only what the response team needs, control access, record lawful handling decisions and link to protected evidence repositories. The right evidence boundary depends on the system, contracts, privacy obligations and the possible harm.

Northstar Outfitters is a fictional United States online retailer. At 14:10 Eastern Time on 13 October 2026, a customer reported that its generative AI returns assistant quoted a 15 day return period although the approved policy allows 30 days. The assistant uses a hosted language model and retrieves policy documents from an internal index.

The reviewed candidate rate is 52 divided by 612, which equals 0.084967 and rounds to 8.50 percent. The observed share of all chats in the window is 52 divided by 14,280, which equals 0.003641 and rounds to 0.36 percent. Those figures answer different questions.

The 8.50 percent figure describes confirmed faulty outputs inside the filtered candidate set. The 0.36 percent figure describes confirmed faulty outputs among all chats. Neither is a reliable incident probability or a complete error rate unless the filter sensitivity is known. If the filter missed paraphrases, translations or downstream copies, the true affected population could be larger.

The team should therefore retain the search expression, language coverage, sampling or full review method, reviewer instructions and unresolved data sources. A neat percentage without that lineage can create false confidence.

Stopping the whole AI service is not always the safest first action. A narrower fallback may protect users while keeping a necessary service available. The incident owner should record the available options, expected harms, authority, reversibility and evidence preservation effect. NIST guidance supports planned response, recovery, escalation and criteria for deactivation, but the organisation must set context specific risk tolerances and responsibilities. S1 S2

In the fictional record, the fallback blocks generative interpretation of the return period while preserving the chat channel. That is suitable only because the assistant has no autonomous refund authority and the fallback displays an approved policy. A system making consequential decisions or invoking external tools may need a broader disengagement.

A single successful retest does not show that the failure path is closed. Recovery evidence should cover the suspected mechanism, the affected workflow and the monitoring that can detect recurrence. For the fictional case, the obsolete document must be absent from retrieval, the index manifest must match the approved source set, the regression suite must pass, and a named owner must approve restoration.

After restoration, the team should reconcile customer remediation, complete the cause analysis, decide whether contractual or legal notifications apply, and run an after action review. The Generative AI Profile specifically links incident learning with updated response and disclosure processes and highlights logging, version history and metadata as useful incident information. S2

A record fails when it calls a hypothesis a fact, overwrites the first evidence snapshot, hides an unknown denominator, treats absence of a complaint as absence of harm, or closes after a model response looks correct once. It also fails when the ticket contains more personal or confidential data than the response team needs.

Do not make one severity score carry decisions it was not designed to make. Security, safety, privacy, contractual, customer and operational consequences may need separate assessments. Do not assume that NIST voluntary guidance resolves federal, state, sectoral or contractual duties. Route those questions to the responsible specialists and record their decisions.

Open it when a credible signal needs coordinated evidence preservation or decision making. The status can remain unconfirmed. The opening threshold should be lower than the threshold for declaring root cause or external reportability.

Not by default. The deploying organisation still needs its own record of the business workflow, affected people, local controls and decisions. Link provider evidence and notices, but do not outsource the system boundary.

Only after the organisation addresses the affected population, recovery criteria, outstanding notifications, corrective actions and recurrence monitoring. A technical correction can be necessary without being sufficient.

Use the AI governance decision log to record the policy decision that sets incident authority and risk tolerance. Use the AI model change regression guide when the corrective action changes the model, prompt, retrieval source or workflow.

Primary NIST sources were retrieved on 13 October 2026. Recheck them and any applicable law, contract or sector guidance before relying on this method. Update the record template when system boundaries, escalation routes, evidence retention rules or recovery thresholds change. Readers can report a correction through QSE Advisory or office@qseadvisory.com.

QSE Advisory prepared this draft with AI assisted research and drafting. Reviewer and Assessor: Laraib Naveed Ahmad. The worked incident is fictional.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.