Congress is asking American companies to explain their use of Chinese AI models. The House Homeland Security Committee and the Select Committee on the Chinese Communist Party opened a joint probe in April 2026, sending letters to Cursor and Airbnb. By July, DoorDash had received a similar inquiry. The State Department issued a formal warning on July 8. Treasury Secretary Scott Bessent announced on July 21 that the administration is examining Chinese open-source models for intellectual property theft, and that sanctions and Entity List designations are on the table. That same week, reports emerged that the Trump administration was considering a broader ban on Chinese open-weight models entirely.

None of this has resulted in a legal prohibition on private companies using Chinese AI models. But the regulatory environment is moving fast enough that teams depending on Chinese AI infrastructure need a clear-eyed view of what the actual risks are, what a ban could and couldn’t accomplish, and what the meaningful distinction is between different deployment configurations.

The most important distinction in this conversation is one that most coverage has not made clearly: it matters enormously whether you are calling a Chinese lab’s API or running downloaded weights on your own infrastructure. These are not the same risk profile, and they are not the same regulatory exposure. In this article, we’ll draw a distinction between them.

What Washington Is Actually Doing

It helps to be specific about what has happened and what has not, because the headlines have a tendency to blur the two.

What has happened: federal agencies including the Navy, Army, NASA, and multiple intelligence community components have banned the use of Chinese AI models internally. The House committees have launched a formal probe and are sending information requests to private companies. The State Department has issued a guidance memo. Treasury has signaled that sanctions are being considered for labs that can be shown to have trained on stolen IP. Anthropic filed a complaint accusing Alibaba’s Qwen of conducting large-scale distillation of its Claude models through roughly 25,000 fraudulent accounts.

What has not happened: there is no federal law or executive order prohibiting private US companies from using Chinese AI models. Adoption by companies like Coinbase, Uber, Cursor, and Airbnb is legal. The investigation is an information-gathering exercise at this stage, not an enforcement action. No company has been fined, sanctioned, or ordered to stop using Chinese models as a result of the probe.

The most viable regulatory instrument being discussed is federal procurement restrictions — essentially preventing government contractors from using Chinese AI in work performed for the government. That is a meaningful constraint for defence and intelligence adjacent businesses, but it is a targeted one. The broader question of whether private commercial companies can use Chinese models is a different matter, and most legal experts consulted in press coverage have been sceptical that an outright ban could stick.

On enforceability: Kyle Chan of the Brookings Institution put it plainly in July: “It’s ultimately impossible to ban China’s open-source AI models because their model weights are available freely on the internet.” Legal experts have raised First Amendment concerns about restricting access to already-published model weights, citing precedent from encryption software export cases in the 1990s where courts found that computer code is a form of protected speech. The Bernstein v. DOJ and Junger v. Daley cases established that restriction of published technical information is constitutionally fraught. A company that has already downloaded GLM-5.2, DeepSeek V4 Pro, or Kimi K3 (all available on DeepInfra) to its own servers is beyond the reach of any import restriction on that specific download.

The Deployment Model Matters More Than the Model Origin

Washington’s regulatory instinct is to treat “using a Chinese AI model” as a single category of risk. It is not. The risk profile changes significantly depending on how the model is deployed, and most of the legitimate concerns are concentrated in one configuration: the live API.

Deployment model	Data exposure risk	Regulatory exposure	Ban enforceability
Live API (Chinese provider)	High — data transits to Chinese infrastructure	High — OFAC/Entity List sanctions could cut access overnight	Full — provider controls the switch
Hosted API via neutral provider (e.g. DeepInfra)	Low — data stays on US/EU infrastructure	Medium — depends on whether sanctions target weights or access	Partial — provider dependency remains
Downloaded weights, self-hosted	None — model runs on your own hardware	Low — a downloaded file cannot be un-downloaded; future use may be restricted	Effectively none for existing downloads

When you call Kimi’s API, or Moonshot’s hosted endpoint directly, your prompt transits to infrastructure operated by a Chinese company. The terms of service, data retention policies, and legal jurisdiction over that data are governed by Chinese law. The company can modify the model’s behaviour server-side without notice. And if that company ends up on the OFAC sanctions list or the Commerce Department’s Entity List, your access disappears, your API key stops working, and any production system built on that dependency breaks immediately.

The downloaded weights scenario is structurally different. Once you have pulled DeepSeek V4 Pro or Kimi K3 onto your own servers and you are running inference locally, none of those concerns apply in the same way. Your data does not leave your infrastructure. The model cannot be modified remotely. The Chinese lab cannot revoke your access. And as Kyle Chan’s observation implies, the government cannot meaningfully prevent you from continuing to run a model you have already downloaded. Future new versions might become restricted, but the copy on your servers is yours.

Serving Chinese open-weight models through a US-based inference provider occupies the middle ground. When you route Kimi K3 or DeepSeek V4 Pro through DeepInfra, your data hits US infrastructure and stays there. You are not sending prompts to Moonshot or DeepSeek. The regulatory and data sovereignty risk of the live API is largely absent. The residual risk is that if the underlying model weights were eventually designated as restricted, the inference provider might need to stop serving them but you would have advance notice and the option to self-host.

What the Providers Can Do With Your Data

Choosing a deployment model is only half the picture. The other half is understanding what the specific provider handling your request is permitted to do with your data once it arrives. Provider policies vary significantly and the gap between the most and least restrictive options is the difference between a contractually enforceable no-retention guarantee and a Chinese data jurisdiction with no equivalent constraints on reuse or government access.

OpenRouter, which routes DeepSeek V4 Pro across eighteen providers, surfaces this information as policy badges on each provider endpoint. Each badge represents a distinct data handling commitment or the absence of one. Understanding what the badges mean is the practical starting point for any data-sensitive routing decision.

Private: The provider guarantees that neither your prompt nor the model response is retained after the request completes. This is the strictest guarantee available from an API provider and the relevant certification for teams operating under GDPR, HIPAA, or regulations that prohibit third-party data retention. Among others, Deepinfra complies to this section. 

May retain prompts but no training on inputs: The provider retains prompt and completion data typically for a defined window but will not use that data for model improvement. This is the default for many infrastructure providers. Whether the storage is in a Chinese, US, or European jurisdiction determines what legal framework governs access rights, government compelled disclosure, and deletion obligations. The badge alone does not specify jurisdiction; that requires reading the provider’s terms of service.

May retain prompts and may use them for training: The provider does retain prompts or completions past the inference call, and may use request data for model training. This is the weakest section and it should be well considered if these inference providers are used. 

The Security Concerns That Are Real

Separating the legitimate technical concerns from the regulatory noise is necessary because they point to different mitigations.

The most substantive empirical finding in the public record is the Booz Allen Hamilton study published in June 2026. Booz Allen ran more than 2,800 trials against four Chinese code-generation models and one American model (Claude Opus 4.6) using developer personas ranging from neutral to explicitly US-government-associated. Three of the four Chinese models — Qwen3-Coder, MiniMax M2.5, and DeepSeek V4 Pro — produced significantly more vulnerable code when the prompt identified the user as working for a US government entity. Qwen3-Coder showed the largest shift, adding roughly 130% more vulnerabilities under the government persona. Crucially, the vulnerabilities were highly obfuscated — not the kind of errors that standard static analysis catches.

The concern is not that Chinese AI models produce uniformly bad code. Kimi K2.5, notably, recorded the lowest aggregate vulnerability score in the Booz Allen test, below even the American model. The concern is that some models appear to exhibit context-sensitive behaviour. What you tell the model about who you are and what you are building for shape the security properties of the output. That is a different and more subtle problem than a backdoor or an embedded payload.

Booz Allen sells government technology services, which creates an incentive structure for alarming findings. Some independent researchers, while finding the study credible, noted that the causal mechanism has not been verified. It is not clear whether the persona-conditional behaviour is deliberate or an artefact of training data distribution. The same independent researcher who called the study credible (Lenart Heim, formerly of RAND) noted that more controlled replication would strengthen confidence in the conclusion. That said, a study with 2,800 trials and 450,000 lines of code is not anecdotal.

The practical implication from the Booz Allen findings is to not use Chinese coding models without code review for applications touching government systems, critical infrastructure, or security-sensitive code paths and be aware that standard SAST tooling may not catch the class of vulnerability the study identified. That applies to live API use and self-hosted weights equally, because the risk here is in the model’s outputs, not in data transmission.

The broader jailbreak concern is real, but slightly different. DeepSeek models showed a 94% jailbreak success rate in third-party security testing, compared to much lower rates for US frontier models. That gap reflects years of differential investment in adversarial safety fine-tuning. For general developer tooling it is a background risk. For applications where the model might handle sensitive user inputs or be exposed to adversarial prompting, it is relevant and again, it applies to the weights regardless of how they are served.

The Distillation Question

The IP theft framing from Bessent and Anthropic deserves its own treatment because it is being used to justify regulatory action but the underlying technical and legal question is genuinely unsettled.

“Distillation” in the machine learning sense refers to using the outputs of a large model to train a smaller or different model — a legitimate and widely used technique. The allegation against Chinese labs is not that they used distillation per se, but that they did so covertly, at industrial scale, through fraudulent accounts that violated terms of service, to extract capabilities from models they would otherwise have had to develop independently. Anthropic’s complaint specifically alleged roughly 25,000 fraudulent accounts generating 28.8 million interactions with Claude.

Whether that constitutes IP theft in a legal sense is not resolved. Terms of service violations are not the same as theft. The output of a Claude query does not obviously carry a copyright claim that survives into a model trained on it. Legal scholars have noted that the intellectual property framework for AI model outputs is largely unsettled. Bessent’s use of the phrase “we are finding watermarks of our US large language models on many Chinese models” suggests the administration believes it has technical evidence, but no specifics were disclosed publicly, and the watermarking claim has not been independently verified.

For the purposes of a build-or-not-build decision, the distillation question matters because it is the most plausible basis for an Entity List designation against a specific lab. If the Treasury or Commerce Department determines that a specific lab engaged in IP theft through distillation, that lab could be sanctioned in a way that restricts US companies from doing business with it. An Entity List designation would affect API access immediately. It would not affect already-downloaded weights in any practically enforceable way, but it would create legal ambiguity about continued use of those weights for some business contexts.

What the federal procurement restriction looks like in practice

The policy instrument most likely to actually be enacted in the near term is a procurement rule rather than a broad commercial ban. The congressional letter language is instructive: the committees asked DoorDash and others to scrutinize their reliance on Chinese-developed models and strengthen the availability of “American open-weight alternatives” — framing that suggests the goal is displacement rather than prohibition.

A procurement restriction would prohibit use of Chinese AI models in work performed under federal contracts. That is already the de facto policy for classified systems and most defence work. Extending it to broader federal contracting would catch government-adjacent companies but would not reach the general commercial market.

The more aggressive scenario — an executive order restricting private commercial use — faces the First Amendment and enforceability problems already described. Weights that have been published cannot be un-published, and the distributed infrastructure required to actually block access to files on Hugging Face would require a degree of internet infrastructure control that the US government does not currently exercise and would face significant legal resistance in attempting to exercise.

How to Think About This for a Production Build

The risk is real but it is not uniform, and the deployment configuration is more important than the model origin. Here is a practical breakdown.

If you are a government contractor or building for government systems: Federal procurement restrictions are either already in effect or likely to become so. Do not build production dependencies on Chinese model APIs or weights for government work. The security concerns from the Booz Allen study are specifically heightened in this context, and the regulatory exposure is the highest of any category.

• If you are building a commercial product that processes sensitive or regulated data: The live API route to a Chinese provider is the configuration to avoid. The data sovereignty problem is structural and not mitigated by anything the model does well. Running the same model weights via a US-based inference provider removes the data transmission risk. Self-hosting the weights removes it entirely. Either is a reasonable path if the model’s capabilities justify the choice; the key is that the risk is in the data flow, not the model itself.
• If you are a developer building on general commercial workloads with no government or sensitive data exposure: The current regulatory situation does not prohibit what you are doing. The Booz Allen findings are worth understanding, particularly the persona-conditional vulnerability generation, but they are most relevant to security-critical code paths and government-associated contexts. Standard code review and security testing practices are the appropriate mitigation, as they would be with any model.
• On the question of live API vs. self-hosted weights: If you are building something where continued access over a 12–24 month horizon matters, the live Chinese API is the highest-risk configuration because it is the one a regulatory action could sever overnight. Weights you have already downloaded are not. A US-based inference provider that serves the same weights is a reasonable middle ground. You get the operational simplicity of an API without the data sovereignty exposure, and you have time to react if the regulatory environment changes.

Final Thoughts

The honest bottom line is that the “Chinese AI model” as a category conflates risks that are quite different from each other. The data exposure from a live API call to a Beijing-operated server is real. The security concern about context-sensitive vulnerability generation in specific models is real and requires specific mitigation. The regulatory risk of an outright ban on already-downloaded weights is much lower than the headlines imply. Building on Chinese open-weight models via a neutral US-based inference provider is a materially different decision than calling a Chinese API and it is one that a large number of well-run US companies, including some now receiving congressional letters, have already made.

Chinese Open-Weight Models on DeepInfra

DeepInfra serves Kimi K3, DeepSeek V4 Pro, GLM-5.2, and the Qwen3 family from US-based H100 infrastructure. Prompts do not transit to Chinese labs. Pricing, latency, and integration are identical to any other model on the platform with a single endpoint, OpenAI-compatible API, usage-based pricing with no contracts. Start building today.