AI bill of materials

What it does

It tells the organisation what its AI systems are made of. For each system a maintained list names every component, with its version, source and licence: base models, fine-tuned models, datasets, embedding models, libraries, agent tools and hosted endpoints. The list is checked when a vulnerability, a licence problem or a compromised component is reported, so that affected systems can be found at once. Engineering maintains it and security uses it. It is generated at build and updated at every change.

How to implement it

• Generate the list automatically from the build and deployment pipeline where possible.
• Include models and datasets, not only software packages.
• Record source, version, hash and licence for each component.
• Include hosted components and the supplier's own disclosed sub-components.
• Scan the list against vulnerability and security notice feeds.
• Keep the list for each released version, so past states can be examined.

Evidence it operates

Design: a standard defining the required contents. Operation: a current list for each system; scan results and resulting actions; evidence that a reported issue was traced to the systems affected; lists retained for earlier versions.

Where it fits

Produced in the delivery pipeline and used through operation. It is the primary control for LLM supply chain vulnerabilities, and supports third-party model and dataset provenance and sub-outsourcing visibility gap. It complements safe model loading and artefact scanning.

Limits

It lists components and says nothing about whether they are sound. For a hosted model, the provider's internals are a single opaque line. Formats for describing models and datasets are still settling, so tooling is uneven. A list that is not regenerated at each change soon describes a system that no longer exists.