Know Which Models Your AI Suppliers Use

On 20 October, the US Federal Register published a Department of Homeland Security notice concerning DeepSeek. The attached exclusion and removal order gives its original release date as 24 July 2026. Its scope is federal civilian executive-branch systems and procurement, with national-security and secure compartmented information systems outside this order's stated coverage. ¹

The order reaches DeepSeek and affiliated products, including third-party products and services developed using DeepSeek implementations. It directs exclusion and removal from covered procurement and systems, with an exception process. The document ties required action to issuance, not to the October publication date. This briefing does not establish a fresh grace period. ¹

That is a specific US government measure, not a general prohibition on private-sector or international use. Suppliers serving affected agencies need the responsible procurement and legal teams to resolve their actual exposure. Other organisations should not copy the restriction automatically. The transferable lesson is narrower: a product's commercial label may conceal a dependency relevant to a customer's rules.

For the selected service, record the business purpose, supplier, model developer and model or version identifiers where available. Include secondary routes that can handle the same work, such as a fallback model used when the preferred route is unavailable. Ask who operates each component and which information it receives. Keep these as distinct fields rather than one vague country-of-origin label.

Then connect the record to the decision. Which customer, contract, law or internal rule makes a dependency relevant? What evidence supports the supplier's answer? Who checked it, when, and for which configuration? A product document may establish that a model is available, but not that it is used in your account. A technical log may show an endpoint without identifying every component behind it.

Use three honest states: known with evidence, supplier-declared but not independently checked, and unresolved. An unresolved field does not prove a breach. It does tell the accountable owner that acceptance rests on an assumption. Give that owner a route to request clarification, narrow the permitted use or pause expansion when the missing fact could change the decision.

A one-off questionnaire is not enough if the supplier can change the underlying model tomorrow. Agree which changes require notice and review. Focus on changes that could affect eligibility, information access, consequential behaviour or the evidence used for acceptance. A cosmetic product update should not create the same burden as a new model provider receiving customer records.

Ask for a dated account of the configuration used for your service, a contact responsible for changes and a practical way to restrict unsuitable routes. Where commercial confidentiality limits disclosure, explore scoped assurance or controlled access to evidence. Do not promise customers a level of visibility that the contract or technology cannot provide. Record the residual gap and who accepts it.

Identity alone does not prove safety. Research released this week tests ten model snapshots across English and 78 other languages and finds that English safety results do not transfer reliably. Translation quality and automated judging limit the findings; it is workshop-accepted research, not evidence of customer harm rates. ² The buyer's implication is to attach testing evidence to the actual configuration and supported languages, not merely to a recognised model name.

Singapore offers a different regulatory example. MAS issued AI risk-management guidelines on 7 October, with expectations on inventories and third-party assurance. They take effect in phases: Sections 3–4 from 7 October 2027 and Sections 5–6 by 7 October 2028. These are financial-sector supervisory expectations, not the US exclusion order and not an immediately effective global duty. ³

In the United Kingdom, the ICO's agentic-AI call for evidence runs from 8 October to 20 November. It seeks input on applying data-protection law, including security, accountability and purpose limits. It is a consultation, not a new blanket permission or prohibition. ⁴ European and other cross-border operations likewise need their own applicable-law analysis; a supplier inventory is useful evidence, not a compliance certificate.

Language, infrastructure and institutional capacity change the practical control. A buyer with limited technical staff may need a narrower service and stronger supplier evidence rather than an elaborate inventory it cannot maintain. A multilingual service needs relevant evaluation, while an intermittently connected operation must understand fallback behaviour. These are questions for local verification across Asia-Pacific, Latin America, Africa and the Middle East, not assumptions that every market shares one risk profile.

Bring procurement, the operating owner, security and the relevant legal specialist together around one important service. Trace its declared model dependencies to the work they perform. Separate confirmed restrictions from proposed rules and internal preferences. Identify the missing facts that could change approval, then assign a person and a date to resolve each one.

Test the record against a fictional change: the supplier adds a new fallback model. Would anyone know? Would the right customer or risk owner review it? Could the service continue within its approved limits? This is a desk exercise, not permission to change a live system or an assurance that a substitute will perform equally well.

The decision is whether the organisation can support its own acceptance claim. If it can identify the configuration, explain the evidence and manage material changes, it has a useful basis for procurement. If it cannot, the next investment should close that specific gap before a wider commitment. Buying a trusted brand should not mean accepting an unknown chain of dependencies.