Your compliance team didn't rule out AI. They ruled out someone else's infrastructure.

Your compliance team didn't rule out AI. They ruled out someone else's infrastructure.

Plenty of regulated organisations have quietly closed the AI conversation with a version of the same sentence: our data can't leave the building, so this isn't for us. Legal, healthcare, financial services, parts of the public sector: all landed on the same no, for what sounds like a technical reason. It isn't. It's a reasoning error, and it's an expensive one, because the actual constraint rules out exactly one thing: sending your data to somebody else's model, running on somebody else's servers, under somebody else's roadmap.

That's not the same as ruling out AI.

What "using AI" actually means

Frontier API access (the ChatGPT, Claude or Gemini route most people mean when they say "AI") is a dependency, not a tool. You send data across a boundary you don't control, to a model you didn't build, priced on terms you didn't set. The provider can retrain it, deprecate it, or reprice it, and you find out when they announce it. For a workflow with no sensitivity, that's a fine trade: someone else's engineering, someone else's problem, and you get the output.

Client-privileged documents. Patient records. An unpublished judgment. For a workflow where the data genuinely can't leave, that trade is the actual thing being ruled out. Not "AI". A specific dependency, on a specific vendor, for a specific workload.

Open-weight models change what's on the table. Run one on infrastructure you own: your servers, your network, air-gapped if that's what the workload demands, and the data never crosses a boundary at all, because there isn't one to cross. Nobody deprecates the model out from under you; you hold the weights. Nobody reprices it mid-year; there's no metered bill to reprice. You've traded a vendor relationship for a maintenance obligation, and for the workloads where the dependency was the actual blocker, that's a trade worth examining properly rather than dismissing on the assumption that it doesn't exist.

This is not a savings pitch, and treating it as one will get you the wrong answer

Here's where the argument usually goes wrong, so it's worth saying plainly: running your own model is not cheaper than an API call, and anyone telling you it is hasn't costed it properly. Inference hardware isn't free. Someone has to run it, patch it, and keep it running at 2am when it falls over. And before any of that, someone has to prove the model you've chosen actually hits the accuracy bar for your workload: that evaluation work is real engineering time, not a checkbox. Add those three up and for most organisations they exceed whatever API spend was being avoided. If the pitch you're hearing is "bring it in-house and save money," that pitch is wrong, and the person making it either hasn't run the numbers or is hoping you won't.

The case for self-hosting isn't economic. It's that control has a value separate from cost, and for a workload where the dependency itself is the risk, no amount of API discounting removes it.

And no, regulation doesn't actually say what people think it says

The other error runs the opposite direction: assuming the rules forbid cloud AI outright, full stop, so there's nothing further to think about. They mostly don't. Plenty of regulated work is done lawfully on cloud AI today, with the right contractual terms, the right technical controls, and the right documentation to show a regulator when asked. Air-gapping is one valid posture. It is not the only compliant one, and treating it as the default answer skips the actual question, which is contractual and technical, not moral.

The decision that's actually being avoided

The real question was never "can we use AI." It's narrower, and it's answerable: for this specific workflow, what does the dependency on someone else's model actually expose us to? Data residency, vendor continuity, pricing risk. Is that exposure one we're willing to carry?

Answer that per workflow, and the decision stops being a blanket no. Some of what your organisation does is genuinely fine on a frontier API with a sensible contract behind it. Some of it isn't, and for that slice, owning the model instead of renting one is a real option: expensive, deliberate, and worth doing precisely because it's the workload where "we don't control this" was the actual problem, not a hypothetical one.

That's the decision worth making. Not "no to AI" — "no, specifically, to depending on someone else's infrastructure for this."

Not sure which of your workflows actually carry that exposure, and which don't? Get in touch before a procurement default makes the call for you.