Most organizations are making a quiet, dangerous assumption. In a recent article published on jonahtebaa.com, Dr. Jonah Tebaa — AI strategist, four-time founder, and author of Applied AI for Future Ready Organizations — names it directly: organizations deploy an AI system, watch it run, and at some point, without a formal decision or written standard, begin trusting it. Not because they evaluated it. Because it had not failed yet.
Dr. Tebaa's diagnosis is blunt. That is not governance. That is hope with a software license.
The Binary Trap
Drawing on his work advising executives across industries and geographies, Dr. Tebaa identifies two camps that each handle AI authority badly — and for the same underlying reason.
The first camp moves fast. They ship AI into production, expand its authority incrementally, and treat each expansion as evidence of confidence. When something goes wrong — and eventually something does — they have no framework for determining whether the error was within acceptable range or a systemic failure. They were never measuring. They were watching.
The second camp waits. They want more proof, more case studies, more ecosystem maturity. This sounds prudent. In practice, he argues, it means their competitors are building operational fluency with AI while they are still writing governance committee agendas. Delay is not a neutral choice.
Both camps share the same missing piece: neither defined what trustworthy performance looks like in their specific operational context, before the system was live. This is what Dr. Tebaa calls the governance-over-tooling problem — you cannot make sound adoption decisions if strategy comes after the tool is already embedded.
The technical literature supports the point from an unexpected direction. A 2025 arXiv study, Where LLM Agents Fail and How They Can Learn From Failures, describes modern agents as systems "which integrate planning, memory, reflection, and tool-use modules". Trustworthiness is therefore not a single property a vendor can certify once; it is a claim about how several interacting modules behave together on your data, in your process. That is exactly why the threshold has to be defined locally and in advance — nobody outside the organisation is in a position to define it, and after go-live the definition tends to be quietly rewritten to match whatever the system happens to be doing.
What Trust Actually Means in Operational Terms
Dr. Tebaa draws a clear distinction between trust as a feeling and trust as a formal standard. In his framework, trust is not a comfort level. It is a set of pre-agreed conditions that must be met before authority is extended. If those conditions are not written down before deployment, an organization does not have a trust standard — it has a bias toward inertia that will either delay adoption indefinitely or justify expansion without evidence.
He defines the trust threshold as: a formal, documented set of performance conditions — specified before deployment — that justify extending autonomous operational authority to an AI system within a defined scope.
The phrase "before deployment" carries the weight. Organizations that write these conditions after the first incident are writing them reactively, under pressure, with the system's existing track record already shaping what they decide is acceptable. Dr. Tebaa's position is unambiguous: that is not governance, that is rationalization.
The Three-Axis Trust Audit
To operationalize the trust threshold, Dr. Tebaa's framework evaluates each AI system against three independently measurable axes — all three considered together.
Axis 1: Error Rate vs. Acceptable Threshold
What is the system's error rate in production, measured against a pre-agreed acceptable threshold? Not a general industry benchmark — the organization's own threshold, for its own process, accounting for the cost of each error type. An AI triaging low-stakes customer queries can tolerate a different error rate than one flagging compliance exceptions. The specific number matters less than the fact that it was set before observation began. Once a system has been running, its track record has already begun to influence what leaders consider acceptable.
Axis 2: Reversibility of Decisions
What decisions is the AI system empowering, and can they be undone? Dr. Tebaa identifies reversibility as one of the most underrated variables in governance design. Sending a draft communication for human review is reversible. Automatically executing a procurement decision is not. Systems operating in low-reversibility environments, he argues, require a fundamentally higher trust threshold — not because AI is inherently unreliable, but because the cost of error is asymmetric. This is especially relevant for systems built on large language models, where output variability under edge-case inputs is a documented characteristic, not a patch-able bug.
Axis 3: Auditability
Can every decision the system made be reconstructed in sufficient detail to explain it to an auditor, a regulator, or an employee whose work it affected? Dr. Tebaa frames auditability not as a blame mechanism but as an organizational learning capacity. A system whose decisions cannot be reconstructed is a system that cannot be improved — and in high-stakes environments, one that cannot be defended.
Expanding and Contracting Authority
A central and often overlooked element of Dr. Tebaa's framework is its bidirectionality. The trust threshold is not a one-time gate. Authority should expand when a system exceeds its thresholds consistently across a meaningful time horizon. It should contract when performance degrades, when operational context changes, or when the scope of decisions increases in ways that were not anticipated at deployment.
This means writing both expansion criteria and contraction criteria before going live. Organizations that write only the conditions under which they will extend authority — and not the conditions under which they will pull it back — have built what Dr. Tebaa calls a one-way ratchet. That, he notes, is how organizations end up over-relying on systems they can no longer adequately supervise.
The Practical Starting Point: One Governance Decision Log
Dr. Tebaa is not proposing a hundred-page governance framework. For most organizations, he recommends starting with a single document — one page, updated at defined intervals — that answers five questions for each AI system in production:
- What is this system authorized to do, and what is explicitly out of scope?
- What are the numerical performance conditions it must meet to retain current authority?
- What are the conditions that would trigger authority expansion?
- What are the conditions that would trigger authority contraction or suspension?
- Who is accountable for reviewing the log and when?
That document does not guarantee good outcomes. But it converts an implicit, intuitive, drift-prone relationship with an AI system into an explicit, auditable, defensible one. In Dr. Tebaa's framing, that is the operational difference between organizations that govern AI and organizations that are governed by it.
His closing argument in the original piece is one worth carrying directly: trust is not extended by default. It is earned through demonstrated performance against a standard that was set before the system had a chance to influence judgment. Define the threshold before deployment. Everything else is negotiation under pressure.
This article summarizes Dr. Jonah Tebaa's original piece, The Trust Threshold: How to Decide When an AI System Has Earned Operational Authority, published June 19, 2026, on jonahtebaa.com.
