Commercial large language models trained on public internet data carry provenance and attribution risks that classified environments cannot tolerate. The moment a defence application touches a commercial AI model, it crosses a supply chain boundary that legal and procurement teams have, in most cases, not yet mapped.
The AI Summit frames AI adoption in UK defence as an innovation problem. It is a supply chain problem. The specific form of that supply chain problem is dual-use classification under international export control regimes, and the exposure is already present in programmes that have proceeded on the assumption that calling something “software procurement” resolves the legal classification question.
It does not.
What Dual-Use Classification Means for AI Components
Dual-use goods are items developed for civilian purposes that also have military applications. Export control regimes, including the US International Traffic in Arms Regulations (ITAR), the Export Administration Regulations (EAR), and the UK’s Military and Dual Use Export Control framework (MSCA), exist to restrict the transfer of dual-use technology to jurisdictions and end-users that could use it to undermine national security interests.
AI models trained on data with military relevance, or designed for applications that include military use cases, are subject to dual-use classification assessment. The assessment is not straightforward. A general-purpose large language model is not inherently a controlled item. The same model integrated into a targeting analysis workflow, a signals intelligence processing pipeline, or a threat assessment system may be.
The classification trigger is end-use, not the technology in isolation. A procurement team that classifies an AI model integration as standard software procurement without conducting an end-use assessment is not making a conservative decision. It is making an undocumented assumption that may be wrong.
How Commercial LLMs Are Trained on Multi-Jurisdiction Data with Unverifiable Provenance
The training data for frontier commercial AI models is not sourced from a single jurisdiction. Common Crawl, the primary pre-training corpus for most major LLMs, is a scrape of the public web. The web is not a US domestic dataset. It contains content from every jurisdiction. The provenance of that content, from the perspective of export control, is not tracked by any commercial AI vendor.
This matters because ITAR controls attach to US-origin technology. If a model is trained on US-origin data using US-origin compute by a US-domiciled company, the resulting model weights are a US-origin technology. The export of that technology, including making it accessible via API to a non-US entity, requires an export licence if the technology falls within ITAR’s scope.
Most commercial AI API access by UK defence entities currently proceeds without formal export licence analysis. The vendors have not sought commodity jurisdiction determinations for their frontier models. The procuring entities have not conducted Technology Control Plan assessments for their AI integrations. This is an exposure that exists now, not a hypothetical risk.
What Happens When a Defence Application Integrates a US-Origin Commercial Model
The ITAR analysis turns on whether the AI model is a defence article, a defence service, or controlled dual-use technology under EAR. A general-purpose language model accessed for document summarisation in a non-defence context is unlikely to meet the threshold. The same model integrated into a system that processes intelligence reporting, supports weapons system maintenance, or provides decision support in an operational command environment is a different analysis.
The question legal teams have not yet answered systematically is: at what point does the end-use of a commercial AI integration trigger ITAR or EAR controls, and what licences are required before that integration proceeds?
Until that question is answered with a formal commodity jurisdiction determination or a classified ruling from the relevant authority, programmes that integrate US-origin commercial AI into defence applications are carrying undisclosed legal exposure. A contract that proceeds without that determination is not just commercially risky. In the event of a ITAR violation, the financial penalties and programme suspension consequences are material.
Why Legal and Procurement Teams Have Not Mapped This Yet
The reason this exposure persists is not negligence. It is category error. Procurement teams that have decades of experience assessing the export control status of physical equipment, weapons systems, and controlled materials do not yet have established processes for AI model integrations.
AI models look like software. Software procurement has an established category in defence acquisition. The instinct is to route AI integrations through the software procurement framework, which has lighter-touch export control requirements than the weapons and dual-use goods frameworks. This instinct is understandable but legally untested for the AI use cases now being pursued.
The gap is compounded by the pace of AI adoption. Programmes are making integration decisions in Q2 and Q3 2026 that their legal teams are not being asked to assess for export control exposure. By the time legal review catches up with the technical integration, the procurement decision has already been made.
What a Supply Chain Assessment of a Commercial AI Integration Needs to Cover
A thorough supply chain assessment for a commercial AI integration in a defence context needs to answer six questions before any integration decision is finalised.
What is the origin of the model? Where is the vendor domiciled, where was the model trained, and on what data? This establishes whether ITAR or EAR is the relevant control framework.
What is the intended end-use? A precise definition of how the model will be used within the defence system, sufficient to conduct an end-use assessment against control list categories.
Has a commodity jurisdiction determination been sought? For any model integration where the end-use assessment indicates potential controls apply, a formal determination from the relevant authority is the only defensible basis for proceeding.
What are the data flows? Where does classified or controlled data go during inference? If classified data is sent to a model hosted on commercial cloud infrastructure, the data exfiltration risk is the primary control concern regardless of export control status.
What is the contractual position on model updates? If the vendor updates the model, does the updated model require a new export control assessment?
What is the Technology Control Plan? Who has access to the integrated system, under what conditions, and what controls exist to prevent unauthorised transfer?
These questions can be answered. The investment in answering them before integration is far smaller than the cost of addressing a compliance failure after the system is in service. Programmes scheduled for AI integration in Q4 2026 and Q1 2027 should be running this assessment now.
