# Is 2026 the Year AI Bills of Materials Finally Move From Theory to Practice?
As artificial intelligence systems proliferate across enterprises, a critical transparency gap has emerged. Traditional software bills of materials (SBOMs) were never designed to capture the unique risk vectors that AI introduces—and as regulators tighten requirements, organizations are discovering they lack the visibility, standards, and tooling to comply. This year may be the inflection point where AI bills of materials (AI BOMs) transition from a good idea into an operational necessity.
## The Transparency Problem
When organizations deploy AI systems, they inherit risks that conventional security inventories don't address. A machine learning model trained on a compromised dataset, a foundation model with undisclosed licensing restrictions, or a data pipeline pulling from sources with data quality issues—none of these threats appear on a traditional SBOM. Yet they can fundamentally undermine the integrity, legality, and reliability of the AI systems they power.
This gap matters acutely right now. As AI adoption accelerates in 2026, enterprises are deploying models at scale without clear visibility into their composition, provenance, or potential vulnerabilities. Regulators have noticed. The European Union's AI Act now requires documentation of AI system components for high-risk applications. The U.S. is moving in the same direction through Executive Order guidance and sector-specific regulations. And last month, the G7 released formal recommendations spelling out minimum elements that should appear in any AI BOM.
Yet despite this regulatory pressure, practical AI BOM adoption remains largely aspirational.
## What Is an AI Bill of Materials?
An AI BOM extends the SBOM concept to cover the unique components that make artificial intelligence systems function. Where an SBOM inventories code libraries, dependencies, and their versions, an AI BOM must capture:
The core principle is the same as an SBOM: transparency and traceability. But the specifics reflect AI's unique risk profile. A software vulnerability in a library can be patched. A biased training dataset, by contrast, requires retraining or model replacement—a far more disruptive remediation.
## Why AI BOMs Are Different from SBOMs
SBOMs have matured significantly since the U.S. National Telecommunications and Information Administration (NTIA) published standards in 2021. They've become routine in many procurement workflows and security operations.
AI BOMs face several headwinds that SBOMs did not:
Complexity and Opacity — Many modern AI systems rely on foundation models (GPT-style large language models) trained on undisclosed data at tremendous scale. Vendors often cannot or will not share full details about training data composition, creating an inherent transparency ceiling.
Rapidly Changing Landscape — Foundation models are released and updated constantly. Version control and dependency tracking in the AI world lag far behind software practices.
Absence of Standards — While SBOM formats (CycloneDX, SPDX) were standardized early, AI BOM formats and minimum fields are still being defined. Organizations asking vendors for AI BOMs often receive inconsistent, incomparable responses.
Skill Gaps — Many security and procurement teams lack the expertise to evaluate AI components. Understanding model bias, dataset composition, or the implications of a model's training procedure requires specialized knowledge.
## The Regulatory Push
Europe is moving fastest. The AI Act categorizes high-risk AI systems (those used in hiring, credit decisions, law enforcement, or critical infrastructure) and requires detailed documentation—effectively mandating AI BOMs.
In the U.S., the Executive Order on AI Safety (issued in late 2023) pushed agencies to require AI transparency. The National Institute of Standards and Technology (NIST) followed with AI Risk Management Framework guidance. Sector-specific regulators are now embedding AI BOM requirements into broader security mandates. The Federal Communications Commission (FCC), for instance, is considering AI transparency requirements for network systems.
Last month's G7 guidance crystallized a consensus on minimum AI BOM elements:
## The Reality: Still Largely Aspirational
Despite regulatory pressure, practical AI BOM adoption is still in early stages. Daniel Bardenstein, co-founder and CTO of Manifest Cyber, captured the current state bluntly: "Even just educating people on what an AI BOM is is still necessary in a lot of conversations."
Several barriers persist:
Vendor Reluctance — Many AI vendors, particularly those building proprietary foundation models, resist disclosing detailed information about training data or model architecture. They cite intellectual property concerns and competitive sensitivity.
Lack of Tooling — Unlike SBOMs, which benefit from mature generation and scanning tools (Syft, SPDX generators, etc.), AI BOM tooling is sparse. Organizations don't have straightforward ways to generate, validate, or consume AI BOMs at scale.
Definitional Ambiguity — Without consensus standards, "AI BOM" means different things to different vendors. Some submit a few paragraphs of documentation. Others provide data sheets. There's no common schema.
Skill Constraints — The data scientists and ML engineers building models often don't interface with security or compliance teams. Building cultures and processes to generate AI BOMs requires organizational alignment that many enterprises lack.
## Industry Moves Toward Standardization
Some progress is visible. ISACA, the global association for information systems governance, now recommends AI BOMs as standard due diligence during technology procurement. Several vendors (including OpenAI, Anthropic, and Hugging Face) have begun publishing model cards—simplified documentation of model performance, limitations, and intended use.
The Linux Foundation's SBOM and transparency efforts are beginning to address AI components. And academic researchers are proposing AI BOM schemas that could form the basis for future standards.
## Implications for Organizations
For security leaders, the message is clear: visibility into AI components is now a regulatory requirement in many jurisdictions, and it's becoming table stakes for procurement. Organizations without AI BOM practices face three converging pressures:
1. Regulatory exposure — High-risk AI systems deployed without documented BOMs violate emerging regulations in Europe and increasingly in the U.S.
2. Risk blindness — Without understanding what data trained a model or what biases it may carry, organizations can't effectively manage AI-related risks.
3. Vendor lock-in — Lack of transparency about AI components makes it harder to switch vendors, audit systems, or respond to incidents.
## Recommendations for Security Leaders
Start Now
Don't wait for perfect standards. Begin requesting AI BOMs from vendors today, even if the format is inconsistent. This creates demand and helps clarify what information is most critical.
Build Internal Capabilities
Establish lines of communication between your security, compliance, and data science teams. Start documenting your own AI systems' components, even if the format is informal.
Advocate for Vendor Transparency
Include AI BOM requirements in procurement contracts. Make it clear that vendors without transparent AI practices are at a competitive disadvantage.
Track Regulatory Developments
Subscribe to updates from the NIST AI Risk Management Institute, the NTIA, and relevant sector regulators. Regulatory requirements are crystallizing rapidly.
Invest in Tooling
Evaluate emerging AI BOM tools and platforms. The market is nascent, but solutions for AI component tracking, model auditing, and risk assessment are beginning to mature.
---
## HackWire Analysis
The timing of the G7's AI BOM guidance is telling: 2026 is the year when AI deployment reached critical mass in enterprises, and the security visibility gap has become untenable. Unlike SBOMs, which faced a decade of cultural resistance before becoming routine, AI BOMs are being mandated into existence by regulation. This compression of the timeline is good news for defenders—it forces standardization faster.
But there's a deeper risk that most reporting is missing: the vendor opacity problem is structural, not solvable through better forms. If OpenAI, Anthropic, or other foundation model providers won't disclose training data composition (and there are legitimate reasons they resist—licensing complexity, competitive sensitivity, and the sheer scale involved), then no audit standard will close that gap. Organizations will get an AI BOM that says "trained on 2 trillion tokens from public internet sources"—which is almost useless.
The real shift happening this year is different: organizations are moving from "we'd like to understand our AI systems" to "we must understand them, or we cannot deploy them legally." That forcing function matters. It will drive smaller, specialized model builders (who *can* disclose everything) to gain competitive advantage over closed-shop vendors. It will create market demand for interpretability tools and model auditing services. And it will establish that opaque AI in critical systems is increasingly untenable.
The next critical milestone is convergence around schema and tooling. If the industry can solve those two problems in the next 12 months, 2026 will be remembered as the inflection point. If it doesn't, we'll see a painful period where regulations mandate AI BOMs but few organizations can actually produce ones that matter.
— HackWire Editorial
---
## Related Coverage