Open-weight vs API-hosted models — a vendor risk comparison

The instinct to treat self-hosting as inherently more secure comes from a reasonable-sounding premise: data that never leaves your infrastructure cannot be exposed by someone else's breach. That premise is true and incomplete. It says nothing about whether your infrastructure is actually better operated than the vendor's — and for a security team stretched across a growing AI footprint, that is very often not a safe assumption.

The instinct to treat API-hosting as inherently safer runs the same argument in reverse: a specialised vendor whose entire business is running inference infrastructure has presumably invested more in operating it securely than a generalist internal platform team can. That is also true and incomplete — it says nothing about what happens when that vendor has an incident, and it makes every one of its customers dependent on a disclosure practice they do not control.

Both instincts are half-right, which is what makes this decision harder to reason about than it looks. The question that actually resolves it is not “which is safer” — it is “which specific risks are we equipped to own, for this specific system.”

It is worth naming why this particular comparison resists the shortcuts that work for other build-versus-buy decisions. For most infrastructure choices, the security delta between self-managed and vendor-managed tends to correlate reasonably well with a single factor — how mature the vendor's operational practice is relative to yours. Model hosting adds a second, largely independent axis: the properties of the model artefact itself — its provenance, how predictably its behaviour changes across versions, how it fails — which do not track the same maturity curve as infrastructure operations. A vendor can run excellent infrastructure and still be opaque about model provenance. A self-hosted deployment can have weak infrastructure discipline and still have a fully verified, well understood model underneath it. The two axes need separate evaluation.

The five categories below are where that question actually gets answered. Each one has a real trade-off, not a clean winner, and a review that skips straight to a policy default — “we always self-host for anything sensitive” or “we always use a major vendor API” — is substituting a heuristic for the comparison this system specifically needs.

Self-hosting keeps data fully inside your infrastructure boundary — no prompts or completions transit a third party's network, and no third-party retention policy applies. That is a real property, and for some regulatory or contractual requirements it is a non-negotiable one. What it does not do is make the data handling secure by itself. The data is only as protected as the operational security your team actually applies to the hosting environment — access controls on the inference servers, logging and retention practices for prompts and completions, isolation between the model-serving layer and anything else running in the same environment.

API-hosting sends the same data outside your boundary, to a party whose operational security is, for a serious enterprise AI vendor, frequently more mature than what an internal team stretched across many priorities can build and maintain. The real comparison is not “inside the boundary” versus “outside the boundary” — it is a capability comparison between your team's actual operational security practice and the vendor's, and a review that stops at “self-hosted keeps data in-house” has not actually assessed whether in-house is where the data is safer.

Open-weight models carry a provenance question that is distinct from, and in some ways harder than, the provenance question for a hosted API: where did this specific set of weights come from, has the checkpoint you downloaded been verified against a known-good hash from the model publisher, and — critically — was it fine-tuned or modified by a third party (a model-hub reupload, a community fine-tune presented as the base model) before it reached you. A weights file is opaque in a way source code is not; there is no straightforward way to inspect a checkpoint and confirm it has not been tampered with beyond comparing it to a published hash, if one exists and you actually check it.

API-hosted models sidestep that specific verification problem — you never handle the weights, so there is no checkpoint-hash question for you to answer — but they replace it with a different opacity: the vendor's own supply chain, from base model through any fine-tuning to the production serving stack, is invisible to you. What you gain is a single accountable party you can put a question to, with a contractual relationship behind the answer. What you do not gain is visibility — you are trusting the vendor's account of their own supply chain, not verifying it independently.

Self-hosting gives you control over the upgrade cadence — you decide when to move to a new model version, and a version stays exactly as it was until you choose to change it. That control comes with the corresponding burden: you are also responsible for tracking which model updates carry security-relevant fixes (a discovered jailbreak susceptibility, a patched alignment regression) and for actually applying them. A self-hosted deployment that never gets updated because no one owns the update process is not more secure than an API-hosted one — it is running a known-stale model indefinitely.

API-hosting removes that burden by handing the vendor control of the upgrade cadence — and that is exactly the trade-off: the vendor can swap the model version behind a stable endpoint without your team doing anything, which means you get security-relevant fixes automatically, but it also means the model your application is calling today may not be the model it was calling last month, without your team having decided that or necessarily being told. This is the same model-change-notification problem covered from the contract side elsewhere — the practical control is a contractual notification clause, not the hosting model itself.

When something goes wrong — a jailbreak succeeds in production, a model produces a harmful or clearly misaligned output, an inference server is compromised — the question that determines how fast the organisation responds is: who do you call, and how fast do they answer.

Self-hosted, the incident is entirely yours: your team detects it (if your monitoring catches it at all), your team diagnoses root cause, and your team decides what, if anything, gets disclosed to affected users or regulators. There is no one else's incident-response playbook to fall back on, which means the quality of the response is bounded by your team's own AI-incident maturity — a capability many security teams are still building.

API-hosted, you depend on the vendor's own detection and disclosure practice, on a timeline you do not control. A mature vendor with a real AI incident-response process and a contractual notification obligation can outperform an internal team that has never run an AI-specific incident before. A vendor without either can leave you finding out about an incident from a customer complaint, well after the fact.

The last category is not about likelihood — it is about shape. A mistake in a self-hosted deployment (a misconfigured access control, an unpatched known vulnerability, a data-handling bug) stays inside your boundary. It can still be a serious incident, but its blast radius is bounded by your own footprint.

A vendor incident has a structurally different shape: because many customers share the same hosted infrastructure and, frequently, the same model-serving stack, a single vendor-side failure can affect every customer of that vendor simultaneously. This is not a claim that vendor incidents are more likely or more severe per-incident than self-hosted ones — it is a claim that when a vendor-side incident does happen, it happens to everyone at once, which is a different kind of exposure than a self-hosted incident that, by construction, cannot spread past your own environment.

Neither shape is strictly worse. A bounded-but-more-likely risk and an unlikely-but-shared risk are different bets, and which one an organisation should prefer depends on factors the hosting decision alone does not settle — how well the organisation can actually detect and contain a self-hosted incident, and how much visibility it has into the vendor's own incident history and disclosure discipline.

There is one more asymmetry worth naming here: a shared-blast-radius incident is, almost by definition, more visible after the fact than a contained one. When a hosted vendor has an incident affecting many customers at once, it tends to become public — reported by other affected customers, covered by trade press, disclosed under contractual or regulatory obligation. A self-hosted incident affecting only your organisation has no equivalent external pressure forcing it into the open, which means the review question for a self-hosted deployment has to include not just “can we detect this” but “will this actually get escalated internally if it happens,” a question a shared vendor incident answers for you by making silence much harder to sustain.

The table below condenses the five categories side by side. Read it as a map of who owns which risk, not as a scorecard with a winning column — every row has two real answers, not a correct one and an incorrect one.

“Should we self-host” is not, on its own, a security question with a security answer. It becomes answerable once it is asked about a specific system, with a specific data sensitivity, against a specific team's actual operational maturity, weighed category by category against a specific vendor's actual practices — not against a generic sense of what “a major AI vendor” is presumed to do well.

Skip that comparison and the decision does not become neutral — it defaults to whichever option the engineering team already knows how to operate, which is a reasonable operational consideration but not a security judgment, and a review that lets it stand in for one has not actually reviewed the decision.