The software world learned a hard lesson over the last decade: you cannot secure or trust something when you do not know what it is made of. The answer was the software bill of materials, an inventory of the components, libraries, and dependencies that go into a piece of software. When a vulnerability appears in a widely used library, the bill of materials is what lets an organization answer, quickly, whether they are affected. AI is now arriving at the same lesson, and the answer has the same shape: an AI bill of materials, or AI BOM.
What an AI BOM records
An AI BOM is an inventory of what your AI systems are built from. At minimum that means the models in use, including versions and providers; the data sources the system can draw on, including their sensitivity and lineage; and the tools the system can call, including their scopes and risk. It is the structured answer to the question "what is this AI actually made of and what can it reach."
There are two useful levels at which to keep this. At the system level, an AI BOM describes a deployed AI application as a whole: these models, these data sources, these tools. At the interaction level, it describes what a particular request actually used: this model answered, drawing on these sources, calling this tool. The system-level view tells you what is possible. The interaction-level view tells you what happened. Both matter, and the second is the one that turns the BOM from a static document into a living record.
Why enterprises increasingly need one
The pressure for an AI BOM comes from several directions at once. Regulators and emerging standards expect organizations to know and document what their AI is composed of. Customers conducting due diligence ask what models and data are involved before they will trust a vendor's AI. And internal risk functions need to know, when a model is deprecated or a data source is found to be compromised, which AI systems and which past interactions are affected. Each of these is the same question a software bill of materials answers, asked of AI.
There is also a faster-moving reason. The AI supply chain changes constantly. Models are updated and retired, providers change terms, tools are added and removed. Without an inventory, you cannot reason about the impact of any of those changes. With one, you can ask "which of our systems used that model" and get an answer, the same way the software world learned to ask "which of our systems use that library."
Where an AI BOM comes from
You can try to maintain an AI BOM as a hand-curated document, and it will be out of date within a sprint, because the underlying reality changes faster than anyone updates a spreadsheet. The durable approach is to derive it from records you are already keeping, and the natural source is the audit trail.
The audit trail captures, for each interaction, which model answered, which data and chunks were involved, and which tools were called. That is precisely the raw material of an interaction-level AI BOM. The tool registry, covered in building an approved tool registry, contributes the tool inventory. The model catalog behind the LLM gateway contributes the model inventory. Classification at ingestion contributes the data inventory. The AI BOM is, in large part, an aggregation and presentation of governance records you already produce if you are governing AI properly. The complete guide to the AI audit trail shows where the underlying records come from.
The point of it
An AI BOM is not paperwork for its own sake. It is the thing that lets you respond to change and to scrutiny with facts instead of guesses. When something in the AI supply chain shifts, or when someone asks you to account for what your AI is built from, the difference between a confident, specific answer and an uncomfortable silence is whether you maintained a bill of materials. And the cheapest way to maintain one is to build it from the audit trail you should be keeping anyway.