What Does an Aerospace or Defence Prime Need From On-Premise AI Under ITAR and Export Control?

An aerospace or defence prime needs artificial intelligence that runs entirely inside its own controlled perimeter, on operator-owned hardware, with no route for controlled technical data to leave. Under ITAR and the Export Administration Regulations, sending controlled data to a public cloud service can itself be an export, because a foreign person who administers that infrastructure is a deemed export even when no file visibly crosses a border. The concrete requirement is therefore five architectural properties: a verified air gap, one-way signed updates, hardware-attested identity, a sovereign supply chain, and a sealed record of every action. Each is a property an auditor can test, not a policy promise.

This matters in 2026 because primes are under pressure to adopt generative artificial intelligence for design, bid work and sustainment, while the public services that make that easy are the ones export control forbids for controlled technical data. The market has narrowed to a single question: can the artificial intelligence do useful work without ever creating a path off the site.

Why can a prime not simply use a public cloud AI service?

Public services such as ChatGPT, Claude and Gemini run on infrastructure the prime does not own or control. Under ITAR and the EAR, controlled technical data may not be released to foreign persons, and administrative access by a non-US person counts as a deemed export. The US CLOUD Act compels US-based providers to produce data on lawful demand regardless of where it is physically stored, which no enterprise contract fully neutralises. Even a private tenancy still routes the data through provider-operated systems. For controlled programmes the safe assumption is simple: if data leaves the perimeter, it has been exported.

What does a verified air gap actually mean?

A verified air gap is not a firewall rule or a promise. It is a zero-egress inbound perimeter: the system runs offline on operator-owned hardware and has no outbound network path by construction. Requests go in through a controlled channel; nothing initiates a connection out. An auditor can confirm this by inspection, because the property is physical and configural, not behavioural. The test is blunt. Disconnect every uplink and the system must still perform every function it claims. If any capability degrades, the air gap was never real.

“Under export control the only defensible position is an artificial intelligence that never had a route to the outside in the first place.”

How do you update a sealed system without opening it?

Through one-way signed updates. An update is packaged, cryptographically signed, and carried into the perimeter over a controlled channel. Inside, the system verifies the signature against a pinned root of trust before anything is applied, and rejects anything that fails. We sign with post-quantum algorithms aligned to FIPS 204 (ML-DSA), the primary signature standard, and FIPS 205 (SLH-DSA), so the update chain and the audit ledger survive a future quantum adversary. There is no live update connection, no automatic pull, and no telemetry pushed back. The direction of trust is one way, always inbound.

What can an auditor verify after the fact?

Every action is written to a post-quantum signed audit ledger, and every action is bound to a hardware-attested identity. The operator, the machine and the model are cryptographically named at the point of use, and the record is tamper-evident. An auditor does not have to trust our word. They pick any action, any inference, any file access, and verify the signature chain back to the attested hardware that produced it. A sealed record of who did what, on which machine, with which model, is exactly the evidence an export-control review and an ISO/IEC 42001 audit both demand.

Why does the model's own supply chain matter?

Because you cannot air-gap a system and then trust a component you cannot see inside. A sovereign supply chain means the weights, the runtime and the data lineage are known, fixed and verifiable, with no phone-home and no silent change. Mickai, a Sovereign Intelligence Operating System (SIOS), runs sovereign models trained and sealed for this purpose, never a public consumer service wired behind a corporate label. The architecture is covered by 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending, never granted or patented. For a prime the point is narrower: you must be able to state what is inside the system, and prove it has not moved.

Which rules make this architecture necessary?

ITAR and the EAR govern the technical data itself and treat deemed exports as real exports. The US CLOUD Act is why provider jurisdiction matters more than data-centre location. In Europe, DORA has applied since January 2025 for the financial links in the supply chain, NIS2 raises the bar for critical suppliers, and GDPR still governs personal data. The EU AI Act moved: the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk to 2 August 2028 and Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. A prime that architects for offline verifiability now meets the standard whenever it lands.

Frequently asked questions

Can defence contractors use ChatGPT or Claude for controlled technical data?

No, not for ITAR or EAR controlled technical data. These services run on infrastructure the contractor does not control, and administrative access by a foreign person is a deemed export. The safe course is an artificial intelligence that runs air-gapped on operator-owned hardware, where controlled data never leaves the perimeter.

Does moving ITAR data to a cloud AI count as an export?

It can, yes. Releasing controlled technical data to a foreign person is an export even inside your own country, and cloud infrastructure administered by non-US persons can trigger that. The US CLOUD Act adds a separate jurisdictional exposure. Treat any egress of controlled data as an export until proven otherwise.

What is the difference between an air gap and a zero-egress perimeter?

An air gap describes physical separation; a zero-egress perimeter describes the guarantee that matters, which is that nothing can initiate a connection out. A properly built system has both. The test is to remove every uplink and confirm the system still does everything it claims.

Is the 2 August 2026 EU AI Act deadline still live for defence AI?

No. The high-risk Annex III obligations once set for 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk under Annex I moving to 2 August 2028. Article 50 transparency duties are largely unchanged. We treat the delay as time to build compliant architecture, not permission to defer it.

How does an air-gapped AI receive security updates?

Through one-way signed updates. Each update is signed with post-quantum algorithms, carried in over a controlled channel, and verified against a pinned root of trust before it is applied. Nothing is pulled automatically and no data is sent back, so the update path never becomes an egress path.