The Inventory Is Not the Evidence
An AI Bill of Materials (AIBOM) is a way to describe an AI system so that someone can later ask where its parts came from, how they were assembled, what happened when they ran, and what evidence supports using them. The immediate question is why an ordinary Software Bill of Materials (SBOM)—already designed to list software components and dependencies—is not enough. The answer determines a practical judgment: whether a machine-readable record gives a downstream user genuine grounds for reuse, audit, security review, or governance, or merely the appearance of transparency.
This distinction matters because pretrained models are no longer isolated research artefacts. They are downloaded, fine-tuned, combined with other models, placed inside applications, and redistributed through software systems. A model can therefore acquire the risks of a supply chain even when the person reusing it did not train it. The two supplied studies examine different sides of that problem. One proposes and evaluates an operational AIBOM pipeline in a controlled Trusted Research Environment; the other measures how much information can actually be extracted from a large collection of public Hugging Face repositories. Together, they suggest that an AIBOM has two prerequisites: it must capture the right relationships, and the people releasing the system must supply meaningful evidence for those relationships.
The package inventory stops at the wrong boundary
An SBOM answers a valuable but bounded question: which software components and dependencies are present? That answer supports vulnerability lookup, license review, patching, and a baseline view of software supply-chain exposure. It can identify a library, its version, and sometimes its relationship to other packages. For ordinary software, that may be close to the most important composition question.
For an AI system, composition is only the beginning. The model's behaviour can depend on training and evaluation data, preprocessing, parameter values, quantisation, floating-point precision, hardware acceleration, runtime configuration, and the environment in which inference occurs. The system may also retrieve components dynamically, call an external model or service, or change through retraining. A package inventory may tell us that a framework is installed without telling us which model artefact was loaded, which dataset version shaped it, or which configuration produced the reported output.
That missing context changes the decision a user is trying to make. Consider a team selecting a pretrained model for a sensitive application. They need more than the answer to “What libraries does this file require?” They may also need to know which data influenced the model, what license governs reuse, what limitations were documented, whether the model was evaluated for the intended setting, which base model it derives from, and whether the execution environment can be reconstructed. A software inventory can coexist with all of those questions being unanswered.
The boundary problem is not that an SBOM is wrong. It is that it describes only one layer of the object. The Frontiers study puts the difference plainly: conventional SBOMs focus on relatively static binaries and packages, while AI systems include dynamic components such as retrained models, parameter drift, runtime calls, and—when agents are involved—decision flows. An AIBOM extends the record because the AI system itself has a wider and more changeable composition.
What an AIBOM changes
The simplest way to understand an AIBOM is to stop treating the model file as the system's centre of gravity. The model is one important artefact, but its meaning depends on the relationships around it. The proposed conceptual framework groups those relationships into six domains: data; model; software; hardware; human and organisational context; and deployment and operations.
The data domain records what fed training, validation, or testing and how those inputs were transformed. The model domain identifies the architecture, version, parameters, and training details. Software and hardware describe the libraries, operating system, container, processor, accelerator, and other execution substrate. Human and organisational information connects the artefacts to developers, domain experts, review bodies, and governance records. Deployment and operational information captures topology, monitoring, patching, retraining, incident response, and risk assessment.
These domains are not six independent checklists. They explain one another. A model hash can identify the exact artefact, but a dataset reference helps explain where its statistical behaviour came from. A container digest can identify the software environment, but inference context explains whether the model ran with a different device, precision, or quantisation setting. A retraining record can show that the model changed, while operational ownership determines who was responsible for reviewing that change. The purpose of the AIBOM is to keep these relationships available for later reasoning.
This is also why a model card and an AIBOM should not be treated as interchangeable. A model card is primarily a human-readable account of purpose, evaluation, intended use, limitations, and possible biases. An AIBOM organises supply-chain information in a machine-readable form that can be validated, linked, enriched, and consumed by other systems. Model-card information can supply important content to an AIBOM, but an AIBOM gives that content a place in a broader chain of artefacts, dependencies, identities, and execution events.
The result is a shift in the questions a bill can support. Instead of only asking whether a dependency is present, an auditor can ask whether the model, data reference, runtime environment, and output belong to the same recorded execution. Instead of only looking up a package vulnerability, a security team can ask whether the affected component was actually present, how it was reached, and which deployment context matters. Instead of treating provenance as a paragraph in a repository, a downstream user can inspect whether a model's origin, version, license, limitations, and external references are connected well enough to support a decision.
The diagram's final boundary is essential. An AIBOM is not a trust label. It is evidence arranged so that trust-related questions can be examined with less guesswork. A record that binds a model hash to an output can make tampering or mismatch easier to detect. It does not prove that the training data were representative, that the model is fair, or that the output is safe for a particular use. Those conclusions require different evidence and accountable judgment.
A record can be valid and still be weak evidence
There are at least three different meanings of “complete,” and confusing them is one of the fastest ways to overestimate an AIBOM.
First, an artefact can be structurally complete: it has the required fields, valid JSON, and a recognisable component. This matters because an invalid document cannot reliably move through an audit or tooling pipeline. Second, it can be provenance-complete for a particular question: the relevant model, data reference, environment, execution event, and output are linked well enough to support verification or replay. Third, it can be substantively informative: its descriptions, limitations, intended use, safety discussion, and evaluation evidence actually help a human decide whether the system fits a context.
Those forms of completeness do not automatically arrive together. The large-scale Hugging Face study found that generated artefacts could be structurally valid while AI-specific documentation remained weak, especially around model-card information, limitations, safety-risk assessment, intended use, environmental information, and meaningful descriptions. The study's detailed score and field results will matter later, but its opening lesson is already clear: a green structural check does not mean that the important questions have been answered.
The operational study offers the complementary perspective. Its AIBOM pipeline captures model and environment state before loading, during runtime, and after execution; enriches dependencies with vulnerability information; and cryptographically binds outputs to the resulting record. In a controlled, simulated research environment, the authors report high reproducibility fidelity, strong vulnerability-matching precision, and reduced manual validation time. These results show that richer provenance can be operationalised. They do not show that every AI environment will expose the same state, that every vulnerability will be found, or that an attested record settles questions of model quality.
The distinction between integrity and quality is therefore foundational. A cryptographic hash can establish that the object inspected later is the object that was recorded, assuming the surrounding process and key material are trustworthy. It cannot establish that the object deserved to be trusted in the first place. A completeness score can show that certain fields were populated under a defined generator and scoring method. It cannot turn missing training information into known information, and it cannot substitute for a safety evaluation.
This is why “more than an SBOM” should not be read as a marketing claim for a bigger document. It describes a change in the unit of accountability. The relevant unit is not just a package collection; it is a model-and-data system executed in an environment, under controls, by organisations, with outputs that may be reused by people who were not present when the system was built. An AIBOM is valuable to the extent that it makes those relationships inspectable and preserves uncertainty where they cannot be established.
The next question is consequently concrete: what must be represented when a model is only one part of the system producing an outcome? Answering it requires looking closely at the AIBOM's six domains and the relationships that make them more informative together than apart.