Inteldefense
The DeepSeek Ban Is About Jurisdiction, Not Quality
The Navy memo did not say the model was bad. It said where the data goes. That distinction decides how you write the control, and who has to prove it.
In January 2025 the Navy told its people not to use DeepSeek. Not for work, not for personal use, not in any capacity. The stated reason was "potential security and ethical concerns" tied to the model's origin and usage.
That wording is doing more work than it looks like. The Navy did not say the model was inaccurate, or slow, or unsafe in the sense a benchmark measures. It said the origin was the problem.
Reporting at the time (opens in a new tab) also found that Pentagon staff had been using the chatbot for at least two days before DISA blocked it on the department's networks. That is the part worth sitting with. The block came after the exposure, not before it.
The memo was about where the data goes
Every hosted model is a data flow. You type a question, the question leaves your network, and something happens to it on somebody else's computer. For most tools, that flow is governed by a contract and a jurisdiction.
With a service hosted in China, the jurisdiction is Chinese. DeepSeek's own terms place the data under the laws of the People's Republic of China. That is not an accusation about the company's intentions. It is a statement about which government can compel it.
China's National Intelligence Law, in force since 2017, obliges organizations and citizens to support and cooperate with national intelligence work. Read that together with a service that stores data in the country and you get the conclusion the Navy reached: the tool cannot be used for anything you would not hand to a foreign government.
The model's quality is irrelevant to that finding. A perfect model hosted in the wrong jurisdiction fails the same test.
What this means for a contractor
If you hold a contract with CUI on it, the question is not whether DeepSeek is good. It is whether the tool creates a data flow you cannot describe in your system security plan. A public chatbot with a Chinese data store cannot be described in a way that survives the review.
The mistake is treating this as a banned-vendor list. It is a data-flow question, and the list will keep changing while the question stays fixed.
That matters because the enforcement mechanism is not a press release. It is a clause. The CMMC rule that took effect in November 2025 lets a contracting officer put a cybersecurity requirement in a solicitation and decline to award without it, with the third-party assessment requirement phasing in over the following three years. A tool that moves CUI to a foreign jurisdiction is a control failure under that framework whether or not anyone names the tool.
Allow-lists, not deny-lists
Blocking a domain is easy and insufficient. The useful artifact is a positive inventory: the models your organization has approved, where each one runs, who approved it, and what data class it is allowed to touch.
An allow-list has properties a deny-list cannot have. It has an owner. It has a review date. It can be tested, because you can compare what is installed against what is approved and get a number. A deny-list can only be tested by trying every name you did not think of.
The inventory is also the only thing that answers the derivative question. DeepSeek published open weights, and the open-weight ecosystem produces fine-tunes and distillations under new names. You will not enumerate them. You do not have to. If the rule is "only models on the approved list may run in this environment," the derivative problem disappears into the intake process, where it belongs.
Two mechanics make the list usable. Record the model's provenance (who trained it, where it runs, which license) as a field, not a footnote. And pin versions, because a model that updates itself is a configuration item nobody assessed.
Where contractors actually get caught
The failure I would expect is not a deliberate violation. It is a browser tab.
An engineer pastes a log excerpt into a free chatbot to get a second opinion. No procurement, no approval, no data handling review. The data leaves, and nothing in the environment records that it did. Multiply that by every employee with a laptop and you have the reason agency-level bans keep arriving after the fact.
Three controls address it, in order of value.
Network egress that you can query. If you cannot list the AI endpoints your network talked to last month, you cannot answer the question an assessor will ask.
An approved-tools page a person can find. Most shadow use is convenience. A sanctioned path that works removes the excuse.
Training that names the consequence. Not "AI awareness." The specific rule: CUI does not go into a tool that is not on the list, and here is the list.
For primes, add flowdown. A subcontractor at any tier can create the exposure, and the prime is the one answering for it. That means the requirement has to appear in the subcontract with enough specificity to be auditable, and somebody has to sample evidence rather than take an attestation. The clause language is the easy part. The evidence trail is the work.
The policy contradiction is above your pay grade
The export policy question, whether compute hardware should move to China while Chinese models are blocked here, is a real tension and it is not yours to resolve. Reasonable people in the department disagree about it.
What is yours is narrower and harder to argue with. You have to be able to say which models run in your environment, where the data goes, and who approved it. That answer does not change when the model of the week changes.
A ban names a company. A control names a data flow. Build the second one, because the first will be out of date before your next assessment.
Reread the Navy memo with that in mind. The finding was never about the chatbot. It was about the boundary, and the boundary was breached for two days before anyone noticed.