Inteltech
An AI Bill of Materials Is Not a Control
A list of model components tells you what went in. It does not tell you what the model will do. SBOM taught that lesson the hard way.
A bill of materials answers a narrow question: what is in the box. It is a good question. It is not the question an authorizing official is actually asking, which is what the box will do when it is wrong.
The AI bill of materials is being sold as a transparency regime. It is better understood as an inventory format with a transparency side effect. That distinction decides whether it becomes a useful control or a form that everyone fills out and nobody reads.
What a BOM is good for
A BOM is an incident response tool before it is anything else. When a vulnerability lands in a component, the BOM tells you which systems contain it. When a model's provenance is questioned, the BOM tells you where it came from and what it was built on.
That is real value, and it is the value SBOM delivered in software. A software bill of materials lets an organization answer "are we exposed" in hours instead of weeks. It does not tell you whether the software is secure. It tells you what you have.
An AI BOM does the same job for models. Base model and version, fine-tuning approach, training data sources, third-party components, evaluation results, known limitations. Useful fields, all of them.
What it cannot answer
Four questions sit outside the format.
What will the model do? A list of ingredients is not a behavior. Two models with identical BOMs can behave differently because of training order, data quality, and reinforcement learning choices that a BOM does not capture.
Is the training data lawful? A BOM can name a source. It cannot establish that the source had the right to the data, that the license permits this use, or that the data was collected with consent. Those are legal determinations, not inventory fields.
Is there a backdoor? Weights can encode behavior that only activates on a trigger. No BOM field reliably detects it. Detection comes from adversarial testing, and testing is a different artifact.
Is the model still the model you approved? Providers update models. A BOM is a snapshot. Without a version pin and an update notification requirement, the inventory goes stale quietly.
That last one is the practical failure. An approved BOM for a model that has since been updated is worse than no BOM, because it creates a record that says you checked.
The SBOM precedent
Software went through this exact arc, and the lesson is available for free.
In May 2021, an executive order on cybersecurity required software vendors to the federal government to provide a software bill of materials. NTIA then published the minimum elements for one. The intent was supply chain visibility after a series of compromises that were hard to trace.
What happened next is familiar. SBOMs became a procurement checkbox. Vendors generated them, buyers collected them, and the documents accumulated in repositories where nobody queried them. The organizations that got value were the ones that wired the BOM into vulnerability management, so a new advisory triggered a query instead of a meeting.
The AI BOM is on the same path. NTIA's AI accountability work recommended documentation practices. It did not create a certification, and no FAR or DFARS clause requires an AI BOM by name today. That means the format will be defined by whoever has a use for it, and the use that matters is incident response.
What to require instead
If a program wants evidence that a model is safe to deploy, a BOM is one input. The rest of the package is more useful.
- An evaluation record. Test set, scoring method, threshold, and the name of the person who signed it. Not a benchmark score from a vendor blog.
- A data provenance attestation. Who supplied the data, under what terms, and what the provider will do if a claim is challenged.
- A version pin and an update notice. The exact model version approved, and a contractual obligation to notify before it changes.
- A red-team scope statement. What was tested, what was not, and what the provider considers out of scope. The gaps are the interesting part.
- A rollback path. If the model is updated or withdrawn, what runs in its place, and how fast.
Those five items plus a BOM is a defensible package. A BOM alone is a manifest.
Inventory is the beginning
The AI BOM is worth building. It makes an AI estate legible, and legibility is a precondition for every control that follows. The mistake is treating the artifact as the assurance.
A bill of materials tells you what you bought. It does not tell you what you bought will do. The difference is the entire job of deploying AI in a place where being wrong has consequences.
Build the BOM. Then build the evaluation, the pin, and the rollback. The BOM tells you where to look when something goes wrong. The other three are what you do when you get there.