What to tell users when the model is wrong
AI features fail in front of users, and the interface around the output determines the damage. Showing sources, making corrections easy, matching confidence to reliability and keeping the user in control of consequential actions preserves trust through failures that are going to happen regardless.
Plan for this, because it is not a risk but a certainty: at some point your feature will state something false, fluently, to someone who believed it. The technical work reduces how often. The design work decides what it costs you.
Show where it came from
A claim with a visible source can be checked in two seconds. The same claim floating free requires the user to go and look, which they will not do — they will either believe it or distrust the whole feature.
Citations, quoted passages, a link to the record: all of them convert an act of faith into a glance.
Match the confidence of the interface to the reliability of the output
Presenting a shaky extraction in the same crisp typography as a database field tells the user it is equally solid. A flag, a softer treatment, a "check this" marker on low-confidence output is honest and costs nothing.
Make correction cheap
If fixing a wrong answer means discarding everything and starting again, users stop using the feature after the second failure. If they can edit the part that is wrong and keep the rest, a failure becomes a small annoyance.
Editable output, regenerate-this-section, adjust-and-retry — these are what make a feature survive being wrong.
Keep consequential actions confirmed
Drafting an email is a suggestion. Sending it is an action. Proposing a database change is a suggestion; applying it is an action.
Keep a human in the loop wherever the result is hard to undo, and show exactly what will happen — a diff, a preview, a plain summary — rather than asking for confirmation of something unseen.
Turn failures into inputs
Every reported failure is a free eval case. A feedback control that asks what the right answer would have been produces something you can actually test against, unlike a rating.
Trust is lost in how you fail, not in that you failed. Users forgive a feature that is occasionally wrong and honest about it; they abandon one that is wrong and confident.
Frequently asked questions
Should I add a disclaimer that output may be inaccurate?
A blanket notice is ignored within a week. Specific, local signals work far better — a citation next to a claim, a flag on a low-confidence extraction, a diff before anything is written.
How do I collect feedback that is actually useful?
A thumbs-down gives you a count. A thumbs-down that asks what should have happened gives you an eval case. Route those straight into the evaluation set and the feature improves from real failures.
