How the NDAA's AI supply chain rules create new compliance layers

The awkward part of the FY2026 NDAA for defense supply chains is that it is already law, while much of the machinery contractors normally wait for is still forming. That matters for defense supply chain teams: the useful question is no longer whether AI will be regulated in defense procurement, but which onboarding records, supplier attestations, ownership screens, tool controls, and audit evidence have to start changing before the DFARS clauses arrive.

The Act creates four compliance layers that should be kept separate in operating plans, even though they will eventually collide in the same procurement systems.

The Covered AI Ban Is an Ownership and Access Problem

Section 1532 is the sharpest obligation because it reaches past government acquisition offices and into contractor and subcontractor use. Summaries from KS Law and Freshfields describe the provision as prohibiting DoD, contractors, and subcontractors from using AI domiciled in China, Russia, North Korea, or Iran, as well as AI from entities on the Consolidated Screening List or the civil-military fusion list.[1][2]

That is not just a country-of-origin screen. The provision also includes a 20% indirect ownership trigger tied to entities connected with HighFlyer, the parent associated with DeepSeek, which means a supplier review that stops at the contracting entity’s legal name is not enough.[1][2] Investment chains, parent entities, beneficial ownership, and upstream control rights become part of AI tool diligence.

For supply chain operations, the first practical change is taxonomy. “AI vendor” is too narrow. The field structure needs to capture hosted tools, embedded AI features inside procurement or engineering platforms, API providers, model providers, development environments, data-labeling vendors, subcontractor-supplied AI outputs, and any AI capability bundled into a larger service. If the onboarding form only asks whether a vendor sells software, the answer will miss the products Section 1532 is trying to reach.

The second change is ownership diligence. A supplier attestation that says “not domiciled in a covered country” will not answer the 20% indirect ownership issue. Procurement systems need fields for parent entities, investment links, listed-party screening results, and refresh dates. The review also needs a way to flag ownership changes after award, because an AI service that cleared onboarding can become a problem when its capital stack changes.

The third change is subcontractor flowdown. Section 1532’s reach to contractors and subcontractors means prime contractors should expect to ask lower tiers for more than a generic compliance certification.[1][2] A useful flowdown will ask what AI tools are used to perform the work, whether any outputs enter contract deliverables, whether subcontractor personnel can use public AI tools on covered data, and how prohibited tools are blocked or segregated.

The waiver pathway should not be treated as an ordinary business exception. Freshfields describes a waiver mechanism, but available commentary supports a narrow reading rather than a routine procurement workaround.[2] A contractor that wants to rely on waiver availability still has to know which tool is in scope, why it is necessary, what alternatives were considered, what data it can access, and what compensating controls exist.

The hardest operating gap is employee-level use. A prohibited AI system does not need a purchase order to enter a program environment; it can arrive through a browser tab, a free account, a plug-in, or a developer’s API key. Containment.ai argues that this creates a real-time enforcement gap because hardware-style restrictions assume procurement visibility that AI tools often bypass.[5] That observation is useful, but it comes from a vendor with a commercial interest in data-boundary controls, so it should be treated as a prompt for control design rather than as independent evidence of how DoD will enforce the statute.

Waiting for a perfect clause before acting creates an evidence problem. Six months later, it is much harder to prove which browser tools were available, which API endpoints were called, whether contract data was pasted into a public model, and whether a subcontractor’s AI-generated work product relied on a prohibited service. The control set does not have to be elegant on day one, but it does need to distinguish approved AI, prohibited AI, unknown AI, and AI that requires legal or security review.

The AI Security Framework Reaches the Whole Stack

Sections 1512 and 1513 create a different kind of obligation. They are not simply another vendor exclusion rule. Crowell describes Section 1513 as directing DoD to develop a risk-based cybersecurity and physical security framework for covered AI/ML technologies as an “extension or augmentation” of CMMC, with covered AI/ML defined to include source code, model weights, methods, algorithms, data, and software used to develop AI/ML.[3]

That definition is the part that should change internal inventories. If the framework covers source code, model weights, methods, algorithms, data, and development software, then a deployed model card alone is not a compliance inventory. The development pipeline matters. The training data matters. The fine-tuning process matters. The platform used to build or evaluate the model matters. The vendor who hosts the model may not be the same party that supplied the weights, labeled the data, or maintains the development environment.

Crowell’s summary also identifies supply chain vulnerabilities that the framework is expected to address, including data poisoning, adversarial tampering, counterfeit parts, and unintentional data exposure.[3] Those risks do not map cleanly to a single procurement checkbox. Data poisoning points toward provenance and change control. Adversarial tampering points toward testing and monitoring. Counterfeit parts points back to supplier qualification. Unintentional data exposure points toward access controls, prompt logging, API boundaries, and contract data-handling rules.

Calling this “CMMC for AI” is convenient, but it can hide the scope. CMMC grew around controlled unclassified information and cybersecurity practices. The AI security framework will have to deal with model artifacts, training pipelines, evaluation methods, and physical security issues around AI/ML technologies. The status update to Congress was due June 16, 2026, and DFARS rulemaking is expected to follow, but final contract text has not been published as of Q3 2026.[3][4]

There is also timing uncertainty. WilmerHale notes the NDAA’s AI and cybersecurity provisions, while a July 13, 2026 CMMC Phase II suspension memo from the Department of War creates uncertainty about how quickly the AI security framework will be integrated into CMMC.[4] That does not erase the statutory mandate. It does mean contractors should avoid building a control program that depends on one assumed assessment sequence.

The practical move is to prepare evidence in layers. An AI inventory should identify the business owner, contract touchpoints, data categories, model provider, hosting provider, development tools, model weights if known, training or fine-tuning data sources if applicable, external API calls, access controls, logging, and subcontractor use. Some fields will be incomplete at first. That is still better than discovering during a solicitation response that the only record of an AI capability is a product name in a purchase-card statement.

Where the Framework Changes Supplier Reviews

Supplier questionnaires should stop asking one broad question — “Do you use AI?” — and start separating development, delivery, and support. A subcontractor may not sell an AI product but may use AI to generate engineering analysis, summarize controlled documents, monitor logistics, or produce software code. A SaaS vendor may add an AI assistant inside an existing platform without a new procurement event. A managed service provider may use third-party models to handle tickets or analyze customer data.

• Add AI component fields to vendor master data, not just to one-time risk questionnaires.
• Require suppliers to identify whether AI touches contract data, deliverables, source code, controlled technical information, or operational decisions.
• Track model providers, hosting locations, development tools, and subcontracted AI services separately.
• Keep evidence of screening decisions, restrictions, exception approvals, and monitoring results.
• Build refresh triggers for ownership changes, product feature changes, new model integrations, and subcontractor substitutions.

This is where legal, procurement, IT, security, and program operations have to share the same object. If legal drafts a clause that procurement cannot map to ERP fields, the clause will not produce usable evidence. If IT blocks a public tool but procurement approves an embedded version of the same capability inside a vendor platform, the program still has exposure. If security inventories models but not the subcontractor using them to perform the work, the flowdown fails at the tier where the activity occurs.

Domestic Sourcing Moves Diligence Earlier

The domestic sourcing provisions are not AI-specific in the same way Sections 1532 and 1513 are, but they belong in the same operating calendar. Wiley and KS Law identify multiple FY2026 NDAA provisions affecting defense contractor supply chains, including optical glass and display restrictions, compliant source qualification, a voluntary compliance repository, advanced battery restrictions, critical mineral restrictions, 3D printer restrictions, and China-owned computer and printer restrictions.[6][1]

The common shift is earlier diligence. A post-award certification cycle is a poor fit for phased bans that affect component selection, alternate-source qualification, and production equipment. By the time a program discovers that a display component, battery source, printer fleet, or additive manufacturing system is noncompliant, the fix may require redesign, supplier substitution, schedule relief, or a waiver conversation that could have been avoided.

For teams already using AI to monitor geopolitical supply chain risk or tariff disruption, this is a different workflow. Scenario planning can show where a material or supplier concentration creates exposure. NDAA sourcing compliance has to turn that exposure into contract eligibility, evidence, and source qualification. A supplier risk score is useful only if it connects to the acquisition decision that must be defended later.

AIBOM Transparency Has to Stay Current

The transparency layer is where familiar software supply chain language starts to strain. The NDAA links SBOM policies to AI systems and encourages model cards, according to Freshfields and Manifest Cyber.[2][7] That is a logical starting point: contractors need to know what components are inside systems they buy, build, integrate, or allow suppliers to use.

But an AI bill of materials is not just an SBOM with a new label. Software components may change too, but AI systems can add another set of moving parts: model weights, training data, fine-tuning data, retrieval sources, evaluation methods, external inference services, prompt-management layers, and retraining cycles. If a vendor changes the model behind an API, the contractor may see the same product name and a different risk profile.

Manifest Cyber argues that static documentation is not enough because AI systems can retrain and change over time.[7] That is a vendor assessment, not final DoD guidance, but the underlying operating issue is real enough for procurement design: a point-in-time PDF will not answer whether the system in use today is the same system that was reviewed last quarter.

A useful AIBOM process should therefore capture both composition and change. Composition asks what model, data, software, and services are part of the AI system. Change asks who can update them, how often they change, what notice the contractor receives, what testing occurs after a change, and whether the change affects contract data, export-controlled material, controlled unclassified information, or Section 1532 screening.

• For internally built AI: document model lineage, data sources, training or fine-tuning steps, evaluation records, access controls, and deployment locations.
• For vendor AI: require notice of material model changes, new subprocessors, hosting changes, retraining behavior, and external service calls.
• For subcontractor use: require disclosure when AI contributes to deliverables, analysis, code, technical writing, supplier selection, or contract-data processing.
• For audit readiness: retain the reviewed version, approval date, reviewer, data boundary decision, ownership screening result, and any restrictions imposed.

What Should Change Before DFARS Text Arrives

The cleanest mistake would be to wait for DFARS and then launch a discovery project. The messier but better approach is to build a provisional control baseline now, with labels that can be adjusted when clauses and DoD guidance become clearer. The baseline should not pretend the rulemaking is finished. It should make sure the organization can find its AI exposure, explain its screening logic, and produce supplier evidence when the acquisition system asks for it.

Start with inventory. Find AI use in purchased software, engineering tools, logistics platforms, finance and procurement systems, code repositories, cyber tools, document systems, analytics platforms, and supplier-provided services. Include browser-based and API-based access, because a contract restriction that only attaches to formal software purchases will miss some of the easiest paths into the environment.

Then separate allowed, restricted, prohibited, and unknown tools. Unknown should be a temporary status with an owner and deadline, not a junk drawer. A tool that touches no contract data and has no defense work connection may receive a different treatment from a tool used to draft technical deliverables, analyze supplier risk, generate software, or process controlled information.

Supplier onboarding should add AI-specific fields before the final clauses make them mandatory. The useful fields are not exotic: AI capability description, model or service provider, hosting location, ownership and parent entities, listed-party screening, subcontractor AI use, data categories processed, external API calls, change-notice commitments, and evidence attachments. If the ERP cannot hold the details, it should at least hold a risk flag and link to the evidence system.

Contract language should anticipate flowdowns without overclaiming final regulatory text. The clause set can require disclosure of AI used in performance, prohibit covered AI where applicable, require cooperation with ownership and source screening, require notice of material AI system changes, restrict use of contract data in public or unapproved models, and preserve audit rights. Legal should own the wording; supply chain and IT should make sure the obligations can actually be monitored.

Evidence capture deserves its own workflow. A supplier’s representation, screening screenshot, model card, AIBOM, exception approval, technical control, and access log may live in different systems. During a bid, audit, incident, or customer inquiry, “we asked the supplier” will not be enough if no one can find what was asked, who answered, when it was reviewed, and whether the answer covered subcontractor use.

The Baseline Has Shifted

The FY2026 NDAA does not turn every AI tool into a banned object, and it does not give contractors a finished checklist. It does something more operationally inconvenient: it creates AI-specific supply chain obligations that cut across ownership, tool access, cybersecurity, physical security, component sourcing, and transparency. Those obligations will land in the same places where compliance always becomes real — supplier onboarding, ERP fields, contract flowdowns, IT controls, subcontractor attestations, and audit evidence.

ChainSignal is not a law firm, and this article is not legal advice. As of Q3 2026, DFARS rulemaking and DoD guidance remain unresolved for important parts of the AI security framework and enforcement model. The practical baseline has still moved. Defense contractors should not merely track AI policy; they should start building AI supply chain compliance controls now.

References

1. FY 2026 NDAA: Domestic Sourcing, Artificial Intelligence, Cybersecurity, and Acquisition Reforms — KS Law
2. AI Supply Chain and Security: Congress Mandates Strict Controls for AI Acquired by the U.S. Defense Agencies and Intelligence Community — Freshfields
3. CMMC for AI? Defense Policy Law Imposes AI Security Framework and Requirements on Contractors — Crowell
4. What the NDAA Means for AI and Cybersecurity — WilmerHale
5. The FY2026 NDAA Bans 'Covered AI' From Defense Contracts. Banning a Tool Isn't the Same as Blocking It. — Containment.ai
6. Important NDAA Provisions for Contractors and Their Supply Chains — Wiley
7. AI Security in the FY26 NDAA: What It Gets Right and What's Missing — Manifest Cyber