Which AI models sit under your vendors' tools? What the federal DeepSeek order means for a health system

On October 20, 2026, the Department of Homeland Security published an order in the Federal Register that tells federal civilian agencies to remove DeepSeek's AI products from their systems, along with "third-party products and services developed using DeepSeek implementations." The order does not bind a private health system. But any organization that wants to follow a rule like it, including its own policy, first has to know which AI models run inside each vendor's product.

Below are what the order requires, how it can reach a health system through a federal contract, the HIPAA rule that already asks a related question, five questions to ask every AI vendor, and where each answer belongs in your AI tool inventory and your contracts. This is not legal advice, so have counsel review any contract language before you use it.

What does the order require?

It requires federal civilian agencies to stop buying DeepSeek products and to take them out of their systems. The Secretary of Homeland Security issued it as Exclusion and Removal Order #2026-01, with an original release date of July 24, 2026, under the Federal Acquisition Supply Chain Security Act of 2018. That law lets the Secretary order civilian agencies to exclude or remove technology products and services that put federal systems at risk. The order covers every federal civilian executive branch agency, except for its national security systems and secure compartmented information systems.

Agencies must do two things. They must stop buying from DeepSeek and its affiliates at once, including versions of DeepSeek that other companies provide and purchases through approved product lists and online marketplaces. And they must remove from their systems the products of DeepSeek and its affiliates, and products and services that other companies developed using DeepSeek implementations, or ask for an exception in writing within 60 days of the order's issuance. The order does not say whether those 60 days run from its July 24 release or from the October 20 notice. The Cybersecurity and Infrastructure Security Agency (CISA) reviews exception requests and answers each one in writing.

The order lists several risks, and most of them concern data. DeepSeek's servers are in China, where the order says the legal system gives government cyber and intelligence agencies broad access to company systems. When DeepSeek hosts its own models, its sign-up process collects personally identifiable information and may track users, and prompts sent to its apps may move sensitive data to China. The order also says that "the models themselves may contain malware or other security vulnerabilities." Both the buying ban and the removal step cover products that other companies built with DeepSeek as well as DeepSeek's own.

The order does not define "DeepSeek implementations." So it does not say whether a product that runs DeepSeek's published models on other companies' servers, or a model trained from a DeepSeek model, is covered. An agency would ask CISA, and a health system applying its own policy would ask its counsel.

Why is a model hard to spot inside a product?

DeepSeek publishes its R1 models for anyone to download and build on. Its model card for DeepSeek-R1 says the model weights are licensed under the MIT License, and that the series supports commercial use and "any modifications and derivative works." The same card lists six models "distilled from DeepSeek-R1 based on Llama and Qwen", two other model families. They are Llama and Qwen models trained on output from DeepSeek-R1, with names such as DeepSeek-R1-Distill-Llama-70B, and the card says each one comes from a Llama or Qwen model that was originally licensed under its own terms.

So a vendor's answer about where your data goes does not tell you which model a product runs. Ask for each model's name and what it was built from, as well as who runs the servers.

Can the order reach a health system?

Not directly, unless the health system is part of a federal civilian agency, as the Indian Health Service is part of the Department of Health and Human Services. A private or nonprofit health system can meet the order through a federal contract that includes the clause below.

Through a federal contract

Federal Acquisition Regulation clause 52.204-30, which contracting officers insert in many federal contracts, bars a contractor from providing or using, in performing the contract, any product or service from a source that an applicable order prohibits. Under the basic clause, for contracts awarded outside the Department of Defense, the orders from Homeland Security apply. The clause tells a prime contractor to search SAM.gov, the federal System for Award Management, for the phrase "FASCSA order", and to check it again at least once every three months during the contract. A subcontractor gets the clause without the three-month check.

An order issued after a contract was solicited applies to that contract only once the contract is modified to add it, but the duty to check SAM.gov and report applies either way. A contractor that finds a covered product was provided or used in the contract must report it to the contracting officer, with the first details due within 3 business days. If your organization holds federal contracts, ask your contracts office which ones include the clause.

What HIPAA already requires

HIPAA does not enforce the order, but it already asks a related question of vendors that handle patient information. If a vendor handles your patients' information and sends it to an AI model that another company runs for the vendor, HIPAA treats that company as the vendor's subcontractor (45 CFR 160.103). The vendor may share the information with it only after getting satisfactory assurances, in a written agreement, that the subcontractor will safeguard it (45 CFR 164.502(e)). Your business associate agreement must also require the vendor to make sure the subcontractor agrees to the same restrictions and conditions the vendor accepted (45 CFR 164.504(e)). So a vendor that sends patient information to a model should already be able to name the company that runs it. HIPAA does not make the vendor tell you, so ask for the names in the contract.

What should you ask each AI vendor?

Ask these five questions in writing, for each product, and record each answer where the figure says.

Ask the second question even when the first answer names a model family you know, because a vendor running one of DeepSeek's distilled models could truthfully say Llama or Qwen. The fourth question rests on the HIPAA rules above, so a vendor that handles patient information should answer it with names and dates. The fifth question covers what happens after you sign: if a vendor later changes the model under a product, a notice term is how you find out.

These questions add to the five data questions in how to score an AI vendor before the demo, one of which asks for the full list of companies that touch your data and where it is hosted.

Where do the answers belong?

The answers belong in your AI tool inventory, which lists every AI tool in use, and in the contract for each product. Add the columns below to the inventory, with one row for each model in each product.

Ask every vendor to confirm its answers at each renewal, and update the inventory whenever a vendor announces a model change. A vendor that closes or sells its business raises a separate set of contract questions, covered in what happens to your data when an AI vendor shuts down.

What if you have no AI tool inventory yet?

Start one before the next renewal comes up, because the model columns need a row for every tool to sit in. The AI Governance Starter ($8,500, fixed, three weeks) builds the inventory in its first week. It finds every AI tool in use from IT records, vendor contracts, expense reports and an anonymous staff survey, and it includes a vendor and BAA checklist with the questions every AI vendor answers in writing before a contract.