Insights · AI Governance
Do you know where your AI supply chain ends?
You can name your AI vendors. You cannot name theirs, and neither, in a growing number of cases, can they. Why the answer is not a deeper map — and what to build instead.
A client sent me their AI vendor inventory last month. It was good work — eleven tools, an owner for each, contract dates, a note on what data each one touches. Better than most of what I see.
I asked one question about the third row. Which model is behind that feature, and who runs the hardware it executes on?
Nobody knew. So we asked the vendor. The vendor named a model provider. We checked that provider's public documentation to find out who hosts inference, and learned that it depends on capacity and region, and that the list is subject to change.
Four questions past the contract, we were reading a page that could be edited without notice to anyone in that room. That is not a diligence failure. It is the shape of the problem.
Framing
Two questions that get asked as one
There is a question you can answer and a question you cannot, and they are usually asked in the same breath.
Who are our AI vendors? That one is answerable. It takes work — shadow adoption makes it harder than it should be — but it terminates. You can produce a list, assign owners, and keep it current.
Where does our AI supply chain end? That one does not terminate. Every honest attempt produces another layer, and at some depth you reach a party whose identity changes on a schedule nobody tells you about.
Treating the second as a harder version of the first is the mistake. It is a different kind of question, and it takes a different kind of answer.
Structure
What sits below your contract
In a conventional software relationship you have a vendor, possibly a hosting provider, and a subprocessor list. Three layers, mostly stable, mostly disclosed.
An AI feature typically has more, and they move.
Note what shifts as you descend. It is not simply that you know less. It is that the thing you are trying to know stops being stable. A subprocessor list is a snapshot of an arrangement both parties expect to revise.
The core problem
Why the map is the wrong deliverable
The instinctive response to Figure 1 is to go deeper. Build a fuller map. Collect the subprocessor list, the region list, the model card, and put them in a binder.
I have watched that project run more than once. Three things happen to it.
It is stale on delivery. The routing that was true in June is not the arrangement in September, and nothing obliged anyone to tell you.
It stops where the vendor stops knowing. Not evasion, in most cases. Your vendor built on a platform and has no more visibility into that platform's tenancy than you do.
It creates a false record. This is the part I would actually worry about. A binder describing an architecture that has since changed is worse than no binder, because someone will rely on it, and eventually someone will affirm on the strength of it.
The trap: a documented supply chain that is no longer accurate does not reduce your exposure. It relocates it — from "we did not know" to "we asserted something that was not true." Those are different problems, and the second is worse.
So the deliverable is not a deeper map. It is a boundary that does not depend on the map being complete.
Requirements
What the rules already give you
The useful news is that this problem is not novel, and the existing instruments address it more directly than people expect.
| Instrument | What it does here |
|---|---|
| DFARS 252.204-7012(b)(2)(ii)(D) | Where a cloud service will store, process or transmit covered defense information, the contractor must ensure it meets requirements equivalent to the FedRAMP Moderate baseline. This applies to an AI service like any other cloud service, and it does not care how many layers sit beneath it. |
| DFARS 252.204-7012(m) | Flow-down. The obligation travels with the data to anyone performing on the covered work. The clause moves down the chain even where your visibility does not. |
| 32 CFR § 170.19 | Asset categorization. A service that processes, stores or transmits CUI is a CUI asset, in scope. There is no separate category for services whose downstream architecture you cannot see. |
| ESP / SPA determination | Fixes the provider's relationship to your assessment. The determination turns on the data flow, not the product category — see Vendor Brief 01. |
| NIST SP 800-161 | Supply chain risk management practices. The reference point for the depth problem specifically, and the natural place to look where 800-171 alone does not reach far enough. |
Read those together and a pattern emerges. Not one of them requires you to enumerate the bottom of the chain. Every one attaches the obligation at a boundary and makes depth someone else's problem to carry contractually.
That is the design, and it is the right design, because enumeration was never going to scale.
Outlook
The framework that is coming
Defense policy law now directs the Department to establish an AI security framework addressing AI and machine-learning specific risks — data poisoning, adversarial tampering, unintentional data exposure — and to implement it as an extension or augmentation of existing DoD cybersecurity frameworks, CMMC among them.
Two things follow for planning purposes.
First, it is additive. Nothing in the direction suggests your 800-171 obligations get simpler. Expect an overlay on a control set you already owe.
Second, look at the named risks. Data poisoning and adversarial tampering are supply chain risks in the strict sense — they live in layer four of Figure 1, in training data and model provenance. The direction of travel is toward requirements about the part of the chain you currently cannot see.
Which makes the contractual position you take now more durable than any map you build now.
Approach
Terminate the chain instead of tracing it
Three moves, in order. None requires knowing what is in layer four.
Decide where CUI stops
The strongest control is architectural. If CUI does not reach the AI service, the depth below it is not your problem. That is not an anti-AI position — it is a scoping position, and it is how you get to use these tools at all in the parts of the business where they are genuinely useful. Segment the workflows. Approve each tool for the tier of data it is actually appropriate for, and enforce that with something other than a policy sentence.
Push depth onto the party that has visibility
Where CUI does reach the service, the contract is the instrument. What you want is not a list. It is an obligation: notification before material change to subprocessors, model provider or hosting region; commitments on data location and personnel access, including nationality where export control applies; flow-down of your 7012 obligations; and a right to evidence rather than assurance. Your vendor can bind their vendor. You cannot.
Verify at the boundary, not at the bottom
Test what you can observe: what leaves your environment, where the endpoint resolves, what the logs show, whether deletion is confirmable. Egress evidence you gathered yourself is worth more than a subprocessor list you were handed, because it describes what is happening rather than what was intended.
The question I would ask your leadership
If the model behind one of our approved AI tools were swapped next Tuesday, and inference moved to a different host in a different jurisdiction — would we find out? Through what mechanism, and how long would it take?
If the answer is that we would find out by reading a documentation page we do not monitor, then we do not have a supply chain position. We have a snapshot, and it is already old.
Action
Four things to do this quarter
Supply chain depth — quarterly actions
- Take one tool and go four layers down. Pick the AI tool closest to your CUI and trace it as far as it goes. The point is not the answer. The point is finding the layer at which your organization stops being able to ask, because that is where your contracts have to do the work.
- Read your change-notification terms. For every AI vendor touching regulated data, find the clause governing subprocessor and material change. In most standard terms the obligation is weak, the notice period is short, or the mechanism is a webpage. That clause is your entire early-warning system.
- Separate the inventory from the assertion. Keep your vendor list. Date every depth claim in it and mark its source. A list that distinguishes what you verified from what you were told is defensible. One that presents both identically is not.
- Decide the CUI question per workflow, not per tool. The same tool can be appropriate for one workflow and out of the question for the next. Approving at the tool level is what produces the shadow use you find later.
References
Primary sources for this brief
- DFARS 252.204-7012 — safeguarding covered defense information; cloud service provider and flow-down provisions
- 32 CFR Part 170 — CMMC Program, § 170.19 scoping and asset categorization
- NIST SP 800-171 — external systems and external system services requirements
- NIST SP 800-161 — cybersecurity supply chain risk management practices
- FY2026 defense policy legislation — direction to establish an AI security framework as an extension of existing DoD cybersecurity frameworks
FAQ
Common questions
Do I have to know every subprocessor behind an AI service?
No, and you will not be able to. The obligation attaches at the boundary: the service handling your CUI has to meet the requirement, and the contract has to carry your obligations forward. Enumeration to the bottom is neither required nor achievable, which is why the instruments are built the way they are.
Our AI vendor cannot tell us who hosts inference. Is that a disqualifier?
Not automatically, but it changes what you can safely put through the service. If they cannot tell you where processing happens and who can reach it, you cannot make a defensible determination for CUI, and certainly not for export-controlled data. That is a scoping answer, not a vendor verdict.
Is a SOC 2 report enough for the AI layer?
It is evidence of something, but not of the thing the clause asks about. For a cloud service handling covered defense information, the standard is equivalence to the FedRAMP Moderate baseline. A SOC 2 does not substitute for it, and a trust centre page substitutes for neither.
What about export-controlled data in an AI workflow?
Treat it as a stop condition until you can answer the personnel question. Export control turns on access by foreign persons, which means provider staff, offshore support and the jurisdiction of whoever runs the hardware. Retention and training terms are irrelevant to that analysis.
Should we wait for the DoD AI framework before doing this work?
The framework is directed as an extension of existing requirements, so it is unlikely to make anything you implement now redundant. The contractual positions in particular — change notification, data location, evidence rights — hold under any version of it.
How does this differ from ordinary third-party risk management?
In degree rather than in kind. Conventional vendor chains are deep but comparatively stable. AI chains re-route by capacity and swap models on the provider's schedule, which means a point-in-time assessment decays faster than the review cycle that produced it.
Not sure where your AI supply chain terminates?
We trace the data flow, read the change-notification and flow-down terms, and give you a written determination — boundary, classification and evidence position — that you can hand to an assessor.
Book a scope call. Thirty minutes, no charge.
Related briefs
This brief reflects published guidance as of 7 September 2026, during the CMMC reform task force review. The DoD AI security framework referenced above was directed but not published at the time of writing. Verify specifics against the current 32 CFR Part 170 text, your contract clauses and applicable DoD guidance before relying on them. Advisory content, not legal advice.
Cyber DSC · Insights · Vendor Brief 03 · 07 Sep 2026