When AI Gets It Wrong: Errors and Fallbacks
Every AI feature will sometimes be wrong, slow or unavailable. Products that plan for it keep users’ trust; products that don’t leave people staring at a spinner or a confident mistake.
How should SaaS products handle AI errors?
Design for five failure modes: a wrong answer, no answer, a slow answer, a usage limit and a provider outage. For each, show an honest message, keep the user’s work, and offer a fallback, such as the manual path, a retry, or a narrower question. The product must still work when the AI doesn’t.
What failure modes should you design for?
The table lists the common failure modes, what users see when they’re handled badly, and the fallback that keeps them moving.
| Failure | Bad experience | Better fallback |
|---|---|---|
| Wrong answer | Confident mistake, no way to correct | Sources, edit, feedback, undo |
| No answer found | ‘I don’t know’ and nothing else | Say what was searched; suggest a narrower question or the manual path |
| Slow response | Spinner with no end | Stream partial results; allow cancel |
| Usage limit reached | Feature silently disappears | Clear limit message, when it resets, upgrade option |
| Provider outage | Error codes or broken screen | Plain message; manual path still works; retry later |
What do good AI error states look like?
Good AI error states are calm, specific and give a next step. The mock-up shows three: an answer the AI couldn’t find, a temporary outage, and a monthly limit reached.
Notice that the outage message doesn’t apologise at length or blame the provider. It tells users what still works, which is what they need to know.
How do you reduce wrong answers?
Reduce wrong answers by grounding the AI in the user’s own records, limiting it to questions it can answer, and testing against real cases before release. OWASP lists misinformation (LLM09) and improper output handling (LLM05) among the top risks for LLM applications (OWASP Top 10 for LLM Applications 2025). Show sources so users can check, as described on designing AI users can trust.
- Build a test set of real questions with correct answers.
- Re-run it whenever prompts, data or models change.
- Prefer ‘I couldn’t find that’ over a guess.
- Review negative feedback weekly.
The product must work when the AI doesn’t.
AI should make the product better, not make it fragile. Design the manual path first, then add AI on top.
How should usage limits be shown?
Show usage limits before users hit them: a meter in settings, a warning near the limit, and a clear message at the limit with the reset date and the upgrade option. Never remove the feature silently. How to price usage is on pricing AI features, and general error copy in the UX guide on error messages. Patterns for where AI appears are on AI UX patterns.
Frequently asked questions
How should AI features handle errors?
With honest, specific messages, the user’s work preserved, and a fallback such as the manual path or a retry.
What should AI say when it doesn’t know?
What it searched, why it couldn’t answer, and a narrower question or manual path to try.
How do I reduce AI wrong answers?
Ground answers in the user’s records, limit scope, test against real cases, and show sources.
What happens if the AI provider has an outage?
Show a plain message and keep the rest of the product working; core workflows shouldn’t depend on AI.
How should AI usage limits be displayed?
With a meter, a warning near the limit, and a clear message at the limit with the reset date and upgrade option.
What does OWASP say about AI misinformation?
It lists misinformation as LLM09 in its 2025 Top 10 for LLM Applications.
Sources & further reading
Standards and platform rules change. These sources let you verify the current requirements directly. All screens shown are mock-ups of fictional products.