How to show uncertainty in AI answers without confusing people
Showing uncertainty in AI means telling people how sure an answer is and what to check. How to design it with clear levels, sources and verification steps.
Why should a model say it is not sure?
A language model writes in the same tone whether it is right or making things up. The correct answer and the false one arrive with the same fluency, and the person has no signal to tell them apart. For a designer, that is the problem: the text carries no mark of its own quality.
Showing uncertainty tries to bring that signal back. It is not about the AI saying “I don’t know” all the time, but about the interface showing where it is worth checking.
Microsoft’s HAX Design Library of human-AI interaction patterns has a guideline that sums it up: “Make clear how well the system can do what it can do”. It is guideline G2, and its four patterns are concrete: match the precision of the interface’s language to the system’s real performance, match the precision of the numbers you show, report the system’s performance, and alert people when performance is low.
What does the evidence say?
One useful study is a paper posted to arXiv in January 2025 by Zichen Chen, Yunhao Luo and Misha Sra. In a controlled experiment with 108 participants, on a diabetes management decision task, they tested six decision-support mechanisms: AI confidence levels, text explanations, performance visualizations, human feedback, AI-driven questions and visual explanations. According to the abstract, AI confidence levels, text explanations and performance visualizations improved the performance of the joint human-AI task.
The same study found that human feedback and AI-driven questions encouraged deeper reflection, but often lowered performance because they demanded more cognitive effort. Showing more is not always better: a clear confidence signal can help more than making the person think through every step.
How do you show it in practice?
There are three forms you can combine:
- Qualitative levels. A label such as “high”, “medium” or “low” confidence, with a criterion you can explain. Avoid percentages if the model is not calibrated for your case: an “87%” promises a precision the system may not have, and HAX lists this as a pattern of its own (matching the precision of numbers to real performance).
- Specific parts. Instead of a notice at the end, mark the sentence or fact that is less certain. “The delivery date comes from an email from three months ago” is more useful than “may contain errors”.
- Verification paths. Offer the source, the original data or a check action: open the document, compare with the system, ask for the origin to be cited.
Sources help a lot. If the answer links to the passage it comes from, the person calibrates on their own. This connects with citations and sources, the most concrete way to show where a claim comes from.
When should you show more and when less?
Adjust the signal to what is at stake. Illustrative example of how to grade it:
| What is at stake | Example | Recommended signal |
|---|---|---|
| Low | Summary of an internal meeting | Light note or none |
| Medium | Draft email to a client | Mark on the doubtful sentences and a link to the source |
| High | Figure in a financial report, medication dose | Visible mark and a mandatory verification step before use |
If everything has a warning, nothing does. That is why strong signals should be reserved for high-impact results, and the rest left unmarked. The underlying idea, that trust should be proportional to what the AI can actually do, is developed in trust calibration.
How do you decide what to mark?
Before marking something as uncertain, answer three questions:
- What happens if it is wrong? If the cost of an error is low, a light note is enough. If it is a financial figure, a legal fact or a dose, the mark must be visible and come with a verification step.
- Can the person check it in seconds? If yes, offer the link or the fragment. If not, tell them that it cannot be verified from here and who to ask.
- Does the system know where the doubt comes from? A mark that says “I found no source for this figure” is more useful than a generic low-confidence label.
Then measure. If people correct the marked parts more than the unmarked ones, the signal works. If they correct none of them, the mark may be noise or sit in the wrong place.
When should you NOT do it?
When the answer is trivial or can be verified at once, such as a sum or a format, an uncertainty note only gets in the way. And when the uncertainty cannot be reduced, saying so without offering a way to act leaves the person on their own.
Example
Illustrative example: a purchasing tool summarizes supplier prices. Some prices come from scanned invoices with unreadable text. The team marks those numbers with a “review” label and shows the invoice fragment beside them. The rest of the prices appear unmarked.
The result: people check only the flagged numbers, instead of distrusting everything or nothing. That is the point of a specific signal.
Common mistakes
- Putting the same disclaimer on every answer, until nobody reads it.
- Showing a confidence percentage that looks exact but is not.
- Marking uncertainty without offering a way to verify.
- Hiding the answer behind warnings instead of showing it with its level of doubt.
- Losing the mark when summarizing. If a long answer is shortened or copied elsewhere, the doubt must travel with the data; otherwise the short version reads as a firm fact.
- Not measuring whether the signal changes anything. A useful question is whether people correct the flagged parts more, and that can be seen in the user feedback.