AI Incident Triage

AI incident triage

Two jobs, and the second is time-critical: classify what happened, and establish whether a reporting clock is running. Do them in that order but do not let the first delay the second — EU AI Act Art. 73 and DORA deadlines run from the point of awareness, not from the point where your investigation concludes.

Immediately: is a clock running?

Before the detailed analysis, make a preliminary call and say so explicitly. Get this question to whoever owns the determination within the first hour.

Signals that an external obligation may be engaged:

• Death, serious harm to health, or serious damage to property
• Serious and irreversible disruption of critical infrastructure
• Breach of fundamental rights obligations
• Personal data breach (GDPR Art. 33 — 72 hours)
• ICT-related incident affecting a critical or important function (DORA)
• Any incident in a system classified high-risk under the EU AI Act

You are not the person who makes the reporting decision. Your job is to surface the possibility fast, with the facts, and route it. Never let a report imply that no obligation exists merely because you did not assess it — say what you assessed and what you did not.

Timings, for the escalation note: EU AI Act Art. 73 — 15 days generally, 2 days for widespread infringement or serious critical-infrastructure disruption, 10 days for death. An initial incomplete report is permitted to meet the deadline.

Then: classify

Run agent-failure-diagnosis for the mechanism, working from framework/diagnostic-manual.md.

The essentials, if you are doing it inline:

1. Collect artefacts first — trace, tool logs, inputs including retrieved content, outputs, memory state, permissions held. Not narrative. An agent's own account of what happened is evidence about R1 and nothing else.
2. Classify against criteria, recording every entry whose criteria are met. Do not assume a cascade — measured across 2,400 unscripted episodes in evidence/disorder/, only ~4% of incidents involved more than one environment-induced mode. Most are one failure sitting on top of a defect the policy already had, which is a different remediation.
3. Name the primary — the failure whose absence would have prevented the harm.
4. Severity from the manual's specifiers; blast radius realised (B0–B3), and separately the radius that was available. The gap between them is the near-miss, and it is often the more important number.
5. Check the tier — declared versus evidenced. A mismatch is a separate finding and is frequently the actual story.

Harm assessment

Distinct from severity, and the part most incident records skip.

• Who was affected, including people who were not users
• How many, and whether the number is known or estimated
• Whether affected people know — and whether they need to be told
• Whether the harm is reversible, and what reversal would take
• Whether it is ongoing — the first question, and the one that determines whether you are triaging or still responding

If the incident is ongoing, containment precedes analysis. Say so and stop.

Remediation

Distinguish three horizons, and be honest about which you have actually done:

Contain — stop the bleeding. Usually a halt, a permission revocation, or a rollback. Correct — fix this instance, including any bad state that was written. Prevent — the control that stops the class recurring.

Take candidate controls from the diagnostic manual entry, then say which would actually have prevented this instance. Be willing to say a listed control would not have helped. A remediation plan full of controls that would not have stopped the incident is how organisations persuade themselves they have fixed something.

Prefer controls enforced outside the model. If the proposed fix is "we updated the prompt," record that as a mitigation, not a control, and say why.

Output

# Incident — [system], [date]

## Status
[Ongoing / contained / resolved] · Detected [when] · Contained [when]

## Reporting assessment — PRELIMINARY
Possible obligations: [EU AI Act Art. 73 / DORA Art. 19 / GDPR Art. 33 / none identified]
Clock starts: [awareness date/time]
Routed to: [who owns the determination] at [when]

## What happened
[From the record. No speculation about intent.]

## Classification
Primary: **[code] [name]** — criteria A/B/C with evidence
Contributing: [codes]
Severity: [mild/moderate/severe]
Blast radius realised: [B_] · available: [B_]
Tier declared: [A_] · evidenced: [A_]

## Harm
Affected: [who, how many, known or estimated]
Reversible: [yes/no — what reversal requires]
Notification needed: [yes/no/undetermined]

## Remediation
| Horizon | Action | Owner | Status |
|---|---|---|---|
| Contain | | | |
| Correct | | | |
| Prevent | | | |

## Evidence gaps
[What you could not obtain and what it prevents concluding.]

Append to incidents on the system record using framework/system-record.schema.json.

Why consistency matters more than eloquence here

A well-written incident report that classifies by vibe is worth less than a terse one that classifies by criteria. The value compounds only if records aggregate: ten incidents classified consistently show you where your controls actually are, while ten described in prose show you nothing. Resist the pull toward narrative.

Near misses

Triage them the same way. An agent that could have sent the wrong payment and did not, because a rate limit happened to fire, is the cheapest possible lesson about a real B3 exposure. Record the available blast radius, not the realised one, and treat it with the severity that reach deserves.