The DeepSeek Ban Makes Model Provenance a Procurement Question

What the order covers, and what it leaves open

On 24 July 2026, Secretary Markwayne Mullin signed Exclusion and Removal Order #2026-01 under the Federal Acquisition Supply Chain Security Act of 2018 (FASCSA). The DHS notice was filed for public inspection on 19 October and scheduled for formal publication in the Federal Register on 20 October. It does two things. It excludes IT products and services from Hangzhou DeepSeek Artificial Intelligence Co. and its affiliates from federal civilian agency purchasing, and it removes DeepSeek products, plus third-party products and services developed using DeepSeek implementations, from civilian agency IT. National security systems and secure compartmented information systems are outside its scope.

DHS framed the risk around data transfer and code integrity. It said use of the product "may result in the transfer of sensitive data to the PRC if used by U.S. government employees or vendors." It also described "multiple threat vectors": collection of personally identifiable information, possible tracking or fingerprinting of users, and possible malware or other security vulnerabilities.

Before this order, agencies had used their own discretion to block models like DeepSeek. Now there is a single order for civilian agencies, with limits. It is not a general ban on private use in the United States. Agencies can request exceptions, but only 60 days in advance and with a "compelling justification", such as being unable to carry out a mission-critical function.

Implementation sits with CISA's FASCSA Order Implementation Team. While removing DeepSeek, agencies were advised to monitor network traffic, increase logging and put in data loss prevention controls to reduce the risk of data exfiltration. Those are sensible controls for any organisation trying to find out which AI services its staff are actually calling.

How an agency order reaches private suppliers

If you never sell to a US agency, it is tempting to stop reading here. Don't. Under FAR 52.204-30, unless a waiver applies, contractors may not provide or use any covered article or source prohibited by an applicable FASCSA order as part of contract performance. DHS FASCSA orders apply to contracts outside the Department of Defense. Contractors are expected to search SAM.gov for "FASCSA order", and an order issued after the solicitation date applies only once it is added to the contract by amendment or modification.

The obligation keeps travelling. GSA tells offerors not to offer anything covered by a DHS FASCSA order on GSA-funded contracts and to check that proposed subcontractors at every tier comply. For solicitations that include FAR 52.204-29, contractors must make a "reasonable inquiry" into their supply chain. In practice that inquiry lands on the software vendors those contractors use, and potentially on the vendors behind those vendors.

There is precedent for how this works. The first FASCSA order, issued in 2025, targeted Acronis and barred contractors from using its products or services in new and modified contracts with the covered agencies. AI models are harder to spot than a named vendor's product, because they can sit inside other products without appearing on any feature list.

The open-weights gap nobody has closed yet

The order uses the phrase "developed using DeepSeek implementations" without defining it. As one analysis points out, it also does not name the products it means, or say how to treat a DeepSeek model running on a US company's own servers. That matters, because DeepSeek releases its models as open weights, and those weights appear inside other companies' tools.

This next part is my opinion, not something the order says. A cautious contracting officer will probably read "DeepSeek implementations" broadly until there is guidance saying otherwise, because nobody wants to approve an exception and then have to defend it. If your product uses a fine-tuned DeepSeek variant for summarisation, I would assume a federal-facing customer will treat it as covered.

The practical lesson is that "we host it ourselves" answers one question but not the other. It tells a buyer where the data goes. It does not tell them what the model is or where it came from, and this order touches both.

Model origin vs. inference location

A self-hosting guide notes that DeepSeek's hosted API routes through Chinese infrastructure, while running the MIT-licensed open weights on your own cloud removes that data-residency concern. The same guide puts DeepSeek V4-Flash at roughly 170-175GB of memory. That figure is a useful reality check: self-hosting a large model is an infrastructure project, not a configuration change. And as the bullets below show, each deployment pattern settles a different part of the question.

None of the three patterns is automatically safe or unsafe. A local model from an origin your customer rules out still fails a provenance check, and a well-governed vendor API in an acceptable jurisdiction may pass easily. The goal is to know which pattern each AI feature uses and to be able to state both the model and the location in one sentence.

On-premise is not right for everyone either. A twenty-person firm without an IT team will usually get better security from a well-run cloud service with clear data terms than from a server nobody patches. Match the deployment to what your actual customers require, not to the strictest scenario you can imagine.

• Vendor API. Data location: prompts, documents and outputs are processed on the provider's infrastructure, under its retention terms and jurisdiction. Provenance left open: you know who you contract with, but not necessarily which model sits behind the endpoint, or when it changes, unless the provider discloses it.
• Self-hosted open weights in your cloud. Data location: data stays in infrastructure you control, in a region you choose. Provenance left open: you know exactly which weights you run, but their origin does not change with the hosting; a DeepSeek model in your cloud is still a DeepSeek model, and the order does not say how that case is treated.
• Local LLM on premise. Data location: the strongest answer, since inference never leaves your building. Provenance left open: origin questions remain exactly as they are for cloud self-hosting; a customer can still ask which model it is, where the weights came from and who approved them.

Auditing the AI you did not know you had

One compliance checklist published after the order recommends three steps. Audit AI products for DeepSeek models, including embedded or white-labelled integrations. Update vendor due diligence questionnaires so vendors must state which models their products are built on and whether DeepSeek or any PRC-origin model is in the supply chain. Review federal-facing AI vendor contracts for breach or notification triggers.

The phrase "embedded or white-labelled" is where most of the work hides. A product that says nothing about AI on its feature page may still call a model for search, transcription, translation or OCR. If you supply software to federal contractors, your product may be one of the things being audited, and the auditor will start from your subprocessor list, not your marketing site.

The hardest case is a feature that calls a third-party API whose underlying model the provider does not disclose. In my view the honest answer there is "unknown, not disclosed by the provider", together with the provider's name, the date you asked and their reply, rather than a confident "no" you cannot back up. That gives the customer something to evaluate, and it puts pressure where it belongs: on the provider that holds the information.

The contract review step deserves more attention than it usually gets. If your agreements with AI providers say nothing about notifying you of model changes, you cannot promise your own customers that your answer will stay accurate. Fixing that at renewal is far easier than after a questionnaire arrives.

What to document now

The cheapest time to build a model inventory is before a customer's questionnaire forces you to do it in a week. Keep it short, keep it factual and give it a named owner. The list below is a workable minimum for each feature that uses AI.

Treat it as a living document. Vendors can change underlying models, and a subprocessor switch can change your answer. I would suggest a quarterly review, plus a contractual requirement that suppliers notify you of model changes, which should catch most changes between reviews.

Meeting tools make a good first entry, because a single recording can pass through one model for speech-to-text and another for summaries and action items. Those two models may come from different providers and run in different places, so record each one separately rather than listing the tool as a single line.

• Model family, version and provider, including models used inside third-party components such as transcription, OCR or embeddings.
• Deployment pattern: vendor API, self-hosted in your cloud, or on premise, with the hosting region and the company operating inference.
• Data flows: what goes into the model, what is logged, how long prompts and outputs are retained, and whether the provider may train on them.
• Origin and licence of any open weights you run, and who approved their use.
• A swap plan: how long it would take to replace the model if a customer or regulator ruled it out.
• For US federal work: the date you last searched SAM.gov for FASCSA orders and the result.

Who can relax, and who should not

Government restrictions on DeepSeek did not start in Washington. In February 2025, South Korea's foreign, trade and defence ministries blocked access to DeepSeek on government computers. This is not a US-only concern, and suppliers outside the US can be pulled in if a US-headquartered customer adopts the federal rule internally, even without a federal contract of their own.

My view is that if you sell only to consumers or small private businesses in markets without similar rules, this order does not bind you directly, and rewriting your stack in a panic would be a waste. That can change if a larger corporate customer decides to apply the same rule to its suppliers, so a simple inventory is still worth having. It can wait for a quiet week.

If you sell to governments, regulated sectors or multinationals, or to anyone who sells to them, the calculation is different. I expect some corporate security and procurement teams to follow the federal lead over the coming months, and if they do, model origin and hosting are likely to appear in their questionnaires. Being able to answer clearly and quickly is useful in its own right, whichever model you chose.