ITAR AI Workload Compliance Assessment for Defense Manufacturers
This free ITAR AI workload compliance assessment scores your AI deployments across eight dimensions specific to defense manufacturers operating under export control obligations. It is built for facility security officers, export control compliance leads, and IT directors at companies handling technical data related to defense articles. Answer eight questions covering data classification, US persons access, infrastructure isolation, fine-tuning implications, and technology control plan coverage, and get a scored risk band with prioritized remediation steps. AI adoption is outpacing export control review at most defense manufacturers, and an unreviewed copilot or fine-tuning pipeline touching technical data is a real, not theoretical, compliance gap.
1. Have you formally classified whether any data feeding your AI systems constitutes ITAR-controlled technical data?
Technical data under ITAR includes information required for the design, development, production, or use of a defense article, which reaches far beyond drawings marked classified.
2. Does your AI infrastructure run entirely within a US-persons-controlled environment, with no foreign national administrative access?
3. Is your AI infrastructure physically and logically isolated from cloud regions or providers that could expose data outside US control?
4. Do you restrict AI model access by citizenship or export authorization at the identity layer, not just by network location?
5. Have you evaluated whether fine-tuning a model on ITAR technical data constitutes an export of that data to the model provider?
Sending technical data to a third-party model provider for fine-tuning or embedding, even a US-based one, raises real questions about who can access it and where processing occurs.
6. Is your GPU infrastructure and any remote vendor support covered by appropriate export-compliant agreements?
7. Do you maintain a technology control plan that explicitly addresses AI and ML systems?
8. Can you produce an audit trail proving no ITAR-controlled data left the authorized boundary through an AI system?
Why AI creates a new category of ITAR exposure
Technical data under ITAR covers information required for the design, development, production, or use of a defense article, a definition broad enough to include engineering drawings, test data, source code for controlled systems, and manufacturing process specifications. AI systems ingest exactly this kind of content for retrieval-augmented generation, fine-tuning, and embedding, often through pipelines built by engineering teams focused on functionality rather than export control. A cloud AI API processing that content, even briefly, can constitute a deemed export if the provider's infrastructure or support staff include non-US persons, regardless of intent.
- Fine-tuning on technical data sends that data to the model provider's training infrastructure, which may not be US-persons-only.
- Cloud AI support and infrastructure staff are rarely vetted for ITAR purposes by default.
- RAG systems that index engineering documentation create a new, often unreviewed, data flow.
- Agentic AI systems that call external APIs can inadvertently transmit technical data as part of tool use.
The eight risks this assessment measures
Each question maps to a specific ITAR and CMMC control area: data classification, US persons infrastructure access, physical and logical isolation, identity-layer citizenship enforcement, fine-tuning export analysis, vendor agreement compliance, technology control plan coverage, and audit evidence production. These map closely to the questions a DDTC compliance review or a prime contractor's supplier security assessment will ask, and answering them proactively is dramatically cheaper than answering them during an investigation.
How to read your score
Data classification is the foundation every other control depends on, so a low score there should be the first thing you fix regardless of your overall band. You cannot correctly scope infrastructure isolation or access control until you know which data flows are actually ITAR-controlled. The fine-tuning question deserves particular attention because it is the newest and least understood risk area: many teams have not considered that sending technical data to a third-party model provider for fine-tuning, even a well-regarded US company, raises the same export questions as sending it to any other subcontractor.
How Netray builds ITAR-compliant AI infrastructure
Netray designs on-prem AI infrastructure specifically for aerospace and defense manufacturers where ITAR and CMMC compliance is a condition of doing business, not an afterthought. We deploy open-weight models entirely inside your authorized boundary, with no data ever reaching a third-party model provider, build identity-layer access controls tied to citizenship and export authorization, and produce the audit evidence your compliance team and your customers' supplier security teams will actually ask for. We also help update technology control plans to explicitly cover AI systems, closing a gap most defense manufacturers currently have.
Frequently Asked Questions
Does using a US-based AI vendor automatically satisfy ITAR requirements?
No. A vendor being US-based does not guarantee their infrastructure, support staff, or subcontractors are entirely US persons, and it does not guarantee your data stays within the specific authorized boundary your program requires. You need contractual and technical verification of infrastructure location, support staff citizenship, and subprocessor use, the same diligence you would apply to any other subcontractor touching technical data.
Is fine-tuning a model on our own technical data considered an export?
It can be, depending on where the fine-tuning occurs and who can access the data during that process. Sending technical data to a third-party model provider's training infrastructure, even a domestic one, may expose it to personnel or systems outside your authorized boundary. This is an area where formal review with export control counsel is warranted before starting a fine-tuning project on technical data, rather than assuming a US vendor makes the question moot.
Do we need a separate technology control plan for AI systems?
Not necessarily a separate plan, but your existing technology control plan should explicitly address AI and ML systems as a named category, covering data flows, access controls, and boundary definitions specific to how AI ingests and processes technical data. Many technology control plans predate AI adoption and implicitly assume data flows that no longer match reality once a RAG system or copilot has been added to the environment.
What is the fastest way to reduce ITAR exposure in an existing AI deployment?
Start by classifying exactly which data sources feed your AI systems and whether any constitute technical data. That classification determines everything else: whether infrastructure isolation is required, whether identity-layer citizenship controls are needed, and whether fine-tuning pipelines need to move on-prem. Skipping classification and jumping straight to infrastructure changes often means redoing the work once the actual data flows are understood.
Get an ITAR compliance review of your AI workloads and a remediation plan mapped to your technology control plan.
Related Tools
AI Data Sovereignty Risk Assessment
Score your organization across eight dimensions of AI data sovereignty risk, from inference location and encryption key custody to subprocessor visibility and audit readiness.
On-Prem AIAir-Gapped LLM Deployment Checklist
A practical control checklist for deploying and maintaining large language models in a fully air-gapped environment, from initial staging through ongoing patching and drift detection.
On-Prem AIAI Audit Trail Readiness Checklist
A practical control checklist for building AI audit trails that satisfy compliance assessors, covering request-level logging, log integrity, identity evidence, and model lineage.
Go Deeper
ITAR and CMMC Handling of AI Workloads
How ITAR and CMMC apply to AI workloads: technical data boundaries, CUI handling, assessed environments, and where on-prem AI is the only option.
Securing Model Weights in the Enterprise
Secure model weights end to end: custody controls, encryption at rest, access policies, and exfiltration prevention for regulated AI deployments.
EU AI Act Implications for On-Prem AI Deployments
EU AI Act implications for on-prem deployments: risk tiers, high-risk obligations, and how self-hosted models simplify enterprise compliance.