Trust between two people is a bet. You're handing someone the ability to hurt you, and betting they won't.
Roger Mayer, James Davis and David Schoorman spent years asking what that bet is actually made of, and landed on three ingredients. Ability: can this person do the thing. Benevolence: do they want good things for me, not just for themselves. Integrity: do they act on principles I'd sign off on. You need all three. A brilliant, self-interested person with no integrity gets no trust from you. Neither does a kind, well-meaning person who's terrible at their job. Trust is what shows up when all three are present at once.
Now put a robot in the room and ask the same three questions.
Ability, no problem. Robots can be extremely good at what they do, better than most of us in a narrow lane. Integrity, sort of, if you're willing to call consistent, rule-following behavior a kind of integrity. It never lies to cover a mistake. It never plays favorites.
Benevolence is where it falls apart. Not because robots are bad at it. Because there's nothing there to ask the question of. A robot has no stance on you. It doesn't want anything, good or bad. Wanting requires an inside, and a robot doesn't have one.
This is where John Lee and Katrina See's work picks up. Writing about trust in automation, they built a different three-part model: performance, process, purpose. Performance is what the machine does. Process is whether you understand how it does it. Purpose is whether the people who built and deployed it had the right reasons for doing so.
Here's the part worth sitting with. Purpose is standing exactly where benevolence used to stand. Same slot in the model, same job to do. It just doesn't point at the machine anymore. It points at the humans who put the machine there.
So the gap between human trust and machine trust isn't really a gap. It's a redirect. The question "does this thing care about me" doesn't disappear when the thing is a robot. It just changes who's answering it.
Which tells you exactly what needs adjusting if you want real trust in an automated system, not the borrowed kind people extend by default and then quietly withdraw. Most rollouts answer the performance question loudly, accuracy rates, safety certifications, a demo showing the robot doing its job well. That's the easy third. Almost nobody answers the purpose question out loud, on purpose. Why is this here. Who decided that. What happens to the people whose work it touches. Leave that silent and people don't conclude nothing happened. They fill the gap themselves, and rarely with the generous version.
That's not just an unanswered question sitting there quietly. It's exactly how trust gets miscalibrated, the specific failure Lee and See built this whole model to prevent. Left to fill in the purpose gap on their own, people don't land on a neutral guess. They swing to one of two wrong answers, and both are common.
Overtrust is one of them: handing a system more faith than its performance earns. You stop checking. You assume it knows things it doesn't, or handles cases it was never built for. That's how autopilot complacency happens, and it's how a chatbot ends up making a promise nobody signed off on.
Undertrust is the other, and it's the quieter cost. A system that works fine gets ignored, second guessed, worked around, because nobody explained why it's there or how it thinks. You paid for the capability and then nobody used it.
Both come from the same root: people don't have enough honest information to calibrate. Fix performance and process transparency, plain language on what it does and how, and you shrink both errors at once. Fix purpose transparency, plain language on why it's here and who it's meant to serve, and you close the part of the gap the other two can't touch. That's the piece most rollouts skip. It's also the one actually doing the trust-building work.
Mayer, R.C., Davis, J.H., & Schoorman, F.D. (1995). An Integrative Model of Organizational Trust. Academy of Management Review, 20(3), 709-734. Lee, J.D., & See, K.A. (2004). Trust in Automation: Designing for Appropriate Reliance. Human Factors, 46(1), 50-80.