What zero-knowledge proofs mean for regulated AI workflows

Supervisors need to see that a rule held. Clients and counterparties need their data not to travel with that demonstration. Most “AI governance” stacks resolve the tension by picking a side: dump the log, or refuse to show anything useful. A zero-knowledge proof is how you do both.

The tension, stated plainly

A wealth manager rebalances a mandate. The rule is simple: no account may hold more than 10% of a fund. An AI agent proposes the trades. A validator allows or blocks them. An examiner later asks: “Show me that this rebalance respected the concentration limit.”

If you export the portfolio, you have shown the rule — and disclosed every position. If you export only “check passed,” you have asserted the rule and given the examiner nothing they can verify. GDPR, client confidentiality, and market-sensitive books make the first option expensive. Trust-me summaries make the second option worthless.

The same shape appears in procurement (three-way match without revealing supplier pricing), payments (sanctions outcome without circulating the full screening file), and clinical authorisation (pathway compliance without exposing the record). The workflow is regulated. The underlying data is not for general circulation. AI does not create that tension. It makes it daily, because agents propose more actions than humans ever reviewed by hand.

What a ZK proof is — and is not

A zero-knowledge proof is a cryptographic object. A prover shows that a statement is true. A verifier checks the proof. The verifier learns that the statement held, and essentially nothing else.

In a compliance setting the statement is not “the model was confident.” It is “this action, against this policy version, on this committed state, was allowed.” The portfolio stays with the firm. The proof can leave the building.

ZK is not encryption of the log. Encrypted logs still require someone to decrypt them to audit. ZK is not differential privacy, which blurs individuals in aggregates. It is not “the vendor said the check passed.” It is a mathematical demonstration that a specified predicate evaluated to true.

It is also not a substitute for a rule. If you cannot state the invariant precisely, you cannot prove it. Garbage in, succinct garbage out. Specification comes first; the proof is how you show the specification was applied to this action.

Where it sits in the architecture

The AI remains untrusted. It may be prompted, compromised, or simply wrong. It proposes a transition. A deterministic validator evaluates the policy. If the policy requires confidentiality toward the examiner, the counterparty, or even the agent itself, the system emits a ZK proof that the predicate held, alongside a hash-chained audit log entry that ties the decision to time and prior records.

That is the pattern in the Compliance Operator (CECO): agents propose; the validator decides; proofs and receipts explain the decision without becoming the enforcement layer. In a three-way match, you can show PO, goods receipt, and invoice aligned without putting supplier unit prices in the agent’s context window. In mandate compliance, you can show the concentration limit held without publishing the book.

Two properties matter operationally. First, verification is independent: the examiner does not have to trust your SIEM. Second, the proof is about a stated policy. If the policy is vague, the proof is theatre with better maths. Spec++ exists so the predicate is the same object compliance signed and engineering enforced.

What this is not a licence to hide

Selective disclosure is not a way to starve a supervisor of facts they are entitled to. If the law requires you to produce the underlying file, you produce the file. ZK is for the common case where the question is “did the rule hold?” and the data needed to evaluate the rule is more sensitive than the yes/no the examiner needs to record.

It is also not a claim that every rule is currently compiled to a circuit. Some checks stay in the validator with a hash-chained record and no ZK. The architecture should allow proofs where confidentiality and verifiability collide; it should not pretend every invariant is already a circuit.

What to ask a vendor

“Do you use zero-knowledge?” is a branding question. Ask instead:

• Which predicate is proved — a named policy version, or a model score?
• Who can verify without your infrastructure?
• What remains hidden, and what is intentionally revealed (decision, timestamp, rule id)?
• Does the proof exist before execution, or is it reconstructed from logs?
• If the AI is fully compromised, can it still force a non-compliant transition?

If the answers collapse to “we encrypt our audit trail,” you are still in log-and-hope. If they name a validator, a policy, and a proof that a third party can check, you are in the architecture regulated AI actually needs: demonstrate the rule, keep the book.