Sovereign AI Readiness Assessment for Defense and Regulated Manufacturers
This free sovereign AI readiness assessment scores your organization across eleven dimensions of operating artificial intelligence against controlled data inside your own boundary, and it is built for defense contractors, aerospace suppliers, and regulated manufacturers subject to ITAR, CMMC, or national data sovereignty rules. It covers data classification, residency, model provenance, licensing, air-gapped operation, personnel access, retrieval entitlements, audit logging, in-boundary infrastructure, supply chain review, and governance ownership. Most organizations discover their gap is not technology but the absence of a documented data classification and an accountable owner.
1. Have you classified which data your AI workloads will process?
Sovereign AI decisions cannot be made until someone has determined whether the data is CUI, export-controlled, or classified.
2. Can you guarantee data residency for every component of the AI stack?
3. How is model provenance established and recorded?
Assessors increasingly ask where model weights originated and how their integrity is verified.
4. Have you reviewed model licenses for export and commercial restrictions?
5. Can the AI system operate without any internet connectivity?
6. Is access to the AI system restricted to appropriately cleared or authorized personnel?
For ITAR workloads this includes verifying US person status for anyone who can reach technical data through the assistant.
7. Does the retrieval layer enforce document-level entitlements at query time?
An assistant indexed across everything will surface restricted content to anyone who can ask a question unless filtering happens before the model sees candidates.
8. Is every inference request logged in a tamper-evident, auditable way?
9. Do you have in-country or in-boundary infrastructure capable of hosting the workload?
10. Is your AI supply chain, including hardware and software vendors, reviewed for foreign ownership or control?
Defense customers increasingly flow down FOCI and supply chain risk requirements to AI infrastructure, not just to end items.
11. Do you have an accountable owner and governance process for AI decisions?
How the assessment works
Eleven questions score zero to three for a maximum of thirty-three points, converted to a percentage across three bands: 0-39% is not ready, 40-69% is partially ready, and 70-100% is sovereign-ready. Score the state you could evidence to an assessor today, not the state described in a policy document. The questions deliberately mix governance and technical controls because sovereign AI fails on either. A perfectly air-gapped cluster with no retrieval entitlements will leak restricted drawings to unauthorized users, and a beautifully governed program with no in-boundary infrastructure cannot deploy at all.
What sovereign AI actually requires
Sovereignty is not simply keeping servers in your building. It means every path data can take stays inside a boundary you control and can prove to an assessor with evidence rather than assertion. That includes paths teams routinely forget, and the forgotten ones are what generate findings. We have reviewed deployments where the inference cluster was properly isolated while the observability agent shipped prompt samples to a vendor endpoint, and others where a model was air-gapped but its tokenizer downloaded configuration on first run. Enumerate every outbound connection the stack can make and justify each one before you call the deployment sovereign.
- Telemetry and crash reporting from AI frameworks and drivers, which frequently default to external endpoints.
- Model weight provenance with recorded checksums, since assessors now ask where the artifact came from.
- Retrieval-layer entitlements enforced at query time, not just permissions on the source repositories.
- Personnel access verification, because for ITAR workloads a query is potentially an export to whoever is asking.
Reading your band and sequencing the work
Sequence matters more than total score. Data classification and an accountable owner come first, because every subsequent decision depends on knowing what data is in play and who may approve deployments. Residency mapping and retrieval entitlements come second, since those are the controls most likely to generate findings. Infrastructure and model selection come last, even though they are the parts everyone wants to start with. Organizations that begin with hardware procurement consistently end up rebuilding, because the security boundary they should have designed first ends up dictating a different architecture than the one they bought.
How Netray delivers sovereign AI
Netray builds private AI for aerospace, defense, and electronics manufacturers where compliance is the design constraint rather than a review gate. We start with data classification and a control matrix mapped to your framework, then deploy open-weight models inside your boundary with permission-aware retrieval that inherits entitlements from SyteLine, LN, M3, ServiceMax, and your PLM system. Everything is logged to your SIEM, and we produce the evidence package your assessors and prime contractors ask for. For fully disconnected sites we deliver validated air-gapped update procedures so the system stays current without ever opening an external path.
Frequently Asked Questions
Is an AI query over export-controlled data considered an export?
It can be. If technical data controlled under ITAR is transmitted to a service where non-US persons could access it, that is a potential unauthorized export regardless of whether a human ever reads it. The same logic applies to an internal assistant that surfaces controlled drawings to an employee who is not a US person. This is why personnel access verification and retrieval-layer entitlements matter as much as where the servers physically sit.
Can we use commercial open-weight models in a controlled environment?
Generally yes, and most defense suppliers do. The requirements are provenance and licensing: download from a verified source, record the checksum, store weights in a format that cannot execute code, and have legal review the license for commercial and export restrictions. Some model licenses carry acceptable-use terms that conflict with defense applications, so the license review is not a formality. Document all of it in an internal model registry for assessors.
How do we keep an air-gapped AI system updated?
Through a documented, controlled transfer process rather than an ad hoc one. Stage model weights, container images, and package updates on a connected system in a lower enclave, scan and verify checksums, then move them across the boundary using your approved media or data diode procedure. Test the full update path before go-live, because the most common air-gap failure is a system that runs beautifully and then cannot be patched when a vulnerability is announced.
Get a sovereign AI control matrix and deployment roadmap mapped to your ITAR, CMMC, and customer flow-down obligations.
Related Tools
On-Prem AI Security Hardening Checklist
A practical control checklist for securing self-hosted language models, covering model provenance, network isolation, data governance, host hardening, and audit readiness.
On-Prem AIAI Data Center Power and Cooling Calculator
Convert GPU count and class into facility electrical load, required cooling capacity, and annual energy cost before you commit to an on-prem AI build.
On-Prem AIAI Model Selection Assessment
Score ten decision factors - data sensitivity, task complexity, volume, latency, and internal capability - to see whether a self-hosted open-weight model fits your workload.
Go Deeper
Air-Gapped LLM Deployment Patterns That Actually Work
Air-gapped LLM deployment patterns that work: offline model transfer, update workflows, monitoring without telemetry, and CMMC-ready architectures.
Enterprise GPU Cluster Planning for AI Workloads
Plan an enterprise GPU cluster for AI workloads: H100 vs L40S sizing, networking, power, cooling, and cost models for on-prem LLM inference and training.