AI incident response: steps and reporting deadlines

What is an AI incident?

An AI incident is an event in which an AI system's use or malfunction causes or contributes to harm, or nearly does. Near misses count. A triage model that sends an urgent patient to the routine queue is an incident, even if a nurse catches it in time.

Governance teams keep three linked logs:

• A risk is something that might happen. It lives in the risk register with an owner and a treatment.
• An issue is a problem that exists now but has not caused harm, such as a drift alert or a failed logging job.
• An incident is an event where harm occurred or nearly occurred.

Issues escalate into incidents, and incidents reveal risks nobody registered.

The EU AI Act sets a legal threshold. A serious incident under Art. 3(49) is an incident or malfunction that directly or indirectly leads to:

• death or serious harm to a person's health;
• serious and irreversible disruption of critical infrastructure;
• infringement of EU-law obligations that protect fundamental rights; or
• serious harm to property or the environment.

What are the steps of AI incident response?

The steps mirror security incident response, with AI-specific twists.

1. Prepare. Write a response plan with roles, a severity scale, runbooks and an on-call rota. Keep an up-to-date AI inventory, a tested kill switch or rollback, and a contact list for providers and regulators. Rehearse with tabletop exercises.
2. Detect and triage. Monitoring, complaints, deployer reports or staff raise the alarm. Confirm it is real, rate its severity and check whether it meets a legal definition, such as a serious incident or a personal data breach.
3. Contain. Stop the harm spreading: disable a feature, restrict use or roll back. Preserve logs, inputs, outputs and the model version.
4. Notify. Tell those owed notice as soon as a duty is triggered. Notification does not wait for the root cause.
5. Investigate. Find the root cause with a cross-functional team. Causes include model flaws, data, integration, human factors and process.
6. Fix and recover. Deploy and test the fix, then restore service under closer monitoring.
7. Learn. Run a post-incident review. Update the risk register, tests, documentation, model card and training.

One AI-specific rule matters at step 3. Under Art. 73(6), a provider must not alter the system in a way that could affect the cause analysis before informing the authorities. Overwriting the model with a quick retrain can destroy evidence.

What are the reporting deadlines?

Under Art. 73(5), a provider may file an incomplete initial report to meet a deadline, then complete it. The California SB 53 duty, in effect since 1 January 2026, applies only to developers of large frontier models.

Who reports what under the EU AI Act?

Providers of high-risk systems own Art. 73 reporting. After reporting, they investigate, assess the risk and take corrective action. Under Art. 20, that can mean fixing, disabling, withdrawing or recalling the system and informing deployers. Their post-market monitoring system (Art. 72) feeds the whole process.

Deployers monitor operation and act fast. Under Art. 26(5), a deployer that believes a system presents a risk must inform the provider or distributor and the authority, and suspend use. For a serious incident, it informs the provider first. If it cannot reach the provider, Art. 73 applies to the deployer itself.

Sector carve-outs avoid double reporting. For AI that is or is part of a medical device under the MDR or IVDR, AI Act reporting covers only fundamental-rights infringements (Art. 73(10)). The same limit applies to Annex III providers already bound by equivalent EU reporting duties (Art. 73(9)). Other incidents go through the sector's own system.

The AI Office now receives reports for some systems. The Digital Omnibus made the AI Office exclusively competent for AI systems built on a provider's own general-purpose model, with exclusions. Providers of high-risk systems in that group report serious incidents to the AI Office (new Art. 75(1a)).

Timing. The deadlines in Art. 73 did not change in 2026. Because the high-risk classification rules apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I), Art. 73 reporting bites in practice from those dates. See EU AI Act high-risk obligations by role.

What should an AI incident record contain?

Write it so a stranger could follow it a year later:

• what happened, when, and how it was detected;
• systems, model versions and data involved;
• who was affected, and how badly;
• containment steps and their timing;
• the root cause;
• notifications: who was told, when, and under which duty;
• corrective actions, owners and verification;
• lessons learned, and updates to the risk register and documentation.

Keep closed records. They are evidence for regulators, auditors and trend analysis. High-risk deployers must keep system logs under their control for at least six months (Art. 26(6)).

What does a good incident response plan include?

The NIST AI RMF builds incident response into its Core. GOVERN 4.3 calls for organizational practices that enable AI testing, incident identification and information sharing. MANAGE 4.1 expects post-deployment monitoring plans that include incident response, recovery and change management. MANAGE 4.3 expects incidents and errors to be communicated to relevant AI actors, including affected communities, and tracked and documented.

In practice, a plan names an incident lead and a decision-maker for shutdowns. It sets severity levels with examples and maps each legal clock to an owner. It includes templates for regulators and affected people, and a rule for preserving evidence. Your AI policy should point to it.

Public databases such as the AI Incident Database and the OECD AI Incidents Monitor help teams learn from others' failures. Logging an incident there never satisfies a legal reporting duty.

How does the AIGP exam test incident response?

• Contain first, then investigate. Root-cause work does not delay containment or notification.
• Preserve evidence. Do not alter the system in ways that could affect the investigation before telling authorities.
• The clock runs from awareness. Fifteen days is the outer limit, not the target, and an incomplete first report is allowed.
• Deployers tell the provider first for serious incidents, and suspend use when they see a risk.
• Near misses belong in the log.
• Public incident databases are for learning, not regulatory reporting.

Practice the provider playbook in lesson III.C.7 and the deployer's records in lesson IV.C.4.

Change log

• 7 Nov 2026: Page published, reflecting Regulation (EU) 2026/1744.