Clarion Street

Local Does Not Mean Compliant: NDAA §1532 and the Model You Downloaded

·10 min read

Most of this year’s argument about AI and controlled unclassified information has been about location. Put the model inside your boundary, keep the prompts off a vendor’s servers, and the exposure goes away. I have made that argument on this site, and I still think local inference is the right architecture for CUI work.

It stopped being the whole compliance story in December. Section 1532 of the FY2026 NDAA tests where the model came from rather than where it runs, and on October 20 DHS applied the same logic to federal civilian systems. A contractor can now run a model on its own hardware, inside its own system security plan boundary, and still be using something the statute bars from contract performance.

What section 1532 says

Public Law 119-60 was signed on December 18, 2025. Section 1532(a)(3)(A) gives contractors thirty days from enactment and then the rule: no contractor may, “during the period of performance of such contractor under a contract with the Department of Defense, use covered artificial intelligence with respect to the performance of a contract with the Department.” That landed on January 17, 2026. The words cloud, server, network, and deployment appear nowhere in the section.

“Covered” is defined in 1532(c)(2), and it is a short list: any AI, or successor AI, developed by the Chinese company DeepSeek, or any AI developed by High Flyer, by an entity High Flyer owns, funds, or supports, or by an entity in which High Flyer holds at least a 20 percent direct or indirect stake. The definition turns on developer lineage, not on capability, data handling, or country of origin as a general test.

One overstatement is in circulation and worth correcting. Section 1532 also defines a wider category, “covered artificial intelligence company,” built from the Commerce Consolidated Screening List, the Section 1260H civil-military fusion list, covered-nation domicile, and unmitigated foreign ownership or control. Read the definitions together and it looks as though any model from a listed company is now barred. The contractor prohibition for that wider category is conditional. Section 1532(a)(2) directs the Secretary to “consider issuing” department-wide guidance, and 1532(a)(3)(B) bars contractor use only “if the Secretary of Defense issues guidance described in paragraph (2).” I found no public sign that such guidance has issued, and Petronella’s October 10 writeup says the same. Treat the wider category as something to watch rather than a live bar.

King & Spalding’s January alert reads the prohibition as reaching subcontractors too. The enacted text says “no contractor” and never uses the word subcontractor, so I would not settle that from the statute alone. If you write flow-down language now you will not have to renegotiate it later.

The waiver is the government’s to grant

Section 1532(b) lets the Secretary waive a prohibition case by case, and only for four purposes: scientifically valid research, evaluation, training, testing or other analysis needed for national security, counterterrorism or counterintelligence or other operational military activity supporting national security, and mission critical functions. A waiver carries risk-mitigation steps with it. None of those four describes ordinary engineering work on a contract, and a waiver is an affirmative government decision rather than a self-declared exception. I have not found public data on how many have been granted.

The same clock bound the department itself. Section 1532(a)(1) required the Secretary, within those same thirty days, to require the exclusion and removal of covered AI from DoD’s own systems and devices. The department wrote itself the deadline it wrote for contractors.

What moved on October 20

DHS published a notice of order on October 20 (91 FR 66346, Docket DHS-2026-0628) under the Federal Acquisition Supply Chain Security Act. The summary paragraph does two things. It excludes IT products and services “developed by Hangzhou DeepSeek Artificial Intelligence Co., Ltd (DeepSeek), to include affiliated entities” from federal civilian agency procurements, and it removes “all DeepSeek and DeepSeek-affiliate products, and third-party products and services developed using DeepSeek implementations, from civilian agency information technology.”

The second clause is the one to read twice. It reaches past DeepSeek’s branded tools to “third-party products and services developed using DeepSeek implementations.” The notice does not say how much of an implementation has to be DeepSeek’s before a product falls inside that phrase, and the regulated object is a product or service in civilian agency IT, not the company that sells it. A US vendor with a DeepSeek dependency may be inside the removal language, depending on the implementation and on how the buying agency reads it. Anyone selling into civilian agencies has to be able to answer that question now, and the notice does not settle it for them.

It applies to federal civilian agencies, so DoD is governed by the statute rather than this order, and it creates no obligation on contractors either way. It is also not a ban on private or consumer use.

I went looking for an implementing clause and came back empty. The Defense Acquisition Regulations System has published 40 documents in the Federal Register since January 1, 2026, and phrase searches of that set return nothing for “artificial intelligence,” “DeepSeek,” “covered artificial intelligence,” or “1532.” Across every agency, the phrase “covered artificial intelligence” appears in zero documents, and “DeepSeek” appears in exactly one, this DHS notice. Those are query results from October 23, 2026, and a query can miss a rule that words itself differently. Section 1532 also gives the Secretary a route through department-wide guidance, so the next move in this area may never appear as a DFARS case at all.

Where local hosting stops helping

Running the model yourself answers two of the three hops in the data path, transmission and retention. The October 18 post walks them and I am not going to re-derive them here. Neither hop is what Section 1532 asks about, and neither is what the DHS order asks about.

The unresolved case is a fine-tune. Take DeepSeek weights, fine-tune them in the United States, run the result on your own GPU inside your own boundary. The data problem is solved. The statute reaches “any artificial intelligence, or successor artificial intelligence, developed by DeepSeek,” and successor is not defined anywhere in the section. I could not find an agency interpretation that resolves whether a derivative fine-tune is a successor, and the secondary sources I read do not resolve it either. My own reading is that the phrase exists to stop exactly that laundering, so I would treat a fine-tune of covered weights as covered until someone with authority says otherwise. That is a judgment, not a holding, and counsel gets the final word.

The artifact is an inventory

The artifact an assessor can check is a list of models with lineage attached. A network diagram answers a different question. Four fields carry most of the weight: who developed the base weights, under what license you received them, what you fine-tuned from and on what data, and where the checkpoint file came from, with a hash to tie your copy to a published release.

I did not invent that list from first principles. Section 1533 of the same law, which gets less attention, directs the Secretary to stand up a CDAO-led cross-functional team and build a standardized assessment framework for AI models the department uses. The required contents of that framework include “requirements for documentation of the development” of AI models, along with procedures for testing and validating them. The deadlines are unhurried: the team by June 1, 2026, the framework by June 1, 2027, and assessments of major AI systems by January 1, 2028. None of it binds a contractor. It does tell you what the government believes a model assessment contains, and documentation of model development made the list.

It also tells you what CMMC is not. Petronella makes the point that neither 32 CFR Part 170 nor NIST SP 800-171 has an AI-origin rule, and my reading of the assessment scope agrees. This restriction arrives through contract performance, not through your assessment, which is why “we run it locally” answers a question neither instrument asked. “Here is who developed the weights, here is the license, here is the checkpoint hash, here is what we fine-tuned from” answers the question both of them asked.

What you would replace it with

The replacement path got easier in April. Gemma 4 shipped on April 2 under Apache 2.0 in four sizes, and Google’s own framing is “breakthrough capabilities made widely accessible under an Apache 2.0 license.” The unquantized bfloat16 weights fit on a single 80GB H100, and quantized builds run on consumer cards.

For a contractor, Apache 2.0 means a legal review against a standard license instead of a vendor terms-of-use document with its own prohibited-use policy. Swapping a covered model for an open one is now mostly a licensing and operations exercise. Mostly, because the operational part is real: someone has to benchmark the replacement, rewrite prompts and system messages, and rerun whatever evaluation you rely on. In my judgment that is weeks of work for a competent engineer, not a research program.

What I would do this quarter

  1. Inventory every model your teams can reach. Include the ones inside tools you bought rather than built, because a coding assistant with a pluggable backend is the easiest way to end up running weights nobody chose on purpose.
  2. Attach the license, the fine-tune lineage, and the checkpoint hash to each entry. A model card from the vendor is not that record, though it can seed it.
  3. Require the same list from subcontractors and from any tool vendor whose product touches contract performance. The prime will ask, and the answer is cheaper to build now than under a delivery deadline.

Bottom line

Local hosting remains the right architecture for CUI, for the reasons the October 18 post gives, and it was never the compliance claim. Section 1532 attaches to model lineage, has been in force since January 17, 2026, and names DeepSeek and High Flyer in the statute rather than deferring to a list. The DHS order published October 20 carries the same reasoning to the civilian side and reaches third-party products built using DeepSeek implementations, not only DeepSeek’s own tools. The contractor prohibition over the wider “covered artificial intelligence company” category waits on guidance the Secretary was only told to consider, and I could find no DFARS clause implementing the section at all, so the watch list is that guidance and that clause. Until one of them lands, the thing to build is a model inventory an assessor can read, because origin of the weights is the question both instruments actually ask.

Sources

  1. Public Law 119-60, National Defense Authorization Act for Fiscal Year 2026 — GPO, enacted December 18, 2025. Sections 1532 and 1533 read from the enrolled text at 139 Stat. 1157-1161.
  2. Notice of Order Regarding Exclusion and Removal of DeepSeek Products From Federal Civilian Executive Branch Information Technology Systems and Procurements — DHS, 91 FR 66346, Docket DHS-2026-0628, October 20, 2026. The signed order is an image appendix in the published document, so the quoted language comes from the department’s summary paragraph at 91 FR 66346.
  3. FY 2026 NDAA: Domestic Sourcing, Artificial Intelligence, Cybersecurity, and Acquisition Reforms — King & Spalding, January 9, 2026
  4. DeepSeek and the FY2026 NDAA: What DoD Contractors Need to Know — Petronella Technology Group, October 10, 2026
  5. Gemma 4: Byte for byte, the most capable open models — Google, April 2, 2026

Earlier coverage on this site: The Prompt Is Now a Data Channel (October 18, 2026) on the three hops and the deployment patterns, and CMMC for AI: NDAA Sections 1512 and 1513 (September 10, 2026) on the statutory groundwork this section sits beside.