This page is practitioner guidance on deployment mechanics, not legal advice — involve your counsel or DPO for decisions about your specific obligations.
Defence AI deployment means running models inside the accredited enclave that already holds the data, rather than sending that data to a commercial API. For most defence organisations this resolves to open-weight models on accredited on-premise or government-cloud infrastructure at the appropriate impact level, plus a genuinely disconnected edge tier for platforms and forward elements that cannot assume a link. The technical work is unremarkable; the difficulty is accreditation, provenance, and export-control awareness in model sourcing.
Why this is hard
Mission data cannot traverse a commercial API, so the tools everyone else uses are simply unavailable.
Connectivity at the edge is contested, intermittent, and sometimes deliberately absent — cloud inference assumes none of that.
Model provenance is a supply-chain question here, and "we downloaded it from a public hub" is not a provenance answer.
What the deployment gives you
Inference inside the accredited boundary
The model runs at the impact level where the data already lives, so no new cross-domain flow is created. The AI system inherits the enclave's existing accreditation posture instead of opening a fresh boundary discussion.
Edge inference that assumes no link
A compact model on a ruggedised workstation or embedded GPU keeps working when the connection is degraded, denied, or intentionally silent. Sizing follows the platform power and thermal envelope, not the datacentre catalogue.
Provenance recorded, not assumed
Weights hashed, scanned, and version-pinned on the connected side, with the record following the artefact into the enclave. Publisher jurisdiction, licence terms, and export-control posture reviewed before anything is staged.
Defence-in-depth alignment
Identity from the enclave directory, least privilege on the retrieval corpus, full audit of prompts and completions, and no egress from the inference host — controls your assessors already recognise, applied to one more system.
Two tiers: the enclave and the edge
Defence deployments almost always need both, and they are sized very differently. The enclave tier is a normal GPU deployment inside an accredited boundary. The edge tier is a much smaller model on constrained hardware whose defining requirement is that it never expects a network.
Size the edge tier to the platform, not the model you wish you could run — power, thermals, and shock envelope decide this before capability does.
Treat model artefacts as a supply-chain item with a recorded publisher, licence, hash, and review date, the same as any other dependency.
Keep the human decision-maker in the loop by design. These systems support analysis and staff work; they are not the place for autonomous consequential action.
Plan the update cadence around the transfer procedure that already exists, rather than proposing a new pathway across the boundary.
Review licence field-of-use terms specifically — some open model licences carry acceptable-use restrictions that a defence programme has to read closely.
What you have to satisfy
DoD CC SRG IL5 / IL6 — Impact levels: IL5 covers controlled unclassified national-security information; IL6 covers classified up to SECRET. The level sets where inference may run and who may operate it.
ITAR / EAR — Export control: Technical data and some software are controlled. Model sourcing, foreign-national access to the enclave, and cross-border support all need review with your export-control officer.
NIST SP 800-171 — CUI in nonfederal systems: The baseline for defence contractors holding controlled unclassified information; isolating inference keeps the AI system inside an already-assessed boundary.
NIST SP 800-53 SC-7 — Boundary protection: The control assessors examine for enclave isolation — a documented, monitored transfer path rather than an ad-hoc one.
Models that fit this deployment
Model
VRAM (Q4)
Runs on
Context
License
Qwen 3 14B Edge tier — 12 GB, ruggedised — Fits an embedded or mobile GPU envelope while still handling summarisation and structured extraction. ollama pull qwen3:14b
Deploying AI inside an accredited or disconnected environment?
We help defence organisations and their suppliers architect AI that runs where the data already is — enclave sizing, edge hardware selection within real power and thermal envelopes, model provenance review, and the documentation your accreditation process expects. Vendor-neutral and practitioner-level.
For unclassified, non-sensitive administrative work, sometimes — several providers hold government authorisations at the lower impact levels. For mission data, controlled unclassified information, or anything classified, the answer is generally no: the data cannot leave the accredited boundary, and an authorisation held by the provider does not transfer to your use case. That constraint, not model quality, is what pushes defence deployments toward open weights on infrastructure inside the enclave.
What do IL5 and IL6 mean for an AI deployment?
They are impact levels from the DoD Cloud Computing Security Requirements Guide that classify the sensitivity of the information a system handles. IL5 covers controlled unclassified information including national-security systems; IL6 covers classified information up to SECRET. For an AI deployment they determine where the inference may physically run, which providers or facilities are eligible, who may administer the system, and how the boundary is monitored. You deploy at the level of the data the model will touch, including anything reachable through retrieval.
How do you run AI at the tactical edge with no connectivity?
By putting a small model on hardware that goes with the platform and never expecting a link. A 12–14B-class model quantised to 4-bit fits a 12 GB embedded or mobile GPU and handles summarisation, structured extraction, translation, and question-answering over a local corpus. The engineering constraints are power draw, thermal envelope, and physical robustness rather than benchmark scores — and the operational constraint is that the model, its corpus, and its updates all have to be staged before deployment.
Do export controls affect which models we can use?
They can, and this is worth raising early rather than late. The model file itself is generally published openly, but your fine-tuning data, prompts, and outputs may be controlled technical data, and controls also reach who may access the environment — foreign-national access to an enclave holding controlled data is a licensing question. Some open model licences additionally carry acceptable-use terms that interact awkwardly with defence work. Have your export-control officer review model sourcing and enclave access alongside the licence, before the programme commits.
Is an open-weight model secure enough for classified work?
The weights being public is not itself a vulnerability — the security property comes from the environment, not from the model being secret. What does require care is the artefact's integrity and provenance: verify hashes independently, prefer safetensors over pickle-based formats since loading the latter executes code, scan before staging, and pin versions. Treat the model as a third-party dependency entering an enclave, apply the supply-chain controls you already have for that, and the residual risk is comparable to any other imported software component.