A model file can’t send your data anywhere. A service can. Choosing the model and controlling the risk are two separate decisions, and the second one is made in your architecture.
When people hear “DeepSeek,” they usually picture one thing: a Chinese chatbot that sends what you type to servers in China. That picture is accurate for one way of using DeepSeek. It’s wrong for another, and the difference is the most important security decision an organization makes about AI.
There are three ways to use a model like DeepSeek-V4, Qwen3.8, Gemma 4 or gpt-oss:
- Use the developer’s own app or API. Your prompts and files travel to the developer’s servers, under the developer’s terms and its country’s laws.
- Use someone else’s hosted copy. A U.S. cloud provider runs the same published model on its own servers. Your data goes to that provider, under its terms and U.S. law.
- Run the published weights yourself. You download the model file and run it on hardware you control. Nothing goes anywhere unless your own systems send it.
These are three different risk profiles. Policy debates and procurement checklists often treat them as one, under the developer’s name. This paper explains the difference, what can and can’t go wrong in each, and how architecture choices let an organization pick the best model for the job and keep control of its data.
What a model file is
An open-weight model is published as files of numbers: the “weights”, billions of them, stored in a format such as safetensors. A weights file is data, not a program. It can’t open a network connection, read your disk, or run on its own. It does something only when separate software, the inference server, loads it and does arithmetic with it.
So the question “can a downloaded DeepSeek model leak my data?” has a precise answer. The weights by themselves cannot. Data can only leave through a channel, and every channel belongs to the deployment, not to the model:
| Channel | How data could leave | Control |
|---|---|---|
| Network access | The machine running the model can reach the internet | Run with no outbound network, or an allow-list |
| Loader and server code | Some model repositories ship custom Python that runs at load time, or use older file formats that can execute code | Use safetensors only; don’t enable remote code; use a vetted, pinned inference server |
| Tools and agents | A model given web, email or API tools can be talked into sending data through them | Grant only the tools a task needs; no outbound tools on sensitive data |
| Outputs that get run | Generated code or commands, executed on a connected machine, could do anything code can do | Review and test generated code before it runs anywhere connected; sandbox execution |
| People | Someone copies output somewhere it shouldn’t go | Ordinary data-handling policy |
Every one of these channels exists for every model, whoever made it. A U.S.-made open-weight model on a networked machine with web tools has the same channels as a Chinese-made one. Close them, and neither can leak. Trust doesn’t disappear, but it moves from the model’s developer to software you choose, pin and can inspect.
That is the core point: once those channels are closed, a self-hosted open-weight model carries no data-leakage risk that depends on where it was made. The risk lives in the architecture around it, which is entirely in the operator’s hands.
What a hosted API is
A hosted API is the opposite case. Sending a prompt to an API is sending your data to someone else. That holds whether the API belongs to DeepSeek, OpenAI, Anthropic or Google. What differs between providers is not whether your data leaves, but where it goes and what governs it:
- Jurisdiction: which government can compel the provider to hand data over.
- Retention: how long prompts and outputs are kept, and whether they are used for training.
- Contract: whether you have enterprise terms, data-processing agreements, or zero-retention options.
- Visibility: whether you can see or verify any of this, or must take it on trust.
These are legitimate reasons to prefer one API provider over another. A provider subject to Chinese national-security law is a different proposition from one under U.S. law and a negotiated enterprise contract. But even the best API is still a decision to send data off your premises. For data that must not leave, an API run by someone else on their infrastructure is not the right answer, whoever runs it.
The DeepSeek order’s evidence is about the service, not the weights
On July 24, 2026, the Department of Homeland Security ordered federal civilian agencies to exclude and remove DeepSeek products.1 Its stated risks are about data leaving: DeepSeek’s servers are in China, Chinese law gives the state broad access to company infrastructure, and “for DeepSeek-hosted instances of their models”, account creation collects personal information and may fingerprint users. Its one concrete piece of security evidence is a 2025 report of vulnerabilities in DeepSeek’s iPhone app.
Every one of those risks belongs to the first deployment mode: the developer’s own app and servers. None describes a model file running on an agency’s own isolated hardware. Yet the order’s scope also covers “third-party products and services developed using DeepSeek implementations”, which can include self-hosted copies. Whatever one thinks of the policy, its evidence supports restricting DeepSeek’s service. It says nothing specific about DeepSeek’s weights running in isolation.
The order also says “the models themselves may contain malware or other security vulnerabilities.” That is a fair caution about any software, and it leads to the second kind of risk.
The risk that doesn’t go away: what the model says
Containment answers “can my data leave?” It does not answer “can I trust what the model produces?” Those are different risks, and the second applies to every model, open or closed, whatever its origin:
- Wrong or insecure output. Models write vulnerable code, invent facts and follow bad instructions. Rates vary widely between models and with how a request is phrased.
- Built-in behavior. A model can carry its developer’s choices: refusals, political framing, or, in principle, behavior triggered by particular inputs.
- Hidden triggers. Research has shown that a backdoor can be planted in a way that inspecting the model cannot reliably find. The practical defense is not finding it but bounding what it could do: a model with no outbound channel and no unreviewed execution cannot turn a hidden trigger into a data breach.
Open weights are the better position for managing this risk, not the worse one. With the weights in hand, an organization or an independent lab can test the model’s behavior offline as much as it likes, compare it against the model it claims to derive from, and check its architecture against its documentation. None of that is possible against a closed API, where the model can change between one request and the next without notice.
Our own testing shows why this has to be measured, not assumed. In a pre-registered test of a widely cited claim that Chinese coding models write weaker code for U.S. customers (56,160 responses from four Chinese models and two U.S. models), we found that naming the U.S. government never made code less secure in the models and tasks we tested. How the request was framed changed every model’s security output, by 6 to 72 points depending on the model, U.S. models included. (Full results: The Prompt, Not the Passport.) Output quality is a per-model, per-configuration property. It has to be tested, and it can be, when you have the weights.
Choosing the model and controlling the risk are separate decisions
The practical upshot is that two questions usually asked together should be answered separately:
- Which model does the job best? Pick on measured capability, cost, hardware fit and tested behavior on your own tasks, including code security, refusals and bias where they matter.
- How do I contain whatever risk remains? Answer with architecture:
| Layer | Control | What it removes |
|---|---|---|
| Custody | Self-host the weights on hardware you control | Third-party data custody and jurisdiction |
| Network | No outbound network from the inference host (or a strict allow-list) | Any path for data to leave through the model’s host |
| Software | Safetensors only, no remote code, pinned and vetted serving software | Code execution at load time |
| Tools | Least-privilege tools; no outbound tools on sensitive data | Data leaving through agent actions |
| Output | Review, static analysis and sandboxed testing of generated code | Insecure or malicious output reaching production |
| Audit | Logging of prompts and outputs inside the boundary | Undetected misuse; supports audit |
| Verification | Independent behavioral testing before deployment and after updates | Unverified claims; silent behavior change |
With these controls, the data-leak risk of a model is set by the architecture, the same for any model, and the remaining risk is about output quality, which you measure. Without them, even a model from the most trusted developer is only as safe as the network it can reach.
What this means for policy
Restrictions based on a model’s origin are easy to write and easy to check, and for a developer’s own hosted service they address a real risk: where your data goes and who can compel access to it. But applied to model weights, an origin ban answers a question that architecture has already answered, and leaves the question that matters, whether the output can be trusted, untested.
A better rule would follow the deployment, not the developer:
- Hosted services (any developer’s API or app): judge by jurisdiction, retention and contract, as for any cloud service.
- Self-hosted weights: require the containment controls above, and independent behavioral testing for the intended use, whoever made the model.
That approach treats U.S. and foreign models alike, rewards the deployment pattern that actually protects data, and lets organizations use the best tool for the job.
The bottom line: audit the deployment, not just the developer.
Limits of this argument
- Supply chain of the software around the model. Inference servers, drivers and libraries are ordinary software with ordinary vulnerabilities. Containment depends on getting them right.
- Isolation has costs. Air-gapped or egress-blocked deployments need local hardware and operational discipline. Not every organization can run a large model on its own hardware.
- Behavior can’t be fully certified. Testing reduces uncertainty about a model’s outputs, but it cannot prove the absence of every hidden behavior. That residual is why containment matters.
- Other reasons for origin rules exist. Economic policy, export controls and dependence on foreign suppliers are outside the scope of this paper.
1 Exclusion and Removal Order #2026-01, issued under the Federal Acquisition Supply Chain Security Act of 2018; published in the Federal Register on October 20, 2026, document 2026-21447. Defense and intelligence agencies issued their own orders. Back to text
ModelDNA builds tools that inspect open-weight models and test their behavior. That is a commercial interest in the argument made here, and readers should weigh it accordingly.