AI errors and how to recover: designing for the answer that is wrong

Why are AI errors different?

A traditional software error is usually visible: a red message, a button that does nothing. An AI error is usually plausible. The answer is well written, confidently phrased, and may contain an invented figure, a wrong calculation or a citation that does not exist. So users tend to accept it.

This changes the designer’s job. Showing the error when the system detects it is not enough, because often it does not detect it. The interface has to let users review the output, and make that review cheap.

What does Microsoft’s design guidance say?

Microsoft’s HAX Toolkit has a guideline on efficient correction built on one idea: make it easy to edit, refine or recover when the AI system is wrong. The reasoning is that an AI output may be only partly right, and the user should be able to correct it without abandoning their goal. Its core patterns are switching classification decisions, rich detailed edits and undoing automated actions. For cases with many items, it suggests batch editing (Microsoft HAX Toolkit, Guideline 9).

The guideline’s example is a navigation app where users can manually adjust a recommended route. The lesson applies beyond maps: correction should live where the result is, not in a separate form.

What should the interface do?

A 2023 paper by Bisante, Dix, Panizzi and Zeppieri on AI errors in interfaces argues that it is essential to detect errors as early as possible and that systems need clear mechanisms to repair them, so that an initial failure does not become a catastrophic one. The authors acknowledge that detecting AI errors is difficult (Bisante et al., CHItaly 2023).

A designer can take four concrete steps, which match the patterns Simon Whatley describes in a February 2026 article (show reasoning, confidence and sources, and make undo and in-place editing easy):

1. Show the reasoning or the source. The user can see where the logic failed or check a fact.
2. Show confidence when the system has it. A low-confidence result calls for a more careful review.
3. Offer one-click correction. A “This isn’t right” or “Not relevant” button marks the problem, and direct editing fixes it.
4. Ask what it should have been. A guided correction gives a better result immediately and gives the team useful information.

What to avoid: a polished result that hides doubt. The interface should say when it is not sure.

What to do once an error is detected

Recovering is not only fixing the text. The user needs to know what changed, what else was affected and what they can undo. Three steps help:

• Confirm the scope. “I corrected the date in 3 of 5 sections” is better than silence.
• Offer undo. Especially when the AI took an action: sending, deleting or moving something.
• Explain the limit. If the error comes from old data or information the AI does not have, say so. For example, “My pricing information may be out of date”.

Example

Illustrative example: an invoicing tool uses AI to extract data from PDF invoices. One invoice has the amount misread. In the review view, each field shows its source in the PDF and a confidence indicator. The amount field is highlighted in yellow. The user clicks it, sees the original snippet, types the correct amount, and the tool asks whether to apply the same correction to other invoices from that supplier. If the user accepts, the correction is applied in batch, with a preview of the changes and an undo button.

How to apply it tomorrow

1. List the five most costly answers your feature can give: invented data, irreversible actions, miscalculated figures. For each one, define how the person finds out there is an error.
2. Check whether every action the AI executes has an undo. If it does not, add one or require an explicit confirmation before it runs.
3. Write three recovery messages with their next step: one for incorrect data, one for outdated information and one for a missing answer.
4. Trigger an error on purpose in the test environment and count how many clicks it takes to correct it. If it is more than three, the correction flow needs work.

The question to bring to the next design review is: what does the person do when the answer sounds right but is not?

Before designing the correction, decide how much confidence to show; that is covered in trust calibration. The risks of excessive trust are covered in anthropomorphism, and chat screens in chat vs. structured UI.

Common mistakes

• Showing errors only when the system detects them, which is almost never the real error.
• Using a generic message such as “Something went wrong” with no next step.
• Forcing the user to redo the whole task to fix one value.
• Hiding undo behind a settings menu.
• Correcting silently: users stop trusting the tool when they find changes they did not see.
• Designing only for the bad answer and not for the partly good answer, which is the most common case.

Sources

• Microsoft, HAX Toolkit, “Guideline 9: Support efficient correction”: https://www.microsoft.com/en-us/haxtoolkit/guideline/support-efficient-correction/
• Bisante, Dix, Panizzi and Zeppieri, “To Err is AI” (CHItaly, 2023): https://alandix.com/academic/papers/CHItaly2023-to-err-is-ai
• Simon Whatley, “Designing for AI errors and graceful recovery”: https://www.simonwhatley.co.uk/writing/designing-for-ai-errors-and-graceful-recovery/