Navigating Export Controls: Sovereign AI Infrastructure for Multinational Defense Firms

A defense contractor operating in a single country has one export-control regime to satisfy. A defense contractor operating across several — a prime with design offices in the United States, an allied co-development partner in Europe, a subsidiary doing systems integration in the Indo-Pacific — has as many regimes as it has jurisdictions, and they do not defer to one another. ITAR does not stop applying to U.S.-origin technical data because it has been shared with a cleared partner in an allied country. The partner's own national security classification regime does not relax because the data originated somewhere else. Each jurisdiction asserts authority over the data inside its scope, and a multinational firm's obligation is to satisfy all of them simultaneously, not to average them into something more permissive.

Cloud AI tooling breaks this model in a specific and underappreciated way. A single-region contractor sending a prompt to a cloud model has one transmission event to worry about. A multinational firm with engineering teams in three countries, each working against technical data scoped under a different jurisdiction's controls, and all routing prompts to the same cloud provider, has created a de facto shared data environment that no single jurisdiction's regulator asked for and that satisfies none of them. The provider's infrastructure does not know that a prompt from the European office and a prompt from the U.S. office are subject to different legal regimes. It processes both as inference traffic. The firm's compliance posture, however, cannot be that undifferentiated. The gap between how the infrastructure actually behaves and what each regulator requires is where liability accumulates.

The segregation requirement, not just the boundary requirement

Most discussion of export-controlled AI focuses on keeping data inside a boundary: on-premises instead of cloud, air-gapped instead of connected. That is necessary for a multinational firm but not sufficient, because the harder requirement is segregation between boundaries the firm itself operates. Technical data governed by one jurisdiction's controls cannot simply live alongside technical data governed by another's inside a shared infrastructure layer, even if that infrastructure never touches the public internet. An air-gapped data center that pools engineering data from a U.S. program and a co-development program with an allied partner into the same retrieval index or the same model context has solved the external exfiltration problem and created an internal one: data that was authorized to be seen by one program's cleared personnel is now reachable, through the AI system's own retrieval layer, by personnel authorized only for the other.

This is not a hypothetical edge case for a firm with multinational operations. It is close to the default failure mode, because the entire value proposition of a unified AI assistant is that it retrieves broadly across an organization's knowledge base to give a useful answer. An assistant that is good at its job is, by construction, good at surfacing information the requester was not supposed to see, unless the system was architected from the outset to know which program, which jurisdiction, and which clearance a given piece of data belongs to, and to enforce that partition at retrieval time rather than trusting a downstream reviewer to catch the leak.

Why "one deployment, role-based access" is not the same architecture

Enterprise AI deployments typically handle sensitive-data segregation with role-based access control layered on top of a shared backend: everyone's data lives in the same index, and permissions determine what a given query is allowed to surface. That model is adequate for most corporate confidentiality problems. It is a poor fit for export control, because export control is not a permissions question in the enterprise-IT sense. It is a jurisdictional one. The relevant boundary is not "which employees are cleared to see this" but "which legal regime governs this data, and does moving it into a shared system, even one gated by permissions, itself constitute an unauthorized transfer, independent of who subsequently queries it."

A role-based system that stores ITAR-controlled and foreign-partner- controlled data in the same underlying store, differentiated only by an access-control layer sitting in front of it, has already commingled the data at the infrastructure level. Whether that commingling itself violates either jurisdiction's controls is a legal question a firm's export counsel needs to answer directly, not a question an AI vendor's access-control marketing can answer on the firm's behalf. The more defensible starting position, in most cases, is architectural separation strict enough that the question does not need to be litigated after the fact.

What sovereign infrastructure needs to look like at multinational scale

For a firm operating across jurisdictions, the AI infrastructure question is not "on-premises versus cloud." That part of the decision is usually settled once ITAR, EAR, or an equivalent allied-country control regime is in scope at all. The harder question is how many separate sealed environments the firm needs, and where the boundaries between them fall.

The pattern that tracks the underlying legal structure is one sealed environment per jurisdictional scope, not one sealed environment per site or per business unit. A U.S. facility and a European facility working on the same co-development program under a technical assistance agreement may be able to share an environment scoped to that agreement's terms. A U.S. facility working on a purely domestic program and a separate facility working on a foreign military sales program for a third country almost certainly cannot, even if both facilities belong to the same corporate entity, because the controlling question is what each program's technical data is authorized to touch, not what the org chart says. Getting this boundary wrong in either direction has a real cost: too coarse, and the firm recreates the commingling problem inside its own infrastructure; too fine, and every program pays for a fully isolated stack it may not need, which is its own kind of institutional pressure toward quietly recombining environments to save cost. That's exactly the pressure a compliance architecture should be designed to resist rather than accommodate.

Within each sealed environment, the same access, logging, and personnel- screening discipline export-controlled programs already practice applies without modification. An AI system does not relax the requirement that only authorized, appropriately-nationality-screened personnel query controlled technical data, it just needs to be built to enforce that distinction rather than assume every authenticated user inside the environment is equally authorized. What changes at multinational scale is the number of environments a firm needs to stand up and keep genuinely separate, and the discipline required to resist collapsing them for convenience.

Where this fits Element 31's approach

This is the specific problem Element 31's sealed appliances are built to be deployed against: Forge and Czar are physically isolated appliances by design, which means a multinational firm can stand up distinct, non-networked instances scoped to each jurisdictional boundary its programs require, rather than relying on logical separation inside a shared platform to do work that a legal regime expects a physical boundary to do. A U.S.-only program and an allied co-development program can each have hardware that has no network path to the other, which answers the segregation question the way regulators actually ask it, not "who has permission to query this," but "can this data physically reach that environment at all."

For firms whose structure is more particular than the standard deployment covers, a joint venture with a specific partner, a facility operating under a bespoke technical assistance agreement, a workload that needs to be scoped to one program and one buyer rather than one general product line, Chassis exists to build hardware to that specific deal's requirements rather than asking the firm to fit its jurisdictional boundaries around a fixed product shape.

None of this substitutes for the underlying compliance work a multinational defense firm's export control function already owns: classifying technical data correctly under each applicable regime, screening personnel by nationality and program access, and maintaining the paper trail a regulator will eventually ask for. What sealed, jurisdiction-scoped infrastructure does is make sure the AI systems the firm's engineers use every day are drawn correctly along the same lines its compliance program already depends on, instead of quietly redrawing them, one convenient cloud query at a time.