Stop calling it “trusted AI” if you can’t prove it

Every board deck I see now has some version of the same slide: “trusted AI.” There are principles, governance bullets, and a reassuring diagram of the stack. What is usually missing is the one thing that actually earns trust in security: proof.

The next wave of market disruption belongs to organizations that fully embrace AI. Yet the rush to integrate it has outpaced the development of basic safeguards. We are wiring AI into payments, trading, healthcare, and critical infrastructure faster than we are building controls that show us what it is doing and how our data is handled. In privacy, we already lived through this. Before GDPR and CCPA, protection was based on policies and good intentions. It took real standards, backed by enforcement, to move from “trust us” to “prove it.” AI has not had that reckoning yet.

‍

The problem with “trusted AI” today

There are really two fundamental problems with the current definition of “trusted AI.”

The first is operational opacity. For organizations using turnkey AI solutions, the “trust” is entirely theoretical. They usually cannot answer basic questions about the systems they run: Which specific model version executed the request? Which tools or plugins were invoked? Where exactly was the data processed? If you cannot verify the path your data took, you are not managing risk; you are outsourcing it to a vendor’s terms of service.

The second problem is deeper: the gap between probability and semantic understanding. Fundamentally, these models are probabilistic engines, not reasoning agents. While they operate within a "context window," they possess no semantic understanding of the world. To a model, your critical business decision is not a concept, it is simply a stream of tokens converted into a math equation.

The model solves that equation to predict the next statistically likely integer, not to determine the truth. Yet organizations are increasingly treating these probabilistic outputs as verified facts. This creates a verification crisis. How do you check the veracity of an output derived from probability rather than logic? The industry’s current answer is often to use more AI to evaluate the first AI. This leads to a trap of recursive trust. You cannot prove a system is safe by piling more unproven probabilities on top of it. Relying on an AI to grade an AI isn’t governance, it’s just doubling down on the black box.

‍

AI runs on supply chains, not fortresses

Recent events like the OpenAI and Mixpanel incident have shown how fragile modern AI stacks can be. A single analytics provider breach was enough to expose sensitive metadata about API customers, even though no prompts or model weights were touched. Users still carried the risk.

That is the reality of AI today. These systems are not self-contained fortresses. They are long, recursive supply chains of models, tools, data stores, logging systems, and third party services. A gap at a peripheral vendor can compromise the entire experience. You cannot evaluate an AI system only at the model layer, and you cannot trust any part of the stack that you cannot independently verify.

‍

What proof-based AI governance looks like

If we stop calling it trusted AI until we can prove it, what does proof look like?

First, verifiable execution. You should be able to prove which model and which policy ran for a given request. Confidential computing and hardware backed attestation matter here. If your data is processed inside a trusted execution environment and you receive a cryptographic proof of that fact, you are no longer relying on a vendor promise.

Second, verifiable data boundaries. It is not enough to say “we do not use your data for training.” You need technical controls that keep certain classes of data inside specific hardware, regions, or tenants and must be able to demonstrate that separation to regulators and auditors.

Third, verifiable configuration and change control. You should know who can update the model, its tools, and its guardrails, and have a clear history of those changes. If someone quietly expands what an AI agent is allowed to do in your environment, it should trigger immediate review and investigation. Policies and guidelines still matter, but they have to sit on top of infrastructure that can answer hard questions with evidence.

‍

From privacy To AI sovereignty

The parallels with the early days of privacy are hard to ignore. Before GDPR and CCPA, companies handled personal data in wildly different ways, with some doing the right thing and many others doing whatever was easiest until they were forced to change, and AI is in a similar place today, where a small group invests in real governance while most quietly ship AI into production just to say they “have an AI strategy.”

What we need now is the AI equivalent of those privacy standards: governance that treats verifiable privacy, security, and sovereignty as first class requirements, which is why I am interested in approaches like NEAR AI Cloud that run workloads inside confidential hardware and return cryptographic proofs of how they were executed, moving us from “believe us” to “here is the evidence.”

‍

Trust In AI requires proof

There is no path to competitive advantage in AI that does not run through trust, and sooner or later customers, partners, and regulators will demand proof of how these systems handle their data and how decisions are controlled. The organizations that win the next wave will be the ones that fully embrace AI and can show it operates within clear, enforceable boundaries; until you can do that, “trusted AI” belongs in a pitch deck, not a risk report.

If you cannot prove it, stop calling it trust.