Do ITAR or the EAR mention large language models?

No. Both regimes describe data, persons and transfers without naming technology. Model usage enters scope because controlled technical data moves through it, so the scoping analysis belongs with export counsel and the official your export programme designates, not with a tool vendor.

Does a US-region cloud endpoint solve the problem?

Region selection addresses the proscribed-country condition in 120.54(a)(5)(iv) and does nothing about (b)(1)(ii). A provider in Virginia that decrypts your request is still a third party holding the means of decryption. Region and recipient are separate conditions, and both have to hold.

Is a self-hosted open-weight model inside our own environment a transfer at all?

Running inference on infrastructure you control, with no third party able to read the plaintext, keeps the data inside your own boundary. The remaining question is who inside your organisation can see the outputs, which returns you to ordinary person-status access control.

How does this relate to CMMC and CUI?

They are separate regimes that often cover the same company. Controlled unclassified information duties come from the contract and the DFARS clause, and the mapping work is covered in CMMC AI controls mapping. Export control status attaches to the data itself regardless of any contract.

AI Data Protection for Manufacturing: The Deemed Export Rule and Third-Party Models

22 CFR 120.54(a)(5) says that sending or storing technical data is not an export when the data is unclassified, secured using end-to-end encryption, protected by cryptographic modules compliant with FIPS 140-2 or comparable strength, and not sent to or from a proscribed country. Paragraph (b)(1)(ii) then defines end-to-end encryption to require that "the means of decryption are not provided to any third party." A model provider decrypts your request in order to process it. That single sentence is why an engineer pasting a controlled drawing specification into a commercial chat product falls outside the carve-out, and why ai data protection manufacturing work has to start at the outbound request.

I want to work through what the deemed export rules actually say, why the encryption exemption that covers cloud storage fails for model inference, and what the per-request record has to hold when an export compliance officer asks.

TL;DR

ITAR at 22 CFR 120.50(a)(2) treats releasing technical data to a foreign person inside the United States as an export, with no shipment required.
The encryption carve-out at 120.54(a)(5) only holds when the means of decryption are withheld from every third party, and a model provider decrypts what it processes.
EAR at 15 CFR 734.13(a)(2) applies the same deemed export concept to technology and source code for commercial items.
A release to a foreign person counts as an export to every country where that person holds or has held citizenship or permanent residency, so the reviewer's own status matters.

What the deemed export rule says

22 CFR 120.50(a) defines export to include "releasing or otherwise transferring technical data to a foreign person in the United States (a deemed export)." Nothing crosses a border. The transfer happens where the data is.

Paragraph (b) widens the consequence: "Any release in the United States of technical data to a foreign person is deemed to be an export to all countries in which the foreign person has held or holds citizenship or holds permanent residency." One release can be an export to two or three jurisdictions at once, depending on the individual.

The Commerce side mirrors it. 15 CFR 734.13(a)(2) defines export to include "releasing or otherwise transferring 'technology' or source code (but not object code) to a foreign person in the United States (a 'deemed export')," and paragraph (b) makes it a deemed export to the person's most recent country of citizenship or permanent residency.

A manufacturer holding controlled technical data therefore has to reason about two questions on every transfer: what the data is, and who can now read it.

The encryption carve-out and where it breaks

The 2016 rule that added 120.54 was written to let exporters use commercial cloud storage without treating every upload as an export. Four conditions in 120.54(a)(5) have to hold together: the data is unclassified, it is secured using end-to-end encryption, the cryptographic modules comply with FIPS 140-2 or its successors or reach at least the 128-bit security strength of AES-128, and the data is neither intentionally sent to nor stored in a country proscribed in 126.1 or the Russian Federation, nor sent from one. A note to that paragraph adds that data in transit via the internet is not deemed to be stored.

Paragraph (c) then makes the intent explicit: "The ability to access technical data in encrypted form that satisfies the criteria set forth in paragraph (a)(5) of this section does not constitute the release or export of such technical data." A cloud provider holding ciphertext it cannot read has not received the data.

That logic holds for storage and collapses for inference. Paragraph (b)(1) defines end-to-end encryption as cryptographic protection between an originator and an intended recipient such that the data is not in unencrypted form between them, and requires that the means of decryption are not provided to any third party. A model provider cannot produce a completion from ciphertext. The plaintext exists on the provider's infrastructure for the duration of the request, which means the provider holds the means of decryption, which means the condition in (b)(1)(ii) fails.

My opinion is that this is the single most under-examined compliance question in manufacturing AI adoption, and it gets missed because the cloud analogy feels close enough. Encrypted storage and encrypted transport to a processor are different mechanisms with different legal consequences, and the difference is whether anything on the far end reads the bytes.

Why the existing controls miss it

A manufacturer with export obligations usually has good controls at the perimeter it built. Document management systems tag controlled drawings. Access requires a citizenship attribute. Email gateways block attachments by classification, and technical data lives in a segmented environment.

The model request leaves through none of those paths. An engineer reads a controlled specification on an approved screen, retypes or pastes a portion into a browser tab, and the request goes out as ordinary TLS to a hostname the network team has no reason to flag. The document never moved. Its contents did.

Data loss prevention tuned for file movement and pattern matching is poorly positioned here, because controlled technical data has no format signature. A tolerance table, a material callout and a process parameter look like engineering prose. The classification problem is the general one described in AI DLP and traditional DLP, sharpened by the fact that the controlling attribute is regulatory status rather than pattern.

The agentic pattern makes it broader again. Manufacturers now run workflows that summarise supplier quality reports, draft engineering change notices and answer questions against a document index. If a controlled drawing is in that index, the retrieval layer will happily put an extract into a prompt, and the record will name a service account. Where the data physically comes to rest is a separate question covered in AI data residency controls.

What the record has to carry

The record that answers an export compliance officer gets written when the request leaves the authenticated user, before any response comes back.

Per request, the useful content covers the timestamp, the engineer authenticated through the company's identity provider, that person's citizenship or person-status attribute as the access control system holds it, the calling application or agent, the destination provider with model name and version, the region the request was routed to, the classification applied to the request body including export control status, the policy version in force, the enforcement outcome, and a hash of request and response.

The person-status attribute is the field that makes this regime different from every other data protection regime. Most records answer who touched what. An export record has to answer who was legally able to receive it, and that turns on an attribute your identity provider already holds for facility access. Pulling it into the model authorization decision is the work.

Retention should match the recordkeeping periods in your existing export compliance programme rather than a security team default, because a voluntary self-disclosure years later is reconstructed from whatever survives.

The routing decision is the one to enforce inline

Most export controls on AI usage get written as policy and enforced by training, which asks an engineer under deadline pressure to classify a paragraph correctly.

An inline enforcement point can decide by attribute instead. Requests carrying export-controlled markers route to a self-hosted model inside the controlled environment, where no third party holds the means of decryption and the 120.54 analysis never arises. Everything else goes to the commercial provider. The refusal or the reroute both produce records, and the record showing a reroute is the one that demonstrates the control worked. The general argument for enforcing at the request boundary instead of at the policy document is in why AI security must be inline.

DeepInspect

DeepInspect is a stateless proxy between authenticated users or agents and any LLM endpoint. Identity resolution, classification of the request body, model routing and policy enforcement run inline on the HTTP request before it reaches the provider, and routing decisions can send a classified request to an internal endpoint instead of a commercial one.

Each decision writes a signed record carrying the authenticated engineer, the identity attributes the policy evaluated, the classification applied, the destination model and version, the region, the policy version in force, the outcome and the timestamp. Records commit to append-only storage before the response returns, and retrieval by person, classification, destination or time range completes in seconds. The boundary covers authenticated HTTP traffic between your people or agents and the models they call. Technical data classification decisions, licence determinations, the designated official role and any voluntary disclosure stay with the people who own them today.

If your engineers are asking commercial models about controlled drawings, the deemed export analysis is already running whether anyone has written it down. Book a demo today.