An AI incident file should begin before anyone knows whether an event is legally reportable. Waiting for that conclusion reverses the proper sequence: teams need preserved facts to classify the event, assess harm and decide what must be reported.
AI incidents are broader than cybersecurity incidents. A model can produce discriminatory recommendations, unsafe instructions or convincing impersonation without an intrusion. A vendor update can create a performance regression across thousands of decisions. The file must connect technical failure, human impact and governance response.
This checklist is not a universal regulatory form. It is a practical minimum that can feed different legal analyses, regulator templates and post-incident reviews.
1. A controlled cover record
Create one cover record with a stable incident identifier. It should state:
- the date and time of detection, with time zone;
- the person or system that raised the alert;
- the incident owner and decision owners;
- status, severity and confidence;
- affected business services and jurisdictions;
- links to evidence stored elsewhere; and
- the record’s version history and access restrictions.
Keep facts separate from hypotheses. “Model version 4.2 produced 73 flagged outputs” is an observation. “The vendor update caused the failure” remains a hypothesis until tested. Identify the author and timestamp of each substantive update.
The cover record should also explain the incident definition used. The OECD distinguishes an AI incident involving actual harm from an AI hazard involving potential harm, while recognizing that jurisdictions may apply their own thresholds. An enterprise may sensibly track a wider universe of events internally than it must report externally.
2. Exact system and model identity
“The chatbot” or “the scoring model” is not enough. Record the application, model provider, model and version, deployment endpoint, configuration, release identifier and relevant dates. For a system assembled from several components, identify retrieval sources, orchestration logic, safety filters, ranking models, tools and downstream decision systems.
Show whether the organization is acting as developer, provider, deployer, distributor or customer. That role can change available evidence and reporting ownership. Reference the relevant vendor terms, system card, use-case approval and escalation contacts.
Freeze the relevant configuration where feasible. Preserve prompts, system instructions, feature flags, model parameters, policy versions and the hashes or identifiers of artifacts used in production. If a third-party model changed without a customer-controlled version number, record the provider’s change notice and the first observed behavior change rather than inventing precision.
3. A factual timeline with decision gates
The timeline should cover more than detection and containment. Include:
- the earliest confirmed occurrence and the possible exposure window;
- initial alert, triage and escalation;
- material changes in scope or confidence;
- containment, rollback and restoration steps;
- internal legal, safety and executive decisions; and
- external communications or reports.
For every consequential action, record who approved it, the information available and the reason. This matters when a reporting deadline turns on awareness, suspected causation or an organization’s determination—not simply the time a monitoring tool fired.
For example, Article 73 of the EU AI Act requires providers of high-risk AI systems placed on the Union market to report serious incidents to relevant market-surveillance authorities. Its general rule ties reporting to establishing a causal link or the reasonable likelihood of one and sets an outer period of 15 days after awareness, with shorter periods for specified categories. It permits an incomplete initial report when necessary for timely reporting. An incident file should preserve the facts behind timing and causation decisions, not merely the final conclusion.
4. Inputs, outputs and operating context
Preserve representative evidence of what entered the system, what the system produced and how the output was used. That can include input records, retrieved documents, generated content, confidence scores, tool calls, human edits and the final action presented to or taken about an affected person.
Context is essential. Record the intended purpose, user population, prohibited uses, expected human oversight and whether operation departed from approved conditions. NIST’s voluntary AI Risk Management Framework emphasizes documenting context, risks, impacts, human oversight and the limitations of system performance. Its Generative AI Profile adds actions for generative-AI risks and lifecycle testing.
Preservation should be proportionate. Avoid uncontrolled duplicates of sensitive prompts, personal data or customer material. Use restricted evidence stores, access logs and a defined retention rule. Record what was withheld or transformed and why.
5. Impact and affected-party evidence
Describe actual and reasonably suspected consequences separately. Identify affected people, groups, organizations, infrastructure or environments; the number and geographic distribution; duration; reversibility; and whether effects are continuing.
Use incident-specific measures. A hiring tool may require selection-rate and error analysis across relevant groups. A clinical support tool may require patient-safety review. A generative system may require evidence about false instructions, impersonation, nonconsensual imagery or exposed confidential information. For synthetic-media events, the legal landscape can depend heavily on content and channel; federal laws that may apply to deepfakes illustrate why “AI-generated content” is not a sufficiently precise incident description.
Record complaints, appeals, overrides and reports from employees or users, including how they were triaged. Preserve the methodology and denominators behind impact estimates. “Five complaints” has a different meaning across 50 outputs and five million outputs.
6. Baselines, tests and causal analysis
An incident file needs a comparison point. Preserve the performance baseline, acceptance criteria and predeployment tests that applied to the released system. Then record the incident-specific test set, method, environment, results and limitations.
Separate correlation from causation. Compare affected and unaffected versions, cohorts, prompts or time periods where appropriate. Examine data drift, model changes, retrieval failures, adversarial inputs, integration defects, operator behavior and downstream automation. Record plausible alternative explanations and the evidence that supports or weakens each one.
The EU AI Act requires high-risk AI systems to support automatic event logging over their lifetime at a level appropriate to their intended purpose. Providers must keep automatically generated logs under their control for an appropriate period, generally at least six months unless other law provides otherwise. Deployers of covered high-risk systems also have log-retention duties for logs under their control. Those provisions are role- and system-specific, but they demonstrate why logging design must precede an incident.
7. Containment, correction and validation
Document what changed: disabling a feature, reverting a model, narrowing users, adding human review, blocking an input pattern or changing a vendor. Preserve the before-and-after configuration and deployment record.
Containment is not proof of correction. Define validation criteria, test against the original failure mode and check for new failure modes created by the fix. Record residual risk and the person who accepted it. If the system returns to service in stages, identify each cohort, monitoring threshold and rollback trigger.
Keep customer remedies and technical remediation connected. If an incorrect decision was reversed, record how affected records and downstream systems were corrected. If people were notified or given an appeal path, preserve the approved language, recipient logic, delivery evidence and response handling.
8. Reporting and communication decisions
Maintain a reporting matrix in the file, but do not force engineers to make legal classifications. For each potentially applicable regime, record the responsible owner, trigger considered, current conclusion, supporting facts, deadline method and authority contacted.
The European Commission published draft Article 73 guidance and a reporting template in 2025 to help organizations prepare for serious-incident reporting. The draft status matters: a template can guide data collection without replacing the final law, later guidance or a competent authority’s instructions. General-purpose AI models with systemic risk have separate serious-incident obligations under Article 55, so the file should identify the system and organizational role before selecting a form.
Trace every external statement to the controlled fact record. Preserve submissions, receipts, questions and supplemental reports. Label estimates and unresolved facts.
9. Closure, recurrence and institutional learning
Closure requires named criteria: containment verified, affected parties addressed, reports completed, evidence retained, corrective actions assigned and monitoring stabilized. The final analysis should distinguish root causes, contributing conditions and detection gaps.
NIST’s AI RMF calls for processes to track, respond to and recover from incidents and errors, and to document communication with relevant actors. The OECD’s nonbinding common reporting framework similarly uses structured incident characteristics to support comparable learning across jurisdictions. An internal file should therefore end with reusable control changes: updated tests, monitoring, documentation, contracts, training or use restrictions, each with an owner and due date.
Run a quality check before archiving. Can a reviewer identify the exact system, reproduce the sequence, understand the harm assessment, trace each decision to then-available facts and confirm that remediation worked? If not, the organization has a collection of artifacts, not an incident file.
The objective is not perfect documentation during a crisis. It is disciplined reconstruction without guesswork. A well-designed AI incident file lets technical, risk and legal teams work from the same evidence—and makes the organization faster when a regulator’s first question is not “What is your policy?” but “Show us what happened.”
Sources
- Regulation (EU) 2024/1689 — Artificial Intelligence Act
- European Commission — Draft guidance and reporting template on serious AI incidents
- NIST — Artificial Intelligence Risk Management Framework resources
- NIST AI 600-1 — Generative Artificial Intelligence Profile
- OECD — Towards a Common Reporting Framework for AI Incidents
- OECD AI Incidents and Hazards Monitor — Methodology and definitions
- The First File — Deepfakes can invade privacy, and several federal laws may apply in limited ways
