Air-gapped and on-prem AI for ITAR, EAR, and CUI environments

Why a public API is a non-starter

ITAR technical data, EAR-controlled designs, and CUI cannot lawfully be disclosed to uncontrolled systems or foreign persons — and a public AI endpoint is both, from a compliance standpoint: the operator cannot attest to where the data lands, who can access it, or what jurisdiction it sits in. "We don't train on your data" is a policy statement, not a control. Export-control officers need controls: enforced boundaries, audit trails, and deployment the programme itself owns.

The deployment ladder

Controlled environments are not one thing — a research lab, a supplier handling CUI, and a classified integration facility have different boundaries. Private AI deployment follows a ladder, and a serious platform must run at every rung:

• Local — on the engineer's own workstation. No network dependency, nothing transits anywhere. The strictest default, and the right one for early design work on controlled projects.
• On-premises — on servers inside the organisation's facility and network perimeter, shared by a team, administered by the programme's own IT under its own security plan.
• Air-gapped — physically isolated networks with no route to the internet. Installation and updates travel by approved media; the system must be fully functional with zero external calls, including licensing.
• Approved cloud — government or compliance-scoped cloud regions, for programmes whose security plan authorises them. Useful for scale; never a substitute for the rungs below when the data says otherwise.

What breaks when AI goes offline

Most AI products quietly assume the internet: telemetry, licence checks, model updates, retrieval calls. An air-gapped deployment exposes every one of those assumptions. Two design choices make offline operation real rather than nominal: self-contained engines (models, knowledge, and computation packaged inside the boundary, with no callbacks), and deterministic verification — because when a result cannot be checked against an external service, it must carry its own derivation and validity range so engineers on the inside can audit it unaided.

How AETHER runs inside the boundary

AETHER is local-first by architecture. The five engines — from ARITHMOS compute to DYNAMIS avionics — deploy at any rung of the ladder, and behave identically at all of them: same engines, same verification discipline, same auditable outputs whether the host is a laptop, an on-prem cluster, or an isolated facility network. That symmetry is what lets a design that starts on a workstation graduate into a controlled programme without changing tools. It is also the practical foundation of sovereign AI: control of the environment is only useful if the intelligence still works there.

For deployment into a controlled environment — including air-gapped delivery — start with enterprise access or talk to the team.

Published · 6 July 2026 · All technical notes