A Program Leader's Guide to Sovereign AI for Defense

Sovereign AI for defense means running AI workloads on infrastructure that is controlled end to end — data residency on domestic soil, a supply chain with verified provenance, and no foreign government access to models, weights, or data. For a program leader, the question is rarely whether AI is useful, but which deployment posture keeps program data and models under control at the required impact level.

This guide is written for the people accountable for that decision: program directors, CIOs, CISOs, and procurement leads at agencies, primes, and Tier 2 and Tier 3 suppliers. It covers why public cloud is off the table for most defense data, the deployment options available at each sensitivity level, what sovereignty actually means in a defense context, how to spec these requirements in a contract, and a decision framework for choosing between on-premises, private cloud, and air-gapped environments.

Why public cloud is off the table

Most defense and aerospace programs handle at least one of three data classes, and each one has a specific reason commercial public-cloud AI cannot touch it:

• Controlled Unclassified Information (CUI). Established by Executive Order 13556, the CUI program standardizes how the executive branch handles unclassified information that requires safeguarding or dissemination controls. CUI covers a wide range of material — source and object code, technical data, business and financial data, law enforcement information, and personal privacy data. Federal contractors that process CUI on nonfederal systems must protect it under NIST SP 800-171.
• Classified information. National security information at the Secret level (and Restricted Data under the Atomic Energy Act) may only be hosted on environments authorized for DoD Impact Level 6 — in practice, DoD private cloud or dedicated classified clouds such as AWS Secret Cloud, which is accredited for DoD CC SRG Impact Level 6 and Intelligence Community Directive (ICD) 503 requirements and is authorized for data up to Secret.
• Export-controlled technical data. The International Traffic in Arms Regulations (ITAR), codified at 22 CFR Part 120, authorize the President to control the export and import of defense articles and defense services, with administration delegated to the Secretary of State. Technical data that supports defense articles is export-controlled, and exposing it to a foreign-national workforce or to infrastructure with foreign access rights creates a violation risk that no amount of contractual language fully eliminates.

On top of those data rules sits the National Industrial Security Program (NISP), established by Executive Order 12829 and implemented through the NISPOM (32 CFR Part 117). Industry organizations that hold a facility clearance and process classified work must operate in accordance with the NISPOM — a regime designed around physical, personnel, and information security controls, not around multi-tenant commercial SaaS.

There is also a supply-chain question. An AI model is only as sovereign as the pipeline that built it: the training data, the weights, the inference framework, the chips. When a program depends on a commercial API, each of those layers is operated by someone else, subject to someone else’s jurisdiction, terms of service, and change control. For the defense industrial base, that is a risk the enterprise must either accept consciously or eliminate by design.

Deployment options by sensitivity level

DoD’s cloud authorization regime is built around impact levels, defined in the DoD Cloud Computing Security Requirements Guide (CC SRG) and operationalized through DoD Instruction 8510.01 (the DoD Risk Management Framework), effective July 19, 2022. The CC SRG defines the levels a program will encounter:

• Level 4 — CUI that requires protection from unauthorized disclosure under EO 13556 or other mission-critical data. It may be hosted on shared or dedicated infrastructure, on-premises or off-premises, with strong virtual separation controls and jurisdiction restrictions.
• Level 5 — CUI requiring a higher level of protection, and the home for unclassified National Security Systems (NSS) because the FedRAMP+ control set includes NSS-specific requirements.
• Level 6 — Classified national security information up to Secret (and Restricted Data). Only DoD private, DoD community, or federal government community clouds that are stand-alone or connected to SECRET networks (for example, SIPRNet) are eligible, and physical separation from non-DoD, non-federal tenants is required.

The practical mapping for an AI program looks like this:

A few consequences follow from the table. First, the higher the impact level, the fewer eligible providers there are, and the more the program must build and operate the environment itself. Second, at IL6 and above, “cloud” means a government community cloud, not the public offerings most IT teams are familiar with. Third, some programs — particularly those handling Restricted Data or export-controlled technical data at scale — conclude that no external provider, however accredited, should host the workload, and choose a fully air-gapped, on-premises deployment instead.

What “sovereign AI” means specifically for defense

“Sovereign AI” gets used loosely in commercial writing. For a defense program, it has three concrete components:

Data residency. Data and model artifacts live on soil in the program’s home jurisdiction, inside infrastructure the program (or its government counterpart) can audit. The CC SRG encodes this directly: even at Level 4, cloud deployments must restrict the physical location of the information, and Level 6 hosting must meet strict facility and separation requirements under the NISP.

Controlled supply chain. Every layer of the AI stack — model weights, training data, framework code, inference software, and where relevant, the hardware — has documented provenance and a change-control path the program can inspect. In an air-gapped environment this means the update mechanism itself is part of the security design: models and dependencies are vetted, signed, and moved through the boundary on controlled media, never downloaded live.

No foreign access. Access to the data, models, and compute is limited to cleared, vetted personnel, and the infrastructure itself has no path — logical or physical — that gives a foreign actor access. At IL6, the CC SRG requires facility clearances and cleared personnel as part of the hosting arrangement.

DoD is already moving toward exactly this architecture. The 2018 DoD AI Strategy — “Harnessing AI to Advance Our Security and Prosperity” — directs the Department to accelerate AI adoption, deliver AI-enabled capabilities that address key missions, scale through a common foundation, and lead in military ethics and AI safety, with the Joint Artificial Intelligence Center (JAIC) as the focal point. The Chief Digital and Artificial Intelligence Office (CDAO), whose public site is ai.mil, now frames the effort as “AI Dominance” — accelerating adoption of data, analytics, and AI “from the boardroom to the battlefield” through a set of pace-setting projects. The signal for the defense industrial base is unambiguous: DoD will field AI, and the industrial base will be expected to support AI workloads at every impact level.

For a deeper look at the mechanics of the most demanding posture, see Air-Gapped LLM Deployment: The Complete Guide, and for the broader concept, What is Sovereign AI?. The requirements for regulated AI overlap heavily with the defense case, and the broader sector context is covered in AI in Aerospace and Defense and on the Aerospace & Defense industry page.

The procurement reality

Most defense AI buying happens through one of two doors, and each door has its own checklist.

Buying as a government program office. The DoD contract must state the required CMMC level. Under DFARS Subpart 204.75, contracting officers include the required CMMC level in the solicitation, and award eligibility is checked against the DoD’s CMMC status registry before a contract, task order, or delivery order is signed — an offeror without the required current CMMC status is not eligible. From 2028 onward, the clause is triggered whenever the contractor’s systems will process, store, or transmit Federal Contract Information (FCI) or CUI in contract performance, with the CMMC level mapped to the data being handled.

Buying as a prime or supplier. The vendor’s obligations flow down from the prime’s contracts, and the prime’s job is to spec them before the RFP goes out. A defense AI RFP that takes sovereignty seriously should require:

1. Deployment model, named and specific. Which impact level the offering supports, on which infrastructure, with which separation model (shared, dedicated, or air-gapped). “On-premises available” is not an answer; the buyer should see the target environment in writing.
2. Air-gap and egress proof. For air-gapped claims, the exact boundary: network interfaces disabled and documented, update mechanism, media control process, and how model updates cross the gap. A vendor that cannot describe its update path has no air gap, only a promise.
3. Model provenance. Where the weights came from, whether fine-tuning data is auditable, and the change-control and rollback process for model versions in production.
4. Personnel and clearance posture. Whether the vendor holds a facility clearance, how cleared access is granted, and how personnel screening aligns with NISPOM expectations.
5. Security attestations. FedRAMP (and FedRAMP+ at IL5), DoD Provisional ATO where applicable, CMMC status at the required level, and NIST SP 800-171 attestation for CUI on nonfederal systems.
6. Export control handling. How the offering handles ITAR-controlled technical data, and the vendor’s own export-control compliance posture.
7. Audit and incident flow. What the buyer can inspect, and how incidents are reported on the DoD timelines that the CC SRG and DIB cyber requirements impose.

The single most useful test in an RFP: ask the vendor to state, in one paragraph, what their infrastructure looks like on the day the contract is signed — location of compute, who can access it, how the model gets updated. Vendors with a real sovereign offering can answer precisely. Vendors selling a marketing term cannot.

A decision framework for program leaders

Work through five questions, in order:

1. What is the highest sensitivity of the data the model will touch? This question alone determines the eligible deployment set. Public data allows anything; CUI narrows the field to FedRAMP/IL4 or better; Secret narrows it to government community clouds or on-premises; air-gapped requirements narrow it to physically isolated systems.

2. Can the workload tolerate latency and capacity constraints? On-premises and air-gapped environments trade off against public infrastructure in raw compute availability. A program whose model runs nightly batch jobs has different constraints than one that needs inference at the edge of a live system.

3. Who operates the environment? On-premises deployments create an internal operating burden — hardware, networking, security operations, model ops. Private cloud transfers some of that to a provider under a service agreement. Air-gapped on-premises transfers the least, which is precisely the point, and it should be priced as an operating expense, not a license.

4. How do models and dependencies reach the environment? This is the question that separates real sovereignty from branding. Documented, signed, media-based updates through a controlled boundary are acceptable for air-gapped operations. Live downloads from a public registry are not, at any defense sensitivity level.

5. What does the contract require, and can the vendor prove it? Every requirement from the procurement section above should be a stated contract clause with an audit path — not a feature-list bullet. If a requirement cannot be verified after award, it was never really specified.

A common pattern in practice: unclassified CUI workloads (document review, code analysis, logistics optimization) run in an IL4/IL5 private cloud; the same models, or tuned variants, run in an air-gapped on-premises environment for classified or export-controlled work, with the model update pipeline treated as a controlled export. The two environments share the same governance model and the same vendor, which is what makes the program manageable as the workload grows.

For teams evaluating which deployment posture fits a specific workload — and how much it costs to run inference on your own hardware — book a technical walkthrough of sovereign AI deployments with the Shakudo team to work through the architecture with your data constraints in hand.

The strategic point for a program leader: sovereignty is not a feature a vendor adds to a cloud account. It is a deployment architecture chosen deliberately, specified precisely in the contract, and verified at audit. The programs that get it right will be the ones that can put AI to work on data no one else is allowed to see — at the same pace the DoD expects the industrial base to move.

Last verified: 2026-09-05