Stop an incorrect AI reply spreading, identify affected customers and issue a useful correction, with a practical record and clear conditions for restarting.

Direct answer: Stop the affected automated reply route, preserve what was actually sent and contact the customer with the verified correction and a concrete recovery action. Then identify everyone who may have received the same mistake, prioritising people who have already acted or face an approaching consequence. Restart only when you can show that the specific failure is controlled and someone owns the remaining exceptions. If safety, regulated advice or personal data is involved, bring in the appropriate qualified help immediately alongside containment.

Fixing the source document or prompt is not enough. The customer may be acting on a message that already exists in their inbox, and a corrected system does not automatically correct that decision.

Your response should therefore follow the delivered output to the affected person. Explaining why the model failed comes later than helping them avoid further harm.

Applies to: a small organisation responding to incorrect AI-assisted customer communication. Legal references concern the UK; obligations can differ by country, sector and contract.

Create an affected-output register

The affected-output register is an editorial method for organising this response. It is a restricted work record with one entry per potentially affected customer interaction. It connects the delivered statement, the customer's action, the correction and the evidence needed to close the case.

Record only what the response team needs: interaction reference, delivery time, incorrect statement, authoritative correction, known customer action, assigned owner, contact status and unresolved consequence. Link to the original message in its authorised system instead of copying entire customer histories into a new spreadsheet.

Use separate labels for confirmed harm, possible exposure and checked-unaffected interactions. “No complaint received” is not evidence that an incorrect message was harmless. Equally, do not tell a customer they suffered a loss that you have not established.

The parent guide, How Small Teams Can Adopt AI Without Losing Trust, makes accountability a condition of adoption. The register gives that accountability a specific object: each output that needs a human decision.

Contain the route without destroying the evidence

Pause the affected automation through its documented control and route new requests to a person or a verified static response. Confirm that a new test request no longer receives the faulty answer. A dashboard saying “paused” is less useful than evidence from the actual customer route.

Do not delete conversations, overwrite the original source or run a bulk cleanup while establishing the scope. Preserve the sent text, relevant source version and available configuration history with appropriate access restrictions. Record what changed and when. Do not promise that every platform retains enough history to reconstruct the event.

If you cannot isolate the failing route confidently, pause the wider automated function it depends on. This is my default recommendation even if it increases the manual queue. Keeping output running is defensible only when you can demonstrate separation between the affected function and the remaining work.

The NIST Generative AI Profile recommends defined incident responsibilities, communication processes and documented incident handling. It is voluntary US risk-management guidance, not a UK legal deadline or evidence that your particular system is controlled.

Establish the correction before contacting more customers

Compare the generated statement with the source that should govern the decision: the customer's actual order, the policy in force at the relevant time, or instructions confirmed by an authorised specialist. Keep these distinctions clear. A current policy may not establish what applied when the customer acted.

Have a suitable second person check the correction where the consequence warrants it. They should inspect the evidence, not simply approve a more reassuring rewrite. If the facts remain uncertain, tell the customer which instruction to stop following and when they will receive a further update.

Do not send the original complaint and full account history to another unapproved AI service to draft the response. The incident should not create a second, avoidable data exposure. A short human-written correction is usually enough.

Scope the error by mechanism, not identical wording

Start with the known message and identify its shared dependencies. These might include an outdated returns document, a failed lookup, an incorrectly mapped field or an unsupported answer being sent without review. Search other interactions using those dependencies as well as relevant wording.

Set the earliest plausible start from evidence, such as when the wrong source became available. If you cannot establish that boundary, record the uncertainty and widen the review. Do not invent a clean start time to make the affected count smaller.

Review variants. “You have until Friday” and a specific incorrect date might arise from the same failure without sharing many words. Include cases where the customer never replied, since receipt and action are separate questions.

Prioritise based on what can still happen. A customer about to make an irreversible change needs faster attention than someone whose minor misunderstanding is already resolved. Do not bury urgent cases in a first-in, first-out queue merely because that is how the inbox is sorted.

Send a correction the customer can act on

A useful correction identifies the previous instruction, states what was wrong, provides the verified replacement and explains the immediate next step. Give a named response route and a realistic time for the next update if the outcome remains unsettled.

For example, in an illustrative booking error, the organisation could say that its earlier reply gave the wrong collection date, confirm the correct arrangement against the order, and ask the customer to contact a named team member if they have already incurred a cost. Do not promise compensation, reversibility or availability without authority to deliver it.

Explain material AI involvement honestly when it helps the customer understand what happened. Do not use the supplier or the model as a substitute for taking responsibility for your organisation's response. Detailed technical speculation rarely helps somebody recover a missed appointment.

Keep contact proportionate and private. Use the established customer channel and disclose only that person's information. Where identity needs checking, follow the existing verification process rather than requesting unusual credentials during a stressful correction.

Count the repair work, including unresolved cases

Suppose a fictional equipment-hire business identifies 25 potentially incorrect replies. All quantities below are illustrative assumptions, not reported incidents or typical error rates.

Review finds seven customers have acted: four paid an unnecessary £9 delivery charge and three rearranged a collection. Eleven customers may have relied on the reply but have not confirmed their position. Seven received the message but are confirmed not to have acted. The register therefore contains 7 + 11 + 7 = 25 cases, with eleven still uncertain.

Assume initial inspection takes 3 minutes per case: 25 × 3 = 75 minutes. Resolving the four charges takes 15 minutes each, and the three collection changes take 20 minutes each: (4 × 15) + (3 × 20) = 120 minutes. Contacting the other 18 customers takes 4 minutes each: 18 × 4 = 72 minutes. Containment and correction review take another 45 minutes.

Total initial effort is 75 + 120 + 72 + 45 = 312 minutes, or 5 hours 12 minutes. Further follow-up is not included and must be added. If the business authorises refunding the four charges, that separate cash outlay is 4 × £9 = £36; this is an assumed remedy, not a statement of legal entitlement.

The lesson is operational: sending a bulk correction does not close eleven unknown outcomes. Keep them assigned. The repair effort also belongs in the later decision about whether this automation remains worthwhile.

Make a separate personal-data assessment

An inaccurate service answer and a personal data breach are not automatically the same event. If personal data was exposed, altered or otherwise affected in a way that could constitute a breach, involve the person responsible for data protection promptly.

The ICO's UK breach guidance requires assessment of risk to people's rights and freedoms. Its detailed guide describes notifying the ICO when risk is likely, without undue delay and where feasible within 72 hours of becoming aware of the breach. Individuals must also be notified without undue delay where risk is high. The reporting page was marked under review when checked. Obtain qualified local advice for the actual facts; an internal investigation does not justify deferring a required report.

Work towards a controlled restart

  1. Immediately assign an owner, pause the affected route and address any imminent consequence for the known customer.
  2. During the same working session, preserve evidence, establish the authoritative correction and begin the register. Communicate verified facts without waiting for a perfect technical diagnosis.
  3. Over the next working day, review linked outputs and contact affected people in consequence order. These are planning intervals, not legal reporting deadlines; urgent risks require faster action.
  4. Before restarting, reproduce the original failure safely using synthetic data, confirm the repair and test nearby exceptions. Retain manual review where the consequence requires it.
  5. Schedule a follow-up within a week to check unresolved cases and compare operating benefit with repair cost. If the team cannot detect recurrence or support affected customers, keep that function manual.

Frequently asked questions

Should I wait until the software supplier explains the mistake?

No, not if the customer needs a correction or further incorrect replies can still be sent. Containment and assistance can begin from the delivered message and your authoritative business information, even while the technical cause remains uncertain. Give the supplier the minimum relevant diagnostic material through an approved support route and preserve their response. Avoid promising a cause or permanent fix before it is established. If only the supplier can stop the affected function, escalate that request promptly while using the controls you do possess, such as suspending the customer-facing workflow or assigning manual handling.

What if the customer says they acted but cannot show the loss yet?

Record their account accurately, identify what evidence would help and agree a reasonable follow-up route. Do not label an unverified amount as confirmed, but do not dismiss the report because the customer cannot immediately assemble documents. Separate the urgent action needed to prevent further loss from the later assessment of a remedy. Your contractual or legal obligations require advice relevant to the actual jurisdiction and circumstances. Keep the case open with an owner and next review time. A pending evidence request should not become an indefinite gap in communication or assistance.

Do I need to contact every user of the AI feature?

Not automatically. Start with the population that could plausibly have received or relied on the incorrect output, using the evidence you can obtain. If you can demonstrate that a route or time period was unaffected, record why. If you cannot establish the boundary, broaden the review and consider a wider notice appropriate to the consequence. Avoid reassuring unreviewed users that their answers were accurate. Privacy, sector rules and contractual requirements may create additional communication obligations, so involve qualified assistance where necessary. The purpose is to reach affected people, not merely to minimise the number contacted.

Should I ask AI to write the apology?

A person should own the substance and verify every commitment, whether assistance is used or not. In a small incident, drafting directly is often quicker than preparing safe inputs and checking an AI rewrite. If an approved service helps with wording, use only the minimum authorised information and compare its output against the agreed correction. Watch for invented refunds, unsupported certainty or language implying the case is resolved. Empathy does not require elaborate prose. A factual explanation, a practical next step and an accountable contact are more useful than a polished message with promises nobody can fulfil.

What evidence is enough to restart the system?

You need evidence that addresses the actual failure mechanism and the nearby cases it could affect. Replaying the original example once is insufficient if the same source ambiguity still exists or the system can vary its answer. Define who checks the result, what counts as a failure and how the route will stop if that happens again. The required assurance rises with the consequence of another error. If no meaningful detection or fallback is available, leave the consequential step under human control. A supplier's statement that a problem is fixed does not replace your workflow-level assessment.

Should the person who approved the wrong message be blamed?

Start by establishing what that person could reasonably see, verify and control. A nominal reviewer given too little time or no access to the governing source is not a functioning safeguard. Preserve accountability for decisions without making people reluctant to report future errors. Review workload, instructions, source access and escalation options alongside individual actions. Deliberate misconduct or an employment issue requires the organisation's appropriate process, not an improvised technical investigation. The practical objective is a system in which someone can recognise a bad output, stop it and obtain help before another customer relies on it.

Sources and verification

  • NIST: Generative Artificial Intelligence Profile, checked on 9 September 2026 for incident responsibilities, communication and review guidance. The register described here is an editorial method.
  • ICO: UK GDPR data breach reporting, checked on 9 September 2026 for risk assessment and notification distinctions. The page states that guidance is under review following the Data (Use and Access) Act.
  • ICO: personal data breaches guide, checked for when the reporting period begins and the distinction between ICO and individual notifications.
  • The supplied parent-guide text was read locally. Its public category URL could not be retrieved during verification; the supplied editorial path is retained.
Twokq Tech

This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.