Does using an open-weight model make my data private?

No. Whether a model's weights are publicly available is a licensing property and says nothing about where your data goes. An open-weight model served over a third party's public API sends your data to that third party exactly as a proprietary model would. Privacy is determined by the deployment, not by the licence.

Is self-hosting always the most private option?

It gives you the most control over where data goes, and it transfers the entire operational and security burden to you: patching, isolation, capacity, monitoring, and key management. A badly operated self-hosted deployment can be a worse privacy outcome than a well-contracted enterprise endpoint. Control and safety are not the same variable.

Hosted, Private Endpoint, or Self-Hosted

Q: Is country-based model routing a data-residency guarantee?

No, and describing it as one is how a compliance claim becomes untrue. Choosing a provider or a regional endpoint based on the user's country selects a provider. Residency is a contractual and infrastructural property that has to be established with the provider and evidenced. The two are frequently conflated in vendor material.

There are two questions about a model that get answered as if they were one, and the conflation is a security error rather than a wording slip.

The first is who made it and under what licence: open-weight or proprietary. The second is where it runs and who can see the traffic: a third party's public API, an endpoint under contractual and technical control, or infrastructure you operate. Those are independent. Every combination exists, and each has a different privacy answer.

Getting this wrong in either direction is common. "We use an open model, so the data stays private" is wrong. So is "it is a proprietary model, so it must be a black box in someone else's cloud".

The grid

Six cells, all of them real deployments somebody is running today.

Public API, open weights An open-weight model served over a third party's hosted API. The licence is permissive; your data still leaves your boundary and lands with that third party. Cheap and fast. Privacy posture is set entirely by that provider's terms.

Public API, proprietary The default arrangement most teams start with. Usually the strongest capability per unit of effort, and the weakest control over destination. Fine for public data, and a question that has to be asked for anything else.

Private endpoint, open weights An open-weight model on an endpoint bounded contractually and technically: a dedicated deployment in your cloud account, or a vendor endpoint with named infrastructure and terms. Often the practical answer for regulated work, because it buys control without the operational load of self-hosting.

Private endpoint, proprietary Same control properties, closed weights. Available from most major providers now. The thing to read carefully is what the contract actually says about retention, training rights, and where the compute physically sits.

Self-hosted, open weights You run the weights on infrastructure you control. Maximum control over destination, and the entire operational burden: patching, isolation, capacity, monitoring, key management. The right answer for a narrow class of restricted data, and over-applied elsewhere.

Self-hosted, proprietary Rarer, and licence-dependent. Exists where a vendor licenses a closed model for private deployment. Worth knowing the cell is occupied, because its existence is what disproves "closed means someone else's cloud".

Three claims to stop making

"Open source means private"

A licence describes what you may do with the weights. It describes nothing about the network path your data takes. An open-weight model behind a public API sends your data to that API's operator exactly as a proprietary model would, and the operator's terms govern it identically.

This one matters practically because it is often used to skip a data-classification conversation. If you find an "it's open source" sitting where a destination approval should be, that is the finding.

"We route by country, so we have data residency"

This is the one we see most often in vendor material and it is the most consequential, because it converts an architectural choice into a compliance claim that will not survive scrutiny.

Selecting a provider or a regional endpoint based on a user's country selects a provider. Residency is a contractual and infrastructural property: it has to be established with the provider, evidenced, and typically written into an agreement. Country-based routing is a reasonable input to that design. It is not the guarantee, and describing it as one means your compliance register now contains something untrue.

Related: a provider available in one country is not necessarily available, lawful, or appropriate in another, and that is a question with a jurisdictional answer rather than a technical one.

"Self-hosted is the safe option"

Self-hosting maximizes control over destination. It does not maximize safety, because it moves the entire security and operational burden onto you: an unpatched, poorly isolated, badly-monitored self-hosted deployment is a worse outcome than a well-contracted enterprise endpoint.

Control and safety are different variables, and the honest question is which one your constraint is actually about. A lot of self-hosting decisions are made for a residency requirement that a private endpoint would have satisfied at a fraction of the running cost.

How to choose, in order

The order matters more than the options, because the common failure is choosing a deployment and then reverse-engineering a justification.

Classify the data first. Public, internal, personal, sensitive, or restricted to named infrastructure or a jurisdiction. Nothing else can be decided before this.
Derive the admissible cells. For each class, which of the six cells above are permitted. This is a policy artifact, written once, not a judgement made per feature.
Apply jurisdiction. Residency requirements, applicable law, and provider availability by country. This narrows the set further and it is where counsel belongs.
Then consider capability, latency, and cost. Last, deliberately. These are the axes with the loudest advocates and they must not reorder the three above.

The discipline worth adopting: "it produces better results" is never a reason to send data somewhere it is not approved to go. When no authorized option can serve a request, failing the request is the correct outcome. That sentence is easy to agree with in a design review and hard to hold under delivery pressure, which is why it belongs in the architecture rather than in a policy document.

Why we can argue this specifically

Because we built two of the cells rather than reasoning about them. The platform this company builds runs the same open-weight model family in two places behind one interface: a self-hosted local deployment, and an enterprise-hosted endpoint on a major cloud with real per-token billing. Same weights, same family, entirely different privacy and cost properties, reachable through the same provider-neutral seam.

Having both wired is what makes the point on this page concrete. The licence did not change between them. Everything that matters for a data-classification decision did.

We are also clear about the limit of that: having the deployment options available is not the same as having a policy layer that steers a given data class to the right one automatically. That routing policy is a design target in our own system rather than a shipped component, and the difference between resolution and policy is worth understanding before believing any vendor's version of it.

Hosted, private endpoint, or self-hosted