AI for regulated industries: the hard part isn't the model, it's proving where the data went and what touched it. An infrastructure problem, not an AI one.
In finance, health, and insurance, the model is rarely the bottleneck. Proving exactly where the data went and what touched it is. The hard part of regulated AI lives in the infrastructure, not the intelligence.
Disclosure: we're building a venture in this category. Figures are attributed to named sources, and we name our own stake where it's relevant.
Spend time with teams trying to bring AI into a bank, a hospital, or an insurer, and a strange thing becomes clear. They're not stuck on the model. The models are good enough, often better than good enough. They're stuck somewhere upstream of the model entirely.
They're stuck on proof. Proving, to a regulator or an auditor or a nervous client, exactly where the data went and precisely what touched it. The AI is the easy part. The chain of custody is the hard part.
In a regulated industry, deploying AI is mostly a question of evidence. Can you show a reviewer where every byte of sensitive data lived, who could see it, and that it was deleted when it should have been?
The requirements are concrete and they don't bend. A European hospital may need patient data to never leave the EU, governed by GDPR, with a signed agreement and a documented deletion. A Canadian financial firm may need personal data handled under PIPEDA, with breach notification inside a fixed window. A US health system needs a chain of custody an auditor can actually follow. None of those rules ask how clever your model is. They ask where the bytes went, who could see them, and whether you can prove it. We walk this demand in full in The data you can't send to the cloud is the data most worth computing on.
So the real question for regulated AI isn't "is the model accurate." It's "can the infrastructure produce evidence." Those are different problems, and only one of them is solved.
The cheap, abundant compute that powers most AI experimentation comes from sharing, many tenants on hardware no one of them owns. That's a fine foundation for most workloads and a non-starter for regulated ones, because the same sharing that lowers the price raises the questions a compliance officer must answer.
The market admits this plainly. On open rentals, a host can sometimes observe your workload, as one widely-cited marketplace thread stated outright: "a host can snoop on your workloads" (Hacker News, discussion 36026101). The vendors know it, which is why a special lane keeps appearing for sensitive work. One network routes regulated jobs to "Verified Data Center" nodes and warns against its community tier for SOC 2 or HIPAA data (a leading decentralized GPU network, vendor comparison, Apr 2026). A major marketplace adds a separately-certified "Secure Cloud" tier carrying ISO 27001 and HIPAA classifications (a major GPU marketplace, data-center application, 2026). Credit to both: they're honest that the default machine isn't built for the regulated job. The existence of that special lane says the rest. The ordinary one doesn't pass.
In regulated AI, the model is the part everyone can buy. The chain of custody is the part almost no one can prove. The bottleneck was never the intelligence. It was the evidence.
Reduce it to what an auditor would sign off on, and the list is short and unforgiving. None of it is about the model.
Isolation that's structural. Per-job network boundaries so a workload reaches the coordinator and nothing else, closing the exfiltration path rather than promising it's closed.
A provable chain of custody. Encryption in transit and at rest, plus a durable record of what ran where that survives a review.
Data residency you can specify. The ability to keep a job inside a jurisdiction by design, not by hope.
A real data-processing agreement. Under GDPR, whoever runs someone else's machine is a sub-processor, which means a signed DPA and a guaranteed deletion, not a verbal assurance.
Every item on that list is infrastructure. The model sits on top, almost incidental to whether the deployment is allowed to exist.
No architecture makes input data invisible to the hardware computing on it, and any vendor promising perfect, absolute confidentiality on someone else's machine is selling the claim, not the capability. The defensible standard is documented risk reduction: minimization, contractual control, structural isolation, an auditable trail. That's a real thing a regulated buyer can rely on. Perfect secrecy is not, and a serious institution knows the difference.
The supply-trust gap that makes all of this hard is the flagship, The sub-1% problem in decentralized compute, and the verification mechanism that helps close it is Proof you can't fake.
This is the buyer we're building for, and it's where security stops being a feature list and becomes the whole product. Per-job WireGuard isolation, hardware-rooted attestation, host intrusion detection, data handling auditable against GDPR: in a regulated deployment those are not extras, they're the thing that lets the deployment exist at all. Pair them with deep vertical software work in finance, health, and insurance, and the wall at the infrastructure layer comes down. The model was always ready. The evidence layer wasn't. That gap is what our AI venture, Griddly, was built to close.
Nothing here is an offer to sell a security or investment advice.
Field notes on venture building, AI, and capital. No spam, unsubscribe anytime.
By subscribing you agree to receive AOS Insights e-mails. We use your address only for this newsletter - see our Privacy Policy.
