AI incident reporting is the structured documentation of harms and near-misses involving AI systems, built so governance teams can meet regulatory obligations and learn from failures. It benefits safety, compliance, and product teams alike by turning scattered observations into evidence. A recommended step is to adopt a minimum reporting dataset aligned with OECD and NIST frameworks, then connect it to post-market monitoring.
TL;DR:
- The EU AI Act gives 2 days for widespread disruptions, 10 for deaths, and 15 for other serious incidents; initial reports may be incomplete.
- Incident records need a system ID, reporter, event and detection times, description, impact, stakeholders, and evidence, plus four severity levels and a sortable harm taxonomy.
- Preserve logs, prompts, and outputs before changing the system, assign one investigation owner, and start regulatory clocks at detection rather than resolution.
- A nonpunitive channel, explicit whistleblower protections, and separation of reporters from decision makers encourage near miss reporting; privacy teams should review personal data in submitted evidence.
- Connect postmarket monitoring to incident reporting, and require vendors to provide fixed notification windows, root cause access, evidence sharing, and joint investigation response times.
Table of Contents
- What AI incident reporting covers and when to report
- Standards and reporting frameworks to know
- Minimum report fields and a practical taxonomy
- Incident lifecycle: from detection to organizational learning
- Institutional design: roles, incentives, and anonymity
- Data sharing, public repositories, and interoperability
- Metrics and KPIs to run an incident reporting program
- Integrating reporting with post-market monitoring and vendor contracts
- What audits reveal about where reporting breaks down
- Perspective: incident reporting as a trust and resilience mechanism
- How we operationalize incident reporting and continuous assurance
- FAQ
- Sources
What AI incident reporting covers and when to report
An incident is a confirmed harm: a chatbot gives dangerous medical advice, a hiring algorithm screens out protected groups, a fraud model misflags legitimate transactions at scale. A near-miss is the same failure mode caught before it reaches a person, such as a bias check that flags skewed outputs in testing before release. Both deserve a record, because near-misses often predict the next confirmed incident.
Regulatory triggers vary by jurisdiction, but the EU AI Act’s Article 73 sets a useful reference point: providers must report serious incidents to market surveillance authorities immediately, within 2 days for widespread infrastructure disruptions, within 10 days for incidents involving death, and within 15 days for other serious incidents. The Article also permits an initial incomplete report followed by a full one, which matters when root cause takes longer to confirm than the clock allows.
Internally, escalation thresholds should sit well below the regulatory bar. Waiting for certainty before logging anything guarantees you miss patterns.
- Log every confirmed incident and every near-miss with potential for harm, regardless of severity.
- Escalate to leadership or legal review when an incident touches safety, discrimination, or financial loss.
- Escalate externally only when a jurisdiction’s defined threshold or timing rule applies.
Standards and reporting frameworks to know
Several frameworks now shape how AI incidents get documented and shared, and governance teams benefit from treating them as complementary rather than competing.
The OECD’s common reporting framework standardizes incident reporting across jurisdictions and sectors using 29 specific criteria that help identify high-risk systems, assess impacts, and evaluate emerging risks. That breadth is the point: a framework built for cross-border comparison needs criteria specific enough to be useful and general enough to apply across industries.
ETSI’s AI Common Incident Expression specification addresses a different problem: interoperability. It defines a container format and JSON record structure so incident data from different organizations and tools can be exchanged and discovered without custom translation layers.
NIST’s AI Risk Management Framework and Generative AI Profile focus on process. The GAI profile includes specific guidance, cataloged under references like GV-1.5-001 and GV-4.3-002, on periodic review responsibilities, after-action reviews, and incident disclosure procedures that feed governance decisions rather than sitting in a drawer.
The EU AI Act ties these together operationally: post-market monitoring under Article 72 generates the evidence that Article 73’s serious-incident reporting then requires within its specified timelines.
- OECD: cross-jurisdiction standardization through 29 criteria.
- ETSI AICIE: interoperable container and record format.
- NIST AI RMF/GAI profile: after-action review and disclosure procedures.
- EU AI Act Articles 72 to 73: monitoring feeds reporting obligations.
Minimum report fields and a practical taxonomy
Every report your team files should capture the same core fields, regardless of which tool or team files it. Guidance from NIST and related research converges on a minimum dataset that makes records useful for post-market analysis rather than just archival.
- System ID: a unique, consistent identifier for the AI system involved.
- Title: a short, searchable summary of what happened.
- Reporter role: who filed the report and their relationship to the system.
- Date and time: when the incident occurred and when it was detected.
- Description: what happened, in plain language, without speculation about cause.
- Observed impact: who or what was affected and how.
- Stakeholders: everyone touched by the incident, internal and external.
- Evidence: logs, screenshots, transcripts, or model outputs tied to the event.
Severity scales should be simple enough for a non-technical reporter to apply: low, moderate, severe, and critical, with critical reserved for safety, discrimination, or regulatory-trigger events. A type taxonomy covering bias, security, hallucination, escalation failure, and data privacy keeps reports sortable for trend analysis later.
Pro Tip: Auto-generate System IDs from your asset inventory rather than letting reporters type them freely; free text IDs are the single biggest cause of duplicate and unmatched incident records.
Structured evidence attachments, rather than pasted text, also reduce the manual cleanup that erodes report quality over time.
Incident lifecycle: from detection to organizational learning
Reporting is one stage in a longer cycle, and treating it as a standalone form defeats the purpose. Detection signals arrive from several sources: automated monitoring thresholds, direct user reports, third-party feeds, and periodic audits.
Triage should happen fast and follow fixed criteria rather than ad hoc judgment calls. A rapid decision rule works well: does the incident involve safety, discrimination, financial harm, or a regulatory trigger? Any yes moves it to the fast track.
Investigation needs discipline. Evidence preservation comes first: capture logs and system state before anyone attempts a fix, because premature changes destroy the trail needed to confirm root cause. Investigators should resist the urge to patch and move on until the record is complete.
- Preserve logs, prompts, and outputs before modifying the affected system.
- Assign a single investigation owner to avoid conflicting changes mid-review.
- Separate the fix timeline from the reporting timeline, since regulatory clocks start at detection, not resolution.
Internal reporting should reach risk owners and legal counsel immediately for anything flagged as fast track. External reporting follows the jurisdiction’s defined timeline, as set out in Article 73 for serious incidents in the EU.
After-action reviews close the loop. The point of the exercise, as the Stanford HAI and RegLab issue brief argues, is that adverse-event reporting lets both organizations and policymakers learn about real-world risks and respond before they recur, rather than filing paperwork and moving on.
Institutional design: roles, incentives, and anonymity
Who reports, how, and under what protection determines whether a reporting system gets used at all. Research on designing incident reporting systems for general-purpose AI identifies design choices, particularly around anonymity and enforcement, that drastically affect reporting uptake and the usefulness of what gets collected.
Seven dimensions shape a working system: the policy goal the reports serve, who can submit and receive them, which incident types are in scope, how risk levels get assigned, what enforcement follows a report, whether anonymity is available, and what happens after a report is filed.
A clear RACI pattern helps operationalize this. Intake should be owned by a single team, usually risk or compliance, with product and engineering as consulted parties. Investigation is typically led by whichever team owns the affected system, with risk as the accountable reviewer. Disclosure decisions, internal or external, belong with legal and compliance, informed by both.
- Offer a non-punitive reporting channel so staff surface near-misses instead of hiding them.
- Define whistleblower protections explicitly, in writing, before an incident forces the question.
- Separate the person who reports from the person who decides on consequences.
- Build privacy review into intake, since incident evidence often contains personal data.
Pro Tip: A reporting channel that feels like a disciplinary process will produce fewer reports, not safer systems. Design for psychological safety first.
Legal and privacy constraints deserve planning before launch, not after the first complicated case. Evidence that includes customer data triggers its own handling rules, separate from the incident’s severity.
Data sharing, public repositories, and interoperability
Beyond internal records, public repositories give governance teams a way to benchmark against the wider field. The AI Incident Tracker, maintained by MIT’s AI Risk Lab, classifies incidents across harm categories and layers LLM-generated labels over the public AI Incident Database, giving researchers a searchable view of real-world failures.
That same tracker is candid about its limits: it notes variability in report quality and sampling bias in voluntary datasets, since incidents that get submitted are not a random sample of incidents that occur. Anyone citing public incident counts as a complete picture of AI harm is overstating what the data shows.
OECD’s 29 criteria and ETSI’s AICIE container format exist precisely to make reports from different organizations comparable and exchangeable, which is what turns isolated reports into a usable public resource rather than a pile of unstructured text.
- Public disclosure builds a shared evidence base but can expose sensitive operational details.
- Internal-only logging protects confidentiality but misses patterns visible only at industry scale.
- Quality checks and metadata tagging are necessary before reusing any public incident data for analysis.
Metrics and KPIs to run an incident reporting program
A reporting program needs its own health metrics, separate from the incidents it tracks. Operational KPIs: time to detect, time to triage, and time to report, each measured against your internal escalation thresholds and any applicable regulatory deadline.
Quality KPIs matter just as much: report completeness against your minimum dataset, severity distribution over time, and the rate of repeat incidents tied to the same root cause. A high repeat rate signals that after-action reviews aren’t changing anything.
Outcome KPIs close the loop: recurrence reduction after a fix, the number of fixes actually shipped from investigation findings, and demonstrable readiness for a regulatory audit. The OECD framework’s 29 criteria offer a ready-made checklist for that last metric.
- Time to detect, triage, and report, tracked against internal and regulatory clocks.
- Completeness scores against your minimum dataset fields.
- Recurrence rate for the same root cause across reporting periods.
Integrating reporting with post-market monitoring and vendor contracts
Post-market monitoring under the EU AI Act’s Article 72 generates the ongoing evidence that feeds serious-incident reporting under Article 73. The two cannot run as separate programs without creating gaps where an incident gets detected but never reaches the reporting pipeline.
Vendor contracts need specific language to close those gaps when a third-party model or agent is involved: notification windows matching your internal escalation thresholds, root-cause access rather than summary-only disclosures, evidence-sharing rights, and defined SLA response times for joint investigations.
- Require vendor notification within a fixed window, matched to your own fastest escalation tier.
- Demand root-cause access, not just a vendor’s own remediation summary.
- Rehearse a cross-vendor investigation at least once before you need one for real.
What audits reveal about where reporting breaks down
Audit work consistently surfaces a specific failure pattern: conversational agents that handle the interaction correctly right up until the moment a human needs to step in.
That gap matters more than most reporting frameworks account for. A minimum dataset and a clean taxonomy only help once an event gets captured, and escalation failure is exactly the point where capture most often fails. Continuous auditing across full conversation volume, rather than sampled review, is what surfaces these events early enough to log them before they repeat at scale.
Perspective: incident reporting as a trust and resilience mechanism
Most organizations treat incident reporting as a compliance artifact, something produced for an auditor rather than used by anyone. That framing gets the value backward. A reporting program’s real output is evidence, the kind that demonstrates to regulators and customers that failures get caught and fixed rather than buried.
Mature programs feed that evidence back into design decisions, not just into a filing cabinet. The organizations that treat reporting as a resilience mechanism, not a paperwork requirement, end up with systems that fail less often because they actually learn from the failures they log.
Operationalize reporting now, before an incident forces the question.
— Sergio Llorens
How we operationalize incident reporting and continuous assurance
We built our approach around the gap audits keep finding: incidents that never get logged because no one caught the escalation failure in the first place. Lexic Compass audits conversational agents from any vendor, verifying real behavior against regulatory requirements and surfacing the evidence a reporting program needs at the point of detection, not after the fact.
For ongoing coverage rather than a point-in-time check, Lexic Pulse monitors 100% of customer conversations continuously, generating the structured evidence and alerts that feed directly into the minimum dataset and escalation thresholds covered above.
- Start with a preliminary review to identify where agents may fail to escalate.
- Consider ongoing monitoring for continuous oversight tied to your reporting pipeline.
- Choose platforms that support OECD and ETSI-aligned evidence retention according to your needs.
The evidence retention and escalation data produced align directly with the OECD and ETSI structures outlined above. See available audit and continuous assurance options to find the right starting point for your governance program.
FAQ
Does AI report crime?
AI systems themselves do not report crime in a legal sense; they can flag anomalies or patterns to human reviewers, who then decide whether a report to authorities is warranted. Incident reporting frameworks like the ones covered here document AI system failures and harms, not criminal activity.
When should a security incident be reported?
A security incident tied to an AI system should be reported internally the moment it is detected, with external reporting following the applicable regulatory timeline. Under the EU AI Act’s Article 73, serious incidents carry specific deadlines, including 2 days for widespread disruptions and 10 days for incidents involving death.
What is the 30% rule in AI?
There is no established “30% rule” in AI governance or incident reporting standards; definitions vary across contexts and none of the major frameworks covered here, including OECD, NIST, or the EU AI Act, define such a threshold. Readers encountering this term should check the specific source using it, since it is not part of any recognized reporting standard.
What’s the best AI for reporting?
There is no single best tool, because incident reporting quality depends more on your minimum dataset, taxonomy, and escalation process than on any one piece of software. Platforms that support structured fields, evidence attachments, and OECD or ETSI-aligned formats, such as Lexic Compass for audit-based evidence capture, tend to produce more usable records than general-purpose ticketing tools.
How does bias get documented in an incident report?
A bias or fairness incident should be logged with the same minimum dataset as any other incident, with observed impact specifying which groups were affected and how. Evidence should include the specific outputs or decisions that triggered the concern, since bias incidents are often disputed and need a clear record to investigate.
Sources
- Towards a common reporting framework for AI incidents (OECD)
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST)
- Adverse event reporting for AI: Developing the information infrastructure government needs to learn and act (Stanford HAI / RegLab)
- AI Incident Tracker (MIT/AI Risk Lab)
- AI Common Incident Expression (AICIE) Global Framework (ETSI TS 104 158-01)