A lender runs an AI agent that helps assess loan applications. On a Monday, a customer complains that her application was rejected for a reason that makes no sense. A support lead looks at it, thinks it might be a one-off, and moves on. On Thursday, a second complaint arrives with the same pattern. On the following Wednesday, someone in compliance asks a question nobody has asked yet: is this a serious incident?
By now a week has passed. Nobody can say when the agent's behavior changed, because a prompt was edited and a model version was upgraded in the same fortnight. The logs hold the final answers but not the retrieved context. The engineer who made the change is on leave. And the clock, depending on the answer to that question, may have started on Monday.
This is a hypothetical, but every ingredient is real. This article starts with the problem: what a reporting clock demands, why agents make it hard to meet, and what usually goes wrong. Only then does it turn to a way of handling it. It is not legal advice, so check anything specific with counsel.
What the clock is
The EU AI Act includes a regime for reporting serious incidents. Article 73 requires providers of high-risk AI systems to report a serious incident to the market surveillance authorities of the Member State where it occurred. As summarized by several legal guides, the deadlines depend on severity:
15 days after becoming aware, as the general rule.
10 days where the incident involves the death of a person.
2 days for widespread infringements, or serious and irreversible disruption of critical infrastructure.
The report is due immediately after the provider establishes a causal link, or a reasonable likelihood of one, and in any case no later than those limits. Deployers must inform the provider without delay. Initial reports may be incomplete, with fuller information to follow. Providers of general-purpose AI models with systemic risk have a separate duty to report serious incidents to the AI Office.
Two cautions. First, summaries differ on how days are counted, and the Commission has been consulting on draft guidance and a reporting template, so check the official text and the final guidance. Second, the timing has moved. The Digital Omnibus on AI, Regulation 2026/1744, in force since 27 July 2026, deferred the high-risk obligations for Annex III systems to 2 December 2027, and for systems embedded in regulated products under Annex I to 2 August 2028. So for many providers, the Article 73 clock is not yet running, but it will be, and other regimes already run clocks of their own. A personal data breach under the GDPR, for instance, has a 72 hour notification window to the regulator.
Why agents make the clock hard
A reporting deadline sounds like an administrative matter. For agents, it is an engineering problem, because meeting it requires answering hard questions quickly.
Awareness is fuzzy. The clock runs from the moment you become aware, or suspect a causal link. In the scenario above, was that Monday, Thursday, or Wednesday? One practitioner has pointed out that fifteen days is not much runway if the first conversation about whether something is an incident does not happen until day six or seven.
Classification needs facts. Deciding whether an event is a serious incident, and which tier applies, depends on what the system did and what harm followed. If you cannot reconstruct the behavior, you cannot classify it, and you cannot tell whether you are in the 15 day tier or a shorter one.
Agents are not deterministic. You cannot rerun the failing case and expect the same result. The evidence has to come from what was recorded at the time, not from trying again.
Context is invisible. What the agent retrieved, which tool results it saw, and what memory it used are rarely in the logs. Without them, the question why cannot be answered.
Everything changes underneath. Prompts, models, tools, and memory change often. By the time someone investigates, the system that caused the incident no longer exists in that form.
Scope is unknown. The first complaint is rarely the only one. To report responsibly you need to know how many other people were affected, and that means finding every similar decision.
What the data says about how often this happens
Incident counts are rising, though counting them is difficult. The Stanford AI Index 2026, drawing on the AI Incident Database, reports 362 documented incidents in 2025, up from 233 in 2024. The OECD, which monitors media reports, found that reported AI incidents and hazards rose from an average of 92 a month in 2022 to 324 a month in 2025.
These figures need care. The AI Incident Database is a curated collection and not a census, and analysts note that growth partly reflects better detection and reporting, and that the true number is undercounted. They also cover a very broad range of harms, from deepfake fraud to physical safety failures, and do not measure how many incidents would meet the legal definition of serious. The fair reading is that incidents are becoming common enough, and visible enough, that regulators and customers expect organizations to have a process for them.
Where it goes wrong in practice
Teams that struggle with incident response tend to fail in the same places.
Nobody owns the call. Engineering assumes compliance will decide, and compliance assumes engineering will flag it. The clock runs while the question sits unanswered.
The causal link cannot be established. Without the chain from input to decision, you cannot say whether the system caused the harm, which is the very thing the report turns on.
The past cannot be recreated. Nobody can say which prompt, model, or memory was live when the decision was made.
The evidence cannot be trusted. Logs that anyone with access can edit invite the question of whether they were changed after the incident.
Fixes destroy evidence. In the rush to stop the harm, the team patches the prompt or clears the memory, and the state that caused the incident is gone.
The scope is a guess. Without a way to find every similar decision, the team either reviews everything or reports on an assumption.
What it costs
Missing the clock has direct and indirect costs. A practitioner guide states that penalties for provider obligations can reach 15 million euro or 3 percent of global annual turnover, but check the Act's penalty article for the exact tier that applies to you.
The indirect costs are probably larger. A late or thin report tells a regulator that you did not know what your system was doing. It also invites a wider inquiry, with requests for documentation that is hard to produce on demand. Customers in finance, health, and insurance ask the same question in procurement: what is your incident process, and can you show it working? An organization that cannot answer loses deals before any incident happens.
What good looks like
Teams that handle incidents well have prepared for the clock before it starts. The practices are common to most guidance:
Name an owner for the classification decision, with a deadline measured in a day or two, and write down the reasoning, including dissent.
Preserve before you fix. Take a snapshot of prompts, model versions, tool settings, and memory before changing anything.
Reconstruct from records made at the time. The record should include inputs, retrieved context, tool results, and decisions, linked to each other.
Scope downstream. Be able to list every later decision that depended on the faulty step.
Keep evidence that can be verified. An auditor should be able to check that the record was not altered after the incident.
Report early and complete later. Use an initial report with what you know, and follow with detail as the investigation proceeds.
Rehearse. Run a tabletop exercise on a past session and see how long it takes to answer the regulator's questions.
How ZizkaDB helps
ZizkaDB is an open source causal database for AI agents. It records activity as linked events and makes the record tamper-evident. It does not decide whether something is a serious incident, and it is not legal advice. What it gives you is the evidence to answer the questions the clock demands, fast. Here is the opening scenario again, with a record in place.
Day one, find the event. Open the complaint session in the dashboard and use session replay to read it in order. Run the lineage call on the rejected decision. It returns the chain of inputs, retrieved context, tool results, and prior steps behind it, so the causal link is a lookup and not an argument.
Day two, rebuild what was live. The time travel function reconstructs state at the moment of the decision from the state events you log, such as prompt versions, model names, and enabled tools. It shows that the prompt edit and the model upgrade both preceded the first bad decision, and lets you test which one the pattern follows.
Day three, scope it. The impact route walks downstream from the faulty step to list every later decision that depended on it, and the baseline comparison shows when behavior began to shift. Instead of guessing, you know how many applications are affected.
Day four, preserve and prove. Because the state is recorded as events, you can fix the prompt without erasing what it was. Each event carries a SHA-256 checksum and a chain hash linked to the previous one, so editing or deleting a record breaks verification. Run the verification, and store the chain head outside the database.
Day five, report. Export the relevant history, attach the verification result, and write the report from the record. The Audit action on GitHub produces an attested report, and read-only, expiring keys let you give an authority or auditor access to the evidence without handing over your own credentials.
Redaction before storage and retention settings help you keep personal data out of what you share, and erasure tombstones keep the chain verifiable when data must be removed.
What to record before any incident. The five days above only work if the right events exist. Three habits cover most of it:
Log configuration as state whenever it changes: prompt version, model name, enabled tools, and policy settings.
Log retrieval events that list which memories and documents were supplied to the model, and make the model call their child.
Log the decision and its inputs together, so the lineage call returns something a regulator can read.
What the clock asks, and what answers it.
What the regulator or clock demands What supports it
Establish the causal link quickly Causal lineage from the harmful decision back to its inputs
Show what the system was at the time Time travel over logged state events
Find everyone affected The impact route, plus baseline comparison to date the shift
Prove the evidence was not altered SHA-256 checksums, hash chain, external chain head
Share evidence safely with authorities Read-only, expiring keys and an attested audit report
Keep personal data out of the pack Redaction before storage, retention, erasure tombstones
Prepare for the next one Scheduled chain verification and rehearsal on past sessions
None of this is exotic. It is the same record that helps with debugging, drift, and audits, used under a deadline. That is the practical argument for building it before you need it: an incident is the worst moment to start.
The honest scope: ZizkaDB does not classify incidents, decide who must be told, or draft your legal position. It only helps if you recorded the right things in advance, including state and retrieval events. The open source edition records one agent per install, and multi-agent coverage is a Cloud feature.
Start this week
Pick one high-impact agent and rehearse the clock. Take a real session from last month and ask a colleague outside the build team to answer three questions using only your records: what did the agent see, what was it configured to do, and who else was affected? Time it. If the answer takes days, you have found your gap before a regulator did. Then start recording each step with its cause, log your configuration as state, and schedule a chain verification.
Want to test ZizkaDB on your agent? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB Interested in a design partnership? Fill in the form on our site or reach me directly at founder@zizka.ai
Sources: Article 73 summary, RGPD.com · Article 73, SpringLex · Article 73, Responsible AI Platform · Babl AI, Commission draft guidance on incident reporting · CIO, The EU AI Act breach notification clock · Usercentrics, Digital Omnibus in force · Gibson Dunn, Omnibus agreement · Cloud Security Alliance, incident disclosure gap · RockCyber, AI incident and benchmark trends · Axis Intelligence, AI safety statistics · Devdiscourse, OECD study of AI incident reporting · sota.io, Article 73 timelines guide · ZizkaDB changelog · ZizkaDB repository