Serious-Incident Reporting

What triggers a report is an outcome, not a misbehaviour.

The instinct is to look for a definition of "the agent did something bad". There isn't one. Article 3(49) defines a serious incident by the consequence, and the AI system only has to have contributed to it — directly or indirectly.

• Death or serious harm to a person's health. The fastest clock in the regime attaches here.
• Serious and irreversible disruption to the management or operation of critical infrastructure.
• Infringement of obligations under EU law intended to protect fundamental rights. This is the one that will actually fire for most agent deployments — discrimination in a hiring or credit decision, an unlawful processing of personal data, a denial of access to a service. It has no physical-harm component at all.
• Serious harm to property or the environment.

Two consequences of the outcome-based framing are worth internalising before you design anything. First, a perfectly-functioning system can produce a reportable incident: nothing has to have malfunctioned. Second, the Commission's draft guidance takes the view that an indirect causal link suffices — its own worked example is an incorrect analysis from an AI system that causes harm only after a clinician acts on it. A human in the loop does not sever the chain. It is worth being blunt about that, because the human-approval step in most agent designs is quietly assumed to be a liability firewall, and here it is not.

Three deadlines, and the one that decides your architecture.

Article 73 sets an outer bound of 15 days from awareness, with two accelerated tracks, and requires the report "immediately" once a causal link is established regardless of which bound applies.

• 15 days — the default, counted from when the provider or, where applicable, the deployer becomes aware of the serious incident.
• 2 days — a widespread infringement, or a serious and irreversible disruption of critical infrastructure. This is the deadline that should drive your instrumentation, because it is the only one no manual process survives.
• 10 days — where a death may have been caused; here the trigger is explicitly "has established, or as soon as it suspects, a causal relationship".

The relief valve is Article 73(5): an initial, incomplete report is permitted, with the rest to follow. Use it. The obligation is to notify inside the window, not to have finished the investigation inside it, and organisations that treat the deadline as an investigation deadline are the ones that miss it. What the initial report still needs is enough to identify the system, the outcome, the affected parties and the reason you believe the two are linked — which is the artefact your telemetry either produces or does not.

The obligation and the observation sit in different companies.

The reporting duty falls on the provider — the party that puts the high-risk system on the market under its own name. The party that sees the harm is almost always the deployer. Article 26(5) closes the loop by requiring a deployer that identifies a serious incident to immediately inform the provider, and then the importer or distributor and the relevant market surveillance authority.

• If you build an agent product, you are probably a provider, and your two-day clock can be started by a customer's support ticket that lands in a shared inbox at 18:00 on a Friday. The intake path from customer to compliance is the control, and it is usually undesigned.
• If you deploy someone else's agent, you are in the chain and cannot outsource the timing. Your duty to inform the provider is immediate, and your provider's ability to meet a two-day deadline depends on when your ticket reaches them. This is the concrete version of the contractual argument in third-party and vendor risk.
• Substantial modification can make you the provider. Putting your name on a system, or changing its intended purpose, moves the obligation to you — which is a live question for anyone wrapping a foundation model in an agent and selling the result. Settle it in writing before an incident does it for you; the role mapping belongs in accountability and roles.
• General-purpose model providers have a parallel duty. Under Article 55(1)(c), providers of general-purpose models with systemic risk have had to track, document and report serious incidents to the AI Office since 2 August 2025, and the Commission has published a template for it. If your agent is built on such a model, there are two reporting chains in the picture and they do not merge.

Why agents are structurally bad at establishing a causal link.

The regulation's demand is modest — establish a causal link, or reasonable grounds to believe in one. The reason it is hard is that the properties that make agents useful are the same ones that destroy the evidence chain.

• The harm is several steps downstream of the model. An agent drafted a rejection, a human sent it, a candidate was excluded. To assert or exclude a causal link you need the trajectory, not the final output — which is why trajectory-level records are a compliance artefact and not only an eval one.
• Traces are sampled and traces expire. A 1% sampling rate is excellent observability practice and means that in 99 cases out of 100 you cannot reconstruct what happened. A 30-day retention window is normal, and a complaint that arrives on day 45 is a complaint you cannot investigate. Retention and legal hold is where this gets decided, and the decision is usually made by whoever set the default in the tracing config.
• The version that produced the output no longer exists. Model versions rotate, prompts are edited, retrieval indexes are rebuilt. Without a pinned record of exactly which model, prompt, tool set and index version served a given run, "was it the system" is unanswerable — the discipline in rollout and versioning, applied to evidence rather than to deploys.
• Retrieval is the usual confounder. When the harmful content came from a retrieved document, the causal question splits: did the system reason wrongly, or faithfully repeat a bad source? These have different corrective measures and you cannot distinguish them without recording what was retrieved, not just what was answered.
• Non-determinism means you cannot reproduce it. Re-running the prompt and getting an acceptable answer is not evidence that the system did not cause the harm, and it is a tempting conclusion under time pressure. The record is the evidence; the re-run is not.

All five point at the same fix, and it is not a compliance project. It is a decision about what the trace contains and how long it lives — the point at which tracing stops being an engineering convenience and becomes the thing that lets you file inside two days.

One event, several clocks, different recipients.

A single agent failure can be a serious incident, a personal-data breach, and an ICT incident at the same time, and the regimes do not defer to each other. Building one pipeline that assumes a single obligation is the standard mistake.

• GDPR — a personal-data breach goes to the supervisory authority within 72 hours, with a separate test and a separate recipient. An agent that emailed one customer's data to another has tripped this and may or may not have tripped Article 73.
• NIS2 and DORA — sectoral incident regimes with their own, often faster, clocks. For financial entities under DORA, the sensible reading of the Commission's guidance is that operational disruption stays on the DORA route while a fundamental-rights infringement still triggers the AI Act filing. Check the current position for your sector rather than assuming a merge.
• Sectoral product-safety law — where the high-risk system is a safety component of a regulated product, existing incident regimes apply and Article 73 is adjusted to avoid duplication.
• Customer contracts — notification windows in enterprise agreements are frequently shorter than any of the statutory ones, and they are the deadline your account team will actually feel.

What to build, in the order that pays.

Nothing here is a large project. All of it has to exist before the event, because none of it can be created during a two-day window.

• An intake path with a named owner and a stated response time. Every channel where harm can be reported — support, sales, the security inbox, an in-product report button — must route to one triage queue that a named role watches. Most organisations discover their gap here, in the ninety minutes it takes a ticket to be recognised as something other than a bug.
• A trace that survives. For any system touching an Annex III use case, retain full trajectories rather than samples, pinned to model, prompt, tool and index versions, for at least as long as your complaint window plus your investigation time. This is a cost — pay it deliberately rather than discovering the sampling rate during an investigation.
• A subject-and-time lookup. The first question in any real incident is "show me every run involving this person, on these dates". If your traces are indexed by request ID and nothing else, that query takes a week. Index for it, within the limits your data governance policy sets.
• A pre-filled report template. The Commission has published a reporting template; the parts that are stable — system identification, intended purpose, deployment geography, provider details, version scheme — should be filled in already and reviewed quarterly. Only the incident-specific fields should be written under time pressure.
• A drill, on the two-day track. Take a plausible fundamental-rights scenario, start a stopwatch at the moment a fictional customer email arrives, and see whether a filing-ready initial report exists 48 hours later. The first run of this exercise typically fails in the trace-retrieval step, not the legal one. Run it the way you run the rest of incident response.
• A corrective-measures record. The report is not the end: the regulation contemplates investigation, corrective action and cooperation with the authority. Whatever you change afterwards has to be traceable to the incident, which is the same evidentiary chain as audit trails.

Related: the EU AI Act for agents for the obligations this sits inside, accountability and roles for who is provider and who is deployer, decision receipts for the per-decision record that makes causation arguable, and the regulatory landscape for the regimes whose clocks run alongside this one.