The SBOM Equivalent for AI: Why You Need an AI Bill of Materials

The SBOM Equivalent for AI: Why You Need an AI Bill of Materials

Software Bills of Materials have been on everyone's radar since Executive Order 14028 in May 2021 made them a federal procurement requirement. The logic was straightforward: if you don't know what's in your software, you can't secure it. The SolarWinds attack made that painfully concrete. Now apply the same logic to AI systems, and you'll realize the visibility gap is significantly worse.

An AI system isn't just code. It's code plus training data plus model weights plus fine-tuning datasets plus inference infrastructure plus prompt templates plus retrieval sources plus evaluation benchmarks. Every one of those components carries risk. And right now, most organizations deploying AI couldn't tell you the provenance of half of them.

What an AI Bill of Materials Actually Looks Like

The concept borrows directly from the SBOM framework, particularly the NTIA's 2021 minimum elements guidance and the two dominant formats, SPDX and CycloneDX. CycloneDX actually added machine learning model support in version 1.5 (released June 2023), which gives us a real, working standard to point to. SPDX 3.0, released in April 2024, added an AI and dataset profile as well.

An AI BOM goes beyond listing software dependencies. It needs to capture several distinct layers of the AI supply chain, each with its own risk profile.

1. Model Provenance

Where did the base model come from? Is it a foundation model from OpenAI, Anthropic, Meta, or Mistral? Is it a fine-tuned derivative? What's the license? Meta's Llama 2 Community License and Llama 3's updated terms have materially different commercial use restrictions. If your vendor fine-tuned Llama 3 and deployed it into your environment, you need to know that. The license obligations flow downstream.

2. Training and Fine-Tuning Data

This is where things get legally interesting. The ongoing litigation around training data, including Doe v. GitHub, Getty Images v. Stability AI, and the New York Times v. Microsoft/OpenAI suit filed in December 2023, all center on what data went into the model. If you're deploying a model in a regulated environment and you can't document the training data lineage, you're carrying risk you haven't priced in. The EU AI Act (Regulation 2024/1689, entered into force August 1, 2024) explicitly requires training data documentation for high-risk AI systems under Articles 10 and 11.

3. Inference Infrastructure

Where does the model run? On-premises, in a specific cloud region, or through an API that routes through who-knows-where? For organizations subject to data residency requirements under HIPAA, ITAR, or various state privacy laws, this matters enormously. If your AI vendor processes inputs through a third-party API hosted in a jurisdiction you haven't approved, your compliance posture just changed without anyone telling you.

4. Retrieval and Grounding Sources

RAG architectures are everywhere now, and they introduce a dependency that traditional SBOMs never had to account for: the knowledge base. What documents are being retrieved? Who controls them? How often are they updated? A RAG system grounded on stale or inaccurate regulatory guidance is a liability generator. You need to track these sources the same way you'd track a software dependency.

5. Prompt Templates and System Instructions

These shape model behavior in ways that are functionally equivalent to code. A system prompt that instructs a model to "always recommend the premium tier" in a financial advisory context could create fair lending issues. Prompt templates need version control, change tracking, and audit trails. They belong in your AI BOM.

6. Evaluation and Testing Artifacts

What benchmarks were used? What red-teaming was performed? NIST's AI Risk Management Framework (AI RMF 1.0, January 2023) emphasizes measurement and evaluation throughout the AI lifecycle. If you're subject to the EU AI Act's conformity assessment requirements for high-risk systems, you'll need to document your testing methodology. Having evaluation artifacts in your AI BOM makes that documentation structural rather than aspirational.

Why Supply Chain Visibility Changes the Risk Calculus

The real value of an AI BOM is the same as the real value of an SBOM: you can actually respond when something goes wrong. When Log4Shell hit in December 2021, organizations with mature SBOM practices could identify exposure in hours. Everyone else spent weeks scrambling.

Now imagine a scenario where a major foundation model provider discloses that a specific model version was trained on data that included protected health information. Or a fine-tuning dataset is found to contain copyrighted material from a plaintiff who just won a $150,000 per-work statutory damages award under 17 U.S.C. Section 504. Without an AI BOM, you don't even know if you're affected.

The NIST Secure Software Development Framework (SP 800-218) already treats supply chain transparency as a baseline expectation for federal suppliers. The October 2023 Executive Order on AI Safety (EO 14110) extended reporting requirements to developers of dual-use foundation models. And the EU AI Act's Article 13 transparency obligations will require deployers of high-risk systems to understand and document the components of the AI systems they use. The regulatory trajectory is clear, and it points toward mandatory AI BOMs within the next two to three years for anyone touching regulated industries.

Practical Steps to Start Building Your AI BOM

You don't need to solve everything at once. Start with an inventory of every AI system in production or in procurement. For each one, document what you can across the six categories above. You'll quickly discover where your visibility gaps are, and those gaps are your risk map.

• Audit your vendor contracts. Do they require disclosure of model provenance, training data sources, and infrastructure details? If not, you're flying blind. Add AI BOM requirements to your vendor assessment questionnaires now.
• Adopt a standard format. CycloneDX 1.5+ or SPDX 3.0 both support ML model documentation. Pick one and use it. Standardization makes the information actionable rather than decorative.
• Integrate with your existing GRC workflows. An AI BOM sitting in a spreadsheet helps no one. It needs to feed into your risk management, incident response, and audit processes.
• Version everything. Models get updated. RAG sources change. Prompt templates evolve. Your AI BOM needs to be a living document with change tracking, not a point-in-time snapshot.

The organizations that build this discipline now will have a structural advantage when regulators start asking for it. And based on the pace of rulemaking in the EU, the trajectory of NIST guidance, and the expanding scope of state-level AI legislation (Colorado's SB 24-205 being a notable example, signed into law May 2024), that timeline is shorter than most people assume.

How FirmAdapt Addresses This

FirmAdapt's architecture was designed with supply chain transparency as a structural requirement, not a bolt-on feature. The platform maintains detailed provenance records for every component in its AI pipeline, including model versions, data sources, retrieval corpora, prompt configurations, and infrastructure details. This documentation is generated automatically as part of normal operations, which means your AI BOM stays current without requiring a separate manual process.

For regulated organizations that need to demonstrate compliance with frameworks like the EU AI Act, NIST AI RMF, or sector-specific requirements under HIPAA and GLBA, FirmAdapt provides audit-ready documentation of the full AI component stack. The goal is straightforward: when a regulator, auditor, or your own incident response team asks what's in your AI system, you can answer immediately and completely.