You can reduce how often a language model makes things up. You can't get it to zero. So at some point, the product question stops being "how do we prevent this?" and becomes "what does the user see when it happens?"
I think a lot of AI products skip that second question. The interface presents every answer with the same confident formatting, the same tone, the same clean card. The user has no way to tell a well-supported answer from a plausible guess, so they either trust everything or nothing.
Working on Frontline at WiZR, where the platform generated content for enterprise teams, this was one of the design problems I spent the most time on. Here's what I'd consider.
Show where the answer came from
If the output is based on source material, show it. A link to the document, the relevant passage, or at least the name of the source. Users can then check the answer without starting from scratch.
This also changes how people read the output. When sources are visible, users tend to check the ones that matter. When they're hidden, the answer looks like it came from nowhere.
The caveat: showing a source the answer doesn't actually use is worse than showing nothing. If you add citations, test that they really support the claim.
Make uncertainty visible, carefully
| Approach | When it helps | Risk |
|---|---|---|
| Saying "I couldn't find this in the material" | When retrieval found nothing relevant | Users may find it unhelpful if it happens too often |
| Asking a clarifying question | When the request is ambiguous and the answer depends on it | Annoying if overused on clear requests |
| Visual distinction for unsupported content | When part of an answer is grounded and part isn't | Needs reliable detection, or it misleads |
| Confidence scores | Rarely, in my experience | Numbers look precise and often aren't calibrated |
I'm cautious about percentage confidence scores in consumer or business interfaces. They look scientific, but if the number isn't well calibrated, you've just made the wrong answer look more trustworthy.
Make editing easy
If people are going to use the output in their work, they will need to fix parts of it. So make that the easy path. Editable text, easy regeneration of one section, simple ways to flag what was wrong.
Google's People + AI Guidebook spends a lot of time on this idea of letting users correct and give feedback on AI output, and on setting expectations about what the system can do. 1 It's worth reading before designing any AI interface.
Don't let tone carry false authority
A wrong answer written in a confident, polished voice does more damage than a wrong answer that sounds tentative. That doesn't mean every answer should hedge. It means the tone should match the evidence.
In practice, that meant reviewing prompts for phrases that sounded certain where the system wasn't, and testing outputs on cases where we knew the source was thin.
Match the design to the cost of being wrong
A wrong suggestion for a blog title is a minor annoyance. A wrong step in an operational procedure could be dangerous. The interface should reflect that difference.
For low-stakes outputs, light-touch design is fine. For high-stakes ones, I'd want sources visible by default, a clear review step, and maybe a rule that the output can't be used until someone has approved it. The evaluation checklist covers how to test the wrong-answer cases before launch.
Measure it
Track how often users edit, regenerate, or flag outputs, and read a sample of those cases. Heavy editing on one type of request usually points to a specific problem you can fix.
I'd rather ship an AI feature that's honestly a bit less impressive in a demo than one that looks brilliant and quietly teaches users they can't trust it.