DHS excludes DeepSeek and third-party products

You must now be able to identify every AI model and provider in your service chain, document which systems use them, and demonstrate that you can remove or replace any model your organisation deems unacceptable. If you cannot trace a model through third-party products to its origin, you cannot exclude it.

The prompt is an analysis of 20 October 2026 of the DHS exclusion of DeepSeek from federal civilian IT and procurement, which argues that organisations seeking to exclude an AI model must also identify and manage integrated services and the full supply chain. The measure covers not only the vendor's own products but also third-party services that use DeepSeek implementations. In our assessment, the order demonstrates a practical consequence for any organisation handling sensitive data: visibility into AI dependencies is no longer optional, and the ability to exclude a model depends on knowing where it runs.

Which products does the exclusion actually cover?

The order issued by the Department of Homeland Security on 20 October 2026 applies to federal civilian executive branch agencies. It mandates removal of DeepSeek products from IT systems, bars future procurement, and extends to third-party products and services developed using DeepSeek implementations. The measure is not a general ban on DeepSeek for private companies, hospitals, law firms or individuals; it binds only the named federal civilian agencies. However, its significance reaches beyond that scope. The order illustrates how an authoritative purchaser translates risk assessment into hard procurement and removal requirements, and that pattern now shapes how other organisations must think about AI supply chain risk.

Why does the order cover products you don't recognise as AI tools?

An AI model need not appear in a recognisable app or API. It may run invisibly through a subprocessor in a chain an end user never sees, serve as a building block in an integrated service, or operate through a vendor's own infrastructure. By extending the exclusion to third-party products, the DHS order exposes a practical gap: organisations seeking to exclude a model need visibility into relevant dependencies in the service chain. A list of visible AI tools no longer suffices. For each application in your environment, you must know which underlying model, which provider, which API and which subprocessor sit behind the service, and which data flows along that route.

What must you now document and control?

The order combines removal, procurement exclusion, and exception procedures. That combination creates obligations across three areas:

• Model and provider inventory — for each AI application, record which model, provider, API and subprocessor it uses, and the lawful basis for any data it touches.
• Contractual disclosure — require suppliers to declare their AI subprocessors and model provenance, and to report any change so that a prohibited component is later demonstrably replaceable.
• Technical controls — block non-approved model routes technically rather than merely prohibiting them in policy, because a model can still process data via an invisible route.
• Audit trail — keep, for each model, the assessment, the removal decision, or the approved exception separately and verifiably, so that at audit it is traceable who decided what and when.
• Exception management — treat exclusion as a reviewable decision, not an automatism, and maintain the basis for any exception granted.

What concrete steps must you take this month?

Begin with systems of highest data sensitivity. The CISO must record, for each AI application, which underlying model and provider sit behind it. The legal function must now contractually require suppliers to declare their AI subprocessors and model provenance and to report any change. The responsible director must ensure that sensitive information cannot run along a non-approved provider route. The organisation must establish whether a third-party product contains a prohibited implementation—a task that requires more than vendor documentation and demands active verification of the supply chain.

What tooling can and cannot do

Software can help you maintain an inventory of AI applications and flag changes to supplier declarations. It cannot tell you whether a supplier has disclosed all their subprocessors or whether a third-party product truly contains no prohibited model. That remains your own professional judgement, grounded in contractual clarity and technical verification. The order leaves exception procedures open; deciding whether to grant one is not a technical decision but a governance one, and it must stay with the people who carry the risk.