What Is an AI Incident? Definitions Across Frameworks

Why a single definition does not exist

Regulated enterprises usually answer to several regimes at once. AI-specific law, cybersecurity regulation, insurance supervision and health privacy rules each define events in their own terms, for their own purposes. One regime asks whether a person was harmed. Another asks whether a cybersecurity event occurred at a covered entity. A third asks whether a breach of protected information took place.

The practical result is inconsistent classification. Two teams can look at the same event, one calling it a defect and the other an incident, and neither can show an auditor why. A working internal definition solves this by acting as a translation layer. It does not replace any external definition. It gives your teams one vocabulary for triage and one rule for deciding when an event must be tested against each external regime.

This guide compares the two definitions that can be stated precisely from primary text, the EU AI Act serious incident and the NYDFS cybersecurity incident reference, and then turns the differences into a definition you can adapt.

Side-by-side: how the definitions differ

The table compares the definitions across the four dimensions that matter for classification. The third row shows what an internal definition has to reconcile. Add rows for any other framework or sector rule that applies to your organization, using the same four dimensions.

• EU AI Act: serious incident (Art. 3(49)): Scope: an incident or malfunctioning of an AI system. Harm threshold: death or serious harm to a person's health, or a serious and irreversible disruption of the management or operation of critical infrastructure, among other listed outcomes. The recital also refers to infringements of Union-law obligations protecting fundamental rights and serious damage to property or the environment. Causation: directly or indirectly leads to the outcome. Reporting: providers of high-risk systems report to market surveillance authorities; deployers inform the provider first.
• NYDFS: cybersecurity incident (23 NYCRR 500.1(g)): Scope: the NYDFS industry letter on AI-related cybersecurity risk points to the existing cybersecurity incident definition, which concerns a cybersecurity event at the covered entity, its affiliates or a third-party service provider. There is no separate AI-specific incident category in that reference. AI-related events are tested against the existing definition. Treat the full criteria and any notification timelines as questions for the primary text.
• Internal working definition: Scope: any event, including a malfunction, in which an AI system's behavior departs from what it was permitted to do. Harm: tiered by severity, aligned to the external harm categories. Causation: direct or indirect, recorded with the evidence relied on. Reporting: a separate determination made after classification, by role and by regime.

What the EU AI Act definition means in practice

Three features of the EU definition shape internal design. First, it is outcome-based. It names categories of harm rather than describing technical failure modes, so a model producing a wrong answer is not an incident under this definition unless it leads to one of the listed outcomes. Second, it covers both an incident and a malfunctioning, so a classification scheme should handle events that cause harm through ordinary operation as well as those caused by failure. Third, the words "directly or indirectly" widen the causal chain. An AI output that contributes to a harm through a human decision can still be in scope.

Reporting follows a timeline. A provider of a high-risk AI system placed on the Union market reports a serious incident to the market surveillance authorities of the Member State where it occurred. The report is due immediately after the provider has established a causal link, or the reasonable likelihood of one, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware. For a widespread infringement or a serious incident involving critical infrastructure disruption, the report must be made immediately and no later than two days after awareness. The period must take account of severity.

Deployers that identify a serious incident must immediately inform the provider first, then the importer or distributor and the relevant market surveillance authorities. Providers of general-purpose AI models with systemic risk must track, document and report serious incidents and possible corrective measures without undue delay to the AI Office and, as appropriate, national competent authorities. As of October 2026, the consolidated regulation text is dated 27 July 2026, so check the current text before finalizing policy.

Drafting an internal definition and classification approach

The aim is a definition that is broader than any single regulation and a classification step that keeps reportability separate. The following decisions give a practical starting structure.

• Cover incident and malfunctioning: State that the definition applies to harmful outcomes from normal operation as well as from failure, and to direct and indirect contribution.
• Build severity tiers from the harm categories: Use the EU harm categories as the upper tiers. The two EU timelines suggest at least two escalation tiers, one for the most severe events and one for other serious incidents.
• Record awareness time: Timestamp the moment an event is first identified by the provider or deployer. The 15-day and 2-day periods run from awareness, so this record has to be defensible.
• Separate severity from reportability: Classify internally first, then test against each regime. The EU duty attaches to providers of high-risk systems and to deployers who must notify the provider. NYDFS tests apply the cybersecurity incident definition.
• Assign ownership by role: Name an accountable owner for deciding whether an event meets the EU definition, for deployer notification, and for the general-purpose model provider track where relevant.
• Document the rationale: Keep the reasoning for each classification, including severity, so a reviewer can follow the decision later.

Incident types at the interaction and tool-call level

External definitions describe outcomes. Detection happens earlier, at the level of individual model interactions and tool calls. This mapping is an enterprise-defined layer, since the regulatory text does not specify it, but it is where most events first become visible.

Typical examples include a model response that exposes data a user was not entitled to see, an agent calling a tool outside the scope it was permitted, a prompt that attempts to override instructions, and a coding assistant introducing code with an unwanted licence or security context. Each is a policy violation at a single point of execution. Whether it becomes an incident depends on what followed.

It helps to define categories explicitly. A violation that was stopped before any effect can be recorded as a near miss in your scheme. A violation that had an effect but no harm in a listed category is an internal incident. One that plausibly leads to a listed harm, directly or indirectly, goes to the reportability test. Writing these tiers down lets teams classify consistently and lets auditors see the logic.

Establishing a causal link, or its reasonable likelihood, requires retained records that connect the system's output to the outcome. Decide in advance which records those are: the input, the policy in force, the action taken and the time.

Where runtime enforcement and evidence fit

A definition is only useful if events can be detected, escalated and reviewed against it. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Actions include allow, redact, block, rate limit and escalate for human approval. Policy is enforced at runtime, not reviewed after the fact, so a violation that is blocked or escalated can be recorded as a near miss or candidate incident when it happens.

Enforcement also produces continuous, audit-ready evidence of what the AI was permitted to do and what it did. That evidence is mapped to NIST, the EU AI Act, HIPAA, NAIC and NYDFS, and it can support classification, escalation decisions and post-incident review. Trussed does not decide whether an event is reportable. That determination, and the awareness date, remain with your accountable owners.

Trussed is self-managed in the customer cloud, with configurable retention and data residency.