I was writing the incident runbook for an AI feature we ship, and I got stuck on the first line.

When the model is wrong in a way that lands on a person, who do we tell?

"Escalate to legal" was my whole answer. It is also wrong. Article 26(5) of the EU AI Act does not ask deployers to loop in counsel. It sets a notification order: where a deployer has identified a serious incident, it shall immediately inform first the provider, then the importer or distributor and the market surveillance authorities. Provider first. Regulator after. And if the provider cannot be reached, Article 73 applies to the deployer anyway.

I had been treating incident response as a communication problem. It is a notification-order problem, and the clock starts the moment you realise something is wrong.

The two triggers hiding inside Article 26(5)

First, the role. A deployer is someone using a high-risk AI system under their own authority for a professional purpose. If we build the system and ship it, we are the provider, and Article 73's reporting duty is ours directly. If we use someone else's system in our hiring or credit workflow, we are the deployer, and 26(5) is our obligation.

Second, 26(5) has two triggers, not one. The risk trigger: where a deployer has reason to consider that use of the system may result in a risk within the meaning of Article 79(1), it shall without undue delay inform the provider or distributor and the market surveillance authority, and shall suspend use of that system. Then the serious-incident trigger: provider first, then importer or distributor, then the authorities.

Put together, the deployer sequence is: stop the bleeding locally, tell the provider, escalate up the chain to the authority. Counsel is not in that sequence — counsel is in the sequence for the timeline, not the notification.

A third obligation decides whether any of this is possible. Article 26(6) says deployers shall keep the logs automatically generated by the high-risk AI system, to the extent such logs are under their control, for at least 6 months. If the logs do not exist, the notification is a phone call with nothing behind it.

Article 73's clock is shorter than I assumed

Article 73 covers the other half: reporting of serious incidents by providers. The provider reports to the market surveillance authorities of the Member States where the incident occurred, immediately after establishing a causal link or the reasonable likelihood of one, and in any event not later than 15 days after the provider, or where applicable the deployer, becomes aware of it. A widespread infringement is immediately and not later than 2 days. A death, immediately and not later than 10 days.

First, "becomes aware" starts the clock on the deployer's side as well. The moment you spot it you are on the clock, reached anyone or not.

Second, an initial report may be incomplete, followed by a complete one. That sentence makes the first call possible: you do not need the full causal picture to notify.

Third, and this is the one I would have got wrong: after reporting, the provider must investigate without delay, and must not alter the AI system in a way that may affect any later evaluation of the causes, before informing the authorities. My instinct during an incident is to fix it — patched prompt, redeploy, close the ticket. Under 73(6) that instinct can damage the report.

Everything turns on what counts as a serious incident. Article 3(49) covers an AI system that directly or indirectly leads to: death or serious harm to health; a serious and irreversible disruption of critical infrastructure; an infringement of Union law intended to protect fundamental rights; or serious harm to property or the environment.

That third limb is the one a small team should sit with. A model that wrongly denies someone an essential benefit can infringe rights protections without anything catching fire.

Two of the four inputs decide the readiness call

The form takes four inputs: an incident scenario, a sector, whether a playbook exists, and the notify target in hours (24, 48, or 72).

I expected the scenario to drive the output. It drives the narrative section, where the scenario is quoted back up to 220 chars, but not the verdict. The readiness call comes from the other two:

Playbook on file Notify target Readiness call
No any CRITICAL
Yes 48 hours or less READY
Yes more than 48 hours GAPS

The gap list moves with the same two inputs. With a playbook on file, the first gap is to rehearse a tabletop at least annually. Without one, it is marked CRITICAL: write the playbook and name owners for it. Two gaps are always there: a contact tree with the provider and the competent authority path, and counsel review before timelines close.

A rules engine cannot read a novel incident and know whether it is serious, so it refuses to pretend. It gives you the two facts it can verify: is there a named playbook, and how fast we committed to notify.

The engine is rules-first, on purpose

The whole verdict is a few lines of deterministic logic, not a prompt:

let readiness = has ? 'gaps' : 'critical' if (has && hours <= 48) readiness = 'ready'

Same inputs, same pack, every time. The draft path has no model in it. An optional layer polishes wording with the instruction to keep headings and not invent legal conclusions. That boundary is the product: a model that can reword the notify order is worse than no tool, because then you cannot tell law from generated text.

The workflow is three steps: paste your inputs, run it in demo or live mode, then take the draft to counsel. The pack has an incident call, five playbook steps (triage, contain, notify and track the clock, preserve logs, post-incident review), a gaps checklist, and an honesty note.

You can open IncidentKit and run it without signing up. It is $19/mo, or $190/yr.

What it is not

  • Not legal advice. It is decision-support. Your counsel signs the timeline.
  • Not a completed compliance artifact. A starter draft: steps, gaps, and a readiness call, not a filed report.
  • Not a substitute for a DPO or qualified counsel. The gap list itself asks for counsel review before timelines close.
  • Not a risk classifier. It will not tell you if your system is high-risk, or if your incident meets Article 3(49).
  • Not monitoring. It does not collect logs, watch your deployment, or page anyone.
  • Not broad third-party risk management, and not a certification. Act-focused on serious-incident readiness: no vendor scoring, no framework coverage, and it files nothing with any authority.

FAQ

Q: Does this tell me if our incident is a "serious incident" under Article 3(49)?

A: No. The draft gives you the Article 26(5) and Article 73 themed steps, a readiness call, and a gap list. Deciding if your event meets Article 3(49) is a legal judgment.

Q: Who is the provider and who is the deployer here?

A: If you built the system and put it on the market, you are the provider and Article 73's reporting duty is yours. If you use someone else's high-risk AI system under your own authority, you are the deployer, and 26(5) governs notification.

Q: What does the readiness call mean?

A: It is computed from two inputs only: whether a playbook exists, and your notify target. No playbook gives CRITICAL. A 48-hour or shorter target gives READY. A longer target gives GAPS. It measures documentation readiness, not compliance.

Q: Does the AI write the legal content, and can I get the draft out?

A: The draft path is rules-only, and the optional model layer only polishes wording, so the headings, readiness call, and gaps stay deterministic. You can copy the result as Markdown, and there is a REST endpoint behind the form.

References