The pattern we kept seeing
In 2024, the market for AI integrations in regulated industries was heating up. Healthcare teams wanted to use large language models for clinical note summarisation. Financial institutions wanted AI-assisted document review. Legal teams wanted contract analysis. All of them had the same problem: they needed to send data to an AI provider, and they had compliance obligations that made them nervous about doing so.
The response from AI vendors was predictable: a privacy policy with reassuring language, a DPA on request, and — for the larger enterprise customers — a BAA or an MNDA. The procurement process treated these documents as the privacy guarantee. Sign the right forms, check the boxes, proceed with deployment.
We kept asking the same question: what in the system enforces the claim? The answer, uniformly, was: nothing. The privacy guarantee was a legal instrument, not a technical one. It meant "we promise not to misuse your data," enforced by contract law after the fact. It did not mean "the system is designed so that data exposure is structurally impossible."
Privacy as a marketing checkbox
The pattern compounds at the infrastructure level. Most "enterprise" AI deployments route through a general-purpose API gateway — either the vendor's own or a third-party proxy — that has full visibility into request and response content. The gateway logs are stored somewhere. The retention policy is specified in a document that most customers do not read. The AI provider's model training opt-out is a setting that defaults to on (or was, until regulators intervened). The audit trail is a log file that the customer cannot independently access or verify.
In this architecture, "privacy" means: trust our policies, trust our staff, trust our infrastructure, trust our subprocessors. At each step, you are trusting a human process — not a technical property.
We are not saying that trust is worthless. We are saying that it is insufficient for regulated data, because the consequences of a breach are borne by the data subject and the covered entity, not the AI vendor. The incentive structure is wrong.
What "engineering invariant" means
An engineering invariant is a property that holds by construction — not by policy. You do not need to trust anyone to maintain it; you can verify it.
The example we kept returning to: if you encrypt data before sending it to a cloud storage provider, and you hold the encryption key, then the provider cannot read your data. Not because they promised not to. Because they cannot. The privacy property is a consequence of the cryptographic architecture, not a contractual commitment.
We wanted to build the equivalent for AI. The insight: if you tokenise sensitive spans before they leave your application, the AI gateway receives placeholders — not PHI, not PII, not trade secrets. The gateway literally cannot expose what it never received. You can audit this property by reading the code, by verifying the receipts, by checking the chain. You do not need to trust us to maintain the invariant; the invariant holds regardless of our behaviour.
The system literally cannot leak X — not "we have policies to prevent leaking X."
This distinction matters because policy-based privacy is only as strong as the weakest link in the policy chain: the least-careful employee, the unpatched subprocessor, the one log file that wasn't rotated on schedule. Invariant-based privacy has a different failure mode: it fails at the application boundary, which is inside your infrastructure, which you control.
The bet
Our thesis is that a segment of the market will pay for proof, not promises. Not all customers — many are satisfied with vendor assurances and a well-crafted DPA. But the customers in highly regulated industries who have dealt with a breach, or who have a compliance team that actually reads the contracts, will prefer a system where the privacy property is independently verifiable.
This is not an abstract bet. The people we build for are concrete: the healthcare CISO who wants to walk through how tokenisation works at the byte level; the security team that wants the JWKS endpoint so they can verify receipts independently; the auditor who wants the OpenReceipt spec so they can run their own verifier. Those are exactly the requirements a policy-based privacy story cannot satisfy — and exactly what we designed the system to answer.
Why open spec and reference verifier
If our privacy guarantee is "trust our architecture," we have not solved anything — we have just moved the trust one level down, from policy to design claims. The only way to make the guarantee credible is to publish the specification and let anyone verify it.
This is why the OpenReceipt specification is public, the reference verifier is MIT-licensed, the JWKS endpoint is unauthenticated, and the receipt chain can be verified entirely offline. We designed it so we cannot backtrack. If we change how receipts are signed, old receipts will fail to verify against the new key. If we change the canonicalisation scheme, the spec change is public. Every commitment we make in the system is one we cannot quietly undo.
That is the kind of privacy guarantee we wanted. We built CloakAPI because no one else had.