Your AI system caused harm. Here is what to do.

The first hour

Four actions, in this order. Do not move to step five until steps one through four are done.

1. 1

   Contain

   Stop the AI system if continued operation poses ongoing harm risk. Pause is a default-safe decision. If you cannot determine quickly whether harm is ongoing, default to pausing.

2. 2

   Preserve

   Preserve the technical evidence: model state, input data, output logs, system logs, configuration at time of incident. AI systems can change rapidly; what is true now may not be true in six hours.

3. 3

   Escalate

   Engage legal counsel and the incident response team immediately. Privilege attaches to investigations conducted under legal direction; it does not attach to investigations that started informally and were lawyered up later.

4. 4

   Document

   Begin an incident log with timestamps. Who knew what, when. What decisions were made and by whom. This log becomes the foundation for regulatory notification, internal review, and any subsequent litigation.

Notification obligations

The notification analysis is jurisdiction-specific, but the categories to evaluate are consistent. Work through each. Where the answer is yes, notification timelines start running from the moment you became aware of the incident, not from the moment you finished investigating.

• EU AI Act serious incident: for providers and deployers of high-risk AI systems, serious incidents trigger notification to the national market surveillance authority without undue delay.
• GDPR personal data breach: if personal data confidentiality, integrity, or availability has been compromised, 72-hour notification to the supervisory authority may be required.
• Sector-specific obligations: financial services, healthcare, critical infrastructure, and other regulated sectors have their own notification regimes that frequently overlap with AI obligations.
• Customer contracts: enterprise customer agreements often require notification of material incidents affecting their services, on tighter timelines than regulators.
• Affected individuals: where harm has occurred to identifiable individuals, separate notification obligations and rights to information may apply.
• Material disclosure: for listed companies, AI incidents that materially affect financial position or operations may trigger continuous disclosure obligations.

The communication mistake to avoid

In the first 24 hours, you will be tempted to communicate before you understand the scope of the incident. Do not. The information you have at hour two will be different from the information you have at hour 24. Statements made early that turn out to be incorrect compound the original incident with a credibility incident.

The exception: where there is an ongoing risk of harm that proactive communication can mitigate, communicate to enable affected parties to protect themselves. Otherwise, hold all external communication until you can stand behind what you are saying.

What to investigate (and what most organisations get wrong)

The technical investigation asks: what did the AI system do, and why? This is necessary but insufficient. The governance investigation asks: what failures of monitoring, validation, accountability, and culture allowed this incident to occur and to persist until it became visible? The governance investigation is what prevents the next incident.

Organisations that respond to AI incidents with technical fixes alone, without examining governance failures, almost always experience a second incident within 18 months. The pattern is so consistent that responding without governance review is itself a governance failure.