If you buy software that contains AI, you are also buying its models, its training data and the services it quietly calls. Most buyers see a demo, a security questionnaire and a price. They rarely see which models, data and services sit behind the feature they are paying for.
In May 2026 the cybersecurity agencies of the G7 countries published a document that tries to fix this. It is called Software Bill of Materials for AI: Minimum Elements, and it lists what an inventory of an AI system should record. This article is for the operations, product or technology lead who has to decide which of those items to ask a vendor for, and what to do when the vendor does not provide them.
What the G7 document is, and what it is not
A software bill of materials (SBOM) is an ingredients list for software. The G7 guidance extends that idea to AI systems. The document describes an SBOM for AI as a structured record of the components used to build an AI system and the relationships between them (G7 Cybersecurity Working Group, 2026). It says AI systems are also software systems, so the usual SBOM minimum elements still apply and the AI items come on top of them.
It was published jointly by agencies from Germany, Italy, France, Canada, the United States (CISA), the United Kingdom and Japan, in collaboration with the EU Commission. CISA announced it on 12 May 2026.
Two limits matter for a buyer. First, the minimum elements are not mandatory, and the document says it creates no requirements, standards or legislation. A vendor does not have to follow it. Second, the authors say an SBOM for AI is not enough on its own: it only helps if it is connected to tools such as vulnerability scanning and management, and to security advisories.
The seven clusters, in plain language
The guidance groups its items into seven clusters. Here is what each one gives you as a buyer.
- Metadata describes the bill of materials itself: who wrote it, which version, when it was last updated, and in what data format. You get to see whether the record is current.
- System level properties cover the product as a whole: its components, version, data flow, how data is used, input and output types, and the intended application area. You get the overall picture of what the product does with your data.
- Models identify each model in the system: name, version, producer, description, licence, a hash of the model file where available, and references such as a model card. You get to know which models you depend on.
- Dataset properties describe the data used over the model's life: where it came from, what it contains, whether it includes personal or copyright-protected data, and its licence. You get to judge data risk and what you may legally do with the system.
- Infrastructure lists the software the system runs on, such as libraries, frameworks and runtimes, and links to a hardware bill of materials where one exists. You get dependencies that matter if you host the system.
- Security properties record security controls, certifications and standards the producer has obtained, a link to the producer's security.txt file, and where to look up known vulnerabilities. You get a view of how the vendor protects the system and how problems get reported.
- Key performance indicators include security metrics and operational measures such as uptime, latency and incident resolution time. You get performance evidence, mostly for technical teams.
The lesson: the clusters cover the whole system, but a buyer gets the most from the models, data, licence and security items.
Which items to ask for first
The G7 document sets out a minimum set of elements, not an exhaustive one, and it does not rank them by importance for a buyer. The following order is our judgement, not part of the guidance. For most business software with AI features, these are the items that answer real buying questions.
- Which models are in the product, from whom, and in which version. The Models cluster covers model name, producer and version. Without this you cannot tell whether a published vulnerability or a licence change affects you.
- Where your data goes and how it is used. The system data flow element covers input and output endpoints and the external services the system calls. The data usage element points to documentation on whether data is used to improve the model and whether the APIs log it. This is the item most closely tied to privacy and confidentiality.
- Licences. The guidance asks for the licence of the model and of each dataset, including whether a model is open weight. If you plan to build on top of the product, this decides what you are allowed to do.
- Dataset provenance and sensitivity. The guidance asks for the origin of data, how it was collected, and whether it includes personal, copyright-protected or sensitive data. Ask for this when the system makes decisions about people or handles regulated data. For a drafting assistant, a short answer may be enough.
- Vulnerability and security contacts. The guidance includes a link to the producer's security.txt file and links to repositories of known vulnerabilities. This is cheap for a vendor to supply and tells you whether anyone is watching for problems. For vendors selling into the EU there is also a legal side: since 11 September 2026 the Cyber Resilience Act requires manufacturers to send an early warning within 24 hours of becoming aware of an actively exploited vulnerability, as our article on CRA vulnerability reporting explains.
- Infrastructure dependencies. Libraries, runtimes and frameworks matter most when you host the system yourself or pay for a custom build.
Match the depth to the risk
A reasonable rule, again our own: ask for more as the consequences of failure grow. A meeting-notes tool that sees internal calendars needs a short answer on models and data use. A system that scores job applicants, approves payments or touches customer health or financial records needs the full set of data and security elements.
Put the request in writing before you sign. Our article on questions to ask an AI vendor before signing covers data access, records, exit and price in that conversation, and vetting a new software vendor covers general security questions. A bill of materials adds the technical facts about what is inside the product.
What to do when the vendor says no
Because the G7 document is voluntary, you should expect partial answers. Some elements may be unknown to the vendor itself. The guidance anticipates this: where a version or hash is not available, the author should record that the value is unknown. An honest "unknown" is more useful than a vague reassurance.
Practical options:
- Ask for the gap to be written down. A vendor that cannot name its models has told you something.
- Narrow the use. Keep the product away from sensitive data until the missing items are provided.
- Put it in the contract. Require notice of model changes. Our guide on what to do when an AI vendor changes the model or pricing shows how to plan for that.
When this advice does not fit
If you only use a consumer chat tool with no company data, a full bill of materials is excessive. If your vendor is a very large provider, you may get public documentation such as model cards rather than a tailored document, and that can be acceptable for low-risk use. Finally, this is early guidance that the authors expect to expand, so check the source before you put it in a contract.
Your next step
Pick the one AI system in your company that handles the most sensitive data. Send its vendor a short list: the models and versions, the data flow, whether your data is used to improve the model, the licences, and where to report a vulnerability. Record what you get back, including every "unknown". If you want help deciding what to require from vendors, or what to build yourself instead, talk to our AI consulting team.
Sources
- G7 Cybersecurity Working Group (BSI, ACN, ANSSI, CSE, CISA, NCSC, NCO, with the EU Commission), Software Bill of Materials for AI: Minimum Elements, 2026, hosted by BSI: bsi.bund.de. Source for the seven clusters, the element names and examples, the statements that the elements are not mandatory and not exhaustive, and the "unknown" convention.
- CISA, Software Bill of Materials for AI - Minimum Elements, published 12 May 2026: cisa.gov. Source for the publication date and CISA's description of the guidance.
- G7 Cybersecurity Working Group, A shared G7 vision on Software Bill of Materials for AI, June 2025, referenced by the 2026 document: acn.gov.it. Background only.
The ranking of items, the risk-based depth rule and the options for vendors that decline are our own judgement, not part of the G7 guidance. We have not verified whether any particular vendor provides an AI bill of materials.
