What is the difference between a serious incident and a malfunction?

A malfunction is the system not operating as intended or not delivering the result intended by the design. A serious incident is a category-defined outcome under Article 3(49), which can be caused by a malfunction or by a system operating as designed. A malfunction without one of the four Article 3(49) outcomes is not a serious incident and is handled internally. A serious incident with no malfunction (for example, a fundamental-rights infringement caused by a system operating exactly as designed) is reportable under Article 73.

When does the 15-day clock start?

The clock starts when the provider has established the causal link between the AI system and the incident. The Commission's expected interpretation is that the link is established when a reasonable investigation supports the conclusion, not when the conclusion is certain to a forensic standard. A provider that delays the initial report pending an exhaustive root-cause analysis risks missing the window. Article 73(5) allows for supplementary information after the initial report.

Who triages the event?

The provider's incident response function performs the triage, with input from the deployer when the deployer detected the event. For deployers that have inherited provider status under Article 25, the triage function sits inside the deployer. The triage function should include a person with the authority to make the reporting decision and the technical understanding to assess the causal link.

Is a near-miss reportable?

A near-miss is reportable when the AI system, operating as it did, would have produced one of the four Article 3(49) outcomes if the corrective action had not intervened. The "directly or indirectly leads to" language in Article 3(49) is read to include reasonably foreseeable harm that did not occur because of post-hoc intervention. The triage record should document the near-miss assessment.

What if the provider is uncertain whether the threshold is met?

Where the threshold is genuinely uncertain, the Commission's posture supports reporting and using the supplementary information mechanism under Article 73(5). The initial report can be flagged as provisional. The downside of under-reporting is the regulatory penalty under Article 99. The downside of provisional reporting is administrative overhead. The asymmetry favors reporting.

How does Article 73 interact with the GDPR breach notification?

A serious incident that involves personal data may trigger both Article 73 reporting under the AI Act and the GDPR's 72-hour breach notification to the data protection authority. The two obligations apply in parallel. The provider has to satisfy both. The factual record that supports one report typically supports the other, but the reports go to different authorities and address different harm categories.

Serious Incident or Malfunction: The Article 73 Trigger That Decides Whether the Clock Starts

Under Article 73 of the EU AI Act, the provider of a high-risk AI system has 15 days to report a serious incident to the market surveillance authority, 72 hours for a widespread infringement, and 2 days for an incident resulting in death. The reporting clock starts when the provider establishes the causal link between the system and the incident. The threshold question that decides whether the clock starts at all is the Article 3(49) definition of "serious incident." An event that meets the definition triggers external reporting. An event that does not is handled through the provider's internal incident management. The August 2, 2026 high-risk application date is 32 days away, and many providers approaching that date have no documented triage decision pattern for this question.

I want to walk through the Article 3(49) definition, the decision criteria the supervisory authorities are expected to apply, the borderline case patterns that recur in enterprise AI deployments, and the operational record the triage decision actually requires.

The Article 3(49) definition

Article 3(49) defines a serious incident as "an incident or malfunctioning of an AI system that directly or indirectly leads to any of the following: (a) the death of a person, or serious harm to a person's health; (b) a serious and irreversible disruption of the management or operation of critical infrastructure; (c) infringement of obligations under Union law intended to protect fundamental rights; (d) serious harm to property or the environment."

Four threshold concepts shape every triage decision: causation ("directly or indirectly leads to"), severity ("serious," "irreversible"), the scope of the protected interest (health, critical infrastructure, fundamental rights, property and environment), and the affected category (person, infrastructure, fundamental-rights obligations, property and environment).

The word "or" between "incident" and "malfunctioning" matters. A malfunction that produces one of the four listed outcomes is a serious incident. The malfunctioning concept is itself defined as the system not operating as intended or not delivering the result intended by the design.

How the supervisory authorities are expected to read the threshold

The Commission has indicated that supervisory authorities will apply a precautionary read on the threshold. Where the harm is plausibly within the regulation's scope, the expectation is that the provider reports. The legal-defensibility framing favors over-reporting rather than under-reporting because Article 73(5) provides for supplementary information, and the initial report can be provisional.

For each of the four outcome categories, the operational read is the following.

Death or serious harm to health. Death is unambiguous. Serious harm includes physical injury that requires medical treatment, hospitalization, or that produces lasting impairment. Psychological harm is in scope where it is medically attested and meets a threshold of severity.

Serious and irreversible disruption of critical infrastructure. Critical infrastructure is defined by reference to the Critical Entities Resilience Directive and the NIS2 Directive. "Serious" is qualitative and includes loss of service across a region, financial losses above sector-specific thresholds, and safety implications. "Irreversible" is the conjunctive modifier and rules out incidents that were resolved through normal recovery procedures.

Infringement of fundamental-rights obligations. The Union law instruments that protect fundamental rights include the GDPR, the Charter of Fundamental Rights as transposed in sectoral instruments, the Equality Directives, and consumer protection law. An AI decision that systematically excludes a protected group from a service, that produces discriminatory pricing, that infringes data protection rights at scale, or that compromises the integrity of a regulated process is in scope.

Serious harm to property or environment. The regulation does not provide a monetary threshold for serious property harm. The sectoral guidance from the supervisory authorities is expected to provide thresholds. In the absence of sectoral guidance, the operational read aligns with the thresholds used in product safety law for the same product category.

Borderline case patterns in enterprise deployments

Six patterns recur in enterprise AI deployments and require careful triage.

The single-user clinical AI miss. A clinical decision-support system gives an incorrect recommendation to a clinician about a specific patient. The clinician follows the recommendation, and the patient suffers serious harm. The incident is in scope. The causal link runs through the clinician's reliance on the AI, which is the "directly or indirectly" contemplated by the definition.

The credit-scoring discrimination cluster. A credit-scoring AI systematically lowers scores for applicants in a protected group. No individual decision is reportable in isolation. The pattern aggregates into an infringement of fundamental-rights obligations under the Equality Directives. The triage question is when the pattern crosses from individual decisions to a reportable infringement, and the answer involves both the regulator's enforcement posture and the deployer's monitoring artifacts.

The HR screening systematic exclusion. An employment screening AI produces consistently lower scores for one demographic. The exclusion may not be apparent in any single decision. The aggregation across decisions produces the fundamental-rights infringement. The reporting is triggered when the pattern is identified and the causal link to the AI is established.

The infrastructure control near-miss. An AI-augmented control system in a utility produces an output that would have caused a disruption if the human overseer had not intervened. The system is operating as intended in a strict design sense; the output was countermanded before harm occurred. The triage question is whether the near-miss qualifies as a malfunctioning. The reading from the safety-critical regulatory tradition treats near-misses as in-scope for reporting because the harm was avoided by chance rather than by design.

The fundamental-rights compliance break. An AI system that processes personal data in a way that breaches the GDPR (insufficient legal basis, retention overrun, transfer without safeguards). The GDPR breach is a fundamental-rights infringement and triggers Article 73 reporting in addition to the GDPR's own notification obligations.

The property damage tied to autonomous operation. An autonomous AI system causes property damage during normal operation. The damage scale relative to the deployer's operational baseline determines whether the harm is "serious." Sector-specific thresholds apply in product safety regimes that the AI is integrated into.

The triage decision pattern

A defensible triage decision applies five criteria in sequence.

Criterion 1: Is the system high-risk under Annex III or Annex I? Article 73 only applies to high-risk systems. A non-high-risk system that causes harm may trigger other obligations but is outside Article 73.

Criterion 2: Has the event occurred, or is it a near-miss? Actual harm and reasonably foreseeable harm both qualify under the "directly or indirectly leads to" language of Article 3(49).

Criterion 3: Does the harm fall into one of the four outcome categories? Death or serious health harm, critical infrastructure disruption, fundamental-rights infringement, or serious property or environmental harm.

Criterion 4: Is there a causal link to the AI system? The link can be direct (the AI's output is the proximate cause) or indirect (the AI's output contributed to a decision or action that caused the harm). The causal link does not require the AI to be the sole cause.

Criterion 5: Has the provider become aware? The reporting clock starts on the provider's awareness of the incident and the causal link, not on the certainty of the link.

If all five criteria are met, the event is a serious incident and the Article 73 clock starts. If any criterion is not met, the event is handled through internal incident management with the documentation that supports the criterion not being met.

The operational record the triage decision requires

The triage decision is itself an audit artifact. The supervisory authority that comes back six months after an event and asks "why did you not report this?" will look at the triage record.

The minimum record per event has six fields. The event description, including the operational facts. The system identifier and the high-risk classification. The harm assessment against each of the four outcome categories. The causal link assessment. The triage outcome (serious incident, malfunction handled internally, or further investigation pending). The decision-maker identity and timestamp.

The triage record draws on the operational evidence that the Article 12 logs already produce. The request and response records show what the system did. The policy state shows the rules in effect at the time. The identity context shows who initiated the action. The triage decision references the logs that support the assessment.

How architecture shapes the triage outcome

The triage decision is faster and more defensible when the operational evidence is in hand at the moment of the decision. Two architectures produce different decision speeds.

Application-controlled audit. The incident-response team has to request logs from the application team. The application team has to extract the records. The extracted records have to be assessed for completeness and integrity. The decision-maker waits.

Gateway-mediated audit. The records are already produced by the gateway, indexed by request identifier, identity, and timestamp. The decision-maker queries the gateway directly. The records are by construction independent of the application under investigation. The decision proceeds without the delay or the integrity-question overhead.

The second architecture is the difference between a triage decision in two hours and a triage decision in two weeks. For events on the 2-day or 72-hour clocks, the difference is between reporting on time and reporting late.

DeepInspect

DeepInspect is a stateless policy gateway between authenticated users or agents and any LLM. Every AI request and response produces a signed, tamper-evident record at the gateway. The record includes identity, policy version, model version, data classes, and timestamps. The records are queryable by request identifier, by user, by deployer, and by time window.

For an Article 73 triage decision, DeepInspect produces the operational evidence in the form the triage team needs. The records are independent of the application, which addresses the self-attestation problem. The records are queryable in real time, which compresses the triage decision from days to hours. The records support the causal link assessment with the actual inputs, outputs, and decision metadata.

If you are facing the August deadline, let's talk.