Is every wrong AI answer an incident?

Not under every definition. Its consequences and the applicable criteria determine classification, though errors can still be valuable findings.

Can one incident generate many alerts?

Yes. Several observations may reflect the same underlying event or connected sequence.

Should uncertain reports be discarded?

No. Record the concern and uncertainty, then investigate and revise the classification as appropriate.

AI Glossary / Governance, ethics and safety / Beginner

Incident

Definition

An incident is an event or connected set of events that meets an organization's or framework's criteria for requiring investigation and response because something harmful or unacceptable has occurred or is imminently threatened. In AI governance, the precise meaning depends on the context. A cybersecurity incident, an AI harm incident, and an ordinary product defect are related but not interchangeable categories.

What it means

The word should be tied to a stated definition. NIST's cybersecurity guidance includes events that actually or imminently compromise information security or violate relevant security rules. The OECD's proposed AI terminology distinguishes events producing actual harm from AI hazards that could plausibly produce such harm.

These scopes differ. An AI-generated answer can be incorrect without causing a reportable incident under a particular scheme. Conversely, a system can contribute to harm through an apparently successful prediction or an unsuitable workflow, without being hacked.

An internal process can record concerns before their final classification is known. Reporting a suspected incident should not require the person noticing it to establish every fact or legal consequence first. Investigation can refine the classification as evidence develops.

How it works

Someone or something detects an unusual outcome: a monitoring alert, a customer report, a failed control, or an unexpected operational effect. The responsible team records what was observed and distinguishes confirmed facts from preliminary explanations.

It assesses scope, urgency, affected parties, and the applicable criteria. Related reports may belong to one incident; apparently similar events may have different causes. The team can update severity and classification while taking proportionate action to prevent further harm.

A useful record preserves the relevant system version, timing, inputs and outputs where appropriate, and actions taken. It should protect sensitive information while supporting investigation. Closure requires more than making the alert disappear: the organization needs a defensible account of the effect, response, and remaining follow-up.

Three practical examples

1. An AI service exposes confidential material to an unauthorized recipient. This raises an information-security incident concern even if the model generated an otherwise accurate answer.

2. A malfunctioning automated process damages equipment. Investigation considers the AI component, surrounding controls, and actual consequences rather than assuming the model alone caused the event.

3. A tester discovers a harmful output in a controlled evaluation before anyone is affected. It still deserves attention, but may be classified as a hazard, defect, or test finding rather than an actual-harm incident under the chosen terminology.

Think of it this way

Think of a smoke alarm and a fire report. The alarm is an observation requiring attention; the report describes what investigation establishes about an event. Several alarms can arise from one fire, while an alarm can also reveal a fault without a fire.

The analogy is limited because AI-related harm may emerge gradually and be difficult to observe. There may be no clear moment equivalent to ignition. The useful lesson is to keep the signal, the investigated event, and the classification distinct while responding appropriately to uncertainty.

Worked example

Consider an invented monitoring week with 30 alerts. Investigation links 18 alerts to one misconfigured retrieval permission, seven to an unrelated outage, and five to test activity that did not affect users.

The team records two operational incidents under its internal criteria, plus five test alerts. Thirty alerts therefore do not mean 30 distinct incidents. Nor do two incidents describe their severity: the permission problem and outage may affect different people and require different responses.

Suppose the permission issue affected six sessions. That gives six potentially affected sessions, not necessarily six different people or six confirmed disclosures. The team must examine the evidence before making those claims.

This example shows why logs should distinguish alert count, incident count, affected-session count, and confirmed impact. Each measure answers a different question, and combining them casually can exaggerate or understate what happened.

Illustrative case study

Fictional case: Silverleaf Support receives three complaints that its assistant included information from the wrong customer record. The service owner opens a suspected incident record and restricts the affected retrieval feature while the team investigates.

Reviewers preserve the relevant configuration and logs, determine whether the complaints share a cause, and check the scope of possible exposure. They avoid announcing either “only three users affected” or “all records exposed” before the evidence supports a conclusion.

The case illustrates careful classification and scoping. It does not establish notification duties or prescribe a universal response timeline. Those decisions depend on the actual facts, applicable requirements, and responsible specialists.

Common misconceptions and mistakes

An incident is not necessarily a cyberattack. Errors, unsuitable configurations, or interactions between people and systems can also produce serious adverse effects.

An alert is not automatically a confirmed incident, and an incident is not automatically a legally reportable event under every scheme. Keep these distinctions explicit.

Another mistake is waiting for complete certainty before raising a concern. Early reports can support timely investigation. Conversely, do not present an initial allegation or suspected cause as established fact. Update the record transparently as the evidence changes.

Business use

Businesses benefit from a shared vocabulary that connects customer support, technical operations, security, and governance. Define how concerns enter the process, who can classify them, and how urgent matters reach the right decision-maker.

Use incident records to learn about recurring causes and ineffective controls. Trends need context: more reports may reflect better detection rather than worse performance, and fewer reports may reflect a reporting barrier. Compare counts with exposure, reporting practices, severity, and operational changes before drawing conclusions about reliability or safety.

Check your understanding

Twenty alerts trace back to one faulty configuration. Should a report automatically describe twenty separate incidents?

Answer: No. The team should determine how the events relate and distinguish alert volume from incident count and actual impact.

Related terms

Incident response
Information security
Impact assessment
AI hazard
adverse event
monitoring
root cause analysis
risk management

Learn next

Study incident response and root cause analysis next. Compare an alert record with an incident record and identify which facts establish the affected scope, confirmed consequences, and relationship between multiple reports.

Incident response

Sources

NIST, SP 800-61 Revision 3, incident terminology and response guidance: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf

OECD.AI, Name it to tame it: Defining AI incidents and hazards: https://oecd.ai/en/wonk/defining-ai-incidents-and-hazards/

Relevant definitions and explanations were read. The differing cybersecurity and AI-harm scopes are intentional. Counts and scenarios are original illustrations; this entry does not determine legal reporting obligations.

Previous: Inauthentic text Next: Incident response