AI Assistants Should Be Better at Saying “I’m Not Sure”

One of the most useful things an AI assistant could say is also one of the least impressive-sounding: “I’m not sure.”

AI tools are often judged by how quickly and smoothly they answer. That makes sense when the task is drafting a note or explaining a familiar concept. But when a response sounds equally certain about a well-established fact and a shaky guess, fluency becomes a problem. People can mistake a confident tone for reliable evidence.

Confidence is part of the answer

When someone asks a colleague for advice, they read more than the words. They consider whether that person knows the subject, how certain they sound, and whether they have a reason to be cautious. An AI assistant’s replies need the same kind of context. A useful answer should help readers understand not just what the system suggests, but how much weight to give it.

That does not mean every response should come wrapped in warnings. If I ask for a few ideas for a birthday card, an elaborate disclaimer is just friction. The stakes and the available evidence matter. A system should be more careful when answering questions about health, money, law, or a specific event than when it is helping brainstorm a story title.

Uncertainty can be practical, not vague

“I may be wrong” is a weak substitute for explaining the actual uncertainty. Better responses identify what is missing or unsettled. For example, an assistant might say that its answer depends on a detail the user has not provided, that sources disagree, or that it cannot verify whether a rule has changed recently. Those statements give the reader a reason to pause and a clear next step.

There is a meaningful difference between uncertainty about the facts and uncertainty caused by an ambiguous question. If a user asks whether a particular policy applies, the assistant may need to know their location or circumstances. If they ask about a breaking development, the issue may be whether the system has access to current reporting. Treating both cases as a generic lack of confidence helps no one.

Show the limits where they matter

Developers can make uncertainty more useful by connecting it to the answer. If a tool relies on older information, it should make that limitation visible when freshness matters. If the answer changes based on an assumption, the assumption should be stated plainly. And when the system cannot substantiate a specific claim, it should avoid dressing that claim up with polished detail.

This is not a call for timid software that refuses to help. A good assistant can still offer a likely explanation, compare possibilities, or suggest what to check. The difference is that it should mark the boundary between a supported answer and a plausible guess. That boundary is especially valuable when a user is likely to act on the response rather than simply read it.

There is also a design challenge here: people may ignore constant caveats, while a clean, confident answer is easy to trust. So uncertainty needs to be selective and specific. A short note about the missing information is often more helpful than a paragraph of generic legal-sounding language.

AI assistants do not need to imitate human hesitation. They do need to communicate limits in a way people can use. A system that sometimes slows down, asks for a key detail, or says what it cannot verify may feel less dazzling in the moment. Over time, that honesty is a better foundation for trust than sounding certain about everything.