Verifiable of What?
A year ago, very few AI vendors described their systems as verifiable. Today the word is everywhere: verifiable privacy, verifiable guardrails, verifiable audit trails, verifiable trust. That is progress. It means the market has accepted that "trust us" is no longer an acceptable answer.
It also means the word has stopped telling you much on its own. When a vendor says their AI is verifiable, the useful response is a question: verifiable of what?
There are three distinct properties hiding under that one word.
Nobody could see the data. Not the operator, not the cloud provider, not the other parties in a shared computation.
Nobody rewrote the record afterwards. What was logged at the time is what you are reading now.
What the record says actually happened. This model, this version, on this input, produced this output.
Each property holds independently
These are not three levels of the same thing. They are three different guarantees, built with different techniques, and any one of them can hold while the others fail.
Hidden is achieved with encryption that persists while data is being processed, typically inside hardware-isolated environments. It answers the question every data protection officer asks first: could anyone see what we sent?
Unaltered is achieved with signatures, append-only logs and independent parties who countersign that history at intervals. It answers a different question: has anyone quietly changed the record since?
True is the one that tends to get assumed rather than established. It asks whether the computation the record describes actually took place as described. Not whether the record was kept safely, but whether it was accurate at the moment it was written.
That sentence is the whole argument. Confidentiality protects what went in. Tamper-evidence protects what was written down. Neither, on its own, establishes that what was written down is what happened.
Where "true" usually rests
When a system does claim the third property, it most often rests on hardware attestation: the processor itself signs a statement about what code and which model were loaded. That is a genuine technical achievement, and in most circumstances it works.
But it moves trust rather than removing it. The guarantee now depends on the silicon vendor's root of trust and on the physical integrity of the machine. In October 2025, researchers at Georgia Tech and Purdue showed they could extract attestation keys and forge attestations on current confidential computing platforms from the major chip vendors, using a memory interposer assembled from off-the-shelf equipment. The attack needs physical access to the server. The vendors have long treated physical attacks as outside their threat models. The two threat models are compared field by field in the engineering companion Hardware attestation versus independent re-execution.
Ask who has physical access to a server running your vendor's AI. The answer is the operator: the data centre, the cloud, the compute provider. In other words, the party whose account of what ran you are trying to verify.
A second way to establish truth
The alternative does not ask you to trust the machine at all. An independent party, running on separate infrastructure, re-executes an unpredictable sample of the work and checks that the declared model on the declared input produces the declared output. The result is a signed receipt binding model, input and output, which anyone can check later without trusting the operator.
The operator cannot forge its way past this, because the check never relied on anything the operator's hardware says about itself.
It has its own boundaries, and they should be stated plainly. Sampled re-execution is economic deterrence rather than proof of every step: an operator who cannot predict which work will be re-checked finds cheating a losing bet, but not an impossible one. And it does nothing for confidentiality. The verifier processes the sample it checks, under contract. If your first concern is that nobody may ever see the data, this is not the property that answers it.
The layers stack
None of this is an argument for one technique over another. The three properties answer three different fears, and a serious deployment in a regulated setting may need all three: data kept hidden during processing, records protected from rewriting, and the truth of the computation established by someone who is not the operator.
What matters is knowing which property you are actually buying, and not letting a strong answer to one question stand in for an answer to another. How the properties compose in an evidence record, and which mechanism establishes each, is worked through in the engineering companion Three properties of an AI evidence record.
Three questions for any vendor who says verifiable
Hidden from whom? From other customers, from the cloud provider, or from the vendor itself?
Unaltered since when, and witnessed by whom? Is the history countersigned by a party the vendor does not control?
True according to whom? And does that party have physical access to the machine that ran the job?
The third question is the one an examiner will eventually ask, usually about a single decision, usually long after the fact. It is worth knowing the answer before they do.