🚨 DeepSeek AI Ban: Federal AI Security Checklist (2026)

Existing deployments and new purchases

The order covers both new procurement and existing deployments. Agencies have two different problems to manage: stopping new adoption and figuring out what's already in use. A purchasing restriction alone won't fix what's already deployed, and a removal instruction without procurement controls won't prevent new instances from appearing through another contract or vendor.

To get this right, agencies may need to review software inventories, vendor disclosures, contracts, integrations, and who has access. Exactly what they do depends on the system and where the model is used. A service that processes public information is operationally different from one that handles sensitive government material - even if both rely on the same underlying technology.

The directive also permits exceptions. That matters because it signals that the government is using a risk-based process rather than assuming every technical use has identical exposure. An exception isn't blanket permission; it's a way for an agency to make a case under the directive.

How this differs from the earlier restriction

The federal government had already taken steps to limit DeepSeek's use in certain intelligence national security systems through a law passed in December 2025. This newer order extends restrictions to federal civilian agencies and explicitly addresses purchases, existing IT systems, and third-party products built using DeepSeek technology.

So this is an expansion of the government's approach, not the first federal action involving DeepSeek. It also shouldn't be described as a nationwide consumer prohibition. The reported order applies to federal civilian agencies, and the information provided does not establish a general ban on private companies, state governments, or individual consumers.

For the original reporting and additional details about the directive, see TechCrunch's report.

Data governance is part of model selection

When teams evaluate AI tools, they often focus on output quality, price, latency, and features. Those are real factors, but they don't answer the basic operational questions that determine whether a system is safe to use:

• What information is sent to the model or service?
• Is data retained, and for how long?
• Who can access it, including the provider and any subprocessors?
• Which jurisdictions and legal rules apply?
• Can the customer control retention, deletion, and access?
• Does the vendor disclose changes to the model or its hosting setup?

Those answers can look very different across local deployment, a hosted API, and a third-party product that uses a model behind the scenes. Knowing the model name isn't enough. The deployment architecture, contract terms, configuration, and the data flowing through the system all shape the actual exposure.

For a federal agency, the threshold for acceptable risk can be lower because the stakes include exposure of sensitive government information. For a private company, the "right choice" depends on its own obligations and threat model. And if you handle regulated personal data or confidential customer records, you shouldn't assume a widely used tool is appropriate just because it's easy to access.

The supply-chain problem

By including third-party products, the order points to a bigger issue: AI dependencies can be several steps removed from the buyer. A company might contract with a software vendor, the vendor might rely on a cloud provider, and the cloud might call an external model. If procurement teams only ask, "Do we use DeepSeek directly?" they can miss indirect use.

This isn't unique to one provider or one country. Modern software supply chains already involve cloud services, libraries, data processors, and subcontractors. AI adds another dependency that can shift quickly: vendors can switch models, add features, or route requests through different services without changing the product name on the invoice.

The practical response isn't to ban every indirect dependency by default. It's to make dependencies visible enough to assess. If a supplier can't tell you which models process your data, what controls apply, or how it would respond to a material change, that uncertainty should affect purchasing decisions.

Distillation allegations remain allegations

The U.S. has accused DeepSeek and five other Chinese AI companies (including Alibaba and Moonshot AI) of using large-scale model distillation to extract information from American AI systems, according to a September report. OpenAI and Anthropic have also raised concerns about suspected or unauthorized collection of outputs from their models.

Model distillation is a technique where outputs from one model are used to train another. It can be legitimate work for building smaller or more efficient models. The dispute is about the circumstances, authorization, and scale of the alleged use - not about whether distillation exists as a technique.

These claims should be treated as allegations and concerns, not confirmed findings. They're also separate from the federal order's stated data-access rationale. If you mix them together, it's harder to see what the government is actually responding to: one set of concerns relates to handling user information, while another involves alleged extraction of model outputs and intellectual property.

China has rejected the U.S. move. A Foreign Ministry spokesperson, Mao Ning, said Beijing opposes "overstretching the concept of national security and politicizing technology and trade issues," and said China would protect the legitimate rights and interests of Chinese companies. That response fits the broader disagreement over where national security ends and protectionism begins.

Export controls add another layer

The technology relationship isn't moving in one direction only. China is reportedly considering export restrictions on 23 AI-related technologies, including chip designs and certain advanced AI models, citing security and misuse risks. That report is another example of how AI is becoming part of trade and national-security policy - not just product competition.

For companies operating internationally, that creates uncertainty around availability, deployment, and compliance. Rules can affect which tools a company may use, and also which technologies it can transfer, export, or support across borders. Organizations should treat jurisdiction and supply-chain exposure as an ongoing review topic, not something you solve once and forget.

1. Build an AI inventory

Start with what people actually use, not only what shows up in procurement records. Include approved tools, pilots, developer tools, browser-based services, APIs, and AI features embedded in existing software. Ask business teams and technical owners to identify tools that may have been adopted outside formal purchasing.

For each use, capture:

• The product, vendor, and the underlying model if you can identify it.
• The business owner and technical owner.
• The data types processed, including whether personal or confidential data is involved.
• Where processing happens and which providers are involved.
• Whether it's a pilot, production service, or an integration nobody uses anymore.

Even an incomplete inventory is still useful if you're clear about what it misses. The goal is to replace guesswork with a picture that keeps getting better.

2. Classify use by data and consequence

Not every AI feature needs the same level of scrutiny. A model generating public marketing ideas isn't the same as one summarizing customer records or supporting decisions with legal consequences. Classify use cases by how sensitive the inputs are and how consequential the outputs could be.

A simple starting point is to separate public, internal, confidential, and regulated data. Then add one consequence question: what happens if the model returns a wrong answer, exposes an input, or stops working? This helps teams prioritize reviews based on business impact, not on how visible the vendor is in the news.

3. Put requirements into procurement and contracts

Ask vendors to identify the models and subprocessors used in the features you care about. Where feasible, require notice of material changes. Clarify data retention, deletion, access, and training policies. For high-risk use cases, ask what support looks like for audits, incident response, and migration if the service becomes unacceptable.

A contract can't eliminate every technical risk. But it can make responsibilities clearer and reduce the odds that a dependency stays hidden until a security review - or a policy change - forces a rushed response.

4. Plan for replacement before it is urgent

A model shouldn't become effectively irreplaceable just because an application was built around a specific API or output format. For important workflows, keep integration boundaries clear, document prompts and evaluation criteria, and test whether another model can meet your minimum quality bar.

That doesn't mean building every application to support five interchangeable models. Abstraction costs time and money, and building it everywhere can slow delivery without actually reducing meaningful risk. Use it where the cost of losing a provider is high enough to justify the extra work - critical workflows, sensitive data, or systems with long replacement timelines.

The framework is straightforward: assess the sensitivity of the data, the impact of failure, how transparent the supplier is, and the real cost of switching. If risk is low and replacement is easy, a lighter review may be enough. If data is sensitive and the dependency is hard to remove, invest in stronger controls before you expand usage.