Reporting a serious AI incident starts long before the incident

A serious-incident procedure needs more than an escalation address and an approved document. Its owner must be able to establish what happened, identify the relevant system and assess the reporting obligation. The procedure depends on records and detection routes designed into the service.

Useful records connect the request, evidence, system versions, output and subsequent action. They also help establish who may have been affected and whether similar behaviour occurred elsewhere. Decide which of these facts the service must preserve, how they can be retrieved and which retention limits apply.

Design the evidence needed for incident assessment before approving the reporting procedure. A response team cannot reliably reconstruct facts that the service never recorded, and an approved process does not establish that those facts are available.

What the duty asks for

Article 73 of the EU AI Act addresses providers of high-risk systems. The official consolidated text requires reporting immediately after establishing a causal link or its reasonable likelihood, and ordinarily no later than 15 days after the provider or deployer becomes aware of the serious incident. Specified widespread infringements and critical-infrastructure incidents have a two-day outer limit. Incidents involving death have a ten-day limit and an immediate reporting trigger once a link is established or suspected. Assess role, incident category and the provisions’ applicable dates with legal advisers. Latham & Watkins’ analysis of the earlier draft guidance provides historical context, rather than a substitute for the current text.

A human decision between the output and the harm does not by itself settle whether an incident is reportable. Investigate the possible causal link. The Act’s serious-incident definition includes specified harms involving health, critical infrastructure, fundamental rights, property or the environment. The response process needs routes for identifying those harms, including complaints and reports outside technical monitoring.

The clock, and where it actually starts

1. Before anything The system records what it did Design time Inputs, retrieved material, versions, output, and what the human on the other end did with it.
2. The event Something goes wrong for someone Often invisible Detection may come through monitoring, complaints or service teams.
3. Awareness The organisation becomes aware Assess reporting trigger Record awareness and assess the causal link, incident category and applicable deadline.
4. Days, not weeks Initial report Statutory With what is known — the duty does not wait for a complete investigation.
5. After Investigation and corrective action Ongoing Reconstruction of the specific output, and what changed as a result.

Record when the organisation became aware, what information was available and when a causal link was established or suspected. These facts inform the applicable deadline. An incomplete initial report may be followed by a complete one, so the team should not delay escalation while waiting for the entire investigation to finish.

What has to be recorded for a report to be possible

1. 01 The request What was asked, by whom, and under whose entitlement.
2. 02 The basis What the system retrieved or was given, at which version.
3. 03 The output What it produced, with the model and prompt versions recorded.
4. 04 The action What the person did — accepted, edited, overrode, escalated.
5. 05 The spread How many others received the same behaviour, which needs the trace to be queryable.

A single case trace can explain one output. Assessing the wider impact may require searches across outputs, affected populations and system versions. Specify those queries and test them before relying on the reporting process. Existing records may support retrospective analysis, but omitted information cannot always be recovered.

Rehearse a reconstruction using a retained output from the relevant period. Measure the time required, identify inaccessible evidence and record what remains uncertain. The result supports a specific response capability. It cannot establish readiness for every incident or replace the legal assessment of whether an event is reportable.

Who this applies to

The Article 73 duty attaches to providers of high-risk systems, and a great many organisations reading this are deployers rather than providers, or are running systems that are not high risk. That does not make the exercise irrelevant, for two reasons.

Deployers have their own duties, including cooperating with providers and informing them of incidents, and a deployer who cannot describe what happened is not able to discharge them. And the role can change without anyone deciding to change it — an organisation that adapts a system substantially, or puts its own name on one, can find itself holding provider obligations it never accepted.

What this does not tell you

Whether a particular event is a serious incident under the Act, and whether your system is high risk, are legal determinations that depend on facts we do not have. The guidance is recent, the interpretation is not settled, and the classification question is exactly where we would tell you to involve counsel rather than a framework.

The architecture review can establish which facts the service records and whether the response team can retrieve them. That finding should be explicit: demonstrated, partly demonstrated or missing. It gives the incident owner a concrete basis for deciding which evidence gaps to address.

Before accepting the procedure, the incident owner should review a completed rehearsal with the system and legal owners. Agree reporting responsibilities, evidence access and unresolved limitations. Keep that decision current when the service, supplier or retention policy changes.