{"slug": "the-15-day-clock-could-you-reconstruct-an-ai-incident-before-the-deadline", "title": "The 15-Day Clock: Could You Reconstruct an AI Incident Before the Deadline?", "summary": "A practitioner analysis argues that the EU AI Act's Article 73 serious-incident reporting deadlines—15 days generally, 10 days for deaths, and 2 days for widespread infringements—pose a hard engineering problem for AI agents, because non-deterministic behavior, invisible retrieval context, and frequent prompt and model changes make incidents impossible to reconstruct after the fact. The piece notes the Digital Omnibus on AI (Regulation 2026/1744, in force since 27 July 2026) deferred high-risk obligations to December 2027 for Annex III systems and August 2028 for Annex I products, while GDPR's 72-hour breach window already applies.", "body_md": "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?\n\nBy 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.\n\nThis 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.\n\nWhat the clock is\n\nThe 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:\n\n15 days after becoming aware, as the general rule.\n\n10 days where the incident involves the death of a person.\n\n2 days for widespread infringements, or serious and irreversible disruption of critical infrastructure.\n\nThe 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.\n\nTwo 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.\n\nWhy agents make the clock hard\n\nA reporting deadline sounds like an administrative matter. For agents, it is an engineering problem, because meeting it requires answering hard questions quickly.\n\nAwareness 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.\n\nClassification 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.\n\nAgents 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.\n\nContext 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.\n\nEverything 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.\n\nScope 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.\n\nWhat the data says about how often this happens\n\nIncident 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.\n\nThese 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.\n\nWhere it goes wrong in practice\n\nTeams that struggle with incident response tend to fail in the same places.\n\nNobody owns the call. Engineering assumes compliance will decide, and compliance assumes engineering will flag it. The clock runs while the question sits unanswered.\n\nThe 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.\n\nThe past cannot be recreated. Nobody can say which prompt, model, or memory was live when the decision was made.\n\nThe evidence cannot be trusted. Logs that anyone with access can edit invite the question of whether they were changed after the incident.\n\nFixes 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.\n\nThe scope is a guess. Without a way to find every similar decision, the team either reviews everything or reports on an assumption.\n\nWhat it costs\n\nMissing 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.\n\nThe 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.\n\nWhat good looks like\n\nTeams that handle incidents well have prepared for the clock before it starts. The practices are common to most guidance:\n\nName an owner for the classification decision, with a deadline measured in a day or two, and write down the reasoning, including dissent.\n\nPreserve before you fix. Take a snapshot of prompts, model versions, tool settings, and memory before changing anything.\n\nReconstruct from records made at the time. The record should include inputs, retrieved context, tool results, and decisions, linked to each other.\n\nScope downstream. Be able to list every later decision that depended on the faulty step.\n\nKeep evidence that can be verified. An auditor should be able to check that the record was not altered after the incident.\n\nReport early and complete later. Use an initial report with what you know, and follow with detail as the investigation proceeds.\n\nRehearse. Run a tabletop exercise on a past session and see how long it takes to answer the regulator's questions.\n\nHow ZizkaDB helps\n\nZizkaDB 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.\n\nDay 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.\n\nDay 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.\n\nDay 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.\n\nDay 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.\n\nDay 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.\n\nRedaction 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.\n\nWhat to record before any incident. The five days above only work if the right events exist. Three habits cover most of it:\n\nLog configuration as state whenever it changes: prompt version, model name, enabled tools, and policy settings.\n\nLog retrieval events that list which memories and documents were supplied to the model, and make the model call their child.\n\nLog the decision and its inputs together, so the lineage call returns something a regulator can read.\n\nWhat the clock asks, and what answers it.\n\nWhat the regulator or clock demands What supports it\n\nEstablish the causal link quickly   Causal lineage from the harmful decision back to its inputs\n\nShow what the system was at the time    Time travel over logged state events\n\nFind everyone affected  The impact route, plus baseline comparison to date the shift\n\nProve the evidence was not altered  SHA-256 checksums, hash chain, external chain head\n\nShare evidence safely with authorities  Read-only, expiring keys and an attested audit report\n\nKeep personal data out of the pack  Redaction before storage, retention, erasure tombstones\n\nPrepare for the next one    Scheduled chain verification and rehearsal on past sessions\n\nNone 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.\n\nThe 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.\n\nStart this week\n\nPick 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.\n\nWant to test ZizkaDB on your agent? Try our open source version here: [https://github.com/ZIZKA-AI-SL/ZizkaDB](https://github.com/ZIZKA-AI-SL/ZizkaDB)\n\nInterested in a design partnership? Fill in the form on our site or reach me directly at [founder@zizka.ai](mailto:founder@zizka.ai)\n\nSources: 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", "url": "https://wpnews.pro/news/the-15-day-clock-could-you-reconstruct-an-ai-incident-before-the-deadline", "canonical_source": "https://dev.to/mir_arshadalitalpur_1b3/the-15-day-clock-could-you-reconstruct-an-ai-incident-before-the-deadline-8co", "published_at": "2026-11-09 13:42:21+00:00", "updated_at": "2026-11-09 13:54:13.937653+00:00", "lang": "en", "topics": ["ai-policy", "ai-agents", "ai-safety", "artificial-intelligence"], "entities": ["European Union", "EU AI Act", "AI Office", "Digital Omnibus on AI", "Regulation 2026/1744"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-15-day-clock-could-you-reconstruct-an-ai-incident-before-the-deadline", "markdown": "https://wpnews.pro/news/the-15-day-clock-could-you-reconstruct-an-ai-incident-before-the-deadline.md", "text": "https://wpnews.pro/news/the-15-day-clock-could-you-reconstruct-an-ai-incident-before-the-deadline.txt", "jsonld": "https://wpnews.pro/news/the-15-day-clock-could-you-reconstruct-an-ai-incident-before-the-deadline.jsonld"}}