AI Bill of Materials (AI-BOM)

A standard software bill of materials enumerates code dependencies: libraries, packages, versions, known CVEs. It says nothing about what a model was trained on, which inference provider processes a system's prompts, or which fine-tuning dataset shaped a model's behaviour. An AI-BOM extends the same discipline — a structured, queryable inventory — to the parts of an AI system an SBOM cannot see.

A complete AI-BOM documents: the model(s) in use (provider, version, whether fine-tuned); the training and fine-tuning data sources, where known and disclosed; the inference infrastructure (self-hosted or third-party, and which); the frameworks and orchestration libraries connecting the model to the application; and any tool or plugin integrations (including MCP servers) the system depends on at runtime.

The AI-BOM's practical use is triggering re-assessment. A documented model version change, a new fine-tuning dataset, or an added tool integration each maps to a specific row in the AI-BOM — and each is a defined re-assessment trigger in a structured security review, rather than a change that ships without anyone noticing the system's risk profile shifted.

AI-BOM data is frequently incomplete for third-party and vendor-embedded AI, where training data and infrastructure details are often undisclosed. An honest AI-BOM records the gap explicitly (unknown/undisclosed) rather than omitting the row — an omitted row looks like the risk doesn't exist; a row marked undisclosed is a visible evidence gap the disposition can act on.

Regulatory relevance is growing. The EU AI Act's technical documentation requirements (Article 11) and transparency obligations for general-purpose AI models both point toward the same underlying need an AI-BOM satisfies: a structured, current record of what an AI system is actually built from.