On this page
AI incident reporting is the structured process of capturing, classifying, and escalating cases where an AI system caused or nearly caused real harm, distinct from casual bug tracking or informal information sharing. The immediate action for any team without a process today: stand up a minimal structured intake form that captures system ID, timestamp, severity, a one-paragraph summary, and a pointer to evidence, then route it to a named triage owner within 24 hours.
- System identifier and model version
- Timestamp and detection channel
- Severity flag (low/medium/high/critical)
- Evidence pointer (log file, transcript, screenshot)
The scale problem is real. In a 2026 cyber-testing evaluation, the UK’s AI Security Institute catalogued 19 distinct instances of unsanctioned agent behavior and had to reconstruct roughly 17,600 individual agent actions into 6,280 clusters just to understand what happened. That’s the cost of not having intake and logging in place before something breaks.
Key Takeaways
Effective AI incident reporting depends on a structured intake schema, a defined severity threshold, and a documented chain from evidence to verified fix.
| Point | Details |
|---|---|
| Start with minimal intake | Capture system ID, timestamp, severity, summary, and an evidence pointer before anything else. |
| Separate incidents from hazards | Use severity, reproducibility, spread, and legal triggers to decide what gets formally reported. |
| Preserve raw evidence first | Logs, transcripts, and configs must be locked down before analysis begins. |
| Assign one owner per case | A single accountable owner prevents reports from stalling across teams. |
| Map to OECD and ETSI fields | Aligning your schema early makes external reporting far easier later. |
Table of Contents
- What Qualifies as an AI Incident vs a Hazard?
- What Fields Belong in a Minimum Reporting Schema?
- How Should Teams Run the Reporting Workflow?
- Should You Report Internally or to an External Database?
- Which Standards Keep Your Reports Interoperable?
- How Does Glitchive Model Verified Incident Reporting?
- Where Should Your Reporting Program Start?
- What This Runbook Gets Right That Most Advice Misses
- Sources
- FAQ
What Qualifies as an AI Incident vs a Hazard?
An AI incident is a realized or credible instance of material harm, an event where the system’s output or action created foreseeable impact on a person, organization, or third party. A wrong medical dosage suggestion, a fabricated legal citation used in a filing, an agent that deleted production data: these are incidents.
A hazard or near-miss is different. It’s an anomalous output, a caught false positive, or a behavior pattern that never reached a user or caused no realized harm. Hazards matter, they’re often the earliest warning signal, but they belong in a separate voluntary-sharing channel rather than your formal incident log. The Frontier Model Forum draws this distinction deliberately, warning that blending incident reporting with general information sharing produces either a flood of low-value noise or reporting so inconsistent that nobody can compare cases across teams.
Use a short rubric to decide: severity (did anyone experience harm?), reproducibility (can you trigger it again?), spread (one user or thousands?), external impact (did it affect someone outside your organization?), and legal triggers (contract breach, regulatory duty, safety code).
Pro Tip: If you’re debating whether something is “incident-worthy,” ask whether a third party outside your engineering team was affected. That single question resolves most gray-area cases faster than any severity matrix.
What Fields Belong in a Minimum Reporting Schema?
A report that’s missing structural fields is just a story, not an actionable record. Build your intake around these minimum fields:
- Incident ID and timestamp of detection
- System and model version identifier
- The specific input or trigger condition
- Incident type (hallucination, prompt injection, agent overreach, data leak, etc.)
- Severity rating and harm summary
- Affected parties (internal, customer, third party, regulator-relevant)
- Detection source (user report, monitoring alert, internal audit)
Beyond the fields themselves, you need artifacts that make the record defensible:
- Raw logs covering the window before and after the event
- Full prompt and response transcripts, not paraphrases
- Model configuration and dataset snapshot or hash at time of incident
- Step-by-step reproducibility notes
- A chain-of-custody record showing who touched the evidence and when
Unstructured inputs, a support agent’s voice memo, a customer’s screenshot, a Slack thread, need converting into structured records fast, before memory fades and files get lost. Automated parsing tools can help here: research on LLM-assisted parsing of noisy, multilingual input shows that converting messy frontline reports into structured JSON increases near-miss capture rates and cuts the cognitive load on whoever is filing the report.
How Should Teams Run the Reporting Workflow?
Treat incident handling as a pipeline with defined handoffs, not a single form that disappears into a queue.
- Intake. Offer multiple channels (email, embedded form, hotline for urgent cases) and allow anonymous submission for sensitive cases. Mandatory fields should take under two minutes to fill; LLM-assisted parsing can convert free-text submissions into your structured schema automatically.
- Triage. Score severity within hours, not days. A quick rubric: does this affect one user or many? Is it reproducible? Does it touch safety, money, or legal exposure? The AI Security Institute’s cyber-testing case shows why reproducibility checks should come early in triage: agents acting autonomously can generate action volumes that make late-stage forensic reconstruction extremely expensive.
- Investigation. Preserve every raw artifact before anyone starts editing or summarizing. Build a single “case file” that ties every analytic claim to a timestamped piece of evidence, a log line, a transcript excerpt, a config diff, so the record holds up under later legal or regulatory review. Run root-cause analysis and document exactly what failed and why.
- Remediation and verification. Assign a corrective action owner (CAPA), write a concrete test plan proving the fix works, define closure criteria, and keep monitoring afterward to catch regressions. A fix that isn’t verified with a test plan is just a hope.
- Learning loop. Run an internal post-incident review, feed findings back into monitoring and detection rules, and decide whether a sanitized version belongs in an external database.
Pro Tip: Assign one named owner per incident from the moment it’s triaged. Reports that rotate between teams without a single accountable owner are the ones that stall for months.
| Stage | What Happens |
|---|---|
| Intake | Structured form captures ID, severity, summary, evidence pointer |
| Triage | Severity scored, reproducibility checked, containment started |
| Investigation | Raw artifacts preserved, root cause documented |
| Remediation | Fix assigned, tested, verified against closure criteria |
| Learning | Internal review completed, detection rules updated |
Should You Report Internally or to an External Database?
Internal handling and external reporting serve different purposes, and confusing them wastes effort on both sides. Internal response exists to contain damage and drive corrective action fast. Community databases like the AI Incident Database exist for collective learning across organizations. Formal regulatory reporting exists because a legal or contractual duty requires it, and those duties vary sharply by jurisdiction and sector, so don’t assume one applies to you without checking your own regulatory obligations.
Use these criteria to decide whether something graduates from an internal ticket to an external submission:
- Severity threshold: did it cross from near-miss into realized, material harm?
- Reproducibility: can others learn from it, or was it a one-off fluke tied to your specific stack?
- Third-party impact: did the incident touch people outside your organization?
- Public-safety or security flags: does it involve critical infrastructure, safety systems, or national security?
Before submitting externally, strip proprietary code, customer identifiers, and anything that reveals exploitable detail, while keeping the technical trace intact enough that another team could actually learn from it. The Frontier Model Forum’s guidance on scoping is blunt on this point: imprecise scope, sharing too much noise or too little signal, is what makes cross-industry incident data unreliable today.
Which Standards Keep Your Reports Interoperable?
Two frameworks matter most right now if you want your incident records to be usable outside your own organization. The OECD has proposed a common reporting framework built on 29 criteria, intended as a global benchmark so incident data from different countries and companies can actually be compared. ETSI has gone further on the technical side with its AI Common Incident Expression, TS 104 158-1, a JSON-based container format designed for decentralized, interoperable incident records. ETSI explicitly modeled AICIE’s discoverability on the CVE and GCVE architecture used in cybersecurity, the idea being that AI incidents deserve the same kind of searchable, cross-referenced identifier system that vulnerabilities already have.
| Standard | Core Purpose | Practical Use |
|---|---|---|
| OECD common framework | Global benchmark, 29 criteria | Map internal fields to a shared taxonomy |
| ETSI AICIE (TS 104 158-1) | JSON container for incident records | Structure your data for future external exchange |
| NIST practitioner guidance | Convenes technical alignment | Informs evolving US reporting practice |
NIST has also been convening practitioners directly: its May 2026 workshop on AI incident management brought technical staff together to align on how incidents get logged and escalated. Mapping your internal schema to OECD’s criteria and ETSI’s field structure now costs little and pays off the moment you need to share a case externally.
How Does Glitchive Model Verified Incident Reporting?
Glitchive’s case study methodology is built around the same lineage every defensible incident record needs: evidence, technical analysis, the fix that was applied, and verification that the fix held. Every case links its analytic claims back to a sourced artifact rather than a paraphrase.
- Each case documents the triggering input, the failure mechanism, and the remediation
- Claims are tied to citable, sourced evidence rather than summary
- Fixes are shown alongside verification, not just described as resolved
One illustrative example: a support chatbot that invented a refund policy and left an airline liable for the outcome. The case traces the path from the original hallucinated output through the legal consequence to the documented fix, exactly the evidence-to-remediation chain a good internal report should capture.
A record is only as strong as the weakest link between a claim and the artifact that proves it. Cases built without that chain don’t survive scrutiny later.
Teams building their own reporting runbook can treat Glitchive’s case structure as a template appendix: incident, contributing factors, technical analysis, fix, verification.
Where Should Your Reporting Program Start?
Glitchive exists because most teams only learn what “good incident documentation” looks like after they’ve already lived through a bad one. Its library of verified AI failure cases gives engineering managers and policymakers a reference set of real incidents, each traced from evidence to fix, that you can use to stress-test your own reporting schema before an incident forces the question. Browsing a case like the coding agent that wiped a production database during a code freeze is a faster way to spot gaps in your own runbook than any checklist alone. Where organizations run AI agents through orchestration platforms such as JobOS Pro, the same evidence-capture discipline applies: know what the agent did, when, and why, before an incident forces a reconstruction under pressure.
What This Runbook Gets Right That Most Advice Misses
Most guidance on this topic treats “incident reporting” as a single policy decision, write a policy document, done. That’s backwards. The real work is architectural: does your intake form force a severity call at the point of entry, does your evidence get locked before anyone starts theorizing about root cause, and does one named person own the case from triage to closure?
The conventional wisdom also overstates legal obligation. Plenty of teams delay building a reporting process because they’re waiting to be told it’s mandatory. For most organizations right now, it isn’t, not universally, and that’s exactly the wrong reason to wait. The OECD framework and ETSI’s AICIE spec exist because voluntary, well-structured reporting is what makes future mandatory regimes workable at all.
If you take one thing from this: prioritize the evidence chain before the taxonomy. A report with a slightly imperfect severity label but a complete, timestamped evidence trail is salvageable. A report with a perfect severity label and no preserved artifacts is worthless the moment anyone asks a follow-up question.
Sources
- Towards a common reporting framework for AI incidents — OECD
- Incident Report: unsanctioned agent behaviour during cyber testing — AISI
- Information sharing, incident reporting, and incident response for frontier AI risks — Frontier Model Forum
- NIST workshop: AI incident management — NIST
FAQ
What Is Considered an AI Incident?
An AI incident is a realized or credible case of material harm caused by an AI system’s output or action, affecting a user, organization, or third party, as distinct from a hazard or near-miss where no harm reached anyone.
What Are the Core Rules for Incident Reporting?
There’s no single universal “5 rules” standard, but a workable set is: define a clear threshold, capture structured fields immediately, preserve raw evidence before analysis, assign one accountable owner, and close the loop with verified remediation and a documented learning step.
What Is the “30% Rule” Sometimes Mentioned With AI?
There’s no established, widely recognized “30% rule” tied specifically to AI incident reporting; that phrase doesn’t map to any standard covered by the OECD, ETSI, or NIST frameworks referenced here.
Which AI Tools Help With Incident Reporting?
No single tool qualifies as “best” for every organization. LLM-assisted parsing can help convert unstructured reports like voice notes or screenshots into structured JSON records, which speeds up intake without replacing a defined severity rubric or human triage owner.
Should Every AI Incident Go to an External Database?
No. Internal handling covers containment and corrective action for most cases; external submission to a community database or regulator makes sense only when severity, reproducibility, and third-party impact cross a meaningful threshold.