The Opacity is the Risk
Your car has AI in it. Your medical device probably does too. So does your bank's fraud detection system, the software your hospital uses to route patients, and the enterprise tools your security team runs every day. And in almost every case, the organization that bought and deployed that software has no idea what AI is actually powering it under the hood.
Is it GPT-4? Something fine-tuned from a model pulled off Hugging Face? Did the vendor build their own model? Was the training data legally obtained? Is any of it derived from DeepSeek?
They do not know. And the longer that remains true, the worse the problem gets.
The Logical Progression I Keep Coming Back To
I have spent the last two years researching AI supply chain security. The conversations I have had, from the White House to Capitol Hill to Fortune 500 security organizations, keep circling back to the same core problem. Here is the logical chain as I have come to understand it.
Software supply chain security is critically important to global security, yet software supply chains have historically been opaque. Software bills of materials (SBOMs) are globally accepted, if imperfect, tightly scoped artifacts that help communicate software information between software suppliers and software consumers. AI is a subset of software. AI has supply chains, which have been targeted by adversaries and pose real risk. Therefore, SBOMs should be applicable to AI, specifically to the models, datasets, and related components that end up inside larger AI-enabled systems.
That progression sounds clean on paper. The implementation gap is enormous in practice.
AI is getting incorporated into nearly every piece of software being built today, from cars to medical devices to weapons systems. How can software buyers trust the AI in those systems and know how those systems were assembled? How can they know if a model was fine-tuned from a problematic source, or trained on illegal or inaccurate datasets?
Right now, they cannot.
A New Policy Memo Gets It Right
The Institute for Security and Technology (IST) just published a policy memo titled "Driving AI Transparency: Supply- and Demand-Based Paths Toward AIBOM." It is co-authored by Dr. Allan Friedman, one of the most credible voices in software and AI supply chain policy, and Nick Leiserson. As the memo puts it directly: "A future in which organizations can effectively manage AI supply chain risk will require AIBOMs." I recommend reading it in full.
The memo argues, clearly and correctly, that widespread adoption of artificial intelligence bills of materials (AIBOMs) requires coordinated action on both sides of the market. Supply: vendors building AI systems must have a consistent, standardized way to document their components. Demand: government procurement requirements and regulation must create the expectation that this documentation exists and is maintained. Neither side alone will get us there.
The IST memo also offers a foundational set of minimum data elements for what an AIBOM should capture, covering model identity, dataset provenance, licensing, integrity verification, and lineage. It is tightly scoped. It is achievable. It is not a final standard. It is explicitly a starting point for community discussion.
Think of it as what the NTIA Minimum Elements document was for SBOMs in 2021. A stake in the ground. A reference point. A foundation the ecosystem can build on. That framing is exactly right, and it sets realistic expectations for what minimum elements documents are designed to do.
Why the Name Does Not Matter, But the Requirement Does
Whether you call it an AIBOM, an AI SBOM, or something else entirely is a semantic question. The operational need is not.
Any organization buying or deploying AI-enabled software needs a standardized, consistent mechanism to understand what AI components are embedded in the products they use. Without that mechanism, you cannot assess risk. You cannot respond to incidents. You cannot make procurement decisions that hold vendors accountable for the provenance of what they deliver. This applies to a hospital system, an automaker, a financial institution, and a defense agency equally.
This is not a new problem. It is the same problem we faced with software supply chain security before the SolarWinds breach (2020), before Log4Shell (CVE-2021-44228), and before the XZ Utils supply chain attack. The pattern is identical. Accelerate adoption, skip the visibility infrastructure, scramble when something goes wrong.
The difference with AI is that the stakes are higher and the timeline is shorter.
Why Model Cards Are Not Enough
I hear this often: "We already have model cards and data cards. Is that not the same thing?"
No. It is not.
Model cards are long PDFs. They are written in natural language. They are inconsistent across providers. OpenAI's model card looks nothing like Meta's, which looks nothing like Anthropic's, which looks nothing like what you find on HuggingFace for an open-source fine-tune. There is no required set of fields. A vendor can write whatever they want, omit whatever they want, and call it a model card.
More importantly, PDFs are not machine-readable at scale. You cannot automate risk analysis against a PDF. You cannot build tooling on top of it. You cannot query it across a portfolio of hundreds of third-party AI systems.
AI transparency that cannot be automated is not transparency at scale. It is a paperwork exercise.
The value of a minimum elements specification, whether for SBOMs or AIBOMs, is exactly this: it creates a consistent, structured, machine-processable artifact that security teams can actually use. Formats like CycloneDX and SPDX have already begun encoding AI-related metadata. The IST memo's proposed skeleton of minimum elements, tightly scoped and grounded in what is achievable today, levels the playing field and sets clear expectations for AI developers. That is what the SBOM movement learned. That is what the AIBOM movement needs to internalize now.
Why This Moment Matters
This administration is pushing AI adoption faster than any in history. The White House AI Action Plan, Executive Order 14409 ("Promoting Advanced Artificial Intelligence Innovation and Security," signed June 2026), and the series of AI-focused executive orders leading up to it have made clear that accelerating AI adoption is a policy priority. The private sector is moving just as fast, if not faster.
I do not object to that goal. American leadership in AI matters. But acceleration without governance is not a feature. It is a threat.
The risk is not hypothetical and it is not confined to the government. AI is embedded in autonomous vehicles, medical devices, weapons systems, critical infrastructure, and enterprise software across every major sector. Our adversaries are actively targeting supply chains. The XZ Utils attack previewed how a single malicious contributor can compromise infrastructure that millions of systems depend on. AI supply chains are at least as exposed, and in many cases more so.
The longer we wait to build the visibility infrastructure, the harder it becomes to correct. Every system deployed without provenance documentation is another unknown in an already complex environment. The transparency tax compounds over time, and it compounds across every sector simultaneously.
What Good Looks Like
The IST memo charts a realistic path. Here is what I want to see happen.
The Office of Management and Budget (OMB) and Congress should point to the IST framework, and to complementary efforts from the CISA SBOM for AI Tiger Team, the G7 Cybersecurity Working Group, and the OWASP AIBOM community, as reference anchors for future AI supply chain security requirements. But this is not only a government problem. Industry governance leaders across healthcare, automotive, financial services, and critical infrastructure should be looking at this work too, and using it to set expectations with their own AI vendors today.
On the supply side: launch a formal multistakeholder process to develop AIBOM Minimum Elements, modeled directly on the NTIA SBOM process. Engage model developers, AI system integrators, cloud providers, cybersecurity practitioners, and standards bodies. Set a deadline. Publish the output as a binding reference.
On the demand side: require, through procurement language and contract standards, that vendors selling AI-enabled products know what is in those products. Not in 2030. Now. The initial requirement does not need to mandate a formal AIBOM. It can start with what the IST memo calls an internal tracking obligation: vendors must be able to answer questions about the AI components in their systems, document known unknowns, and respond when new risk information emerges.
A phased approach, with a clear timeline toward full AIBOM requirements, creates the demand signal that drives vendor investment, tooling development, and community consensus. That is how the SBOM ecosystem matured. It is how the AIBOM ecosystem will mature too.
On the international side: coordinate now, not after. The G7 published its "SBOM for AI: Minimum Elements" guidance in 2026. It has value, and the IST memo gives it fair credit while naming its limitations honestly. The U.S. has an opportunity to lead, improve on that work, and drive alignment before fragmented national requirements create the compliance burdens that will slow adoption more than a clear standard ever would.
The Better Question
The question most organizations are currently asking is: "How do we adopt AI faster?"
The better question is: "How do we adopt AI we can actually trust?"
You cannot answer the second question without knowing what is in the AI you are deploying. Provenance is the new perimeter. It is the boundary between AI we can trust and AI we cannot. That boundary matters whether you are a federal agency, a hospital network, or a Fortune 500 enterprise buying AI-enabled software from a third-party vendor.
Many kudos to Allan and Nick for a timely, well-reasoned piece. The IST memo is the clearest articulation I have seen of what it will take to build that boundary at scale. OMB and Congress should take note. So should everyone else buying software with AI in it. Which these days is…everyone.
