An engineering lead at a mid-size aerospace supplier asks a fair question: “Why can’t we just point a chatbot at our drawings and parts data like everyone else?” The demo took an afternoon. The model summarized a stack of legacy specs, drafted a supplier RFQ, and flagged three dimensioning errors a junior engineer would have missed. Everyone in the room wanted it shipped by Friday.
Then someone from the program office asked where the prompts were being processed. The honest answer was: a commercial cloud region, routed through a vendor’s API, logged somewhere for “abuse monitoring,” and possibly used to improve a model. Three of those drawings were marked as technical data under ITAR. One described a component on a controlled munitions list item. The demo didn’t just leak data — under the regulations, sending that drawing to a server a foreign national could administer is a potential export. No shipment. No data crossed a border. The act of putting controlled technical data somewhere an unauthorized person could access it is the violation.
That is the entire problem in defense AI, and almost none of it is about the model. The model is the easy part. The hard part is that your data carries legal weight, and the moment you hand it to a system you don’t control, you’ve made a compliance decision — usually without realizing it, and usually the wrong one.
This post is about deploying useful AI inside that constraint, not around it. None of this is legal advice; your compliance team and your contracting officer own the final call. But the architecture patterns below are what actually let teams ship.
Start with the data, not the model
Every serious defense AI decision starts by classifying what the model will touch. Not “is this sensitive” in a hand-wavy sense — what regulatory regime governs each input and output.
In practice you’re sorting data into a few buckets:
- ITAR-controlled technical data — drawings, specs, and documentation tied to items on the U.S. Munitions List. The binding constraint is access by U.S. persons only, including whoever can administer the infrastructure.
- CUI / Controlled Unclassified Information — the broad category CMMC is built to protect. Most of your contract performance data lives here.
- EAR-controlled data — dual-use technical data, often overlooked because it feels “commercial.”
- Genuinely uncontrolled data — marketing material, public specs, internal notes with no contractual sensitivity.
The mistake I see most often is treating this as a document-level problem when it’s actually a flow problem. A prompt that combines an uncontrolled question with one controlled drawing becomes a controlled prompt. A model output that synthesizes CUI is CUI. The classification follows the data through the system, and your architecture has to follow it too.
This is unglamorous work, and it determines whether anything else is legal. If you can’t say which buckets a feature’s inputs and outputs fall into, you are not ready to deploy it.
Where the data lives is the whole game
For controlled data, “data residency” isn’t a privacy nicety — it’s the wall the entire system stands on.
The practical landscape for a U.S. defense supplier:
- Commercial cloud (standard regions). Fine for uncontrolled data. Disqualifying for ITAR technical data and, in most readings, for CUI in a CMMC Level 2 context. The infrastructure can be administered by non-U.S. persons, and that alone is fatal for ITAR.
- Azure Government / GCC High. The default landing zone for CUI and ITAR workloads. Data residency in the continental U.S., screened U.S.-person operations personnel, and the compliance attestations (FedRAMP High, DoD IL levels) that your assessors will ask for by name.
- Sovereign or on-prem. For the most sensitive programs, or primes who simply won’t accept a shared-tenant cloud, the model runs inside infrastructure you physically control.
The AI angle adds a wrinkle most cloud guidance skips: the model endpoint has to live in the boundary too. It is not enough to store your drawings in GCC High if your application then calls a commercial model API to reason over them. The inference endpoint is part of the data flow. If your CUI leaves the accredited boundary to reach the model, you’ve broken the boundary, full stop.
This is why the availability of models inside Azure Government matters so much. When a capable model is hosted within the GCC High boundary, you can keep the controlled data, the application, and the inference all on the correct side of the wall. That single fact is what moved defense AI from “interesting but unshippable” to “deployable” over the past couple of years.
A note on “the model won’t train on it”
Vendors will reassure you that your data isn’t used for training. Take the reassurance, then ignore it as insufficient. Training is one risk. Residency, operator access, logging, and transit are separate risks a no-training promise does nothing about. For controlled data, a contractual promise from a commercial endpoint is not a substitute for an accredited boundary.
Control what the model can reach
Once the boundary is right, the next failure mode is over-broad access. Teams wire a model into a retrieval system pointed at “all the engineering data” because it’s easier than scoping it. Then the model cheerfully surfaces a controlled drawing to a user — possibly a foreign-national contractor — who had no business seeing it.
The model has no concept of need-to-know. You have to enforce it in the layer around the model.
What that looks like in a real system:
- Identity-aware retrieval. The user’s clearance, citizenship status, and program access gate what the retrieval layer is even allowed to return before anything reaches the model’s context. Filter at query time, not after generation.
- Per-document authorization that mirrors your existing controls. If a user can’t open a drawing in your PLM today, the AI must not be a side door around that control. Reuse the access model you already had assessed.
- Output classification and handling. A response built from CUI inherits CUI handling — banners, storage rules, transmission limits. Tag it at generation time and carry the tag downstream.
- Tool and action scoping. If the model can call tools — query a database, file a ticket, draft an email — each tool runs with constrained, audited permissions, never the model’s “ambient” reach.
The governing principle is old and correct: least privilege. The model gets exactly the access the current user is entitled to for the current task, and nothing wider. An AI assistant that can see more than the person using it is a data-spill incident waiting for a date.
Audit and traceability are not optional add-ons
CMMC and your DFARS obligations assume you can answer, after the fact, who accessed what and when. AI makes that question harder and more important, because the system is now generating derived artifacts from controlled inputs.
You want a complete, tamper-evident record of:
- Which user issued which prompt, under which authorization.
- Exactly which documents entered the model’s context for that prompt.
- What the model returned, and how that output was classified and handled.
- Every tool or system the model touched on the user’s behalf.
Build this from day one. Retrofitting audit logging onto an AI system that’s already in production is miserable, and it’s exactly the gap an assessor will find. The good news: most of the controls you need (centralized logging, immutable storage, access review) already exist in your accredited environment. Route the AI layer’s events into the same pipeline rather than inventing a parallel one.
There’s an engineering benefit too. A clean trace of “this answer was built from these three documents” is also how you debug a wrong answer and how you build the human reviewer’s trust. Provenance is a compliance requirement and a quality feature at the same time.
Keep a human between the model and controlled actions
For controlled data, full autonomy is the wrong default. Not because the model is incapable — because the consequences of a confident mistake on a defense program are not symmetric with the time saved.
The pattern that holds up: the model drafts and recommends, a qualified U.S. person reviews and commits. The AI compresses the analysis — pulling the relevant clauses, flagging the dimensioning conflict, drafting the supplier response. A human who is accountable and authorized makes the call that leaves the building.
Where the line sits depends on the action:
- Reading, summarizing, and drafting over CUI with proper boundaries — relatively low risk, faster review.
- Anything that transmits, exports, or commits controlled data externally — explicit human authorization, logged, every time.
This isn’t AI theater. A reviewer who rubber-stamps output adds no control. The human stays in the loop because they carry accountability the model structurally cannot — and on a controlled program, accountability is not something you delegate to a probability distribution.
The takeaway
Defense AI is a data-governance problem wearing a machine-learning costume. The model is rarely the hard part. The hard part is knowing what your data is, keeping it inside an accredited boundary with the inference endpoint in that boundary, scoping access to need-to-know, logging everything, and keeping an accountable human on the controlled actions. Get those right and you can ship genuinely useful tools — spec review, RFQ drafting, knowledge retrieval — without your AI initiative becoming an export-control finding.
What I’d push back on, gently: don’t let “compliance” become the reason to do nothing, and don’t let “innovation” become the reason to do something reckless. Both failure modes are common in this industry, and both are avoidable. The suppliers getting real value are the ones who did the boring classification work first and treated the boundary as non-negotiable.
If you’re weighing whether a specific workload belongs in GCC High, a sovereign setup, or fully on-prem, that’s a scoping conversation — the right answer depends on your contracts, your assessor, and your data, not on a blog post. If it’s useful to think it through with someone who’s built inside these constraints, a 30-minute call is enough to map the boundary before you write any code.
