MICKAI®ArticlesWhy export controlled technical d…
Article · 31 July 2026

Why export controlled technical data cannot go to cloud AI

Cloud AI must decrypt technical data to process it, which breaks the ITAR encryption carve-out and turns provider staff into deemed export exposure, so on premise, air gapped review is the defensible route.

Author
Micky Irons
Published
31 July 2026
Follow Micky Irons
LinkedInX
itar-complianceexport-controlsdeemed-exportsovereign-aidefence-industrial-base
Why export controlled technical data cannot go to cloud AI

Export controlled technical data cannot go to cloud AI because a cloud service must decrypt that data to process it, and the moment it does, the protection of the ITAR encryption carve-out falls away. The International Traffic in Arms Regulations treat the release of technical data to a foreign person as an export wherever it happens, so plaintext in a multinational provider's infrastructure is exposure, not convenience. The defensible route is to bring the intelligence to the data, on hardware the contractor owns, inside a boundary the contractor controls.

This is not an aggressive reading. It follows from ITAR section 120.54, which the Directorate of Defense Trade Controls brought into effect on 25 March 2020 to clarify when sending or storing technical data does not count as an export. The provision was written for encrypted transit and storage, never for a service that must read your data to do its job.

What does ITAR actually say about putting technical data in the cloud?

ITAR section 120.54 says that sending or storing technical data is not an export, reexport, retransfer or temporary import when the data is secured with end-to-end encryption and further conditions are met. That carve-out lets a defence contractor use commercial infrastructure for encrypted backups and transmission without a licence. The logic is simple: if nobody outside the originator and the intended recipient can read the data, no release has occurred.

The critical phrase is end-to-end. Under the regulation, the means of decryption must not be given to any third party. Data must remain ciphertext from sender to intended recipient, and the provider in the middle must never hold the ability to read it. Encrypted storage passes. Encrypted transit passes. Processing does not.

Why does the encryption carve-out fail the moment AI touches the data?

The carve-out fails because inference requires plaintext. A hosted AI service cannot summarise a drawing, extract tolerances or cross reference a certificate while the bytes remain encrypted. To do useful work, it must decrypt the data inside infrastructure the contractor does not control, precisely the condition section 120.54 excludes. At that point the contractor is not relying on the carve-out. It is relying on hope.

  • Decryption inside the provider's infrastructure: the service must read plaintext to run inference, so end-to-end encryption is broken by design.
  • Third party decryption: keys or plaintext become available to the provider, which section 120.54 does not permit.
  • Foreign person access: providers run global engineering and operations teams, and a foreign person reading plaintext technical data is a release under ITAR.
  • Opaque data handling: prompts, caches and logs may persist in jurisdictions the contractor cannot enumerate, let alone control.

What makes a cloud provider's own staff a deemed export risk?

Under ITAR, releasing technical data to a foreign person is deemed an export to that person's own country, even if the data never leaves the United States. A hyperscale provider runs international engineering and support teams, and anyone with access to plaintext customer data sits inside that deemed export analysis. The contractor cannot identify them, cannot vet them, and cannot name them on a licence application. An export control officer asked to sign that off has nothing to sign.

An export control officer cannot license what they cannot see. If plaintext controlled data can be read by people you cannot name, in places you cannot list, no paperwork makes it defensible.

Mickai

What does a defensible way to use AI on controlled technical data look like?

The defensible shape is sovereignty: the AI runs on hardware the contractor owns, on premise and air gapped, so controlled technical data never crosses the organisational boundary. This is how Mickai is built. Our Sovereign Intelligence Operating System runs entirely on the customer's own machines, fully offline, with no external dependency at inference time. There is no provider in the middle and no plaintext in anyone else's data centre.

Document review is where this matters daily. Our system reads incoming document packages, cross references certificates against the records behind them, drafts the routine paperwork, and holds anomalies for a person to decide. Consequential actions wait for a person's clearance, and every action is sealed to the Open Audit Record before it runs: a cryptographically signed, post quantum, tamper evident record, verifiable offline years later. For a contractor facing an audit, that record is standing evidence of what was reviewed, by whom, and under what authority.

How should an export control officer evaluate an on premise AI system?

Start from the data boundary and work inwards. If the system genuinely runs air gapped, no transmission occurs and the data stays where it already lawfully sits. Then ask who can invoke the system. Mickai gates operator access with voice biometrics and anchors identity in a hardware held root of trust, so only cleared operators can act. Finally, ask what record survives. A sealed, verifiable audit trail turns a compliance assertion into an artefact an auditor can test.

The same architecture serves the wider compliance picture. Offline deployment, controlled access, encryption and comprehensive sealed audit logging support a contractor achieving CMMC Level 2, and they answer the equivalent questions raised by the UK Export Control Order 2008, which makes intangible transfer of controlled technology by electronic means a licensable act in its own right. The wall between controlled data and the cloud is not an American peculiarity.

The direction of travel is clear. Defence supply chains are being asked to prove more, document more and expose less, while AI capability shifts from curiosity to competitive necessity. We believe the contractors that resolve that tension will be the ones who stop asking how to get controlled data safely into the cloud and start asking how to bring intelligence safely inside the boundary. That is the question Mickai was built to answer: intelligence on your hardware, under your control, with evidence sealed at every step.

Frequently asked questions

Does encrypting data before uploading it to a cloud AI solve the ITAR problem?

No. ITAR section 120.54 requires end-to-end encryption in which no third party holds the means of decryption. A cloud AI service must decrypt the data to process it, so the carve-out cannot apply to inference, whatever encryption is used in transit or at rest.

Is it still an export if the data never leaves the United States?

It can be. ITAR treats the release of technical data to a foreign person as a deemed export to that person's own country, wherever the release takes place. Foreign person access inside a domestic data centre falls within the analysis.

Can a contractor rely on a provider's government or sovereign cloud offering?

That is one for the contractor's export control counsel, and it turns on the specific offering, its personnel controls and its terms. The structural point stands either way: any service that processes plaintext outside your boundary asks you to trust controls you do not operate. Review on your own hardware removes the question.

How does on premise AI help with the audit side of export control compliance?

Mickai seals every review and action to the Open Audit Record before it executes. The record is cryptographically signed, tamper evident and verifiable offline, which gives an export control officer standing evidence of what was reviewed, who cleared it and what policy applied.

What is MICKAI?

MICKAI is a Sovereign Intelligence Operating System, a SIOS, that runs entirely on the customer's own hardware, on premise and air gapped. Every action is sealed to the Open Audit Record, a cryptographically signed, tamper evident record that can be verified offline. The system comprises 87 studios, with ten production ready at launch and 77 in development, and it is protected by 104 filed UK patent applications across 2,340 claims, filed rather than granted.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/why-export-controlled-data-cannot-go-to-cloud-ai. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles