Four cornerstones of trust in AI systems
Imagine an AI assistant rebooks your flight overnight. The notification says "Done." Now you have questions. Why that flight? Can I undo it? What do I get out of this? And what did it read in my inbox to do it?
Those four questions are the whole trust problem. People don't trust an AI system because it's accurate. They trust it when they can answer those questions without effort.
Trust is the design problem
AI systems make decisions we can't watch being made. Unlike a button that does one visible thing, they act, summarize, rank, and recommend, often before we ask. Trust is what lets a person accept that without checking every result by hand.
I think about it through four cornerstones: Transparency, Agency, Benefit, and Security (TABS). I first heard them in a talk at SXSW in 2017 by Jeff Wilson, founder of Kasita, a startup that built small, stackable smart homes. Wilson is a former environmental science professor, better known as "Professor Dumpster" after he lived in a 33-square-foot dumpster for a year as an experiment in small-space living. He concluded that people don't require much space, and pairing tiny homes with AI was a plausible solution for future housing constraints. Those AI cornerstones were key to building trust in the product concept, and they've stuck with me because they apply to any system that acts on your behalf, like AI. The definitions below are how I define them.
1. Transparency: show your work
Transparency builds trust. It lets people see the data, the source, or the transaction behind what the system is doing, and how it reached its conclusion. The test is simple: can the user answer "why did it do that?" without asking anyone.
In practice, that looks like:
Sources next to claims. Every summary or recommendation links to the data it came from.
Visible reasoning. A one-line "why this" on any ranked, filtered, or generated result.
A record of actions. A readable log of what the system did on the user's behalf, and when.
Honest confidence. Say when the system is unsure, instead of presenting every answer in the same confident voice.
I used this in my Video Overlay case study in showing users what the camera sees.
Transparency is also what makes the other three cornerstones checkable. You can't override an error you can't see.
2. Agency: allow for a human in the loop (HITL)
Agency gives people enough control to fix what the system gets wrong. It's oversight plus the power to override where appropriate, so an error is an inconvenience instead of a trap.
In practice, that looks like:
Easy undo. Any automated action can be reversed, and reversal is as easy as the action was.
Edit, don't just reject. Let users correct a result, not only accept or discard it.
Approval where stakes are high. The system proposes; the person approves anything costly, public, or hard to reverse.
A way to teach it. Corrections should change future behavior, so the same mistake doesn't repeat.
Alluding back to my Video Overlay example, I provided a toggle to turn off the overlay in case it got in the way or presented an error. Paired with a behavior edit/contest option, this provided an out for users who saw when the AI got it wrong.
An AI system that's right 95% of the time still fails the other 5%. Agency decides whether that 5% costs the user a minute or their confidence in the product.
3. Benefit: make the value obvious
Benefit means the user can see, quickly and clearly, what they gain from using the system. If people have to take the value on faith, they'll reasonably ask why they're handing over data and control.
In practice, that looks like:
A visible payoff. Show time saved, errors caught, or decisions made easier, in the product itself.
Value before the ask. Earn access to more data or autonomy by delivering something useful first.
Proportion. The more the system asks of the user, the larger and clearer the benefit should be.
No AI for its own sake. If the old way was better for a task, let people keep using it.
In my Video Overlay case, the benefit was immediate to the coaches: clear evidence removed room for argument so they could move on to the coaching.
Benefit is the cornerstone teams assume they've covered. A feature that's impressive to its builders but invisible to its users doesn't count.
4. Security: protect the data, and say how it's used
Security means the user's data and privacy are safe, and they know exactly how that data can be used. The second half matters as much as the first. A system can be technically secure and still lose trust if people discover, later, what it was doing with their information.
In practice, that looks like:
Plain-language data use. Say what's collected, why, and who can see it, in words a person would actually read.
Least data necessary. Ask only for what the task needs, when it needs it.
Visible boundaries. Show which accounts, files, or sources the system can reach, and let users narrow them.
Clear ownership. Make it easy to export or delete data, and say whether it's used to train anything.
For Video Overlay, no extra work was needed here; security was built into the system, allowing only those authorized to see video.
Security is the one cornerstone users rarely praise and always remember when it fails.
Why you need all four
Each cornerstone covers a weakness in the others. Remove one and trust doesn't drop a quarter; it breaks in a specific, recognizable way:
If this is missing | Users feel | Typical result |
|---|---|---|
Transparency | "I can't tell what it's doing." | Blind faith, then abrupt distrust after the first visible error |
Agency | "I can't fix it when it's wrong." | Anxiety, double-checking everything, or switching it off |
Benefit | "Why am I using this?" | Low adoption, or resentment at the data and control it asks for |
Security | "What else is it doing with my data?" | Withheld access, which limits how useful the system can be |
The four also trade off against each other. More transparency can overwhelm; more agency can slow the very automation people wanted. Good design is deciding how much of each a given moment needs, not maximizing all four at once.
A checklist for your product
Before shipping any feature where the system acts on a user's behalf, ask:
Transparency: Can the user see what it did and why, without leaving the screen?
Agency: Can they undo or correct it in one step, and does the system learn from that?
Benefit: Can they name what they gained, within a few seconds of using it?
Security: Do they know what data it touched, and can they limit or remove it?
If any answer is "not really," that's your next design task.
The question I'd leave you with: when your system makes its first mistake in front of a user, which of the four will they reach for?
Comments