Every business using AI will eventually have an incident: a wrong figure in a client report, a fabricated citation in a proposal, confidential data entered into an unapproved tool, or a support response that promised something the business cannot deliver. What separates a well-governed business from an exposed one is not the absence of incidents — it is the response.
This guide covers how to prepare for an AI incident, the five-step response, what to disclose, and how to fix the cause so it does not recur. It is part of the Governance, Risk & Data pillar.
The incident is the event. The incident response is the thing you control.
Define “incident” before you need to
An AI incident is any output or use that caused, or could have caused, harm. Four categories cover most cases.
- Accuracy failure. A wrong figure, claim or citation that reached a client, a filing or a decision.
- Confidentiality failure. Data that should not have been entered into a tool, or reached somewhere it should not.
- Commitment failure. An AI-drafted communication that promised something the business cannot deliver.
- Systemic failure. A claim, error or behavior repeated across many outputs before anyone noticed.
Naming the categories in advance is what allows a rapid classification, and classification determines the response.
Prepare before the incident
Four preparations make the response quick.
- A named incident owner, who is the person to tell first.
- A reporting route that feels safe. Where staff fear the consequences of reporting a mistake, mistakes are concealed, and concealed mistakes are the expensive kind.
- A retention and terms summary for each approved tool, so exposure can be assessed in minutes rather than days.
- A short incident log, so patterns can be seen and the same cause fixed once.
None of this is elaborate. The most important element is the safe reporting route, because an unreported incident cannot be managed at all.
The five-step response
1. Contain. Stop the workflow, and stop the output circulating further. Recall or hold the document rather than waiting for the assessment.
2. Assess. Establish what happened, who relied on it, and how material the effect is. For a confidentiality incident, include what the tool’s terms say about retention and training.
3. Correct. Fix the output. Where it was distributed, reissue through the same controlled channel with a new version, and mark the superseded one.
4. Disclose. Tell the people affected, proportionate to the impact, and record it. For regulated or contractual contexts, follow the applicable requirement and take advice where needed.
5. Fix the cause. Was it the workflow, the data rule, the training, or the tool? A correction that fixes only the output leaves the cause in place.
The order matters, and each step is short. The most common failure is skipping step 5, which converts one incident into a recurring one.
Fixing the cause
The cause almost always falls into one of five buckets, each with a matched fix.
| Cause | Fix |
|---|---|
| A figure was drafted rather than sourced | Change the workflow to supply figures from the system of record |
| A citation was never opened | Add the citation check to the workflow, and drill it in training |
| Data entered an unapproved tool | Approve a tool for the category, or provide an alternative |
| Verification happened but was not recorded | Add a record step to the workflow |
| Nobody was trained on the check | Deliver the training with a practice drill |
The discipline is to record the cause alongside the correction. Three incidents with the same cause is a process gap rather than a series of accidents, and the log is what makes the pattern visible.
What to disclose
Disclosure should be proportionate to the impact, and the categories are familiar from any error in a deliverable.
- Internal and immaterial: note it, and fix the cause.
- Internal and material: correct it, and tell the people who acted on it.
- Client-facing: correct the output, acknowledge the change, and record it.
- Regulated or published: follow the applicable requirement, with counsel where appropriate.
The general principle is the one that applies to errors in reports: a controlled correction strengthens the relationship, and a discovery weakens it. See When Data Is Wrong for the reporting-side version of the same discipline.
A worked incident
A firm discovers that a figure in a client report was added by the model rather than taken from the finance system. The error is $18,000 against a revenue line.
- Contain. The report was issued two days earlier. The client lead holds the next version and does not circulate anything further until the assessment is complete.
- Assess. The error affects one figure in a supplementary table, does not change any conclusion, and the client has not relied on it in a decision. Materiality is low but the report is a formal deliverable.
- Correct. The figure is replaced from the finance system, the report is reissued as version 1.1, and the earlier version is marked superseded.
- Disclose. The client is told plainly that a figure was corrected and why, with the corrected version attached. The verification step is named.
- Fix the cause. The workflow had not specified that all figures must be supplied from the system of record; the prompt permitted the model to populate the table. The fix is a change to the input step, and a line in the playbook.
The client’s response was straightforward, because the correction was controlled and the disclosure was specific. The cause fix prevented the same error on the next cycle.
Common mistakes
- No reporting route. Incidents are concealed, and concealment multiplies the cost.
- Containing late. The output circulates while the assessment is happening.
- Fixing the output only. The cause remains, and the incident recurs.
- Under-disclosure. A material error reaches fewer people than it should.
- Over-disclosure. Immaterial errors are escalated, which erodes confidence in the numbers.
- No log. The same cause recurs without anyone noticing the pattern, and each occurrence is treated as a fresh surprise.
Frequently asked questions
What counts as an AI incident?
Any output or use that caused or could have caused harm: a wrong figure that reached a client, confidential data entered into an unapproved tool, an AI-drafted commitment, or an error repeated across many outputs.
What should we do when AI output causes a problem?
Contain, assess, correct, disclose proportionate to the impact, and fix the cause. Record the incident and the fix so the pattern is visible.
Should we tell a client when AI contributed to an error?
Tell them about the error and the correction, as you would for any error, and state the verification step. Whether AI contributed is usually less relevant to the client than what was wrong and what has been fixed.
How do we stop the same AI error happening again?
Fix the cause in the workflow — the source of figures, the citation check, the approved tool, the record step or the training — and log it. A corrected output with an unfixed cause guarantees a repeat.
Do we need an AI incident policy?
A short section in the AI policy naming the categories, the owner and the reporting route is enough. The important part is that the route feels safe to use.
Should incidents be logged even when nothing bad happened?
Especially then. A near miss is the cheapest information a reporting function can get, and it identifies the cause before it produces a real incident.
Who owns the incident response?
One named person, typically the policy owner, with the use-case owner responsible for the cause fix. Two names, so neither the response nor the remediation is left to assumption.
Next step
Name the incident owner, agree the reporting route, and add a log. Then apply the five steps to any incident in the last quarter, so the pattern is visible before the next one. See Writing an AI Acceptable-Use Policy and Data Security and Confidentiality in AI Tools, or book an AI adoption call to build the process with you.
Sources
- Incident-response structure reflects standard practice applied to AI: contain, assess, correct, disclose, remediate, with root-cause logging.
No statistic in this article is invented. This article is general information, not legal advice; confirm your specific obligations with qualified counsel.