AI Bill of Materials: The 7 Fields Auditors Will Look For First
Ensure compliance with the EU AI Act and SOC 2 by implementing these 7 essential AI Bill of Materials fields for model provenance and security.
An AIBOM is the inventory auditors read first
An AI Bill of Materials (AIBOM) is a structured inventory of the components behind an AI system: datasets, models, software dependencies, and the metadata that ties them together. Auditors prioritize a handful of fields — model identifiers, data provenance, dependency and vulnerability records — because those fields answer the first questions in any assessment for the EU AI Act, SOC 2, or an enterprise security review: what is this system made of, where did each part come from, and what is known to be wrong with it. The AIBOM extends the software bill of materials (SBOM) idea to AI, and it is read the same way — as a claims document whose value depends entirely on whether each field is specific, verifiable, and current. The seven fields below are where that reading starts, ordered roughly as auditors reach them.
Field 1: model identity and version
The first field auditors check is the exact identity of each model in the system: a name, a version, and an identifier unique within the document, with a cryptographic hash where the model artifact is distributable. Everything else in an AIBOM hangs off identity — evaluation results, vulnerability findings, and license terms all attach to a specific version, and an inventory that says "our recommendation model" cannot anchor any of them. In structured BOM formats, each component carries a unique reference that other parts of the document point to, so an ambiguous or duplicated identifier breaks the document's internal integrity, not just its readability. Include every model that affects output, not only the headline one: embedding models, rerankers, classifiers, and safety filters are all components, and auditors increasingly ask about the ones vendors forget to list.
Field 2: training and evaluation data provenance
For each dataset used in training, fine-tuning, or evaluation, record the source, the version or snapshot date, the license or legal basis for use, and the transformations applied before use. This is the field that connects the AIBOM to the questions regulators actually ask: whether personal data was involved, whether the license permits commercial model training, whether evaluation data leaked into training data. Precision matters more than volume — a named public dataset with a version and license beats a paragraph about "diverse, high-quality data." Where a dataset is proprietary, describe its category, origin, and governance rather than omitting it, and say explicitly when the provenance of an upstream dataset is unknown. An honest "unknown" is auditable; a confident blank is a finding waiting to happen.
Field 3: base models and upstream lineage
Most production AI systems are built on someone else's model — a foundation model consumed through an API, an open-weights model fine-tuned in house, or both. The AIBOM must record that lineage: which upstream model and version, from which supplier, under which license or terms of service, and what was done downstream — fine-tuning, quantization, distillation, prompt scaffolding. Upstream lineage determines inherited risk. If the base model's training data is undisclosed, your system inherits that opacity; if its license restricts fields of use, your deployment inherits the restriction; if the supplier retires the version, your system inherits the deprecation. Auditors read this field to size third-party concentration risk, and buyers read it to learn whether they are evaluating your engineering or your supplier's. State it plainly either way — it will surface in technical assessment regardless.
Field 4: the software dependency inventory
AI systems ship on ordinary software, and the ordinary software rules apply. The AIBOM should include, or link to, a dependency inventory in which each library carries an ecosystem-qualified identifier — the package URL (purl) convention, such as pkg:npm/lodash@4.17.21 or pkg:pypi/requests@2.31.0, is the established way to do this — so components can be matched mechanically against registries and advisory databases. Distinguish what you actually resolved: direct dependencies read from manifests are solid evidence, while a full transitive graph is a stronger claim that requires lockfile-level resolution to back it. BOM formats treat presence and absence as meaningful — in CycloneDX, an empty dependency list for a component asserts that it has no dependencies, whereas omitting the section says the data is unknown. Asserting more than you resolved turns an inventory gap into a false statement.
Field 5: known vulnerabilities mapped to advisories
An inventory becomes a security document when its components are matched against public advisory databases such as OSV, the open-source vulnerability aggregation point. For each finding, record the advisory identifier, its source, a severity rating, and — critically — a reference to the exact affected component in the inventory, so the vulnerability record and the component record stay connected inside one document. Auditors check two things here. First, freshness: vulnerability data decays daily, so the AIBOM should state when matching was last run. Second, honesty of scope: matching covers only what the inventory covers, and a clean report over an incomplete inventory is false comfort. AI-specific weaknesses — model-level attacks, data poisoning — do not yet have advisory infrastructure as mature as software CVEs, so say what this field covers and what it cannot.
Field 6: licenses and usage rights
License information in an AIBOM spans three layers, and auditors expect all three. Software dependencies carry open-source licenses with familiar compliance obligations. Models carry their own terms — open-weights releases often use custom licenses with field-of-use limits, user thresholds, or attribution requirements stricter than they first appear — and API-consumed models carry terms of service that constrain outputs and downstream use. Datasets carry licenses or collection terms that may or may not permit model training at all. Record the specific license or terms for each component, not a summary judgment that everything is "properly licensed." The audit question is not whether you believe you are compliant but whether the document lets someone else verify it: an identifier, a license name or link, and any restriction relevant to the deployment.
Field 7: generation metadata
The last field auditors check is the AIBOM's own provenance: what tool or process generated the document, when, from what inputs, and with what serial number distinguishing this document from every other version of it. Structured BOM formats reserve metadata fields for exactly this — a timestamp, the generating tool, a unique serial number, and a description of the subject the document describes. Generation metadata is what makes an AIBOM evidence rather than prose. A document with no timestamp cannot show that it reflects the system as shipped; a document assembled by hand with no stated process cannot be regenerated or checked. The strongest position is an AIBOM produced automatically from the same pipeline that builds the system, so the inventory is a byproduct of the build rather than a parallel artifact that drifts.
Mapping the seven fields to CycloneDX
CycloneDX, an OWASP-maintained BOM standard, covers these fields concretely, and since specification version 1.5 it supports machine-learning components and model card data directly. The subject of the document lives in metadata.component; generation metadata lives alongside it as a timestamp, the generating tool, and a urn:uuid serial number. Each dependency is a components[] entry with a unique bom-ref and a purl identifier. Vulnerability findings live in vulnerabilities[], each carrying its advisory source and an affects list that references component bom-refs, keeping findings bound to the exact inventory entries they concern. Relationship data lives in dependencies[] as ref and dependsOn pairs — with the semantics noted earlier, where an empty list asserts "no dependencies" and omission means "unknown." Whichever format you choose, the seven fields are the substance; the format is the container.