Do Chinese AI models steal your data? A threat model, not a vibe

In most enterprise AI meetings this year, someone has said a version of the same sentence: “We can’t use the Chinese models — they steal your data.”

Sometimes the room nods and moves on. Sometimes an engineer points out that the weights are just a file and asks how a file steals anything. Both people are partly right, and the policy that comes out of that meeting is usually wrong in one of two directions. Either it is too loose — someone pastes customer contracts into a hosted chatbot — or it is too strict, banning a local model that could not send a byte anywhere while allowing a “Western” model that was fine-tuned from the same Chinese base.

The way out is to stop treating “Chinese model” as one risk. It is at least five, and they have different answers.

Why this is a live question at all

It would be easy to ignore if the models were not good. They are. Chinese labs — DeepSeek, Alibaba’s Qwen team, Moonshot (Kimi) and Z.ai (GLM) — now ship several of the strongest open-weight model families, usually under permissive licences and at very low prices. Engineers reach for them for the same reasons they reach for any good free tool, and a blanket ban that nobody understands tends to get quietly ignored.

The five risks, separated

1. The hosted app or API — the risk is real

When you type into a chatbot or call an API, your prompt, the files you attach and the model’s answer go to the provider’s servers. What happens next is decided by the provider’s privacy policy and by the law where those servers sit.

For DeepSeek’s consumer service, the privacy policy states that the information it collects is stored on servers in the People’s Republic of China. That information includes what you type and upload. PRC law also obliges organisations to cooperate with state intelligence work when asked, so a contractual promise from the provider cannot fully answer the question of who else may access the data.

Regulators acted on exactly this. In early 2025 Italy’s data protection authority ordered DeepSeek’s app blocked after finding the company’s answers about data collection and storage insufficient. Australia directed all federal government entities to remove DeepSeek products from government devices, Taiwan barred government departments from using it, and several US federal agencies and states restricted it on government devices.

2. The weights file — it cannot phone home

This is where the conversation usually goes wrong in the other direction.

An open-weight model in the modern safetensors format is a header describing tensor names and shapes, followed by raw numbers. Loading it means reading those numbers into memory. Running it means multiplying your input by them, inside an inference engine you chose — vLLM, llama.cpp, Ollama, TensorRT-LLM — written by someone else entirely.

A matrix has no way to open a socket. Whatever a model “wants”, it can only produce tokens; whether those tokens ever leave your machine is decided by your code. So local inference on a safetensors checkpoint with a trusted engine cannot exfiltrate data by itself, regardless of who trained the weights.

You do not have to take that on trust. Prove it:

# Run the model with no network interface at all.
docker run --rm --network none --gpus all \
  -v /models/my-model:/model:ro \
  my-inference-image serve /model

With --network none the container has only a loopback interface. If the model serves correctly, it did not need the network — and it could not have used one. Pair this with egress-deny rules on the production hosts and the “phone home” question is closed mechanically, not by argument.

3. The loading code — a real risk from any vendor

The weights cannot run code. The files around them sometimes can, and this is the attack surface worth worrying about:

• Pickle checkpoints. Older PyTorch formats (.bin, .pt, .pth) use Python’s pickle, which can execute arbitrary code on load. A malicious checkpoint runs its payload the moment you call torch.load, before any inference happens.
• trust_remote_code=True. Some model repositories ship their own Python modelling code. Passing this flag to Hugging Face transformers downloads that Python and executes it in your process, with your credentials and your network access.
• Unpinned revisions. Pulling main means the next download may contain different files from the ones you reviewed.

None of this is specific to China. It is ordinary software supply-chain risk, and the controls are the same for every model:

1. Load safetensors only. Refuse pickle formats outright.
2. Never pass trust_remote_code=True in production. Use architectures your inference engine supports natively, or vendor and review the code yourself.
3. Pin by commit hash, mirror the files into an internal registry, and verify checksums.
4. Run inference with no egress, as above, so even a compromised loader has nowhere to send anything.

The lesson on model and artifact supply-chain security goes deeper on each of these, including signatures and admission checks.

4. Model behaviour — real, but it depends on the job

A model you run locally can still behave in ways you do not want. This is the part of the worry that inspection cannot settle, and it is where the evidence is most specific.

The US Center for AI Standards and Innovation (CAISI, part of NIST) evaluated DeepSeek’s models in September 2025. Two findings matter for deployment decisions:

• Weaker safeguards. DeepSeek’s most secure model at the time, R1-0528, complied with 94% of overtly malicious requests that used common jailbreak techniques, compared with 8% for the US reference models.
• Political alignment. On questions sensitive to the Chinese Communist Party, DeepSeek models echoed inaccurate and misleading CCP narratives about four times as often as the US reference models.

CAISI’s later evaluation of DeepSeek V4 Pro, in 2026, focused on capability and estimated it at roughly eight months behind the US frontier. Those numbers come from a US government body with a stated national-security framing, which is worth knowing; they are also specific and testable, which is what you want from evidence.

Then there is the risk nobody can measure away: backdoors. Anthropic’s 2024 “Sleeper Agents” research showed that a model can be trained to behave normally until it sees a trigger, and that standard safety training did not reliably remove that behaviour. That is a property of training, not of nationality — but it means you cannot inspect any model’s weights and certify it clean.

What makes these risks manageable is that their impact depends entirely on what the model is allowed to do:

Use	Jailbreakability	Political slant	Hidden trigger
OCR or extraction on internal documents, output reviewed	Low impact	Very low impact	Low — output is checked
Internal coding assistant	Medium	Low	Medium — code is reviewed, but review is fallible
Public chatbot	High — users will try	High — reputational	Medium
Agent with tools, credentials and network	High	Medium	High — the model can act

The bottom row is where caution belongs. An agent that can call tools can turn tokens into actions — sending email, calling APIs, writing to storage — so the “weights cannot exfiltrate” argument from section 2 no longer holds once you give the model a way out. The control is least privilege: permission ladders, allow-listed destinations, and guardrails as runtime checks — which you need for every model, but which a model with weaker refusals needs more.

5. Procurement and contracts — binding regardless

Finally, the reason a ban sometimes has to stand even when the engineering says the risk is controlled: you may have promised someone. Government customers, defence contractors, banks and healthcare clients increasingly put model-origin clauses in contracts and questionnaires. Some public-sector rules restrict specific vendors outright.

That is a legitimate constraint. It is a legal and commercial decision, and it should be recorded as one — “we do not use these models because contract X forbids it” — rather than dressed up as a technical claim that the weights steal data. Being precise here also tells you when the constraint does not apply, which is most internal tooling.

The lineage problem: “Western” models with Chinese bases

Here is the complication that makes a nationality ban leakier than it looks. A lot of open models are fine-tunes, and the base is often Chinese because the Chinese bases are good and permissively licensed.

A concrete example: Ai2’s olmOCR 2 — published by a US non-profit under Apache 2.0 and one of the best open OCR models available — is a fine-tune of Alibaba’s Qwen2.5-VL-7B. Many community models, distilled reasoning models and domain fine-tunes have the same shape.

If your policy is about behaviour (section 4), lineage matters, because a fine-tune inherits most of its base model’s dispositions. If your policy is about data leaving your network (sections 1 and 2), lineage does not matter at all — only where inference runs does.

So record it. The base_model field on a Hugging Face model card, or the equivalent in your internal registry, makes the lineage auditable, and an approval process should ask for it.

The non-Chinese open-weight options

If a policy or contract does rule out Chinese-origin models, the alternatives are far stronger than they were two years ago:

Family	From	Licence	Notes
gpt-oss (20b, 120b)	OpenAI	Apache 2.0	Released August 2025; mixture-of-experts reasoning models, the 120b fits a single 80 GB GPU
Gemma	Google	Apache 2.0 from Gemma 4	Earlier generations used Google’s own Gemma terms
Mistral 3 family	Mistral AI (France)	Apache 2.0	Sizes from small on-device to a large frontier-class model
Granite 4.x	IBM	Apache 2.0	Hybrid Mamba/transformer, aimed at enterprise; ISO 42001-certified management
Llama	Meta	Llama community licence	Not an OSI licence; has an acceptable-use policy and a large-company clause
OLMo	Ai2	Apache 2.0	Fully open: weights, training data and code
Nemotron	NVIDIA	NVIDIA open model licence	Strong at reasoning and agentic tasks

A policy you can actually write down

Put together, a defensible policy fits on one page:

1. Hosted services: allowed only for providers whose data residency, retention and training-use terms legal has approved. This excludes PRC-hosted services for any company data.
2. Local weights: allowed from any origin for approved uses, only through the hardened path — safetensors, no remote code, pinned hashes, internal mirror, no network egress.
3. Tool-using agents and public-facing products: require a red-team evaluation of the exact model version against your own jailbreak and policy tests, and least-privilege tools, whatever the model’s origin.
4. Lineage: every approved model records its base model and licence in the registry.
5. Contractual constraints: where a customer contract or regulation forbids an origin, it is listed by name with the clause it comes from.

That policy is stricter than “ban the Chinese models” where it matters — hosted data and agents with tools — and looser where the risk is not real. It also survives contact with the next model release, because it is written around how a model is used rather than whose model it is.

What to take away

• “Chinese models steal data” bundles five risks. Answer each one separately.
• Hosted apps and APIs: the data-residency worry is valid. Block them for company data.
• Local safetensors weights cannot open a network connection. Prove it with --network none.
• The real local risk is loader code — pickle and trust_remote_code — and it applies to every vendor.
• Behavioural risks are documented and depend on what the model can do. Agents with tools need the most caution.
• Record lineage. Many “Western” models are fine-tunes of Chinese bases.

For choosing between open-weight models on licence, lineage and residency, see choosing open-weight models. For running them well once you have decided to, see the lessons on self-hosting LLMs and GGUF and local models.