Reporting a serious AI incident starts long before the incident
The AI Act's incident duty runs on a clock measured in days, and an organisation that begins assembling the facts when the clock starts will not meet it. What makes the deadline achievable is decided at design time.
Incident reporting obligations are read as a process question and filed with the people who own processes. Somebody writes a procedure, it names a mailbox and an escalation path, and it is approved. The procedure is not wrong. It is also not the thing that determines whether a report can be made.
What determines that is whether the facts exist. A report about an AI system requires knowing what the system did, on what basis, to whom, and how far the effect spread — and every one of those is a property of what the system recorded at the time, not of how well the incident process is written.
The claim: an incident duty is an evidence requirement in disguise, and the evidence is created or lost during the build.
What the duty asks for
Article 73 of the EU AI Act requires providers of high-risk systems to report serious incidents to the market surveillance authority of the member state where the incident occurred, on short timelines that tighten further for widespread infringements and for incidents involving death. The Commission has consulted on guidance and a reporting template to go with it, and the analysis of that draft by Latham & Watkins is a readable summary of where the interpretive difficulty sits.
Two features of the draft matter more than the deadlines. The causal link may be indirect: an incorrect output that leads to harm only through a subsequent human decision can still be reportable, which removes the most common assumption that a human in the loop breaks the chain. And the definition reaches beyond physical harm into serious disruption of critical infrastructure, infringement of fundamental rights and damage to property — categories that require somebody to have been watching for them.
The clock, and where it actually starts
- Before anything The system records what it did Inputs, retrieved material, versions, output, and what the human on the other end did with it.
- The event Something goes wrong for someone Most incidents in these systems are noticed by the affected person, not by monitoring.
- Awareness The organisation becomes aware This is the trigger, and it is a fact about your detection, not about the event.
- Days, not weeks Initial report With what is known — the duty does not wait for a complete investigation.
- After Investigation and corrective action Reconstruction of the specific output, and what changed as a result.
The third row is the one worth arguing about internally. The clock starts at awareness, so an organisation with poor detection has a longer period of undetected exposure and a shorter period of comfort, not the reverse. A complaint that sat in a service inbox for three weeks does not extend the deadline. It compresses everything after it.
What has to be recorded for a report to be possible
- 01 The request What was asked, by whom, and under whose entitlement.
- 02 The basis What the system retrieved or was given, at which version.
- 03 The output What it produced, with the model and prompt versions recorded.
- 04 The action What the person did — accepted, edited, overrode, escalated.
- 05 The spread How many others received the same behaviour, which needs the trace to be queryable.
The fifth stage is the one that separates an incident report from a guess. The question a regulator asks after “what happened” is “how many”, and answering it requires the records to be searchable by behaviour rather than only retrievable by case. That is a storage and indexing decision, made once, cheaply, at the start — and effectively unavailable afterwards.
The last line is the cheapest assurance available in this whole area. Pick an output from three months ago and ask the team to reconstruct it end to end. The exercise takes a day and it answers, definitively, whether the organisation could respond to a regulator. Most first attempts fail, and they fail on the same thing: the index has changed and the source document versions were not kept.
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.
What is not a legal question is whether your systems can produce the facts. That is an architecture question, it has a definite answer today, and the answer in most estates is no.
The reader who should act is whoever owns the incident process. Book the rehearsal before the procedure is approved. A procedure that has never been run against a real output is a document describing a capability the organisation may not have.