AI Incident Response Plan | Business Guide

An AI incident is any event where an AI workflow creates harm, exposes information, behaves outside its approved purpose or can no longer be trusted. The response should not be invented during the incident. A short plan gives staff a clear way to contain the issue and bring in the right people.

This guide is a practical starting point. Connect it to the organisation's existing security, data protection, business continuity and customer response plans.

Define what counts as an incident

Confidential or personal information reaches an unauthorised party.
The workflow produces materially incorrect or harmful output.
A user bypasses an approved restriction.
The supplier or integration is compromised.
Important logs or controls stop working.
A model or service change creates unexpected behaviour.

Use simple examples from the actual workflow so staff recognise the threshold for reporting.

Give people one reporting route

Publish a contact and the minimum information to provide: time, workflow, user, input type, observed output and immediate action. Encourage prompt reporting. Staff should not delay because they are worried about being blamed for an honest mistake.

Contain the issue

Define who can suspend the workflow, remove access, stop an integration or return work to the manual process. Preserve relevant records before changing the system where it is safe and appropriate to do so.

Assess impact

Identify affected people, information, customers, decisions and time periods. Determine whether incorrect output was only generated or also used. Bring in legal, security, data protection or sector specialists where the circumstances require them.

The ICO AI and data protection risk toolkit and current ICO guidance can support data protection assessment. The UK AI Cyber Security Code of Practice sets out baseline security principles for AI systems.

Communicate deliberately

Name who decides what staff, customers, suppliers or authorities need to know. Keep a record of facts, decisions and timing. Avoid speculation. Communication duties depend on the incident and should be handled with appropriate advice.

Recover through testing

Do not restart because the obvious symptom disappeared. Identify the cause, apply the change and repeat representative tests. Confirm access, logging, fallback and monitoring. The business owner should approve return to service.

Learn and prevent recurrence

Record the cause, response, impact and corrective actions. Update the risk assessment, training, test set and monitoring rules. Share useful lessons without exposing sensitive incident details.

Practise the plan

Run a short exercise using a realistic scenario. Ask who notices the issue, who can stop the workflow, where evidence is found and how ordinary work continues. Exercises often reveal missing contact details, unclear authority and unavailable logs. Record actions and repeat after a major workflow or team change.

The purpose is not to predict every failure. It is to make the first response calm, fast and accountable.