It’s still early days for AI bills of materials (AI BOMs), but the drumbeat for their use is growing louder. The younger sibling of software bills of materials (SBOMs), AI BOMs extend the concept by taking stock of the data sets and models that traditional software inventories were never designed to capture.
Regulators in Europe and the US are starting to require them for high-risk AI systems— either explicitly or built into broader SBOMs. The G7 countries just released new guidance spelling out the minimum elements to expect in AI BOMs. Industry groups like ISACA are also now recommending AI BOM requests as standard due diligence for technology procurement. And security leaders are starting to see that without visibility into AI components, they’re going to have a hard go of managing AI risk at their organizations.
Unfortunately, the reality right now is that practical use of AI BOMs is still largely aspirational.
“Even just educating people on what an AI BOM is is still necessary in a lot of conversations,” says Daniel Bardenstein, co-founder and CTO of Manifest Cyber. “You know, ‘Why it’s different from an SBOM? Why is it valuable?'”
With critical AI deployments skyrocketing, this year will be pivotal for security leaders and industry influencers to start making serious progress on AI visibility and transparency. This could be AI BOM’s moment. But it means security industry movers have to move beyond just wrapping their arms around the basic definitions and start crystallizing standards around what they contain and how they’re documented, as well as putting meaningful tooling into place for both generation and consumption of AI BOMs.
So, What Is an AI BOM?
An AI BOM builds off the concept of an SBOM to branch out into the unique components that make AI systems work. Whereas an SBOM inventories code libraries and dependencies, an AIBOM documents the models, datasets, training history, licensing, and operational metadata that define an AI system’s behavior and risk profile.
“An SBOM in general tells you what is inside a piece of software and an AI BOM extends that idea to what’s inside an AI system and what it depends on at runtime,” says Kriti Tallam, VP of AI at Kamiwaza AI and contributor to NIST’s AI Risk Management Framework. “Because in AI the ingredients that drive behavior are not just libraries, they’re also data. They’re also retrieval sources. They’re also tools. They’re also policies.”
There’s no single, universally mandated standard yet for what an AIBOM must contain, but standards and practitioner guidance from authorities like the Cybersecurity and Infrastructure Security Agency (CISA), the G7 Cybersecurity Working Group, Open Web Application Security Project (OWASP), National Institute of Standards and Technology (NIST), and the Linux Foundation have begun to converge on core elements.
“Under the hood, I would enumerate in a few layers,” Tallam explains. “First, the model artifact itself: which model, what exact version, how was it produced? And where this gets interesting is the data lineage that’s shaped it. This includes [details around] the training and the fine-tuning of data sets, such as where they come from, ownership, provenance, the audit trail.”
A peer-reviewed study published in October 2025 by a cohort of experts in charge of Linux Foundation’s Software Package Data Exchange (SPDX) AI BOM standard documented what practitioners actually need to transparently and safely consume AI systems. One lead data scientist interviewed anonymously for the research laid out some of the most unique elements they’d need: “What do I look for? I look for license support (and answers to questions like) which training data was used, what demographic was used, and what biases do they have? What’s the reported accuracy? How did you test it?”
Most frameworks also call for documenting the software dependencies the model relies on, as well as the configuration and hyperparameters used before training. They also recommend documentation of the deployment context describing where and how the model runs, and human oversight records covering validation steps, approval workflows, and audit history.
As agentic AI systems become more prevalent, experts like Tallam argue AIBOMs will need to expand further to cover behavioral artifacts and governance-related artifacts, including retrieval sources, tool integrations, agent chains, and permission structures.
“I think that’s the direction the conversation needs to go. I think what’s going to happen is an agentic BOM is going to add the execution layer,” she says, explaining that this could include information about the agent’s identity and what it is authorized to do.
However, right now even documenting the basics of models and data lineage remains a challenge for most AI builders and organizations who would consume AI BOMs. For example, the SPDX researchers pointed out that even foundational datasets like ImageNet and CIFAR-10 don’t fully disclose their data sources. For this reason, many advocates believe it is best to start simpler.
“Early drafts that attempted to capture every conceivable detail of an AI system consistently faced pushback from practitioners. Most organizations simply do not maintain information at that level of granularity, and a standard that demands it becomes impractical,” they wrote. “We therefore optimized our AIBOM specification for adoption by defining a small set of readily recordable required fields and enforcing strict entry criteria. In some cases, we intentionally excluded ambitious goals to improve practicality.”
Why AI BOMs Matter Now
Unvetted and opaque AI systems are increasingly becoming the linchpin to business infrastructure in 2026. Not only are the attackers already starting to take advantage of the situation, but the regulators are also beginning to wrap their arms around the risks.
A recent report from Hugging Face found that this open source repository of AI models and data grew to 13 million users last year. The number of models on the site doubled to 2 million and the number of data sets available reached 500,000. Meantime, the attack surface is growing right along with it. JFrog’s 2025 Software Supply Chain Report found a 6.5-fold increase in malicious models identified on the platform compared to the prior year. And research published in February documented backdoored models that passed all of Hugging Face’s security checks.
Meantime, in August the EU AI Act goes live, and among the requirements is better documentation for high-risk systems that either use AI to impact safety features or that use it for risky use cases like critical infrastructure or law enforcement.
These regulators have been listening to broader security leaders who have been prosteletyzing the most important takeaway that without better visibility tools, including AI BOM documentation, the rapidly expanding AI supply chain will remain effectively invisible to security teams.
“CISOs should really emphasize the bill of materials, both AI BOMs and SBOMs for the software we build around AI,” says Hasan Yasar, technical director of Rapid Fielding of High Assurance Software at the Carnegie Mellon University Software Engineering Institute. “Because at this point we don’t know what we don’t know about AI. All we know is based on the code, but that is only the tip of the iceberg. We don’t see what’s underneath the water.”
Comments are closed