Open-Weight vs Closed Models: Risk for Regulated Teams

"Open or closed?" is usually argued as a question about capability, cost or ideology. For a regulated team it is better framed as a question about where risk lives and who holds it. Each choice moves risk between you and a vendor. Neither removes it. This post sets out the dimensions that matter when you sit under financial, health, public-sector or similar scrutiny, says honestly where closed models are the better answer, and ends with the pattern most regulated teams converge on.

A terminology note. "Open-weight" means the trained parameters are published and you can run them yourself. It does not necessarily mean open source in the strict sense: training data and pipelines are generally not released, and licences range from permissive (Apache 2.0, MIT) to custom. "Closed" means you reach the model only through a provider's API.

1. Data exposure

With a closed model, prompts and context go to the provider. That can be acceptable under contract, with zero-retention terms, regional endpoints and a data processing agreement, but it is a transfer of data to another party and you depend on its terms and its operations. With an open-weight model on infrastructure you control, inference is a process you run: no lab-side API is in the loop at all. For data you are not allowed or not willing to send out, that is the decisive difference. It is also a smaller claim than it sounds. It removes the lab from the path; it does not remove your cloud operator, your own staff access or your logging.

2. Change risk and reproducibility

A hosted model is a moving target. Providers retire versions, re-point aliases and change behavior, and a model ID is not a stable contract unless you treat it as one. We described a concrete case in our DeepSeek V4.1 Flash self-hosting guide: old names can be routed to new models on short notice, so production traffic that follows a name inherits a vendor's product decision. For a regulated process that must be explained and re-run, this matters. With weights on disk you can pin an exact revision, re-run it next year and show an auditor the same artifact. You also take on the work of updating on your own schedule.

3. Safety behavior

This one cuts both ways, and people tend to argue only one side.

• Closed providers invest heavily in safety training and often add lab-side moderation and monitoring. That is real. It is also opaque: you cannot inspect it, and it can change without notice.
• Open-weight models can be fine-tuned, which means they can be adapted to your policies, and also that safeguards can be removed or eroded, by an attacker or by an innocent fine-tune. Research (Qi et al., 2023) showed an aligned model could be jailbroken by fine-tuning on as few as 10 adversarial examples, and that benign fine-tuning degraded safety to a lesser extent.
• With open weights the responsibility for evaluating safety moves to you. That is a cost, and also a control: you can test refusal, over-refusal, jailbreak and injection resilience on your own cases, in your own languages, and re-test after every change. See our evaluation checklist and red-teaming checklist.

4. Licence risk

Closed models have terms of service. Open-weight models have licences, and they vary: Apache 2.0 for Qwen's open-weight releases, Gemma 4 and most recent Mistral releases; MIT for recent DeepSeek releases such as R1; modified MIT with a scale-triggered attribution clause for Kimi K2; and a custom community licence for Llama. The Llama 4 acceptable use policy states that rights for its multimodal models are not granted to individuals domiciled in the EU or companies headquartered there, with carve-outs Meta's FAQ describes for end users and non-EU distributors. An EU regulated team cannot treat "open" as "usable". Read the file for the exact checkpoint and keep the date you read it. Not legal advice.

5. Supply-chain risk

Closed models have a smaller artifact supply chain on your side: you consume an API. Open weights add a new one: files from a public hub, loaders, engines and containers. Pickle-based checkpoints can run code on load; remote-code flags execute repository code; scanners have been bypassed. The controls are well known: pin the full commit hash, use safetensors, keep remote code off, hash and (where available) verify signatures, scan what you must, and pin images by digest. OWASP lists supply chain as the third risk in its 2025 Top 10 for LLM Applications. Details in model supply-chain security.

6. Jurisdiction and sovereignty

A closed model run by a provider headquartered outside the EU may be subject to non-EU legal demands even when it is served from an EU region; take legal advice on what that means for you. Self-hosting on EU infrastructure under an EU operator narrows that exposure but does not erase it: the cloud operator and its jurisdiction still matter. Sovereignty is control over data, infrastructure, models, operations, governance and supply chain together, not a map pin. See deploying an LLM in the EU.

7. Regulation and evidence

The EU AI Act's obligations for general-purpose AI model providers apply from 2 August 2025. Providers of models under free and open-source licences get a partial exemption from some documentation duties, but not if the model presents systemic risk (presumed above 10^25 FLOPs of training compute), and not from the copyright-policy duty. If you substantially modify a model, the Commission's guidelines give an indicative test for becoming a provider yourself: compute for the modification above one third of the original training compute. Whether your system is high-risk depends on its use. In both worlds you need evidence: what ran, which version, how it was tested, who approved it. With open weights you can produce that evidence yourself; with a closed model you depend on what the provider documents.

This is outline, not advice, and no model choice settles a system's regulatory position on its own. The exact posture depends on use case, jurisdiction, deployment and configuration.

8. Capability and cost

Be honest here. Frontier closed models often lead on the hardest general-reasoning work, and open-weight models are strong and improving, with some leading specific tasks such as agentic coding. Hosted APIs are usually cheaper than self-hosting at low or spiky volume; self-hosting pays when volume is high and steady, when prompts cannot leave your perimeter, or when you need to fine-tune. Our self-hosted inference guide gives a method for the comparison with your own numbers.

The comparison at a glance

What regulated teams usually do: both, behind one gateway

The practical pattern is hybrid. Route sensitive, high-volume or latency-critical work to a private open-weight model on infrastructure you control. Keep frontier closed models for the hard slice where data classification allows. Put one gateway in front so that approved-model policy, logging, cost tracking and failover are identical across both, and so you can move a workload without rewriting the agents that depend on it. That is the role of Connect in Swfte's platform, with Nexus giving the agents identity, permissions and an audit trail, and the same evaluation gate applying to whatever you promote.

Decide per workload, using data classification, not per company. A model that is fine for summarizing public filings may not be fine for customer records. For the open-weight half, start with the deploy models hub, and read our broader view in AI governance.

Swfte does not hold a SOC 2 report or an ISO 27001 certificate and does not sign HIPAA BAAs today (a SOC 2 Type I audit is in preparation; see the trust page). Your own regulatory position depends on your use case, jurisdiction and configuration.

Further reading: Custom Domain Models vs Frontier APIs for Regulated Teams.