By Mehdi HassanHow should a product handle AI mistakes and hallucinations?
A product should handle AI mistakes by assuming they will happen and designing the recovery before the happy path. That means making output checkable, wording uncertainty honestly, keeping a manual way to finish the task and letting users correct the AI where the error appears.
Classic error design deals with systems that either work or break. AI adds a third outcome: the system works and gives a wrong answer that looks right. That's what makes hallucination UX hard. Our general guide to error messages and error states covers forms and system failures. This guide covers the failures that only AI products have, and it's part of our hub on AI product UX.
What failure states should AI error handling UX cover?
Design for four kinds of AI failure states: system errors, refusals, low-confidence answers and confident hallucinations. Each one needs different copy and a different recovery, because users need different things from each.
Failure type | What happened | What users need | Main pattern |
|---|---|---|---|
System error | Timeout, rate limit, provider outage | Their input saved and a retry | Inline error with retry and saved prompt |
Refusal | The model declined the request | Why, and what it can do instead | Short reason plus alternatives |
Low confidence | The model isn't sure or sources conflict | Which parts to check | Flagged sections and a review prompt |
Confident hallucination | Wrong output presented as fact | A way to spot and fix it | Citations, editable output, easy reporting |
System errors are the easiest and the most commonly done badly. Never clear the user's prompt on failure, and never show a raw provider error. The streaming and timeout copy in our guide to AI loading states covers that case in detail. The rest of this guide focuses on the three failures that are about the answer itself.
How do you write AI error copy that keeps trust?
Write AI error copy that admits the limit in plain words, tells the user what to check or do, and avoids both blame and false cheer. Trust comes from the AI being honest about what it doesn't know, not from it sounding confident about everything.
- Say what happened, specifically. I couldn't find a refund policy in your documents beats I'm not sure about that.
- Say what to check. Please confirm the renewal date in the contract, section 4, before sending.
- Offer one next step. Search all documents, Rephrase, or Do it manually. One clear option beats a menu.
- Don't apologize at length. One short sorry is fine for a system error. Repeated apologies on every uncertain answer read as noise.
- Don't pretend to be human. I made a mistake is fine. I feel terrible about that is not.
Recovery copy templates you can adapt
No source found: I couldn't find this in your workspace. Here's a general answer, so please check it before you use it.
Sources conflict: Two documents give different dates for this: Pricing 2025 says March, Pricing 2026 says April. Which one should I use?
Low confidence on a field: I wasn't sure about the tax rate on this invoice, so I left it blank.
Refusal with an alternative: I can't write that message, but I can draft a neutral reminder about the overdue invoice.
User corrected the AI: Thanks, I've updated the summary. Want me to use this date in the rest of the document?
How should AI refusal design work?
AI refusal design should explain the boundary briefly and move the user toward something the product can do. A refusal with no alternative feels like a dead end. A refusal with a useful option feels like the product understood the goal.
Keep refusal copy short and neutral, and avoid lecturing. Users who hit a refusal by accident, which is common when a safety filter is cautious, are already annoyed. Show one or two alternatives as buttons, not a paragraph. If refusals are frequent on legitimate requests, treat it as a product bug: log them, review them and adjust the prompt or the policy. A refusal rate you never look at is a churn reason you never fix.
How do you design for confident hallucinations?
Design for confident hallucinations by making every important claim checkable and every output easy to edit. You can't reliably detect every hallucination in the interface, so the job is to make them easy for users to catch and cheap to fix.
Ground claims in sources
Attach citations to facts users might act on, with a preview of the passage. Our guide to AI citations UI covers the patterns.
Separate retrieved from generated
Label content the model wrote from general knowledge so users know there's no source behind it.
Highlight risky values
Dates, amounts, names and legal terms deserve a visual cue and a check before they're sent or saved.
Make output editable in place
Users should fix a wrong sentence directly, not regenerate the whole answer and hope.
Gate high-stakes actions
If the AI is about to send, pay or delete, show the plan and ask for approval first.
The approval step matters most in agents. When an AI acts on its own, a hallucination becomes an action. Our guide to agentic UX covers plans, approvals and undo for that case.
What is a good AI fallback UX?
A good AI fallback UX lets users finish the task without the AI whenever the AI can't help. Every AI-powered path should have a manual twin: a form users can fill themselves, a search they can run, an editor they can type in. If the model is down or wrong, the product still works.
Pros
- Model outages don't block core tasks
- Users who distrust AI still have a path
- Gives you a baseline to measure the AI against
Cons
- Two paths to design, build and maintain
- The manual path can feel second-class if neglected
- Needs clear switching so users aren't confused
Make the switch explicit and reversible: Fill it in myself and Let AI try again should both be one click. Spell out these edge cases for engineers in the design file; our guide to annotating designs for developers shows how to document states like these.
How do you collect feedback on AI mistakes that users actually give?
Collect feedback on AI mistakes at the moment and place they happen, with a few specific reasons to pick from. Users will tap Wrong date on the field that's wrong. Very few will open a feedback form afterward to explain what went wrong with the answer.
- Attach feedback to the part that failed: a sentence, a field, a citation, not only the whole answer.
- Offer three or four reasons, such as wrong fact, wrong source, didn't follow instructions, unsafe, plus an optional note.
- Treat edits as feedback. When users change AI output before using it, that change is the most honest signal you have.
- Show what happened next when you fix a reported issue, so users keep reporting.
Error states, copy and feedback controls work best when they're shared components with written rules, so every AI feature fails the same way. Our guide to design systems for AI products covers that component set. If you want help writing and designing these states, our $3,000 brand & design sprint is a fixed-scope way to explore them in Figma before you build.
