On a Tuesday afternoon in October 2026, the Engineering team at a mid-sized European fintech detected unusual outputs from the customer-service agent: account-balance numbers that looked nothing like the production database. Within twenty minutes the Trust & Safety lead had identified the cause, a prompt-injection payload that had bypassed the input filter and caused the agent to fabricate balances for thirty-one customers, two of whom had already initiated transfers based on the fabricated numbers. The CISO opened a Slack channel. The Head of Engineering paged the on-call. The Head of Legal asked the question that mattered: "Is this an Article 73 serious incident, and if so, what is the clock?" Nobody in the room could answer with confidence. The general IT incident-response runbook did not mention Article 73. The MSA contact for the Member State of operation was not on anyone's contact list. The 10-day / 2-day / 15-day reporting clocks were a vague memory from a quarterly slide deck. This lesson is the policy that prevents that meeting. It is the L2 artifact, the incident-response policy, the playbook library, the MSA contact list, and the tabletop schedule, that turns Article 73 from a paragraph in a regulation into an operational machine.

Why a Dedicated AI Incident Response Policy

Every mature organization already has a general IT incident response plan. Most have a security incident response plan aligned to NIST SP 800-61 Rev. 2 or to the ISO/IEC 27035 standards. Some have a privacy incident response plan aligned to GDPR Article 33 personal-data breach notification. A few have a financial-services operational-resilience plan aligned to DORA or to OCC / FRB guidance. The question for the AI Governance lead is: why do we need yet another incident response plan, specific to AI?

The answer has four parts. First, Article 73 reporting clocks are statute-driven, and they are not the same as any other reporting clock in the regulatory stack. The 10-day, 2-day, and 15-day clocks per the European Commission's published draft template apply to AI providers (and, through Article 26(4), to deployers who must notify the provider of serious incidents) regardless of whether the incident also triggers other reporting regimes. A general IT incident response plan that defaults to "72 hours to the DPO under GDPR Article 33" will miss the 2-day Article 73 clock for widespread fundamental-rights infringement. A security incident response plan that defaults to "report to the CSIRT within 24 hours" will miss the Article 73 reporting destination entirely: the national market surveillance authority, not the CSIRT, receives the report.

Second, cross-coordination with Article 26(4) deployer-to-provider notification is a distinct workflow that the general IT incident response plan does not cover. Article 26(4) requires the deployer of a high-risk AI system to notify the provider (and the importer/distributor, where applicable) of a serious incident, in addition to notifying the market surveillance authority. The deployer's notification to the provider is a precondition for the provider's own Article 73 reporting in many incident classes. A general IT incident response plan that stops at "notify the CISO" will not satisfy the Article 26(4) deployer-to-provider notification obligation.

Third, cross-coordination with the provider's Article 55(1)(c) GPAI incident reporting matters where the in-scope AI system is built on a GPAI model with systemic risk. Article 55(1)(c) places an obligation on the designated GPAI provider to track and report serious incidents to the AI Office. The deployer of a downstream high-risk system built on that GPAI base owes Article 73 reporting to the national MSA; the GPAI provider owes Article 55(1)(c) reporting to the AI Office. The two reports cover overlapping (but not identical) facts, on different clocks, to different regulators, and a coherent program coordinates the two reports so they tell the same story.

Fourth, multi-jurisdiction overlay is a real operational concern. A single AI incident may trigger Article 73 reporting in the EU (national MSA), GDPR Article 33/34 reporting (DPA, on the 72-hour clock, and to affected data subjects on the "without undue delay" timeline), state breach-notification reporting in the U.S. (where applicable; clocks vary by state from 30 days in some states to "without unreasonable delay" in others), sectoral reporting (OCC for federally chartered banks under the 36-hour computer-security incident notification rule; the SEC for material cybersecurity incidents under Form 8-K Item 1.05 within 4 business days; the FCA in the UK for material operational risks; MAS in Singapore under the Cyber Hygiene Notice), and contractual reporting to customers under enterprise SaaS contracts. The general IT incident response plan does not coordinate these reports in a way that prevents inconsistent disclosures.

The AI incident response policy is operationally distinct from the general IT incident response plan for these four reasons. It does not replace the general plan. It complements it. The triage workflow should cross-reference the general plan for IT-only incidents (e.g., a SQL injection on the marketing website that does not involve AI) and route to the AI-specific runbook for incidents that involve in-scope AI systems.

Policy Structure - Scope, Definitions, Categories, Clocks

The policy itself runs eight to twelve pages in mature programs. The structure below is the minimum viable structure for an audit-defensible policy.

Scope

The scope section identifies which systems are in-scope and which are out-of-scope. In-scope: every AI system on the AI inventory (the lesson 020 artifact) that is placed on the market, put into service, or deployed within the EU. Out-of-scope: pure IT incidents that do not involve AI components (e.g., a SaaS marketing tool outage where the SaaS contains no AI features); these route to the general IT incident response plan. The scope section explicitly addresses dual-track incidents, where an AI system is involved in an incident that also has IT or security dimensions, by stating that both plans are activated in parallel, with the AI incident response policy controlling the Article 73 reporting workflow and the general IT plan controlling the technical containment workflow.

Definitions

The definitions section codifies three terms that must not be conflated:

• Serious incident per Article 3(49) and the four Article 73(1)(a)-(d) categories enumerated below.
• Near-miss: an event that, but for a control that fired, would have been a serious incident. Near-misses are tracked internally for root-cause analysis and lessons learned but are not reportable under Article 73. The policy treats systematic near-miss patterns as a trigger for post-market monitoring intensification under Article 72.
• Routine drift, performance degradation or distribution shift detected by post-market monitoring that does not rise to Article 73 thresholds. Routine drift is handled through the normal Article 72 post-market monitoring workflow and does not trigger the Article 73 reporting clocks.

The distinction matters at audit time. Regulators and notified bodies will scrutinize how the program separates serious incidents from near-misses from routine drift. A policy that has no internal definitions for the three concepts is at risk of either under-reporting (treating serious incidents as routine drift) or over-reporting (treating routine drift as serious incidents and generating regulator noise that damages the program's credibility).

Article 73(1) Categories - The Four Buckets

Article 73(1) defines a serious incident as an incident or malfunctioning of an AI system that, directly or indirectly, leads to any of the following:

• (a) The death of a person, or serious harm to a person's health. The clearest category. Physical harm or death attributable to an AI system. Examples: a medical-diagnostic AI that misclassifies a malignant tumor as benign and delays treatment; an autonomous-vehicle system that causes a fatal collision; a workplace safety AI that fails to detect a hazard.
• (b) A serious and irreversible disruption of the management or operation of critical infrastructure. Critical infrastructure as defined in the NIS2 Directive and in national implementing law. Examples: an AI grid-management system that triggers cascading failures across the electrical grid; an AI traffic-management system that causes regional transportation paralysis; an AI water-treatment system that causes a contamination event.
• (c) An infringement of obligations under Union law intended to protect fundamental rights. The broadest and most operationally complex category. Includes infringements of the Charter of Fundamental Rights, the Race Equality Directive, the Employment Equality Directive, the Gender Equality Directives, GDPR (data protection as fundamental right), and other Union law protecting fundamental rights. Examples: an AI hiring system that systematically discriminates against a protected class; an AI credit-scoring system that produces racially disparate outcomes in violation of the Race Equality Directive; an AI surveillance system that violates GDPR Article 9 special-categories protection.
• (d) Serious harm to property or the environment. Material economic loss or environmental damage. Examples: an AI agricultural system that mis-applies pesticides causing crop loss or environmental contamination; an AI industrial-control system that causes equipment destruction; an AI financial-trading system that causes large-scale market disruption with material economic loss.

Each category is its own classification path. An incident may fall into more than one category, for example, a critical-infrastructure AI failure that also causes death (categories (a) and (b)), and the policy should make clear that the most stringent reporting clock applies when multiple categories are triggered.

Reporting Clocks per the Commission Draft Template

The European Commission published a draft serious-incident reporting template in 2026 that codifies three reporting clocks, mapped to incident severity and category. The clocks below reflect the published draft as of May 2026; programs should monitor the Commission's official publication for any adjustments.

• 10 days for the death of a person. Article 73(1)(a) incidents involving the death of a person trigger the 10-day clock. The clock starts when the provider (or, via Article 26(4), the deployer who must notify the provider) becomes aware of the causal link between the AI system and the death.
• 2 days for widespread infringement of fundamental rights OR serious and irreversible disruption of critical infrastructure. Article 73(1)(b) critical-infrastructure incidents and Article 73(1)(c) widespread fundamental-rights infringements trigger the 2-day clock. "Widespread" is a Commission interpretive concept that captures incidents affecting many individuals or affecting a class of individuals systematically, as distinguished from a single-instance fundamental-rights infringement.
• 15 days for all other serious incidents. All other Article 73(1) incidents, single-instance fundamental-rights infringements, serious harm to health not resulting in death, serious harm to property or environment, trigger the 15-day clock.

The clocks are short by design. The 2-day clock for widespread fundamental-rights infringement is shorter than the GDPR Article 33 72-hour clock, which means an AI incident with a fundamental-rights dimension may have the Article 73 clock binding before the GDPR clock. The 10-day clock for death is shorter than the standard product-liability investigation cycle, which means the provider must report on incomplete information rather than wait for the full root-cause analysis. This is the point of the next subsection.

Incomplete-Then-Complete Reporting Mechanism

The Commission's draft template explicitly permits incomplete initial reports followed by complete reports later. The mechanism is designed to reconcile the short statutory clocks with the practical reality that root-cause analysis often takes weeks or months. The initial report, filed within the applicable clock, contains: the in-scope AI system identification, the incident description in the facts known at the time, the preliminary classification under Article 73(1)(a)-(d), the affected parties (numbers and categories), the immediate containment actions taken, and a commitment to file a complete report once root-cause analysis is finished.

The complete report, filed once root-cause analysis is complete, contains: the full incident timeline, the confirmed root cause, the corrective and preventive actions taken, the changes to the risk management system (Article 9) and post-market monitoring (Article 72), the impact assessment, and the lessons-learned summary. The complete report may be filed weeks or months after the initial report; the MSA may request interim updates.

The policy should codify the incomplete-then-complete workflow explicitly. A program that treats the Article 73 clock as a "report when ready" deadline will miss the clock. A program that treats the clock as "file the initial report with what you know, complete later" will hit the clock reliably.

Internal Triage Process - Detection to Lessons Learned

The triage process is the operational heart of the policy. It is best documented as a decision tree with explicit owners, timing, and artifacts at each step. The eight steps below are the canonical workflow.

Step 1 - Detection. Detection sources include: post-market monitoring alerts (Article 72), customer complaints, internal staff escalations, third-party security researcher disclosures, regulator inquiries, media reports, social-media patterns. Every detection source should route to a single intake, the AI incident intake queue, with a service-level expectation of triage within four hours of intake. The detection step has no Article 73 implication on its own; the clock has not started yet because the causal link has not been established.

Step 2 - Classification. The Trust & Safety lead (or designated incident commander) classifies the incident across three dimensions: (a) does it involve an in-scope AI system?; (b) does it potentially meet one of the four Article 73(1) categories?; (c) which reporting clock applies if the classification is confirmed? Classification should complete within 24 hours of detection for any incident with potential Article 73 implications. The classification artifact is the incident-classification memo, retained per Article 18 record-keeping (typically 10 years).

Step 3 - Containment. Containment runs in parallel with classification. The general IT incident response plan provides the containment playbook for technical actions (revoke API keys, disable agent, switch traffic to fallback, etc.). The AI-specific containment additions include: rolling back to the prior model version, disabling tools available to the agent (the ASI10 mitigation), disabling RAG sources suspected of poisoning, applying additional input filters, and freezing affected customer accounts. Containment artifacts are retained for the incident dossier.

Step 4 - Root-cause analysis. Root-cause analysis is led by Engineering with input from Trust & Safety, Data Science, and (where applicable) the foundation-model vendor. Standard tools include: prompt-and-response transcript review, model evaluation against the suspected failure mode, comparison to the post-market monitoring baseline, replay of the input that triggered the incident, A/B comparison against a known-good prior version. Root-cause analysis may take days or weeks; this is why the incomplete-then-complete mechanism exists.

Step 5 - Reporting decision. The reporting decision is owned by Legal in coordination with the AI Governance lead. The decision considers: does the incident meet the Article 73(1) thresholds?; which clock applies?; which other reporting regimes are triggered (GDPR, state breach law, sectoral)?; what is the MSA contact and the report submission mechanism?; what is the customer-notification design?; what is the press/public communications coordination? Reporting decisions are documented in a reporting-decision memo signed by the General Counsel or designated alternate.

Step 6 - Reporting execution. Reporting execution is the mechanical filing of the report to the MSA via the published reporting mechanism (typically an online portal or a designated email address). The initial report should be filed within the applicable clock, with the complete report to follow. Parallel reports to other regulators (DPA under GDPR, state AGs under U.S. breach law, sectoral regulators) are filed by the relevant teams (Privacy, Compliance, Treasury). All reports should be reviewed by Legal before submission and tracked in a single reporting-status tracker.

Step 7 - Remediation. Remediation is the closing of the root cause through model fixes, system changes, control additions, or product withdrawal. Remediation artifacts are tracked through the standard change-control system; significant remediations may themselves constitute substantial modifications under Article 3(23) and trigger Article 43(4) re-conformity assessment.

Step 8 - Lessons learned. Lessons learned closes the loop. A post-incident review (within 30 days of the complete report) covers: what happened, what we did well, what we did poorly, what we changed, what the systemic implications are. Lessons learned feed back into the policy itself (revisions to the triage process), the playbooks (additions to the playbook library), the post-market monitoring system (new monitoring signals), and the annual tabletop exercise (new scenarios).

Designated MSA Contacts and the Playbook Library

Two operational artifacts make the policy live: the MSA contact list and the playbook library.

The MSA Contact List

Each Member State designated a national competent authority and market surveillance authority by August 2, 2026, the unchanged Omnibus VII date. The MSA contact list enumerates, for each Member State of operation: the MSA name, the reporting portal URL or email address, the named contact (where available), the language requirements, the office-hours expectations, and any sectoral overlay (where a sectoral regulator, e.g., the national medical-devices regulator, has overlapping jurisdiction).

For an organization operating in all 27 Member States, the contact list runs to 27+ entries. For a more focused organization operating in 5 Member States, the list is shorter but no less important. The contact list should be reviewed quarterly and refreshed any time a Member State's MSA designation changes.

The Playbook Library

The playbook library is the collection of incident-class-specific playbooks. Each playbook is two to four pages and covers: the incident-class definition, the typical detection signals, the typical Article 73(1) categorization, the typical reporting clock, the containment steps specific to the class, the root-cause-analysis approach, the reporting template language, and the customer-notification template language. The recommended playbook library covers at least the following seven classes:

• Hallucination harm. An AI system generates a factually incorrect output that, when relied on, causes harm. Detection: customer complaint, post-market monitoring drift on factuality metrics, regulatory inquiry. Typical Article 73(1) categorization: (a) if harm is physical health, (c) if fundamental-rights dimension, (d) if economic loss. Containment: input-filter additions, RAG-source verification, prompt-engineering changes, human-in-the-loop additions.
• Prompt injection breach. An attacker uses an OWASP LLM01 prompt-injection or indirect-prompt-injection vector to cause an AI system to take unauthorized action. Detection: anomaly detection on agent action patterns, customer report, post-incident log review. Typical Article 73(1) categorization: (c) if fundamental-rights dimension, (d) if economic loss; may be (b) if critical-infrastructure system. Containment: input-filter additions, prompt-isolation patches, tool-allowlist tightening, agent disable.
• Data exfiltration via agent tool call. An AI agent exfiltrates sensitive data through a tool call (e.g., emailing customer PII to an attacker-controlled address). Detection: data-loss-prevention alerts, anomalous network egress, customer report. Typical Article 73(1) categorization: (c) for personal-data fundamental-rights infringement. Cross-coordinates with GDPR Article 33/34 reporting on the 72-hour clock. Containment: agent disable, tool-allowlist tightening, network-egress block, credentials revocation.
• Model extraction. An attacker uses query-based attacks to reconstruct a proprietary model. Detection: query-pattern anomaly detection, API-rate-limit alerts, post-hoc analysis of model leakage. Typical Article 73(1) categorization: (d) for economic loss to the model owner; may not always trigger Article 73 reporting if no fundamental-rights or critical-infrastructure dimension. Containment: API rate-limit changes, attacker-IP blocking, watermarking-style model fingerprinting for downstream tracking.
• Agent rogue action (OWASP Agentic Top 10 ASI10). An AI agent takes an action, typically a tool call, that the operator did not authorize and that causes harm. Detection: post-action review, customer complaint, anomalous tool-call pattern. Typical Article 73(1) categorization: (c) if fundamental-rights dimension, (d) if economic loss; may be (b) if critical-infrastructure system. Containment: agent disable, tool-allowlist tightening, human-in-the-loop addition for the affected action class, reset of agent memory.
• Bias-driven harm. An AI system produces systematically disparate outcomes across a protected class in violation of fundamental-rights law (Race Equality Directive, Employment Equality Directive, Gender Equality Directives). Detection: post-market monitoring on fairness metrics, regulator inquiry, internal audit. Typical Article 73(1) categorization: (c) for fundamental-rights infringement. Containment: model retraining, threshold adjustment, removal from production where remediation is not possible in the short term, customer notification design where required.
• CSAM / NCII generation. An AI system generates child sexual abuse material or non-consensual intimate imagery. Detection: content-classifier alerts, user reports, law-enforcement inquiry. Typical Article 73(1) categorization: (c) for severe fundamental-rights infringement; coordinates with criminal-law reporting obligations (national hotlines, NCMEC in the U.S., national CSAM reporting authorities in each Member State). Containment: immediate generation block, system-wide content-classifier deployment, model retraining or content-filter update, deepest possible post-incident review.

The playbook library should grow over time. New AI-incident classes emerge regularly, multimodal jailbreaks, voice-cloning fraud, training-data poisoning of customer-deployed systems, and the program adds a new playbook whenever a new class is identified, even if the class has not yet been instantiated as a real incident. The playbook library is a living artifact, not a one-time policy attachment.

Cross-Coordination With Other Reporting Regimes

The AI incident response policy must coordinate with at least four other reporting regimes. The coordination is operational, not theoretical, and a single incident may trigger reports to four or more regulators on four or more different clocks.

Article 26(4) deployer-to-provider notification. The deployer of a high-risk AI system who becomes aware of a serious incident must notify the provider (and, where applicable, the importer and distributor) in addition to notifying the MSA. The deployer-to-provider notification is operationally a precondition for the provider's own Article 73 reporting in many incident classes. The policy should make clear that the deployer's notification to the provider is part of the deployer's incident-response workflow, not a separate workflow. The notification should be standardized via a deployer-to-provider notification template that captures the in-scope system, the incident description, the deployer's classification, and the deployer's containment actions.

Article 55(1)(c) GPAI provider incident reporting. Where the in-scope AI system is built on a GPAI model with systemic risk, the designated GPAI provider owes Article 55(1)(c) incident reporting to the AI Office. The deployer's Article 73 report to the national MSA and the GPAI provider's Article 55(1)(c) report to the AI Office cover overlapping (but not identical) facts. The policy should require the program to alert the GPAI provider promptly upon any serious incident with a plausible GPAI-model-attributable cause, so the provider can satisfy its own Article 55(1)(c) obligation. This coordination is best documented in the procurement contract with the GPAI provider; the policy references the contractual obligation.

GDPR Article 33/34 personal-data breach notification. Where the AI incident involves a personal-data breach, GDPR Article 33 requires notification to the supervisory authority within 72 hours of awareness, and Article 34 may require notification to affected data subjects "without undue delay" if the breach is likely to result in high risk to rights and freedoms. The 72-hour GDPR clock is distinct from the Article 73 clocks: for a widespread fundamental-rights infringement that is also a personal-data breach, the 2-day Article 73 clock and the 72-hour GDPR clock may both apply, with the 2-day clock controlling. The policy should require the Privacy team and the AI Governance team to coordinate on the dual-clock workflow.

U.S. state breach-notification laws. Where the AI incident involves personal information of U.S. residents, state breach-notification laws may apply. Clocks vary: California requires notification "in the most expedient time possible and without unreasonable delay" with notice to the state AG within 30 days if more than 500 California residents are affected; New York requires notification "in the most expedient time possible" with notice to the AG, the Department of State, and the State Police; other states have their own clocks ranging from 30 to 60 days. The policy should reference the state-by-state breach-notification matrix maintained by the Privacy team and require coordination.

Sectoral regulators. Where the in-scope AI system is in a regulated sector, additional reporting regimes apply. The OCC's 36-hour computer-security incident notification rule applies to federally chartered U.S. banks. The SEC's Form 8-K Item 1.05 4-business-day rule applies to U.S. public companies for material cybersecurity incidents. The FCA's SUP 15.3 immediate-notification rule applies to UK financial-services firms. MAS's Cyber Hygiene Notice applies to Singapore financial institutions. The policy should reference the sectoral-reporting matrix maintained by the Compliance team.

The cross-coordination matrix is a one-page artifact attached to the policy. It shows, for each potential incident class, which reporting regimes are triggered and which clock controls. The matrix prevents the worst operational failure mode: inconsistent disclosures to different regulators that the regulators then compare and find non-aligned.

Customer-Facing Notification and Public Communications

Article 73 reporting is regulator-facing. It is not customer-facing or press-facing. But many AI incidents that trigger Article 73 also require customer notification (under contract, under GDPR Article 34, under state breach laws) and may require press / public communications. The policy should codify the coordination.

Customer-facing notification design is led by the Customer Success team in coordination with Legal. The notification template should include: a plain-language description of the incident, the customer-facing impact, the actions the customer should take, the actions the company has taken, the company's commitment to remediation, the channel for customer questions, and the company's contact for the customer's own regulator reporting (where applicable). Customer notifications should be sent before the public-communications cycle begins, where possible, to preserve customer trust.

Press / public communications coordination is led by the Communications team in coordination with Legal and the AI Governance lead. The press release should be prepared in parallel with the Article 73 report and held in reserve. The decision to release publicly considers: the severity of the incident, the likelihood of media discovery if not proactively disclosed, the regulator's expectation of public disclosure, the customer-notification status, and the company's broader public-communications strategy. The policy should make clear that the Communications team does not unilaterally release; the release decision is made jointly with Legal, the AI Governance lead, and the CEO (or designated executive).

Retention, Tabletops, and the Six Mistakes

Two more operational requirements close the policy.

Retention per Article 18. Records related to high-risk AI systems must be retained for ten years after the system is placed on the market or put into service. This includes the incident dossier: incident-classification memos, root-cause-analysis reports, reporting-decision memos, MSA reports (initial and complete), customer-notification copies, remediation records, lessons-learned reports. The retention obligation applies to the AI incident response artifacts and should be codified in the policy.

Annual tabletop exercise and after-action review. The policy should require at least one annual tabletop exercise that walks the full incident-response workflow against a realistic scenario. The tabletop should include representatives from Trust & Safety, Engineering, Legal, Privacy, Compliance, Customer Success, Communications, and the AI Governance Committee. The scenario should rotate across incident classes year to year: hallucination harm one year, agent rogue action the next, bias-driven harm the third. The after-action review documents what worked, what did not, and what changes are needed in the policy, the playbook library, and the contact list. The tabletop is the only reliable way to know whether the policy works before a real incident tests it.

The market-surveillance-authority response expectation is approximately 7 days, the MSA typically acknowledges receipt of the initial report within 7 days and may request additional information at that point. This is not a regulatory deadline on the MSA but is a planning anchor for the program: the dialogue with the MSA is iterative, and the policy should make clear that the General Counsel or designated alternate is the single point of contact for MSA follow-up.

The L2 artifact set is: the incident-response policy itself; the playbook library (seven playbooks minimum, growing); the MSA contact list (per Member State of operation); and the tabletop exercise schedule (annual minimum, with quarterly mini-drills for the largest programs). The four together are what the L2 author ships to the AI Governance Committee for approval.

Six mistakes recur in programs that have a policy on paper but fail at operational execution:

1. No separation from the general IT incident response plan. The general plan is activated, the team works the technical containment, and Article 73 reporting is forgotten because the general plan does not mention it. The fix is the dual-track scope language and an explicit reference in the general plan to the AI incident response policy.
2. Missing one of the three reporting clocks. The program codifies the 15-day clock and forgets the 2-day or 10-day clocks. The fix is the explicit three-clock decision tree at the classification step and a per-clock checklist for the initial report.
3. No incomplete-then-complete reporting mechanism. The program treats the Article 73 clock as a "wait until ready" deadline and misses the clock when root-cause analysis takes longer than expected. The fix is the explicit incomplete-then-complete workflow in the policy and the initial-report template that captures the facts known at the time without requiring full root-cause completion.
4. No MSA contact identified. The program waits until the incident to identify the MSA contact, loses hours or days to research, and misses the clock. The fix is the MSA contact list maintained quarterly, with named contacts where available and reporting-portal URLs verified.
5. No playbook library. The program has the policy but no class-specific playbooks, and each incident becomes a from-scratch response. The fix is the seven-playbook minimum library with quarterly additions as new classes are identified.
6. No annual tabletop. The program writes the policy and never tests it. The first test is the real incident, and the gaps surface at the worst possible time. The fix is the annual tabletop on the calendar, with after-action reviews fed back into the policy.

Key Takeaways

• The AI incident response policy is operationally distinct from the general IT incident response plan because Article 73 reporting clocks, destinations (MSA, not CSIRT), and incident classes are AI-specific.
• Article 73(1) categories are four: (a) death or serious harm to health; (b) serious and irreversible disruption of critical infrastructure; (c) serious harm to fundamental rights; (d) serious harm to property or environment. An incident may fall into more than one category; the most stringent reporting clock controls.
• The three reporting clocks per the Commission draft template are: 10 days for the death of a person; 2 days for widespread fundamental-rights infringement OR serious-and-irreversible critical-infrastructure disruption; 15 days for all other serious incidents. The 2-day clock can be shorter than the GDPR Article 33 72-hour clock.
• Incomplete initial reports followed by complete reports are explicitly permitted by the Commission draft template. The initial report meets the clock; the complete report follows after root-cause analysis. Programs that wait for full root-cause analysis miss the clock.
• The internal triage process has eight steps: detection, classification, containment, root-cause analysis, reporting decision, reporting execution, remediation, lessons learned. Classification owns the clock decision; Legal owns the reporting decision; Engineering owns root-cause analysis.
• Cross-coordination with four other reporting regimes is required: Article 26(4) deployer-to-provider notification, Article 55(1)(c) GPAI provider reporting to the AI Office, GDPR Article 33/34 personal-data breach reporting, and U.S. state breach laws (plus sectoral regulators where applicable).
• The MSA contact list identifies the national market surveillance authority for each Member State of operation. Designated by August 2, 2026 (unchanged Omnibus VII date). Reviewed quarterly.
• The playbook library covers at least seven incident classes: hallucination harm, prompt injection breach, data exfiltration via agent tool call, model extraction, agent rogue action (ASI10), bias-driven harm, CSAM/NCII generation. New classes added as identified.
• Retention per Article 18 is typically 10 years for high-risk AI records, including the incident dossier. Annual tabletop exercise plus after-action review keeps the policy live and the team trained.
• Six recurring mistakes: no separation from general IT IR; missing one of the three clocks; no incomplete-then-complete mechanism; no MSA contact identified; no playbook library; no annual tabletop. The L2 artifact set, policy + playbook library + MSA contact list + tabletop schedule, addresses all six.