Responding to an AI-related incident
Created by Adrian Dunkley. This is an operational planning aid, not a statement of any country’s notification law. Have your responsible security, privacy and legal advisers adapt it before an incident occurs.
An incorrect booking, a leaked customer record and an unsafe recommendation require different responses. Record what is known, what is uncertain and who has authority to act. Do not wait for an AI system to decide whether a serious event is reportable.
Prepare before deployment
- Name an incident owner and backup, with current contact details.
- Identify the person who can safely stop the affected automation and restore a tested manual process.
- Record the data involved, service providers, approved access and locations where processing occurs.
- Maintain an access-controlled incident register and a counsel-verified notification checklist for each relevant jurisdiction, contract and sector.
- Rehearse a realistic failure and check that staff can reach the responsible people.
Respond to the actual risk
- Protect people and contain further harm. For immediate danger, follow the established emergency procedure and contact the appropriate local service. Have authorised staff isolate or pause the affected system where safe. Do not interrupt a safety-critical service without its responsible operator.
- Preserve evidence. Retain relevant records securely, record timestamps and restrict access. Do not erase logs or alter evidence while investigating. Collect only what is necessary; do not paste exposed records into a general AI service.
- Assess with accountable humans. Determine affected systems, people, data and transactions. Distinguish confirmed facts from estimates. Escalate suspected personal-data exposure, unauthorised payments, discrimination or physical harm promptly to the appropriate professionals, regardless of the number of people affected.
- Determine notifications. The privacy/legal owner must check applicable law, sector rules, contracts and provider obligations. Record recipients, triggers, deadlines, required contents and the basis for the decision. Do not assume customers must always be notified before regulators or that a single regional deadline applies.
- Recover and review. Correct verified faults, test the fix and obtain approval before restoring automation. Track affected people and unresolved consequences. Record the cause, corrective actions and evidence supporting closure.
Internal response targets are useful, but they do not extend a statutory or contractual deadline. Where facts remain incomplete, ask the responsible adviser whether an initial notice and later update are required.
Reporting duties: establish a local checklist
There is no universal “72-hour LAC rule” supplied by this guide. Reporting triggers, recipients, time calculations and the rules in force must be checked for the specific incident. A small breach can still be serious or reportable.
| Record before relying on a rule | Question for the responsible adviser |
|---|---|
| Jurisdiction and sector | Which laws and sector requirements apply to this organisation and these people? |
| Role | Are we acting as controller, processor, service provider or another regulated role? |
| Trigger | What event starts the reporting duty and the clock? |
| Deadline | Is time counted in hours, calendar days or working days? What exceptions apply? |
| Recipients | Which authority, customers, partners or affected people must receive notice? |
| Evidence | What official rule, effective date and reviewed interpretation support this decision? |
| Follow-up | Must we send updates, preserve records or support remedial action? |
Use current official regulator guidance and qualified local advice. Do not rely on an AI-generated regulator name, address or deadline without verification.
Communicating with affected people
Use a language and channel the recipient understands. Have the responsible human approve the message and any required legal content. Say only what has been confirmed. Never promise that a problem is fixed, funds are safe or no data was exposed unless the investigation supports it.
A starting structure:
On [date/time], we identified [confirmed issue]. We currently know [verified impact]. We are still checking [uncertainty]. We have taken [completed action]. Please [necessary protective step, if approved]. Contact [verified human contact] for assistance. Our next update will be [approved time/channel].
Translate the approved facts, not speculative reassurance. Have a proficient speaker review important translations. Avoid disclosing another person’s information or investigative details that could cause further harm.
Incident register
Record an identifier, detection time and timezone, owner, affected system, confirmed impact, evidence location, containment actions, notification decisions with their legal/contractual basis, recovery tests, approval to restart, and unresolved actions. Protect the register as appropriate to its contents.
Review patterns rather than applying an arbitrary rule such as replacing a tool after a fixed number of incidents. Repeated failures may require a changed workflow, reduced permissions, retraining staff, supplier escalation or stopping the use altogether.
Related guidance
This page intentionally omits jurisdiction-specific deadlines until they have a current, reviewed source. It is not a legal notification matrix.