An AI incident can start four different reporting clocks at once, and the AI-specific ones run on days while the cyber and data ones run on hours. A model weight theft at a frontier developer with EU customers can owe a five-day report to the EU AI Office, a 15-day report to California's Office of Emergency Services, a 72-hour report to New York's Department of Financial Services from 2027, and a 72-hour personal data breach notification if user data went with it. This map puts the AI-specific reporting deadlines in force or enacted in major economies in one table, shows what starts each clock, and lists the general cyber and data clocks that AI incidents trip as well. It also marks proposals that are not law. It is for AI governance leads, incident response managers, legal counsel and the engineers who have to produce the evidence. Status as of 11 November 2026.
Sources: deadlines and triggers come from the official texts where we could read them: the Commission's AI Act Service Desk for Article 73, the GPAI Code of Practice Safety and Security chapter, the New York State Senate bill text and the GovInfo text of H.R. 9477. California SB 53 details come from Future of Privacy Forum and Morrison Foerster analyses, and the general cyber clocks from our Cyber Incident Reporting Requirements Map. Confirm against the official text before relying on it.
Key takeaways
- AI clocks are measured in days, not hours. The EU AI Act sets 2, 10 and 15 days for high-risk systems, the EU general-purpose AI Code of Practice sets 2, 5, 10 and 15 days for systemic-risk models, California SB 53 sets 15 days and New York's RAISE Act 72 hours.
- Imminent danger collapses the clock everywhere. California and New York both require disclosure within 24 hours to an appropriate authority, which can include law enforcement or a public safety agency, when an incident poses an imminent risk of death or serious physical injury.
- The trigger is awareness of the model's involvement. EU high-risk reporting starts once a causal link, or its reasonable likelihood, is established; the Code of Practice starts when the provider becomes aware its model was involved; California runs from discovery, New York from determination or reasonable belief.
- AI incidents are often cyber and privacy incidents too. Exfiltrated weights, a hijacked agent credential or a data leak through a model also start the GDPR, NIS2, DORA, SEC or Chinese cyber clocks, which are shorter. Run one classification, not separate processes.
- Several clocks are not live yet. EU high-risk reporting follows the high-risk application dates moved by the Digital Omnibus to 2 December 2027 and 2 August 2028, RAISE applies from 1 January 2027, and the US federal AI Incident Reporting Act is a bill, not law.
Regulations and frameworks at a glance
| Regime | Who reports | What is reportable | Deadline and trigger | Recipient | Status (11 November 2026) |
|---|---|---|---|---|---|
| EU AI Act, Article 73 | Providers of high-risk AI systems (deployers where applicable) | Serious incident under Article 3(49): death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental rights obligations, serious harm to property or the environment | Immediately after a causal link or its reasonable likelihood is established, and no later than 15 days after awareness; 2 days for a widespread infringement or critical infrastructure disruption; 10 days where a person died | Market surveillance authority of the Member State where the incident occurred | Enacted; applies in practice with high-risk obligations from 2 December 2027 (Annex III) and 2 August 2028 (Annex I); Commission guidance still in draft |
| EU AI Act, Article 55(1)(c), with the GPAI Code of Practice Commitment 9 | Providers of general-purpose AI models with systemic risk | Serious incidents along the model lifecycle, including serious cybersecurity breaches such as model weight exfiltration | From awareness of the model's involvement: 2 days critical infrastructure, 5 days cybersecurity, 10 days death, 15 days other serious harm; updates at least every four weeks; final report within 60 days of resolution | EU AI Office and, as applicable, national competent authorities | Article 55 obligations apply since 2 August 2025; the day counts come from the voluntary Code, which signatories use to show compliance |
| California SB 53, Transparency in Frontier Artificial Intelligence Act | Frontier developers (trained or started training a model above 10^26 operations) | Critical safety incident: unauthorised tampering causing serious harm, materialisation of a catastrophic risk, loss of control causing injury or damage, a model deliberately evading developer safeguards | 15 days after discovery; 24 hours where there is an imminent risk of death or serious physical injury | Office of Emergency Services; 24-hour disclosures to an appropriate authority, including law enforcement or public safety agencies | In force since 1 January 2026 |
| New York RAISE Act, General Business Law Article 44-B (Chapter 96 of 2026) | Frontier developers | Critical safety incident | 72 hours after determining an incident occurred, or after learning facts giving a reasonable belief that one occurred; 24 hours for imminent risk of death or serious physical injury | Office within the Department of Financial Services; 24-hour disclosures to an appropriate authority | Enacted; effective 1 January 2027 |
| US AI Incident Reporting Act, H.R. 9477 | Covered model developers designated by the Secretary of Commerce | Reportable activity related to a covered model, as listed in the bill | 7 days after the developer knows or reasonably believes reportable activity occurred; expedited reporting for imminent or ongoing serious harm | Department of Commerce | Bill introduced 25 June 2026 and referred to committee; not law |
| China, Cybersecurity Incident Reporting Measures | Network operators, including AI service operators | Cybersecurity incidents at the classified severity levels, regardless of whether AI is involved | 1 hour for critical information infrastructure operators; 4 hours for other operators to the provincial cyberspace administration | Protection department and public security, or provincial CAC | In force since 1 November 2025; not AI-specific |
Jurisdictions with major AI laws but no AI incident reporting clock identified in their current texts: the UK (no AI statute), Japan (AI Promotion Act relies on government information requests), South Korea (AI Basic Act, no incident deadline found) and Colorado (SB 26-189 sets a 30-day consumer explanation duty, not an incident report). Watch these, because each could add one by rule or amendment.
Scope: who and what is covered
Every AI regime draws its line in one of three places: the risk class of the system, the size of the model, or the developer's role. That decides whether an incident at your organisation is reportable at all.
- System risk class (EU high-risk): Article 73 attaches to providers of high-risk AI systems, which are Annex III use cases or Annex I safety components. A deployer using a high-risk system must inform the provider and, where the provider cannot be reached, steps into the reporting role. See the EU AI Act High-Risk AI Systems Guide.
- Model scale (EU GPAI, California, New York): systemic-risk general-purpose models in the EU, and models trained with more than 10^26 operations in California and New York, including compute spent on fine-tuning and reinforcement learning. Most enterprises building on these models are deployers, not developers, and owe nothing under these clocks, but they hold the evidence the developer needs.
- Federal designation (US bill): H.R. 9477 would leave the definition of covered models and covered developers to Commerce regulations within 180 days. Until enacted and implemented, nobody knows who is in scope. See the AI Incident Reporting Act Guide.
- Sector overlap: Article 73(9) and (10) limit EU AI reporting to fundamental rights incidents where the provider already reports under equivalent Union law, such as medical device vigilance under Regulations (EU) 2017/745 and 2017/746. Financial and critical infrastructure entities keep their sector clocks for the operational side.
Key obligations
What starts each clock
| Trigger wording | Regimes | What to timestamp in the incident record |
|---|---|---|
| Causal link established, or reasonable likelihood of one | EU AI Act Article 73(2) | When engineering judged the AI system plausibly caused the harm, with the evidence; 15-day backstop counts from awareness of the incident |
| Causal relationship established or suspected (death) | EU AI Act Article 73(4) | First suspicion of a link, not the conclusion of the investigation |
| Awareness of the model's involvement | GPAI Code of Practice Measure 9.3 | When the provider learned its model was involved, which may come from a downstream deployer or a public report |
| Discovery | California SB 53 | Date the developer discovered the critical safety incident |
| Determination, or facts establishing reasonable belief | New York RAISE Act | Who decided, when, and on what facts; the earlier of the two starts the 72 hours |
| Knows or reasonably believes | H.R. 9477 (proposed) | As for New York |
| Imminent risk of death or serious physical injury | California, New York | The safety assessment that found imminence; the 24-hour clock runs separately from the main report |
What the report must contain
- Incomplete first reports are allowed: Article 73(5) permits an incomplete initial report followed by a complete one, and the Code of Practice expects an initial report, four-weekly intermediate reports while the incident is unresolved, and a final report within 60 days of resolution. California and New York expect enough to identify the incident, its date and the reasons it qualifies.
- Preserve the system as it was: Article 73(6) bars investigation that alters the AI system in a way that could affect evaluation of the causes before the authorities are informed. Snapshot model version, weights hash, system prompt, guardrail configuration and tool permissions before hot-fixing.
- Keep the records: the Code of Practice requires incident documentation for at least five years from the documentation or the incident, whichever is later. See the AI System Incident Report Template.
The general clocks an AI incident also starts
The AI rules sit on top of cyber, data and market rules that care about the effect, not the cause. These clocks are shorter and usually fire first.
| AI incident scenario | Clocks likely to apply | Shortest deadline |
|---|---|---|
| Model weights exfiltrated through a stolen cloud access key | GPAI Code of Practice (5 days); SB 53 or RAISE if a frontier developer; NIS2 or DORA if the provider is in scope; SEC Form 8-K Item 1.05 if material for a US registrant | DORA 4 hours after classification as major; NIS2 24-hour early warning |
| Agent with over-broad OAuth scopes leaks customer personal data | GDPR or UK GDPR Article 33; NIS2 if service is significantly disrupted; EU Article 73 only if the agent is a high-risk system | GDPR 72 hours from awareness |
| High-risk credit scoring system denies loans on a prohibited basis | EU Article 73 (fundamental rights infringement); sector conduct rules | 15 days, or 2 days if widespread |
| AI-controlled grid or water component causes serious, irreversible disruption | EU Article 73(3); NIS2; national critical infrastructure rules | NIS2 24 hours; Article 73 2 days |
| Compromised AI service in China | Cybersecurity Incident Reporting Measures | 1 hour for CII operators, 4 hours otherwise |
The full list of general deadlines, thresholds and recipients is in the Cyber Incident Reporting Requirements Map, and the EU clocks are compared in EU Incident Reporting Clocks.
Timeline and current status
| Date | Event |
|---|---|
| 2 August 2025 | EU general-purpose AI model obligations, including Article 55(1)(c) incident duties for systemic-risk models, apply |
| 26 September 2025 | Commission publishes draft guidance and reporting template for serious AI incidents under Article 73 (still draft when checked) |
| 29 September 2025 | California SB 53 signed |
| 1 November 2025 | China's Cybersecurity Incident Reporting Measures take effect |
| 1 January 2026 | California SB 53 takes effect |
| 27 March 2026 | New York RAISE Act chapter amendment signed (Chapter 96 of 2026) |
| 25 June 2026 | US AI Incident Reporting Act (H.R. 9477) introduced; referred to the Energy and Commerce Committee |
| 1 January 2027 | New York RAISE Act takes effect |
| 2 December 2027 | EU high-risk obligations for Annex III systems apply after the Digital Omnibus on AI |
| 2 August 2028 | EU high-risk obligations for Annex I product systems apply |
Treat these dates with care: the Digital Omnibus already moved the EU dates once, Article 73 guidance is not final, and California lets the Office of Emergency Services designate federal requirements as substantially equivalent, which could change how a developer meets the clock if federal rules arrive. See the EU AI Act Implementation Timeline Tracker.
Enforcement and penalties
- California: civil penalties of up to $1,000,000 per violation, scaled to severity, recovered only by the Attorney General; failing to report a critical safety incident is a listed violation. See the California AI Laws Guide.
- New York: Attorney General civil actions, up to $1 million for a first violation and $3 million for later ones, no private right of action. See the New York RAISE Act Guide.
- EU: Member State penalty regimes under the AI Act for high-risk obligations, and Commission fines for general-purpose AI providers. A late report also weakens any later argument about diligence. See the AI Incident Reporting Guide.
- US federal (proposed): H.R. 9477 would allow civil penalties of up to $2,000,000 per violation, each day of a continuing violation a separate offence.
What it means for AI agents and non-human identities
Many of the incidents these laws describe arrive through machine identities rather than through the model itself.
- Weight theft is a credential incident: the Code of Practice names model weight exfiltration as a serious cybersecurity incident with a five-day clock. The usual path is a leaked access key, a CI/CD token or an over-privileged service account on the storage holding the weights. See the AI Infrastructure Workload Identity Guide.
- Unauthorised tampering: California's definition covers unauthorised modification of a model causing serious harm; a stolen deployment credential that lets an attacker change a system prompt or fine-tune is exactly that. Log who and what changed models, prompts and guardrails, with the identity used.
- Loss of control and safeguard evasion: an agent that keeps acting after revocation, or routes around a policy gate, can meet the California and New York definitions. Your kill switch and its logs are reporting evidence. See the AI Agent Kill Switch and Containment Guide.
- Attribution needs agent identity: every clock asks when you knew the system was involved. Without a distinct identity per agent and per model deployment, you cannot tell which system acted, so you cannot start or stop the clock with confidence. See the AI Agent Observability and Incident Response Guide.
Compliance steps
- Map your roles: for each AI system and model, record whether you are a high-risk provider, deployer, GPAI provider, frontier developer or none, per jurisdiction. Most enterprises will find deployer roles only.
- Write one classification step: at triage, ask in a fixed order: imminent risk to life (24 hours), personal data (72 hours), service disruption in a regulated sector (hours), model weights or safeguards affected (GPAI and frontier clocks), fundamental rights or safety harm from a high-risk system (Article 73).
- Timestamp decisions, not alerts: record causal link, awareness of involvement, discovery and determination as separate fields with a named decision maker.
- Freeze before you fix: snapshot the model version, weights hash, prompts, tool grants and credentials in use; tell the authority before any change that could affect the cause analysis.
- Agree upstream and downstream paths: deployers need a contract route to tell providers fast, and providers need one to receive it, because the provider's clock may start with the deployer's message.
- Rehearse: run a tabletop where one scenario trips three regimes, and measure time from first signal to draft report. See the AI Incident Management and Escalation guide.
Common failure patterns
- Waiting for root cause: every regime allows or expects an early, incomplete report. Teams that hold the report until the investigation closes miss the 2, 5 or 15-day window.
- Treating the AI clock as the only clock: a weight theft or agent data leak usually owes a GDPR, NIS2 or DORA report first, in hours.
- Hot-fixing the model: retraining or changing guardrails before telling the authority can breach Article 73(6) and destroys evidence.
- No deployer channel: providers learn of incidents from social media because customers had no contractual route to report.
- Shared agent credentials: when several agents share one API key, nobody can say which system was involved or when, so the clock cannot be started or defended with confidence.
Practitioner checklist
- Register every AI system and model with its role under each AI regime that could apply.
- Add AI-specific fields to the incident record: model or system ID, causal link time, awareness of involvement, imminence assessment.
- Put the 24-hour imminent-risk route to law enforcement or public safety agencies in the runbook with named contacts.
- Pre-draft initial report templates for Article 73, the AI Office, Cal OES and DFS.
- Build an evidence freeze procedure for models, prompts, guardrails and the credentials they use.
- Give each agent and model deployment its own identity and log every model change against it.
- Add incident notification clauses, with hours not days, to AI provider and customer contracts.
- Track metrics: median time from first signal to classification, reports filed on time, and incidents with complete attribution.
- Review this map against official sources quarterly; mark dates that depend on drafts or bills.
Standards and references
- European Commission AI Act Service Desk: Article 73, Reporting of serious incidents
- EU General-Purpose AI Code of Practice: Safety and Security chapter, Commitment 9
- New York State Senate: S8828, RAISE Act chapter amendment
- GovInfo: H.R. 9477, AI Incident Reporting Act (introduced)
- Future of Privacy Forum: California's SB 53, the first frontier AI law, explained
- Morrison Foerster: California enacts AI safety and transparency regulation (SB 53)
This guide summarises AI incident reporting deadlines as of 11 November 2026 and is not legal advice. Related NHI Mgmt Group resources: AI Incident Reporting Guide · Cyber Incident Reporting Requirements Map · AI Incident Reporting Act Guide · EU General-Purpose AI (GPAI) Code of Practice Guide · AI Kill Switch Act Guide