In March 2025, Anthropic, Google, and Microsoft co-published a model card schema proposal to the AI ML Safety community, and by early 2026, NIST's AI Risk Management Framework had drafted language requiring "component-level provenance disclosures" for foundation models. The trigger wasn't hypothetical: security teams kept discovering that models pulled from public hubs bundled training data of unknown origin, quantization steps that silently altered behavior, and fine-tuning adapters sourced from repositories with no license trail. A traditional SBOM lists open-source packages and their versions. It says nothing about the weights a model was trained on, which datasets shaped it, or which upstream checkpoint it was distilled from. That gap has a name now: the AI-BOM, or AI bill of materials. It extends software bill of materials thinking to machine learning artifacts so that model transparency stops being a marketing claim and becomes a verifiable, auditable record.
What Is an AI-BOM, and How Is It Different from an SBOM?
An AI-BOM is a structured, machine-readable inventory of everything that went into producing a model — not just the code that runs it, but the data, weights, training lineage, and post-training modifications. A standard SBOM, built to formats like SPDX 3.0 or CycloneDX 1.6, enumerates software components: a package name, a version string, a license, maybe a hash. That works because software components are discrete and versioned. Models are not. A 7-billion-parameter Llama-derivative fine-tuned on a proprietary dataset, then quantized to 4-bit precision and merged with a LoRA adapter, has no single "version number" that captures what changed at each step.
CycloneDX addressed this directly in its 1.5 specification, released in April 2023, by adding a dedicated ml-bom component type that captures model parameters, datasets, and quantitative analysis metadata. OWASP's CycloneDX working group extended this further in 1.6 (2024) with explicit fields for model cards, training data references, and "considerations" — bias, safety, and fairness disclosures modeled after Google's and Hugging Face's model card conventions. The practical difference: an SBOM answers "what code is running," while an AI-BOM answers "what shaped this model's behavior, and can I trace it back to source."
Why Do Regulators Suddenly Care About Model Transparency?
Because opaque models have already caused measurable harm, and regulators are done waiting for the industry to self-police. The EU AI Act, which entered into force in August 2024, imposes documentation obligations on providers of General-Purpose AI (GPAI) models starting August 2025 — including a technical documentation package covering training data summaries, computational resources used, and known limitations. Article 53 specifically requires GPAI providers to maintain documentation "sufficiently detailed" for downstream deployers to understand the model's capabilities and constraints.
In the United States, Executive Order 14110 (October 2023) directed NIST to develop guidance for dual-use foundation model reporting, and the resulting NIST AI 600-1 profile explicitly references provenance tracking as a control category. Separately, in December 2023 the White House OMB memo M-24-10 required federal agencies procuring AI systems to obtain documentation on training data provenance and model evaluation results before deployment. None of these mandates work without a standardized artifact to point to — which is exactly the role an AI-BOM is designed to fill.
What Actually Goes Into an AI-BOM?
At minimum, a usable AI-BOM captures five categories: model identity (architecture, parameter count, checksum of the weights file), training data lineage (dataset names, sources, licensing, and known contamination or bias flags), training infrastructure (base model or checkpoint it derives from, fine-tuning method, hyperparameters), post-training transformations (quantization, pruning, distillation, merged adapters), and evaluation results (benchmark scores, red-team findings, safety card contents). CycloneDX 1.6's ML-BOM extension models this as nested components: a root model component with child components for each dataset and each upstream model it was derived from, linked via dependsOn relationships — the same dependency-graph pattern SBOMs use for software packages, applied to model lineage instead.
This matters concretely. In 2024, researchers documented "model soup" and merge techniques (like the LLM merging methods behind Goliath-120B and other community mashups) where a single published model was actually a weighted combination of three or four base models with no disclosed provenance. Without an AI-BOM, a downstream user has no way to know that a "new" 120B model actually inherited the training data — and any embedded vulnerabilities or license violations — of four unrelated upstream projects.
Can a Poisoned or Mislabeled Model Actually Slip Through Today?
Yes, and it already has, repeatedly, on the largest public model hub in existence. In February 2024, security researchers at JFrog identified roughly 100 malicious models on Hugging Face — including PyTorch pickle files crafted to execute arbitrary code on load, some establishing reverse shells to hardcoded IP addresses the moment a user ran torch.load(). Hugging Face hosts more than 1 million public model repositories as of 2026, most uploaded with minimal vetting beyond automated pickle-scanning, which catches known-bad patterns but not undisclosed training data, backdoored weights, or falsified benchmark claims.
This is a direct parallel to the npm and PyPI typosquatting problem SBOMs were originally built to address — except a malicious model doesn't need obfuscated code to cause harm. A model can be perfectly clean at the code level and still be a supply chain risk because its weights were trained on a poisoned dataset, or because a "fine-tuned for enterprise support" checkpoint quietly encodes a backdoor trigger phrase. An AI-BOM doesn't prevent the poisoning, but it makes the poisoning traceable — you can see which dataset was declared, cross-reference it against known-bad training corpora, and hold the publisher accountable when the declaration is false.
Do Any Real Organizations Require AI-BOMs Yet?
Some do, though enforcement is still early and uneven. The US Department of Defense's Cybersecurity Maturity Model Certification (CMMC) ecosystem has begun referencing AI provenance documentation in draft supplier guidance as of 2025, and several large financial institutions now require an ML-BOM as a prerequisite for approving any third-party model for production use — a policy that accelerated after the Hugging Face malicious-model disclosures. IBM, Google, and Anthropic have each published model cards for their flagship releases (Granite, Gemini, and Claude respectively) that cover a subset of AI-BOM fields — training data categories, intended use, and evaluation results — though none yet publish a fully machine-readable CycloneDX ML-BOM alongside a public model release.
The gap between "model card exists" and "AI-BOM is machine-readable and continuously verifiable" is exactly where most organizations sit today. A PDF model card is a start; it is not something a CI/CD pipeline can automatically diff against a policy, the way a CycloneDX SBOM can be diffed for a newly introduced CVE.
How Safeguard Helps
Safeguard extends the same supply chain security discipline it applies to open-source dependencies and container images to machine learning artifacts. For teams pulling models from Hugging Face, internal registries, or third-party APIs, Safeguard generates and validates CycloneDX ML-BOM-compliant records that capture model identity, declared training data sources, upstream checkpoint lineage, and known CVEs in the serialization format (catching unsafe pickle deserialization before it reaches a production torch.load() call).
Because AI-BOMs are only useful if they're enforced, Safeguard integrates model provenance checks directly into CI/CD gates: a build fails if a model component lacks a declared data source, if its checksum doesn't match the AI-BOM record, or if it depends on an upstream model flagged in threat intelligence feeds. That closes the same gap SBOMs closed for open-source packages — turning "we trust this model because someone said so" into "we verified this model's lineage against a signed, auditable record" — and gives compliance teams a concrete artifact to hand auditors under the EU AI Act, NIST AI RMF, or internal model-risk policies, instead of a best-effort PDF.
If your organization is deploying third-party or fine-tuned models into production, Safeguard can help you establish AI-BOM generation and enforcement before regulators — or an attacker — force the issue.