There is a particular moment that repeats itself in the lifecycle of almost every enterprise AI deployment. The technology team has shipped something impressive. The leadership team has signed off on a communications plan. The press release is approved. And somewhere in the document, in carefully chosen language, it says that the new AI system is trustworthy.
The announcement is made. The system is launched. And then — with a predictability that should be more surprising than it seems to be — adoption rates disappoint. Employees use the system less than projected. Engagement drops after the initial weeks. The dashboard numbers flatten. Leadership asks what went wrong.
What went wrong is this: trust was declared. It was not designed.
"Organisations that announce their AI is trustworthy before demonstrating it consistently underperform those that build trust into the architecture of the system from day one. This is what the data shows."
The conflation of declaration and design in AI trust is not a minor semantic error. It has measurable consequences. My doctoral research, conducted across enterprise organisations deploying AI learning systems, found a consistent and significant correlation between trust — specifically, the degree to which workers felt the AI system understood their context, respected their pace, and operated transparently — and both adoption rates and learning outcomes.1
This finding is not isolated. Lee and See (2004) established in their foundational work on trust in automation that trust is calibrated continuously — it is not granted once and held indefinitely, but updated constantly in response to system behaviour.2 Dietvorst, Simmons and Massey (2015) demonstrated what they termed "algorithm aversion" — the tendency for people who observe an algorithm make even a single error to abandon it in favour of human judgment, even when the algorithm is statistically superior overall.3 The research landscape on human-AI trust is consistent on one point: trust is earned through behaviour, not communicated through messaging.
And yet organisations continue to spend more on communications about their AI's trustworthiness than on the design conditions that would make it actually trustworthy. The gap between these two investments is, I would argue, one of the most consequential design failures of the current AI era.
What does it mean to design trust rather than declare it? In my research and in the governance frameworks I have developed, I have found that designed trust operates across three dimensions — and that all three must be present for the effect to hold.
The first dimension is transparency — not as an explanation offered after a decision, but as visibility built into the process before it concludes. There is an important distinction here. Post-hoc explainability — the practice of generating an explanation for an AI decision after that decision has been made — is not the same thing as transparency. It is a narrative constructed to accompany a conclusion. Genuine transparency is structural: the user can see, at each step, what the system is doing and why.4
Amershi et al. (2019), in their landmark guidelines for human-AI interaction developed at Microsoft Research, identified this as one of the eighteen most critical principles for trustworthy AI design: "Make clear why the system did what it did."5 The key word is "clear." Not documented. Not auditable. Clear — to the person who is using the system in real time, without specialist knowledge.
The second dimension is consistency. One of the most counterintuitive findings in the trust literature is that a system which performs at a modest but predictable level is trusted more, over time, than a system that performs brilliantly on average but erratically in individual instances.6 Trust is built not on peak performance but on reliable performance. The system that always does roughly what it said it would do — even when that level of performance is modest — earns something that exceptional-but-unpredictable systems cannot: predictability.
In the context of AI learning systems, this means that the pacing algorithm that adapts smoothly and without surprise generates more trust than the one that occasionally produces startling, if accurate, reassignments. The interaction design matters as much as the underlying model. Variance is the enemy of trust.
The third dimension is the most frequently neglected, and the one I feel most strongly about: the preservation of human agency at every meaningful decision point. Organisations often treat human oversight as a constraint on AI capability — as friction to be minimised on the path to automation. My research suggests the opposite is true. Human agency, embedded structurally into the system's design, is one of the primary conditions that enables sustained trust.7
When employees know that there is a human being responsible for the decisions that affect them — that the AI is a tool with a named accountable person behind it, not an autonomous authority — their relationship with the system changes fundamentally. They use it differently. They trust it more. And when it makes a mistake, they are more willing to continue using it, because the mistake is attributed to a system that a person oversees rather than to an autonomous agent operating beyond human control.
"Human agency, embedded structurally into the system's design, is not friction. It is one of the primary conditions that makes sustained trust possible."
The practical implication of this argument — that trust is designed, not declared — extends beyond individual product decisions into the domain of governance. If trust must be embedded in design from the beginning, then governance frameworks that address AI only after deployment are structurally too late. They cannot produce trust. At best, they can identify its absence.
The EU AI Act (2024) represents a serious attempt to address this — its risk-based categorisation and conformity assessment requirements push organisations to consider trustworthiness earlier in the development cycle than previous regulatory frameworks.8 But regulation is a floor, not a ceiling. The organisations that will build genuinely trusted AI are those that do not wait for regulation to require trust — they build it because they understand that it is the condition under which AI performs best.
This is not a soft argument about ethics. It is a hard argument about performance. AI systems that are trusted are used more, used better, and produce superior outcomes. The return on investment in trust design is, by the evidence available, higher than the return on investment in communications about trust.
The practical demands of designed trust are not exotic. They do not require technologies that do not yet exist or principles that are not yet understood. They require something more difficult: the organisational will to prioritise trust in the design process rather than in the communications process.
That means user research conducted before deployment, not after. It means feedback mechanisms built into the system architecture, not added as a feature request. It means accountability structures that are visible to every person who uses the system — not documented in a governance charter that no one reads. It means measurement frameworks that track trust alongside performance, not as a secondary metric but as a primary one.
And it means — perhaps most importantly — the humility to acknowledge that trust cannot be manufactured through confidence. An AI system that presents itself as certain when it is not, as capable of more than it can deliver, or as transparent when its processes are opaque will eventually face a reckoning with the gap between its claims and its behaviour. That reckoning, when it comes, is expensive — in adoption, in outcomes, and in the far harder currency of human confidence.
I have watched organisations rebuild trust after it collapsed. It is possible. But it takes three times as long as building it correctly from the beginning, and costs considerably more.
Design it in. Do not declare it into existence.