Artificial intelligence (AI) is making its way into an increasing number of business operations. Yet in some cases, it is happening more quickly than firms are able to keep up with, creating visibility issues that can put them at risk.

It is with this in mind that government cyber agencies have released a new resource defining the minimum elements for software bills of materials (SBOMs) for AI. The aim is to help public and private sector stakeholders improve transparency in their AI systems and supply chains, according to reports.

But what exactly is a AI BOM and which companies need one?

AI-Driven Expansion Of The SBOM

An AI BOM is an expansion of the SBOM infantry that has been around for over 10 years. “It provides a list of all the components and software libraries in a piece of software, which gives security teams the ability to vet it for any potential security risks, and to respond more effectively in the event of a breach,” says Dana Simberkoff, chief risk, privacy and information security officer at AvePoint.

AI BOMs are a distinct category mainly because AI has created “unique and pervasive security and governance risks,” according to Simberkoff.

An AI BOM is an inventory of everything that makes up an AI system: The base models, fine-tuned variants, training and evaluation datasets, embeddings, agents, and the tools and APIs agents can call.

“A traditional SBOM tells you what code is in your software,” explains Mike Anderson, CDIO, Netskope. “An AI BOM tells you what intelligence is in your software, where it came from, and what it's allowed to do.”

The "allowed to do" part matters, says Anderson. “With agentic AI, you're not just tracking components, you're tracking actors. An AI BOM that stops at model lineage misses the part that keeps CISOs up at night: Which agents exist, what data they touch, and what authority they've been granted.”

Why Firms Need An AI SBOM

Firms are becoming reliant on AI for critical business processes. “However, we often treat them like a black box, placing complete trust in the vendor,” says Rob O’Connor, EMEA CISO at Insight.

Yet new regulations such as the EU AI Act require firms to be transparent with users about AI systems. This creates obligations to understand how the system was designed and built, explains O’Connor.

“A significant portion of the attack surface for AI systems has moved upstream, outside of our control – poisoned training material and tampered model weights can subtly alter the functionality of a system,” he explains. “The AI BOM is a more standardised approach to sharing the provenance of a system between a creator and a consumer, allowing them some visibility into the black box for auditing purposes.”

Most modern applications are built largely from open source and third-party components. “That means a large share of software risk comes from dependencies that teams did not write themselves,” says Ilkka Turunen, field CTO at Sonatype. “When a serious issue appears, the first question is simple: Where are we exposed? If you cannot answer that quickly, you have a real problem.”

Turunen believes this transparency is even more important when it comes to AI development. “In addition to mitigating risks that come from the open source libraries many AI systems rely on, documenting the provenance of datasets and algorithms helps mitigate risks related to bias, discrimination, or unethical practices.”

Who Needs An AI SBOM

Some firms require an AI BOM more than others. If you build AI products, “you need one, full stop,” says Anderson. “Your customers will start asking for it the same way they ask for a BOM today, and the companies that can produce one will win deals based on trust.”

Not every organisation is formally required to maintain an AI BOM today, but any business building, buying, or deploying AI should “strongly consider one,” according to Simberkoff.        

If you use or consume AI, then you should consider how you can use AI BOMs to add transparency and trust into your supply chain, O’Connor advises. “If you are developing your own models, fine-tuning existing models or deploying AI into regulated sectors, these are key indicators you should be considering creating AI BOMs. While legislation demanding them may arrive in the near future, customers will be demanding them as a market qualifier much sooner – they will need them to comply with legislation.”

The biggest challenge organisations face without AI BOMs is how quickly things change, says Crystal Morin, senior cybersecurity strategist at Sysdig. “New frameworks, models and integrations are released all the time, and developers want to work with the most relevant or newest technologies to produce the best results for the business. Security’s responsibility is to keep pace without impeding innovation. Without a living AI BOM inventory, security teams remain reactive.”

If you don’t need to create AI BOMs – for instance, if you’re primarily a consumer of AI systems from other suppliers – you should consider demanding AI BOMs from your suppliers, says O’Connor.  “Existing information security questionnaires are not geared up to support AI risk, and the AI BOM can help fill this gap, giving you and your end customers the transparency you need.”

Building An AI SBOM

Creating an AI BOM starts with knowing what you have. For organisations still early in their AI adoption, start by cataloguing the models you use and where they exist, advises Morin. “From there, work outward: Note the frameworks and libraries developers are using to interact with those tools, followed by inference servers, harnesses, MCP servers, and orchestration tools. Here, you start to build the basic picture.”

Then build the registry, advises Anderson. “Every model, agent, dataset, and integration gets an entry with an owner, a purpose, the data it touches, and the permissions it holds. Treat agents as first-class citizens here, not footnotes.”

Use the standards that exist, says Anderson. “CycloneDX and SPDX both now support AI components, so don't invent your own format,” he advises.

O’Connor suggests using the G7 minimum elements as the skeleton. “The seven clusters – system, models, datasets, infrastructure, security, performance and metadata – are a sensible scoping exercise, even for organisations that never publish a formal SBOM.”

Yet while having an AI BOM is useful, firms should take into account that simply generating one is not enough, says Turunen. “Organisations must take proactive steps to ensure AI BOMs are not just documents, but living assets used to drive better security decisions.”

Kate O'Flaherty Cybersecurity and privacy journalist