Regulatory Reporting for AI Incidents, in depth: one incident and many regimes, clock computation, a shared fact sheet and the evidence pack

The regime matrix

The table lists regimes that commonly touch AI incidents. The point is the shape of the data, which is what your system must encode: a trigger, a recipient, a clock-starting event and a sequence of stages.

Two timing facts about the EU AI Act deserve care. Article 73 duties attach to high-risk systems, and the Digital Omnibus on AI, formally adopted in mid-2026, deferred high-risk obligations to 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for systems embedded in Annex I products. Your applicability rules should carry those dates rather than assuming the duty is live. Second, the day counts usually quoted for general-purpose models come from the Code of Practice, which binds only signatories; the Act itself says without undue delay. Keep the two distinct in your data so a non-signatory does not inherit commitments it never made, and a signatory does not forget them.

When clocks start

Notice that the clock-starting events differ: awareness, discovery, classification, materiality determination. These are distinct moments that can be days apart, and each needs its own timestamp in the incident record, captured when it happens, by a named person. Awareness in particular is not the time the root cause was understood. Regulators generally read it as the point at which you had a reasonable degree of certainty that a qualifying event occurred, so an on-call engineer confirming that customer records left the system is often the start, even if nobody yet knows how.

This is why incident tooling must record decisions, not just events. A record that says 2026-10-01 09:40 UTC: confirmed exfiltration of records from tenant A, decided by on-call lead is evidence for the timing of every later report. A chat log from which someone later infers the moment is not.

Architecture of a reporting pipeline

The pipeline has five components. The incident record holds facts and timestamped decisions. The applicability engine evaluates each regime's trigger against the record. The clock engine turns triggered regimes into dated stages. The fact sheet is the single agreed statement of what happened, versioned, with every claim linked to evidence. Report drafts are rendered per regime and stage from that fact sheet, and the submission receipt of one stage starts the clock of the next.

Computing deadlines

Encode regimes as data so counsel can review them without reading control flow. Each stage names the event that starts it and an offset in hours or business days. The sketch below computes deadlines and sorts them, so the earliest obligation is always at the top of the dashboard.

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone
from typing import Callable

NOT_YET = datetime.max.replace(tzinfo=timezone.utc)   # all timestamps are UTC-aware

@dataclass
class Stage:
    name: str
    starts_at: str              # key into incident["events"]
    hours: int | Callable[[dict], int] = 0
    business_days: int = 0

def add_business_days(t: datetime, n: int) -> datetime:
    while n > 0:                 # weekends only; load public holidays per regulator
        t += timedelta(days=1)
        if t.weekday() < 5:
            n -= 1
    return t

REGIMES = {
    "gdpr_art33": dict(
        applies=lambda i: i["personal_data"] and i["role"] == "controller",
        recipient="lead supervisory authority",
        stages=[Stage("notification", "aware", hours=72)]),
    "nis2_art23": dict(
        applies=lambda i: i["nis2_entity"] and i["significant"],
        recipient="CSIRT or competent authority",
        stages=[Stage("early warning", "aware", hours=24),
                Stage("notification", "aware", hours=72),
                # one calendar month; 28 days is the safe floor
                Stage("final report", "nis2_notification_sent", hours=28 * 24)]),
    "sec_8k_105": dict(
        applies=lambda i: i["us_listed"] and i["events"].get("material"),
        recipient="SEC (Form 8-K)",
        stages=[Stage("8-K", "material", business_days=4)]),
    "eu_ai_act_art73": dict(
        applies=lambda i: i["eu_high_risk"] and i["serious"]
                          and i["events"]["aware"] >= i["art73_applies_from"],
        recipient="market surveillance authority",
        stages=[Stage("report", "aware",
                      hours=lambda i: 48 if i["widespread_or_critical_infra"]
                      else 240 if i["death"] else 360)]),
}

def deadlines(incident: dict) -> list[tuple[datetime, str, str]]:
    out = []
    for name, r in REGIMES.items():
        if not r["applies"](incident):
            continue
        for st in r["stages"]:
            start = incident["events"].get(st.starts_at)
            if start is None:
                out.append((NOT_YET, name, f"{st.name}: waiting for '{st.starts_at}'"))
                continue
            hours = st.hours(incident) if callable(st.hours) else st.hours
            due = add_business_days(start, st.business_days) if st.business_days \
                else start + timedelta(hours=hours)
            out.append((due, name, f"{st.name} to {r['recipient']}"))
    return sorted(out)

Two details carry the design. Stages whose starting event has not happened yet are listed as waiting rather than dropped, so the dashboard shows that the final NIS2 report exists as an obligation before the notification is sent. And the Article 73 entry shows the awkward part of severity-dependent limits: its offset is a function of the incident, because the window depends on facts (a death, a critical-infrastructure disruption) that may emerge after the first assessment. Recompute on every record update, since a later fact can shorten a deadline that was already running.

One fact sheet for every report

The commonest self-inflicted problem in multi-regime reporting is inconsistency: the data protection notice says 4,100 people were affected, the securities filing says about 4,000, and the cybersecurity notification describes a different entry point because a different team drafted it on a different day. Each statement was defensible when written; together they look evasive.

Prevent this with a versioned fact sheet: a short structured document with fields for what happened, when, which systems and model versions, how many people and which data categories, the cause as currently understood, and the mitigations taken. Every field carries a confidence label (confirmed, preliminary, unknown) and links to evidence items. Report drafts are rendered from a specific fact sheet version, and the submitted report stores that version number. When the facts change, you know exactly which submitted reports now need an update.

LLM assistance is reasonable for turning the fact sheet into each regulator's prose format, with a strict rule: the draft may only restate fact-sheet fields, and a check rejects any number, date or system name in the draft that does not appear in the fact sheet. A human with authority to sign reads every draft before submission.

The evidence pack

AI incidents have evidence that conventional incident tooling does not capture by default. Put these under legal hold in the first hour:

• Model identifiers and versions, including fine-tune and adapter versions, and the prompt or prompt-template versions in effect.
• Request and response logs for the affected window, with tool calls and their arguments; retrieval logs showing which documents entered the context.
• Guardrail and classifier decisions with their thresholds at the time.
• Configuration and feature-flag history, so you can show what changed and when.
• Evaluation results for the deployed version, which bear on whether the risk was known and tested.
• The decision log described above: who decided what, at what time.

Hash each exported artefact and record the hash in the incident record. Retention jobs are a real threat here: a 30-day log expiry policy will happily delete the evidence for a report whose final stage is due in six weeks, so the hold must suspend deletion rather than copy a sample.

Worked example: an injected support assistant

A US-listed software company runs a customer-support assistant for business customers in the EU. The assistant can look up account records through a tool. On Thursday 1 October 2026 at 09:40 UTC the on-call lead confirms that a prompt injection planted in a support ticket made the assistant fetch and echo records from another customer's tenant. That is the aware timestamp.

The applicability engine evaluates each regime. For the business customers' end-user data the company is a processor, so GDPR Article 33 duties fall on its customers; its own duty is to notify each affected controller without undue delay, which the clock engine shows as an immediate task. For its own account-holder data it is a controller, so a 72-hour notification is due by Sunday 4 October 09:40 UTC; weekends do not pause it. The company falls under NIS2 as a cloud computing service provider, and theincident is assessed as significant, so an early warning is due by Friday 09:40 and a notification by Sunday 09:40, with the final report waiting on the notification timestamp. The support assistant is not a high-risk system, so Article 73 does not apply; on the deferred timeline it would not be live for Annex III systems before December 2027 in any case. The disclosure committee determines materiality on Monday 5 October; the 8-K stage becomes due on Friday 9 October.

The fact sheet at version 3 states 1,240 records exposed, preliminary; version 5, after log analysis, states 1,187, confirmed. The clock engine flags that the GDPR notification was submitted from version 3 and needs a follow-up, and the 8-K draft renders from version 5. Every regulator gets the same number for the same date.

Failure modes

• Awareness recorded late. Teams backdate the start to when the root cause was found. Record the decision when it is made, and let counsel argue timing from accurate data.
• One regime only. Security teams think in breach terms and miss the AI-specific or sector regime, or the reverse. Run every regime's trigger on every incident and record a reasoned not applicable.
• Forgotten follow-up stages. Intermediate and final reports are where deadlines are most often missed, because the incident has gone quiet. The clock engine must track them as open obligations.
• Inconsistent numbers. Solved by the fact sheet; caused by drafting in parallel from memory.
• Over-reporting speculation. Stating a suspected cause as fact. Label confidence, and say what is still being investigated.
• Rules frozen in code. Application dates move, as the omnibus showed. Keep regime data versioned and owned by a named reviewer.

Trade-offs

What to do next

1. List the regimes that could apply to each AI system, with counsel, and encode each as trigger, recipient, clock-start event and stages.
2. Add timestamped decision fields to your incident record for awareness, classification, discovery and materiality.
3. Build or adapt a clock engine that recomputes deadlines on every record update and shows waiting stages.
4. Create a fact sheet template with confidence labels and evidence links, and render every draft from a fact sheet version.
5. Write a legal-hold runbook covering model, prompt, retrieval and guardrail logs, and test that it suspends retention jobs.
6. Run a tabletop exercise with one incident that triggers at least three regimes, and time each stage.