There is a difference between a system that occasionally admits uncertainty and one that was designed to handle it.
The first depends on good behavior.
The second has machinery behind the behavior.
I care much more about the second.
Start with evidence
If a model is answering from a defined knowledge base, I want to know what material it actually retrieved.
Not what it claims it consulted.
What was retrieved, which version was available, and whether those passages support the conclusion.
A polished answer with a citation attached is not enough. The citation needs to point to something that says what the answer says.
That sounds basic until you start testing systems that were built around producing agreeable prose.
Separate knowing from doing
Answering a question and taking an action should not share the same trust boundary.
An employee asking about a policy is one thing. An agent modifying an account record is another.
The second operation requires explicit authority, validation and a record that can be independently inspected.
If the answer is uncertain, the system might abstain.
If the action is unauthorized, the system must stop.
Those are different conditions. Blurring them is how apparently intelligent software becomes operationally stupid.
Design the failure path first
I like to ask what a system does when its preferred path fails.
No retrieval result. Conflicting sources. Expired credential. Tool timeout. Ambiguous instruction.
Does it tell the operator? Does it preserve enough context to retry safely? Does it make a hidden assumption and continue?
The last option is appealing in a demo. It's a terrible default for serious work.
I don't expect any AI system to know everything.
I expect an engineered system to know what it is allowed to do when it doesn't.