AI Bill of Materials

When a vulnerability is discovered in a foundational component of your AI stack — a poisoned training dataset, a compromised model weight file, a CVE in a dependency — you need to know immediately which systems are affected. Without an AIBOM, that investigation is manual, slow, and incomplete. With an AIBOM, it is a database query.

An AIBOM captures five categories of AI system provenance: (1) **Model components** — base model identifiers, version hashes, and provider attestations; (2) **Dataset lineage** — training and fine-tuning datasets with sources, licenses, and data processing transformations; (3) **Code dependencies** — the full software bill of materials (SBOM) for the serving infrastructure; (4) **Evaluation metadata** — benchmark results, bias assessments, and safety evaluations conducted pre-deployment; (5) **Deployment context** — hardware, runtime environment, and configuration that could affect model behavior.

The regulatory driver is accelerating. The EU AI Act requires technical documentation for high-risk AI that maps directly to AIBOM concepts. The US NIST AI RMF's "Govern" and "Map" functions require supply chain transparency. CISA's AI Security Roadmap explicitly calls for AIBOM adoption across federal systems. Enterprise procurement teams are beginning to require AIBOM attestations from AI vendors as a contract condition — mirroring the now-standard SBOM requirement in enterprise software procurement.