A model weight file can't call home! The case for Open-weight models.

Seven countries have restricted the DeepSeek app on government devices. Zero have restricted the DeepSeek model weights.

That's not an oversight. It's the whole point.

The bans - Italy, Australia, Taiwan, South Korea, the Netherlands, the Czech Republic, plus a growing list of US federal agencies - target one specific thing: a hosted consumer service that sends your prompts to servers in the People's Republic of China, where they're subject to Chinese cybersecurity and national-intelligence law.

The model weights are a different product. Legally, technically, and architecturally.

If your security team has flagged "Chinese AI models" as a category, this article is the breakdown they need. Because the category is wrong. The question isn't where a model comes from. It's where your data goes.

What a weight file actually is

An open-weight model is a set of numerical matrices - billions of floating-point parameters - published as static files, typically in the safetensors format.

Three properties matter for your security review:

It's data, not code. A safetensors file contains tensors and a JSON header. Nothing else. Unlike the older pickle format (which can execute arbitrary code on load, and which security researchers at JFrog caught doing exactly that on Hugging Face in 2024), safetensors was designed so that loading a model can't trigger code execution. This is why every serious inference stack standardized on it.

It can't make network calls. A matrix of numbers has no networking capability. The model doesn't "phone home" because there's no home to phone and no mechanism to phone with. Any network traffic in an inference deployment comes from the serving software around the model - software you or your provider chooses, runs, and can audit.

"The model doesn't 'phone home' because there's no home to phone and no mechanism to phone with."

It's downloaded once, then severed. The weights are pulled from a public registry one time. After that, the originating lab has no connection to the deployment. DeepSeek can't see who runs DeepSeek weights any more than the authors of PostgreSQL can see your database queries.

Model origin isn't data destination. The lab that trained the model and the infrastructure that runs it are two separate things, connected only by a one-time file download.

The legal footing

The licensing here is stronger than most of the proprietary software in your stack.

DeepSeek publishes its models under the MIT license. Zhipu's GLM models: MIT. These are the same terms as jQuery, Rails, and most of npm. No usage telemetry clause, no data-sharing clause, no revocation mechanism. Moonshot's Kimi and MiniMax's models ship under modified permissive licenses - free for self-hosting, with revenue-threshold clauses that only bite if you're reselling the model as a service at scale.

Compare that to a hosted frontier API, where your data flows are governed by a provider's terms of service that can change, and where your prompts transit infrastructure you don't control.

On the regulatory side, the analysis is clean:

GDPR. Chapter V (Articles 44-49) restricts transferring personal data outside the EEA without adequacy decisions or Standard Contractual Clauses. China has neither an adequacy decision nor a workable SCC path for state-access reasons.

That's precisely why the DeepSeek *app* triggered investigations from data protection authorities in France, Ireland, Germany, Belgium, and Portugal. But a transfer requires data to actually move. When inference runs on EU hardware - or your own - no cross-border transfer occurs, and Chapter V has nothing to attach to.

Perplexity demonstrated this in 2025 by serving DeepSeek R1 from US and EU infrastructure, sending zero bytes to China. Same weights, different data flow, different legal outcome.

EU AI Act. Fully applicable for most obligations since August 2, 2026, with GPAI model obligations live since August 2025. The Act regulates providers and deployers of AI systems in the EU market. Deployment obligations attach to whoever operates the system - which, for self-hosted open weights, is you, on your infrastructure, with full visibility. There's no hidden third-party processor to diligence.

Chinese national-intelligence law. Article 7 of China's National Intelligence Law can compel Chinese companies to cooperate with state intelligence work. This is the substantive concern behind the app bans, and it's legitimate.

It's also inapplicable to a static file on your GPU. The law compels *companies* operating *services*. It cannot compel a matrix of numbers sitting in a Frankfurt datacenter, because there's no Chinese company in the loop at inference time.

The incident that proves the distinction

In January 2025, Wiz Research found a publicly exposed ClickHouse database belonging to DeepSeek: over a million log lines, plaintext chat histories, API keys, backend metadata, no authentication required.

The worst security incident in the "Chinese AI" story is an argument for open weights, not against it.

Read that carefully. The exposure was chat histories from the hosted service. Users who ran DeepSeek weights on their own hardware had exactly zero records in that database, because their prompts never reached DeepSeek's infrastructure.

The worst security incident in the "Chinese AI" story is an argument for open weights, not against them.

Hosted services accumulate your data and can leak it. Self-run weights accumulate nothing.

The core argument is: the security risk is primarily about where inference happens and where data is stored, not where the model was trained.

How this maps to Kimchi

Kimchi runs open-weight models in two modes, and in both, the "does my data reach China" question has a structural answer, not a policy answer.

Serverless: models run on Kimchi-owned GPUs in France, Israel, and the US. Nothing is stored, no prompt is reused, and there's no third-party or model-provider infrastructure in the path. The network path from your prompt to DeepSeek, Zhipu, Moonshot, or MiniMax doesn't exist - not "isn't used", doesn't exist.

Self-Hosted: the same models deployed in your own Kubernetes cluster. Zero dependency on Kimchi infrastructure, zero trust extended to anyone - including us. If your compliance requirement is "processing happens in this country, on this hardware", this mode satisfies it by construction.

There's a third mode - BYOK - for when you want a frontier model from OpenAI, Anthropic, or Mistral. That's the one mode where data leaves, it goes directly to the provider under your key and their terms, and it's labeled as such. No ambiguity about which mode a workload runs in.

And across all three: we never train. Kimchi is infrastructure, not a model trainer. No prompt, no code snippet, no output is ever used to tune any model. That's not a promise buried in a ToS - it's what "pretrained models only" means architecturally. There's no training pipeline for your data to enter.

The checklist version

For the security reviewer who skimmed to the end, the claims and their basis:

• Your prompts can't reach Chinese companies on Serverless or Self-Hosted, because no network path exists between the runtime and the originating labs.
• Weights are static files with no code-execution or networking capability - a property of the safetensors format, not a vendor assurance.
• The licenses (MIT for DeepSeek and GLM) grant unconditional usage rights with no telemetry or data clauses. GDPR Chapter V isn't triggered because no cross-border transfer occurs.
• No training happens on your data, because no training happens at all.

The government bans on the DeepSeek app were correct. They targeted a data flow that actually existed. The same rigor, applied to open weights running on audited infrastructure, reaches the opposite conclusion.

If you need country-specific processing guarantees, Self-Hosted gives you that directly. Full details at kimchi.dev/security.

If you want to talk to us about your security concerns, reach out to us here.