DFARS 252.204-7012, NIST SP 800-171 Rev 3, and CMMC 2.0 turn AI tooling into a controlled-data problem. Cloud AI vendors solve part of it contractually. Self-hosted on a DGX Spark solves it architecturally. Here is the scoping conversation for small-to-mid US defense contractors.

Sovereign AI for Defense Contractors

9 min read
authoritysovereign-ai

The short answer for a small-to-mid US defense contractor: if your contracts contain DFARS 252.204-7012, you already owe NIST SP 800-171 controls on every system that touches Covered Defense Information (CDI). Pasting CDI into a cloud AI chat is a covered-system event, and most consumer AI services cannot satisfy the safeguarding requirement. Self-hosting an open-weights model on a DGX Spark inside your existing 800-171 boundary keeps the AI on the right side of the line. Cloud AI vendors with FedRAMP High or DoD IL5 authorizations can also be correct answers, with caveats this article will walk through.

Quick Take

  • DFARS 252.204-7012 requires “adequate security” on contractor systems with CDI and rapid (within 72 hours) reporting of cyber incidents to dibnet.dod.mil. Adequate security defaults to NIST SP 800-171 plus FedRAMP Moderate (or equivalent) for any cloud services in scope.
  • NIST SP 800-171 Revision 3 (final, May 2024) is the current revision. Many DoD contracts still flow Rev 2; check the clause language in your specific award.
  • CMMC 2.0 is in the rulemaking phase that ties the certification to contract awards. 32 CFR Part 170 (the program rule) was published in the Federal Register on 2024-10-15 and the implementing DFARS clause (252.204-7021) is being phased into contracts.
  • ITAR technical data has an end-to-end encryption carve-out (22 CFR 120.54, effective 2020) that allows cloud storage and transmission when encryption keys are not shared with the cloud provider. Most consumer AI services do not satisfy this; they need the plaintext to run the model.
  • The sovereign answer: keep the model and the inference inside your existing 800-171 enclave. A DGX Spark on the same VLAN as your CUI workstations is one piece of hardware to enumerate in your System Security Plan instead of a new vendor relationship to document, assess, and renew.

What the regulations actually require

Four public documents define the perimeter.

DFARS 252.204-7012, “Safeguarding Covered Defense Information and Cyber Incident Reporting.” The clause requires the contractor to provide “adequate security” on covered contractor information systems, which the clause defines as NIST SP 800-171 (with cloud services additionally meeting at least FedRAMP Moderate baseline). It also requires the contractor to report cyber incidents within 72 hours, preserve system images for at least 90 days, and flow the clause down to subcontractors handling CDI. The clause text is on acquisition.gov.

NIST SP 800-171 Revision 3, “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations,” final on 2024-05-14. The publication is on csrc.nist.gov. Revision 3 reorganizes the families and tightens several controls; many older contracts still reference Revision 2, so the operative version is whatever your specific contract clause cites.

CMMC 2.0 program rule, 32 CFR Part 170, published in the Federal Register on 2024-10-15. The rule establishes the three-tier model (Level 1 self-attestation, Level 2 third-party for most CUI contracts, Level 3 government-led). The acquisition-side clause (DFARS 252.204-7021) is the one your contracting officer will write into the award when the rollout reaches your tier.

ITAR end-to-end encryption carve-out, 22 CFR 120.54 (effective 2020-03-25). Technical data may be stored or transmitted in cloud environments when end-to-end encrypted to a FIPS 140-2 (or 128-bit equivalent) standard, provided the cloud provider does not hold the decryption key. Cloud AI inference fails this test by construction: the model needs plaintext to produce output. ITAR-controlled technical data into a consumer AI chat is an export-control problem regardless of where the cloud vendor’s servers sit.

The other two documents you will hear named: DFARS 252.204-7012 sub-clauses on cloud services, and the 800-171 self-assessment score submission to SPRS (the Supplier Performance Risk System). The DFARS clause set has been reorganized in 2026 (252.204-7019 retired, 252.204-7020 renumbered into the new DFARS Part 240), so check the current clause numbers against your latest award.

Cloud AI versus self-hosted, in DFARS terms

Two valid answers exist for a defense contractor that needs AI tooling. The choice depends on workload size, contract velocity, and operational appetite.

Authorized cloud path. A FedRAMP High or DoD IL5 authorized AI service can be in scope for CUI and (at IL5) NSS-adjacent workloads. The contractor inherits a portion of the vendor’s authorization boundary and documents the remaining customer responsibilities in the SSP. The path works when the contract permits authorized cloud and the vendor offering covers the model family the contractor needs. Pricing is higher than consumer AI and provisioning is slower.

Self-hosted on-premises path. The contractor runs the model on hardware inside the existing 800-171 enclave. The boundary is the contractor’s own facility; no new vendor authorization is involved. The contractor takes on the operational responsibility (patching, monitoring, incident response) that the cloud vendor would otherwise carry. Pricing is a hardware capex plus internal labor; no per-token billing.

The self-hosted path is the better fit for small-to-mid contractors whose CDI volume does not justify a FedRAMP-tier vendor contract, whose IT operations team already manages a 800-171 enclave, and whose contracts include ITAR technical data that the cloud path complicates. The cloud path is the better fit for contractors with thin internal IT, contracts that already authorize a specific cloud vendor, and workloads that benefit from elastic scale.

For the broader cost framing across both paths, see Self-Hosted AI vs Cloud APIs: Real Total Cost. For the architectural patterns that make the on-premises path operable, see The Sovereign AI Stack in 2026.

What a defense-contractor deployment looks like

The deployment shape for a 50-to-500-person prime or sub with one DGX Spark inside its existing 800-171 enclave.

Placement and segmentation. The Spark sits on the CUI VLAN. Outbound traffic is restricted to internal services (the contractor’s identity provider, log aggregator, and update mirror). No traffic to OpenAI, Anthropic, or any other model vendor. The enclave’s existing firewall and IDS cover the Spark by default.

Identity and access control. Inferences are authenticated through the contractor’s existing IAM (typically Active Directory or Entra). Access to the AI is scoped the same way access to CUI workstations is scoped, with the same role definitions and the same offboarding flow.

Audit logging. Every inference is logged: which user, which model, prompt fingerprint (a hash, not the plaintext, where the prompt is itself CDI), response fingerprint, timestamp. The log ships to the contractor’s existing log aggregator under the same retention policy as workstation logs. The pattern overlaps with the file-integrity-monitoring approach in AIDE + Tripwire for AI Boxes: When File Integrity Matters.

Models. Open-weights at the 70B-to-120B-parameter range, quantized to NVFP4 to fit a single Spark’s unified memory. Qwen 3.6 PrismaQuant is the primary; the model selection rationale is in Mistral Small 4 vs Qwen 3.6 vs GLM 5 on DGX Spark.

Workloads. Proposal drafting against past-performance corpora, RFP shred-and-respond, technical-document Q&A, contract-clause review. None of these is a decision-of-record workload; the AI assists humans who own the output. That framing matters when the SSP describes the AI’s role inside the enclave.

Incident response. Cyber incidents touching the Spark get the same 72-hour DIBNet report path as any other CUI system. The Spark is enumerated in the asset inventory and in the SSP; an incident there is in scope for DFARS 252.204-7012 reporting by construction.

How CMMC Level 2 changes the conversation

For contracts that will require CMMC Level 2 (the typical CUI tier), the assessment is performed by a Certified Third-Party Assessor Organization (C3PAO). The Spark needs to fit inside the assessment boundary like every other in-scope system.

What I would prepare for a Level 2 assessment, based on the public assessment guides but not from a completed-assessment war story.

The hardware inventory entry. Make/model, location, network segment, business owner, system owner. Boring; required.

The data-flow diagram update. The Spark consumes prompts and produces responses; both can contain CUI. The DFD has to show the Spark as a CUI processing system with the same controls as any other CUI processing system.

The SSP narrative for the new system. Which 800-171 controls apply, how they are implemented on the Spark, which are inherited from the enclave, which require system-specific evidence (typically AC, AU, IA, SC).

The POA&M (if any). Gaps are honest. A gap with a closure date is acceptable; a gap that the assessor finds first is not.

The training-data question. If the model was trained on data that includes export-controlled material, the model weights themselves may be a compliance question. The pragmatic path is to use open-weights models from vendors whose training corpora are documented and to avoid fine-tuning on CUI without separate counsel review.

This section is the “plan, not war story” disclosure. I have not personally taken a Spark through a C3PAO assessment yet. The pattern above is the one I would propose, validated against the public CMMC assessment guides, but the first contractor to do this will find the surprises.

What this article got wrong on the first pass

The earlier draft treated CMMC 2.0 as a single fixed target. The reality in 2026 is that the rule is rolling into contracts in phases, the DFARS clause set has been reorganized, and the operative compliance posture for a specific contractor depends on which clauses appear in which awards. I cut a paragraph that flatly said “all CUI contracts now require Level 2 certification by 2026.” The accurate statement is that the program is being phased in via DFARS 252.204-7021 and individual contracting officers determine when the clause appears in a specific award.

The lesson generalizes. Compliance writing that hardens a moving regulation into a single date is wrong the day it ships. The article now describes the framework and points the reader at the specific clauses to check in their own contracts.

Where this fits

For the broader sovereignty framing, see What Sovereign Actually Means in 2026. For the regulated-industries pattern that shares most of this article’s structure, see Sovereign AI for Healthcare: GDPR, HIPAA, and the DGX Spark. For the engagement model and pricing, see How I Priced Sovereign AI Consulting. For the systemd patterns that make the deployment operable day-to-day, see systemd Patterns for Self-Hosted AI Services.

Book a Sovereign Deployment consultation

If your contracts include DFARS 252.204-7012 and your team is evaluating AI tooling against the 800-171 control set, the Sovereign Deployment engagement is the structured path. The Stack Audit (€450, two hours) produces a written recommendation that names the controls in scope and the deployment shape that fits your existing enclave. If the recommendation is to proceed, the deployment work follows at €2,400 per day; if the recommendation is to wait, the audit fee is the only cost.

Contact details are in the footer (Nostr, email, GitHub).

DFARS compliance has always required the contractor to control where CDI goes. Self-hosted AI on a DGX Spark keeps it inside the boundary the contractor already controls. The cloud path can work too, with the right authorization. The wrong answer is the consumer-AI shortcut that none of these regulations contemplate.