Software Bill of Materials lists got serious in 2021 after the Executive Order 14028 mandate following SolarWinds. AI Bill of Materials are following the same trajectory, driven by a similar realisation: organisations deploying AI systems often have no idea what is actually in those systems. Which base model. Which training data. Which fine-tuning datasets. Which dependencies. The opacity has consequences for security, compliance, intellectual property, and operational risk. The AIBOM is the proposed solution.
The concept is still new enough that the standards are unsettled. The direction is clear.
What goes into an AIBOM
An AI system is more than weights. A complete bill of materials covers, at minimum:
Base model. The foundation model the system was built on. Llama-3, Mistral-Large, GPT-4, Claude, Gemini, version, source, license. For closed-API systems this is API endpoint plus version. For open-weight systems this is the specific checkpoint and provenance.
Fine-tuning data. The datasets used to fine-tune or instruction-tune the model. Source, licensing terms, sensitive-data classification, provenance.
Training data, where applicable. For models trained from scratch, the training corpus details. The largest unresolved issue in AIBOM standardisation is how granular this needs to be, full data inventories may be impossible at scale.
Adapter models. LoRA, QLoRA, prompt-tuning artifacts applied on top of the base model.
Evaluation results. Performance on standard benchmarks (MMLU, HumanEval, MATH, GSM8K), task-specific evaluations, fairness and bias metrics, security evaluations.
Software dependencies. The frameworks, runtime libraries, inference servers, vector databases. This overlaps with traditional SBOMs.
Hardware requirements. GPU memory, quantisation level, expected latency profile.
Known issues and limitations. Documented hallucination patterns, refusal behaviours, jailbreak susceptibility, language coverage gaps.
Cryptographic hashes. Of the model weights, of the data files, of the build artifacts. Tamper detection.
Author and accountability. Who trained the model, who maintained it, who is responsible for it.
The Linux Foundation’s SPDX 3.0, released in 2024, includes an AI profile that formalises many of these elements. CycloneDX has done similar work. Both at spdx.dev and cyclonedx.org.
Why AIBOM matters
The motivations driving AIBOM adoption:
Vulnerability response. When a vulnerability is disclosed in a base model, an inference framework, or a training-data source, organisations need to know which of their deployed systems are affected. The XZ Utils incident demonstrated the speed at which this information needs to flow; AI systems will face equivalent moments.
Regulatory compliance. The EU AI Act has provisions requiring documentation of training data, model evaluations, and system characteristics. Organisations deploying high-risk AI systems will need to produce something AIBOM-shaped to demonstrate compliance.
Intellectual property and licensing. Many AI training datasets and fine-tuning corpora have specific licence terms. Knowing which corpora trained your derived model is necessary to determine your licensing position. The 2023-2024 wave of copyright lawsuits against AI companies (NYT v. OpenAI, Getty v. Stability) raised the stakes.
Security review. Models can be backdoored. The 2024 research on "model poisoning" demonstrated that weights modified in subtle ways could carry hidden behaviours triggered by specific inputs. Verifying provenance and integrity of model weights is part of defending against these attacks.
Customer transparency. Organisations buying AI systems increasingly want to know what they are buying. AIBOMs are the credible technical answer to "what is in this system."
Sensitive-data exposure. If training data contains personal or proprietary information, knowing this is essential for risk management. Cases of LLMs leaking training-data segments are documented.
What an AIBOM does not solve
Knowing what is in a model does not, by itself:
Determine whether the model is safe to deploy. The AIBOM is documentation; deployment decisions still require evaluation.
Reproduce the model. Even with full data and configuration documentation, modern training is non-deterministic; reproduction is hard.
Establish that training data was lawfully acquired. The AIBOM lists what is there; legality is a separate analysis.
Make the model interpretable. Knowing the training data helps; it does not explain why a specific output was produced.
The standards landscape
Multiple initiatives are converging:
NIST AI 100-1 (the AI Risk Management Framework, 2023) calls for documentation of AI systems including provenance, training data, and capabilities. At nist.gov/itl/ai-risk-management-framework. Specifies the "what" but is intentionally generic on the "how."
ISO/IEC 42001 (AI Management System Standard, 2023) requires organisations operating AI systems to maintain documentation supporting risk management. Drives AIBOM-shaped artifacts as part of audit evidence.
EU AI Act (Regulation (EU) 2024/1689) high-risk system requirements include detailed technical documentation. Annex IV of the Act enumerates required documentation; much overlaps with AIBOM contents.
OpenSSF AIBOM Working Group (under the Linux Foundation umbrella) is developing reference implementations and integration patterns with existing SBOM tooling.
Hugging Face Model Cards. Less formal than AIBOM but the closest thing to a community standard for documenting models in 2026. Templates require many AIBOM-equivalent fields. Hub at huggingface.co.
Stanford HELM (Holistic Evaluation of Language Models) at crfm.stanford.edu/helm provides one of the more rigorous public evaluation frameworks; AIBOMs increasingly cite HELM-style evaluations.
What organisations should do now
For organisations developing AI systems:
Maintain a model card or AIBOM-equivalent for every model deployed. The Hugging Face Model Card template is a defensible starting point.
Track training and fine-tuning data lineage. Knowing what your model was trained on is the highest-leverage transparency investment.
Capture evaluation results at deployment time. Snapshots of how the model performed against your benchmarks at the moment it went live.
Maintain dependency lists for the inference stack. SBOMs for the surrounding software, AIBOMs for the model itself.
Build version control. Every retraining, every fine-tuning run, every prompt-template update becomes a version that can be tracked and rolled back.
For organisations procuring AI systems:
Ask vendors for AIBOM-equivalent documentation. Vendors that cannot provide it are a procurement risk. Vendors that provide model cards may be doing the right thing without using the AIBOM label.
Specify what training data the model was trained on, including any data with sensitive licensing or privacy implications.
Specify ownership of fine-tuning data when you provide it; clarify whether vendor-deployed fine-tuning incorporates your data into the base model.
Require notification of significant model changes, base-model upgrades, fine-tuning runs, prompt-template revisions.
Treat AI system procurement with the same supply-chain rigour as software procurement. The risks are similar; the maturity is lower.
The longer view
The AIBOM concept will follow the SBOM trajectory. From "good idea" to "regulatory requirement" to "table-stakes for procurement" took roughly five years for SBOMs. AIBOMs are likely faster because the regulatory pressure is more immediate and the harm cases are clearer.
Standardisation is the friction. Every AI system has different relevant attributes; rigid one-size-fits-all schemas fail. The successful patterns will be the ones that combine a small mandatory core with rich optional extensions, the way SPDX has done for software.
The deeper change is cultural. AI systems have, until now, often been deployed with less documentation than equivalent traditional software. The pendulum is swinging. Organisations that build the documentation muscle now will be operating with less risk and better compliance than those that wait. The AIBOM is the most concrete artefact of that shift.