The May 12, 2026 G7 and CISA note is an add-on, not a replacement. A model name with no components is not an ingredients list.
Edited by Emilio Santos. October 1, 2026. Updated October 24, 2026.
The operator buying an AI feature inside a product, and the security reviewer who has to describe what that feature contains.
On May 12, 2026, CISA and G7 partners published minimum elements for a software bill of materials for AI. CISA says AI systems are software systems, so the AI list sits on top of the general SBOM elements. The guide is not exhaustive and not, by itself, a mandate. It is still the public list to point at.
Use it when the product is a model, a copilot, or an agent, not only when the vendor’s engineers compiled a binary. Ask which pieces are the model, which are data or adapters, and which are ordinary application code. If the vendor cannot separate those, you cannot tell whether a later incident is in the model, the data, or the wrapper. A traditional SBOM answers a narrow question: which software components, at which versions, are inside this product. That is enough to answer “are we exposed to this new vulnerability in a library?” An AI product adds parts that a component list does not describe well. The model may come from a third party. It may be fine-tuned with adapters. It may depend on datasets, prompt templates, and retrieval indexes that change without a new software release. If a problem shows up, you need to know which of those parts changed and who supplied it.
Two open formats already carry this kind of information. CycloneDX has a machine-learning bill of materials (ML-BOM) capability for describing models and datasets. SPDX 3.0 includes AI and dataset profiles. Asking for one of these formats gives the vendor a concrete target and gives you something your tools can read.
This is an illustrative case, not a real vendor. A support platform adds an AI reply feature. The vendor sends its standard SBOM, which lists the web application’s open-source libraries. It does not mention the model. On follow-up, the vendor says the feature calls a third-party hosted model and uses a retrieval index built from your help-center articles.
What you now know: the vendor’s SBOM covers its application, the model provider’s documentation covers the model, and the retrieval index contains your own content. What you still need: the model name and version, the provider, how you will be notified of a model change, and whether your articles or tickets are used for anything other than retrieval. Those questions go into the renewal agenda. The SBOM request pack drafts the email.
An AI SBOM lists parts. It does not tell you whether the model is accurate, fair, or safe for your use. For those questions, use a risk framework such as NIST’s AI Risk Management Framework and its Generative AI Profile, NIST AI 600-1. Treat the SBOM as the inventory and the risk review as the judgment. You need both.
For the general SBOM request, see Ask a vendor for an SBOM. For what the agent inside the product can do, see Limit what an agent can touch. No. A model card describes behavior and limits. An SBOM lists components. Ask for the document CISA describes, and keep the model card if you want it for a different question.
Trade secret is a reason to negotiate scope. It is not a reason to accept a blank page. Ask what can be shared: name, version, supplier, license, hash algorithm, generation date.