Sooner or later every AI tool gets something wrong. It states a false fact, misreads your instructions, produces a draft that misses the point, sends an automated message you did not intend or gives advice that turns out to be unsafe. What matters is not whether it happens, but whether you notice, what you do in the first few minutes and what you change afterwards.
In this guide you will learn a calm, practical way to respond when an AI tool gets it wrong. You will see how to tell what kind of error you are dealing with, how to contain the damage, how to correct the output, when and how to tell people, how to find the cause, how to report problems to a vendor and how to prevent a repeat. There are tables, a response plan, templates and a checklist for individuals and teams.
Key takeaways
- Act in a sensible order: stop, contain, assess, correct, communicate, investigate and then improve.
- Work out whether the error is a wrong fact, a misunderstanding, a quality problem or a harmful action, because each needs a different response.
- If a wrong output has already left your hands, correct it quickly and honestly with the people who may have relied on it.
- Look for the cause in the input, the instructions, the tool and the checking process, not only in the tool itself.
- Keep a short incident log and turn each lesson into a better prompt, check or rule.
Expect errors and plan for them
AI tools produce output by pattern, not by understanding in the way a person does. That makes them fast and flexible and also prone to confident mistakes. The sooner you accept errors as a normal feature, the better your response will be. Panic and blame are rarely useful, while a ready plan is.
Why errors happen
- Gaps in knowledge. The tool lacks the fact and produces a plausible guess.
- Ambiguous instructions. It interprets your request differently from what you meant.
- Poor or outdated input. The source material was wrong, incomplete or old.
- Limits of the tool. Long inputs, complex tasks and unusual cases are harder.
- Misapplied use. The tool was used for a task it is not suited to.
- Connected actions. A tool that can act on your behalf can act wrongly.
Why it helps to understand this
The background is covered in what AI hallucinations are and how to reduce them and what a large language model is. Knowing the causes helps you choose the right fix instead of just retrying and hoping.
Plan before you need it
A few minutes of preparation pays off: know who to tell, where to log incidents and what you are allowed to do if something goes wrong. If your team has no plan, use the templates at the end of this guide.
Identify the type of error
Responding well starts with naming the problem. Different errors call for different actions.
| Error type | Example | Typical response |
|---|---|---|
| Wrong fact or invented detail | A statistic, name or reference that is false. | Verify, correct and remove the claim; check what else relied on it. |
| Misunderstood instruction | You asked for a short summary and got a long essay in the wrong tone. | Clarify the request and try again. |
| Poor quality | Generic, repetitive or badly structured output. | Give examples, tighten the brief or edit by hand. |
| Faulty reasoning or calculation | Totals that do not add up. | Recalculate independently; request visible steps. |
| Outdated information | Rules or facts that have changed. | Check against current official sources. |
| Bias or unfairness | Output that stereotypes or treats groups differently. | Stop use for that purpose; report and review. |
| Privacy or confidentiality slip | Sensitive data entered or revealed. | Follow your data incident process immediately. |
| Unintended action | An automated message sent or record changed. | Pause the tool, reverse the action and notify those affected. |
| Unsafe advice | Guidance that could cause harm. | Do not follow it; seek qualified help. |
Severity levels
| Level | Description | Example |
|---|---|---|
| Minor | Caught before use, no one affected. | A wrong date spotted in a draft. |
| Moderate | Used internally or shared with a few people, easily corrected. | An incorrect figure in an internal report. |
| Serious | Reached customers, the public or affected decisions. | A false claim published on a website. |
| Critical | Harm to people, data breach, legal or safety consequences. | Personal data exposed or unsafe instructions followed. |
Judge severity by consequence
The size of the mistake matters less than who relied on it and what they did next. A small error in an important document can be more serious than a large one in a throwaway draft.
The first few minutes
When you realise something is wrong, a clear order of actions keeps you from making it worse.
Stop, contain, then think
- Stop using the output. Do not send, publish, file or act on it.
- Pause any automation. If the tool can take actions, switch them off or disconnect it until you understand what happened.
- Preserve the evidence. Save the prompt, the output, the date and the tool used. Take screenshots if needed. Do not delete the conversation.
- Do not try to fix it by arguing with the tool. Asking “are you sure?” can produce another confident answer, right or wrong.
- Tell the right person. If it is serious, inform your manager or the process owner straight away.
Avoid common reflexes
- Quietly deleting it. You lose the evidence and may leave others relying on it.
- Blaming individuals. The aim is to understand and fix, not to punish.
- Retrying endlessly. Different outputs are not the same as correct ones.
- Assuming it is isolated. If it happened once, check for other places the same issue may lurk.
If it involves personal or confidential data
Follow your organisation’s data incident process immediately, and do not wait to find the cause. Some situations carry time-sensitive obligations, so ask a qualified adviser. This is general information, not legal advice. For prevention, see how to protect company data when using AI tools.
Assess the impact
Once the situation is contained, work out how far the error reached.
Questions to ask
- Where did the wrong output go: nowhere, internal, a client, the public?
- Who may have seen or relied on it?
- What decisions or actions followed from it?
- Can those actions be reversed?
- Are other pieces of work built on the same wrong output?
- Is anyone at risk of harm, loss or unfair treatment?
- Are there legal, contractual or regulatory consequences?
Trace the spread
Search for the wrong claim, figure or phrase across your documents, emails, web pages and systems. A mistake copied into a template or knowledge base can quietly spread. List every place it appears.
Decide who needs to be involved
| Situation | Involve |
|---|---|
| Minor, caught early | Yourself and perhaps your manager for awareness. |
| Moderate, internal | Manager, affected colleagues. |
| Serious, external | Manager, communications or customer lead, process owner. |
| Critical | Senior leadership, legal or compliance adviser, data protection contact. |
Correct the output
With the scope understood, fix what is wrong. Do it carefully, because rushed corrections can add new errors.
Correcting a wrong fact
- Find the correct information from a reliable primary or authoritative source.
- Replace the wrong statement and check anything that depended on it.
- Ask whether the same error appears elsewhere and fix those places too.
For more on verifying, see how to check AI output for mistakes.
Correcting a misunderstanding
Restate the request with more detail: who the audience is, what the purpose is, the format and length, and what to avoid. Provide an example of what good looks like. Start a fresh conversation if the previous one has wandered.
Correcting a quality problem
Decide whether it is faster to improve the prompt or to edit the text yourself. Often a hybrid works: keep the useful structure, rewrite the weak parts and apply your own voice.
Reversing an unintended action
- Undo the change if the system allows it, for example restore a previous version.
- Recall or correct a message where possible.
- Check logs to see everything the tool did, not just the item you noticed.
- Keep the tool paused until you understand the cause.
When to stop using AI for the task
If repeated attempts keep producing errors, the task may not suit the tool. Do it by hand or with another method. Persistence for its own sake wastes time.
Telling people
If an error reached other people, they deserve to know, promptly and clearly. Concealing a mistake usually makes it worse.
Principles for a good correction
- Be quick. The longer people rely on wrong information, the worse the consequences.
- Be clear. State what was wrong, what is correct and what they should do.
- Be honest. Do not minimise or blame the tool as an excuse. You are responsible for what you share.
- Be specific. Say which part of the document or message is affected.
- Be helpful. Offer a way to ask questions and to put things right.
Who to tell
| Audience | What they need |
|---|---|
| Colleagues who used the output | The correction and any work to redo. |
| Customers or clients | A clear correction, an apology where appropriate and a route for questions. |
| The public (published content) | A visible correction notice and updated content. |
| People affected by an unfair or harmful result | An explanation, a remedy and a way to challenge it. |
| Regulators or other bodies | As required by the rules that apply. Take advice. This is general information, not legal advice. |
An example correction message structure
Open with what was wrong, give the correct information, say what you are doing about it and how to reach you. Keep it short and avoid jargon. A message of three or four plain sentences is usually enough.
Do not hide AI involvement if asked
If someone asks whether AI was involved, answer honestly. Following your organisation’s policy on disclosure helps you respond consistently.
Finding the cause
After the immediate problem is handled, work out why it happened. A short, blame-free review is enough for most incidents.
Look at four areas
| Area | Questions |
|---|---|
| Input | Was the source material accurate, complete and current? Did we give the tool what it needed? |
| Instructions | Was the request clear, specific and complete? Did it say what to do when unsure? See how to write better prompts. |
| Tool | Was this the right tool for the task? Did a setting, limit or change in the tool contribute? |
| Process | Was output checked? By whom, and how? Were deadlines or workload a factor? |
Ask why more than once
If a wrong figure went out, the first answer may be that the tool invented it. Ask further: why did nobody catch it? Because there was no review step. Why? Because the task seemed low risk. The deeper causes are usually about process.
Try to reproduce, carefully
You can sometimes repeat the request to see if the error recurs. Remember that outputs vary, so a different result does not prove the issue is gone. Do this in a safe setting, not on live data or live systems.
Keep it blame-free
People who fear blame hide mistakes. Make it clear that reporting errors early is valued, so problems come to light while they are small.
Reporting to the vendor
Sometimes the problem is with the tool itself, or the vendor can help. A good report helps them and helps you.
When to report
- The tool behaved unsafely, unfairly or in a way that appears to be a fault.
- It took an action you did not authorise or could not stop.
- It exposed data it should not have.
- The same error recurs despite good inputs and instructions.
What to include
- Date, time and the tool and plan you used.
- What you asked or did, as precisely as you can.
- What you expected and what happened instead.
- Screenshots or saved output, with sensitive data removed.
- The effect and how urgent it is.
- Steps you took to contain the issue.
Check support routes and terms
Find out what support the vendor offers on your plan and what their terms say about responsibility, remedies and incident handling. This can affect how you plan to use the tool. See how to read an AI tool’s pricing page for what to look for in plans and limits.
Do not rely on the vendor to fix your process
Even if the vendor acknowledges a fault, you remain responsible for the work you produce. Keep your own checks in place.
Preventing a repeat
The real value of an incident is what you change afterwards.
Turn lessons into changes
| Cause found | Possible change |
|---|---|
| Vague instructions | Update the prompt template; add examples and a rule to say when unsure. |
| Bad or outdated source material | Fix and date the sources; remove old versions. |
| No review | Add a named reviewer and a short checklist. |
| Wrong tool for the task | Choose a better-suited tool or do the task manually. |
| Over-trust in output | Training on checking; require sources and verification. |
| Tool could act too freely | Reduce permissions; add approval steps and limits. |
| Sensitive data entered | Reinforce data rules; restrict tools; train staff. |
Build protective habits
- Ask for sources and assumptions, and verify them.
- Match checking effort to risk.
- Keep humans in decisions that matter.
- Test new tools and prompts on low-stakes work first.
- Re-run a set of test cases when you change a prompt or tool.
Share the lesson
A short note describing what happened, with no blame, and what changed helps others avoid the same trap. Keep a simple library of incidents and fixes, and add it to your training.
Update your rules
If a rule would have prevented the problem, add it to your policy. If your policy did not cover it, close the gap. See how to write an AI use policy for your team.
Responding as a team
For organisations, it helps to agree a simple response plan before something goes wrong.
Roles
| Role | Responsibility |
|---|---|
| Person who finds the problem | Stops use, preserves evidence and reports quickly. |
| Process owner | Coordinates assessment, correction and review. |
| Communications or customer lead | Handles messages to customers and the public. |
| Legal, compliance or data protection contact | Advises on obligations for serious incidents. |
| Leadership | Makes decisions on serious incidents and ensures lessons are acted on. |
Make reporting easy
Provide one simple way to report: a shared inbox, a form or a chat channel. Respond promptly and thank people for reporting, so that they do it again.
Practise
Run a short tabletop exercise once or twice a year. Pick a scenario, such as a wrong figure sent to a customer, and walk through who would do what. You will quickly find gaps in the plan.
Templates and checklist
Incident log entry
| Field | Entry |
|---|---|
| Date and time found | [when] |
| Found by | [name] |
| Tool and use | [tool, task] |
| What went wrong | [description, type of error] |
| Severity | [minor, moderate, serious, critical] |
| Who was affected or may have relied on it | [list] |
| Immediate actions taken | [stop, contain, correct] |
| Who was told and when | [list] |
| Cause | [input, instructions, tool, process] |
| Changes made | [list] |
| Follow-up date | [date] |
Response plan in one page
- Stop using the output and pause any automation.
- Save the evidence.
- Tell the process owner or manager.
- Assess who is affected and how far it spread.
- Correct the output and every place it appears.
- Notify those who relied on it, clearly and honestly.
- Find the cause across input, instructions, tool and process.
- Report to the vendor if it is a tool issue.
- Make and record changes.
- Share the lesson and review later.
Checklist for the moment you spot an error
- I have stopped using or sending the output.
- I have paused any connected automation.
- I have saved the prompt, output and details.
- I know who needs to be told.
- I have checked whether the same error appears elsewhere.
- I have corrected the output from a reliable source.
- I have told everyone who may have relied on it.
- I have logged the incident and noted a change to make.
Frequently asked questions
Should I ask the AI to correct its own mistake?
You can ask it to redo the work with better instructions, but do not treat its self-correction as verification. Check the new output against reliable sources yourself.
Do I have to tell anyone about a small error?
If it was caught before anyone relied on it, you may not need to. If anyone used or saw the wrong output, tell them. When in doubt, a short, honest note is better than silence.
Is the vendor responsible when the tool is wrong?
Terms differ, but in practice you remain responsible for what you publish, send or decide. Read the vendor’s terms and keep your own checks in place.
How do I know the problem will not happen again?
You cannot be sure, but you can lower the chance by fixing instructions, sources and review steps, and by testing after changes. Keep monitoring and logging.
What if the error affected a person unfairly?
Treat it seriously. Stop using the tool for that purpose, explain and put things right with the person, review the process and take advice about any obligations. This is general information, not legal advice.
Should we stop using the tool after one mistake?
Not automatically. Judge by severity, cause and whether you can add safeguards. Pause use where the risk is high until you understand what happened.
How can I reduce the chance of invented facts?
Supply the source material, ask the tool to use only that and to say when it does not know, request sources and verify them. These steps reduce the risk but do not remove it.
Conclusion
When an AI tool gets it wrong, a clear order of actions helps: stop, contain, assess, correct, communicate, investigate and improve. Name the type and severity of the error, save the evidence, trace where the wrong output went and fix every place it appears. Be quick and honest with anyone who relied on it, and resist the urge to blame the tool or an individual.
The lasting benefit comes from learning. Find the cause in the input, the instructions, the tool or the process, change what needs changing and share the lesson. To strengthen your safeguards, read how to check AI output for mistakes and how to write an AI use policy for your team.



