The Compute Isn't Yours. The Answer Still Is.
Across the regulated AI teams we've been talking to in Poland and the wider EU this outreach pass, one pattern keeps repeating: almost none of them run their own inference. It sits with a hyperscaler, a specialty inference platform, a managed endpoint. Running your own fleet is the rare exception.
That isn't a scandal. Renting compute is the rational default; nobody builds a GPU fleet to serve one clinical decision-support tool. But it creates a split most teams don't examine until something goes wrong: the machine that ran the job belongs to a vendor. The output it produced, and the consequence that followed, belongs to you.
Look at what these teams' systems are actually doing. The most common consequential action in the field right now isn't a chatbot reply, it's a clinical or safety instruction: a dosage flag, a triage recommendation, a fault call on equipment. And the most common party waiting for an answer about that instruction isn't an internal auditor. It's a regulator.
So the operator's actual position: you own the outcome of a decision made on hardware you don't control, and you owe an explanation to someone with the power to shut you down.
What breaks first
Ask any team in this position what they'd hand a regulator, or an enterprise customer, who asks which model produced a given output and whether it ran correctly. Most produce an API log, a vendor invoice line, a dashboard screenshot. All three describe what the vendor's system reported about itself. None of them are something the person asking can check independently. If the vendor's account is disputed, or the model was quietly swapped behind a versioned endpoint, there is nothing underneath it.
That gap doesn't show up in a calm quarter. It shows up mid-incident: a bad clinical recommendation, a safety flag that fired late, an insurer or regulator asking for the exact inference that produced the exact output at the exact time. Reconstructing that from vendor telemetry, under a clock, with the vendor's cooperation required and not guaranteed, is where teams discover the contract they signed covers uptime and data residency, not proof of what actually ran.
What to ask a compute vendor instead
- Can you give me evidence, not just a log entry, that a specific output came from a specific declared model — evidence a third party can check without trusting your word or re-running the job?
- If your infrastructure changes, upgrades, or reroutes silently, does anything travel with my output that would catch it?
- When I owe a regulator or a customer an answer six months from now, what do I have that doesn't depend on your systems still holding the record, or on your cooperation?
Most vendors answer the first two with uptime numbers and the third with a shrug. That's the gap.
The fix is structural, not procedural
The mechanism that closes it is the one at the center of our work: separate the party that runs the inference from the party that proves what ran. A cryptographic receipt tied to a specific, mathematically verified inference gives you evidence that is independently verifiable, reproducible, and tamper-evident, checkable by a regulator or a customer without their needing to trust the vendor, or you, on your word. That's live today for embedding workloads and for ONNX-exportable models brought in directly.