An AI BOM (AI bill of materials) is the structured, machine-readable record of what an AI system is made of: its models, its datasets, its software dependencies, its infrastructure and the relationships between them. Until this year, what went into that record was whatever a tool vendor decided. Since 12 May 2026 there is an official baseline: the cybersecurity agencies of the G7 published a list of minimum elements, 7 clusters and 50 elements by our count, all voluntary. This guide reads that list the way an auditor would: what an AI BOM records, what it leaves out, which laws make its content demandable anyway, and how to build one that survives the next retraining.
Key takeaways
- An AI BOM extends the software bill of materials (SBOM) to models, datasets, infrastructure and their lineage. It comes in addition to the SBOM, not instead of it.
- The G7 guidance of 12 May 2026 lists 7 clusters and 50 minimum elements by our count. It is voluntary and names no law.
- No EU text requires an “AI BOM” by name. Annex IV, Article 25(4) and Annexes XI and XII of the AI Act, and Annex I of the Cyber Resilience Act, require most of its content.
- It does not record risk, human oversight or test results: it is an ingredient list, not a technical file.
- Dates: general-purpose model documentation since 2 August 2025, CRA reporting since 11 September 2026, high-risk duties and the CRA SBOM from December 2027.
What is an AI BOM?
The G7 agencies define it as a structured record, or inventory, of details and supply chain relationships for the components used in building an AI system. Their own image is the ingredient list. The idea comes from software security, where a software bill of materials tells a buyer which libraries sit inside a product, so that a newly disclosed vulnerability can be traced to the systems that carry it within hours. A classic SBOM is not enough for an AI system, for three reasons. A model is not a library: its behaviour comes from weights and training data that no package manifest describes. A dataset is a component with its own provenance, licence and sensitivity level. And an AI system calls external services, such as a hosted model or a retrieval source, that never appear in a build. The G7 text says it plainly: AI systems are also software systems, so the SBOM stays valid, and the AI elements come in addition to it. That is why an AI BOM belongs to AI security and to documentation at the same time.
AI BOM, AIBOM, ML-BOM, SBOM for AI: one artefact, several names
The names differ by community, not by content. AIBOM or AI BOM is the industry and OWASP spelling. ML-BOM is what the CycloneDX format calls the object. SBOM for AI is the name the G7 agencies chose, and AI SBOM is the name of the OWASP initiative. All four describe the same record. Two neighbours are often confused with it. A model card is prose documentation of one model, written for people; the G7 list points to it by link instead of replacing it. An AI inventory is the organisation-level register of AI systems. The relationship is simple: one inventory record per system, one AI BOM per version of that system, attached to the record.
What an AI BOM contains: the 50 G7 minimum elements
The reference text is Software Bill of Materials for AI, Minimum Elements, published on 12 May 2026. It is signed by Germany’s BSI, Italy’s ACN, France’s ANSSI, Canada’s CSE, the United States’ CISA, the United Kingdom’s NCSC and Japan’s NCO, in collaboration with the European Commission. The work stream was co-led by ACN and BSI under the Canadian (2025) and French (2026) G7 presidencies, and it follows a shared G7 vision issued in June 2025. The full text runs to 26 pages. We read it and counted. <table header-row=”true”> <tr> <td>Cluster</td> <td>Elements</td> <td>What it records</td> </tr> <tr> <td>Metadata</td> <td>10</td> <td>The document itself: author, version, data format and its version, the author’s digital signature, tool name and version, generation context, timestamp, dependency relationship</td> </tr> <tr> <td>System level properties</td> <td>9</td> <td>The AI system as a whole: name, components, producer, version, timestamp, data flow between components and to external services, data usage, input and output properties, intended application area</td> </tr> <tr> <td>Models</td> <td>13</td> <td>Each model: name, identifier, version, timestamp, producer, description (capabilities, known limitations, lineage), hash value and algorithm, architecture and size, input and output properties, training properties, licence, external references</td> </tr> <tr> <td>Datasets properties</td> <td>10</td> <td>Each dataset: name, description, content, identifier, hash, provenance, statistical properties, sensitivity, dependency relationship, licence</td> </tr> <tr> <td>Infrastructure</td> <td>2</td> <td>Software needed to run the system, and hardware by link to a hardware bill of materials</td> </tr> <tr> <td>Security properties</td> <td>4</td> <td>Security controls, security compliance, link to the producer’s security.txt, vulnerability referencing</td> </tr> <tr> <td>Key performance indicators</td> <td>2</td> <td>Security metrics and operational performance (uptime, incident resolution time, latency)</td> </tr> </table> Three things stand out from our reading. First, the weight is on what makes AI different. Models and datasets account for 23 of the 50 elements. Infrastructure has two, and hardware is handled by a pointer to a separate hardware bill of materials. Second, integrity is built in. Each model carries a hash and the name of the hash algorithm, each dataset carries a hash, and the document carries the digital signature of its author. Where the author cannot know a value, for example the hash of a model it only reaches through an API, the guidance says to state that the value is unknown. A blank field and an honest “unknown” are not the same evidence. Third, the model card survives. The “Model training properties” and “Model external references” elements point to it by link. An AI BOM indexes the documentation; it does not absorb it.
AI BOM formats: CycloneDX and SPDX
Two open formats carry an AI BOM today. CycloneDX, an OWASP project standardised as ECMA-424, has offered a machine learning bill of materials since version 1.5. SPDX 3.0, maintained under the Linux Foundation, added an AI profile and a Dataset profile, described in the report Implementing AI Bill of Materials with SPDX 3.0. A presentation hosted by NIST on 19 May 2026 compares them in terms a compliance lead can use: <table header-row=”true”> <tr> <td>Format</td> <td>Strength</td> <td>Limit</td> </tr> <tr> <td>CycloneDX ML-BOM (versions 1.5 to 1.7)</td> <td>Native machine learning types, broad support in open source and commercial tools</td> <td>Fewer AI metadata fields; no native field for sensitive personal data, explainability, autonomy or safety risk</td> </tr> <tr> <td>SPDX 3.0.1 AI profile</td> <td>The deepest AI metadata (explainability, energy, sensitive personal data, safety risk) and formal trained-on and tested-on relationships</td> <td>Tooling still maturing; a JSON-LD format that is less convenient in build pipelines</td> </tr> </table> On tooling, the same source reports that the OWASP AIBOM Generator, an open source project introduced at RSAC 2025, produces CycloneDX 1.6 documents for models hosted on Hugging Face, with the mapping to the SPDX AI profile still in progress in May 2026. The G7 guidance prescribes neither. Its metadata cluster only asks you to state the format name and version. The practical rule is to choose the format your SBOM tooling already produces, because the Cyber Resilience Act will ask for the software part from the same pipeline.
What an AI BOM does not prove
The G7 text states that its elements create no requirements, standards or legislation, and its 26 pages name no regulation: we checked the full text. It is a cybersecurity document, written to trace vulnerabilities. Of the 14 top-ranking pages we analysed on this query, none lists the G7 elements and only one maps the artefact to the technical documentation that the EU AI Act requires. So we did the mapping. The table below is our reading, not a G7 or Commission position. <table header-row=”true”> <tr> <td>What Annex IV of the AI Act asks for</td> <td>In the AI BOM?</td> <td>Where the evidence lives</td> </tr> <tr> <td>Intended purpose, provider, versions (point 1)</td> <td>Partly: system name, producer, version, intended application area</td> <td>Instructions for use, classification record</td> </tr> <tr> <td>Pre-trained systems and third-party tools used, and how they were integrated (point 2(a))</td> <td>Yes: Models cluster, lineage, system components</td> <td>AI BOM plus supplier agreements</td> </tr> <tr> <td>System architecture and how components feed each other (point 2(c))</td> <td>Yes: system components, data flow</td> <td>AI BOM plus architecture description</td> </tr> <tr> <td>Training data: provenance, scope, how it was obtained, labelling, cleaning (point 2(d))</td> <td>Largely: Datasets cluster</td> <td>Data sheets, data governance record (Article 10)</td> </tr> <tr> <td>Human oversight measures (point 2(e))</td> <td>No</td> <td>Oversight design and assignment (Article 14)</td> </tr> <tr> <td>Validation and testing: metrics, test logs, signed reports (point 2(g))</td> <td>Marginal: two indicator elements</td> <td>Test reports, accuracy metrics (Article 15)</td> </tr> <tr> <td>Risk management system (point 5)</td> <td>No</td> <td>Risk management file (Article 9)</td> </tr> <tr> <td>Standards applied, EU declaration of conformity, post-market monitoring plan (points 7, 8, 9)</td> <td>No (security certifications only)</td> <td>Conformity file</td> </tr> </table> The pattern is clear. An AI BOM answers “what is it made of” well and “where did it come from” fairly well. It is silent on “what is it for”, “how risky is it”, “who watches it” and “how do we know it works”. Those four questions decide whether a system is high-risk and whether it passes a conformity assessment. One omission is deliberate. In its discussion section, the G7 group says it considered an element on the level of decision-making or autonomy of the system, recognised its relevance with agentic AI, and decided not to include it, noting that jurisdictions may address it differently, including through safety requirements. For a European reader, that is exactly the territory of Article 14 and of the high-risk classification. The record has to exist, and it will not be in the AI BOM. The agencies also say what the document is not: an SBOM for AI by itself is not sufficient. It has to be connected to vulnerability scanning and management tools, security advisories and bulletins. An inventory nobody queries protects nothing.
Which laws make AI BOM content demandable
No EU provision uses the words “AI BOM”. Several require what it contains.
- AI Act, Article 11 and Annex IV. Providers of high-risk systems draw up technical documentation before the system is placed on the market and keep it up to date. Annex IV point 2 asks for the pre-trained systems and third-party tools used and how they were integrated, the system architecture, and data sheets on training data and its provenance. Article 18 keeps the file at the disposal of authorities for 10 years. After the Digital Omnibus, Regulation (EU) 2026/1744, this applies to Annex III systems from 2 December 2027 and to Annex I product-embedded systems from 2 August 2028.
- AI Act, Article 25(4). The provider of a high-risk system and any third party supplying a system, tool, service, component or process used in it must specify by written agreement the information, capabilities, technical access and assistance the provider needs. Tools and components other than general-purpose models released under a free and open-source licence are exempt. This is the legal basis for asking a supplier for an AI BOM.
- AI Act, Article 53 and Annexes XI and XII. Providers of general-purpose AI models keep technical documentation for the AI Office and give downstream providers the architecture and number of parameters, the modality and format of inputs and outputs, the licence, and the type and provenance of training data. These duties have applied since 2 August 2025.
- AI Act, Article 15. High-risk systems need an appropriate level of accuracy, resilience and cybersecurity, including measures against data poisoning and model poisoning. You cannot show control of a supply chain you have not listed.
- Cyber Resilience Act, Regulation (EU) 2024/2847. Under Annex I, Part II, manufacturers of products with digital elements draw up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. It sits in the technical documentation, goes to market surveillance authorities on request and need not be published. Reporting of actively exploited vulnerabilities has applied since 11 September 2026; the regulation applies in full from 11 December 2027. Article 12 adds a bridge: a high-risk AI system that is a product with digital elements and meets the CRA essential requirements is deemed to meet the cybersecurity requirement of Article 15 of the AI Act.
- NIS2. Supply chain security is one of the risk-management measures of Article 21 for essential and important entities.
Lawyers have drawn the same line. In an analysis of 16 June 2026, Morgan Lewis notes that the G7 list overlaps with Articles 11 and 13 and Annex IV, and expects EU guidance on those provisions to track some of its elements. That is their forecast, not a Commission statement. The same note recalls the US path: SBOMs entered federal procurement with Executive Order 14028 and the NTIA minimum elements of 2021, and the G7 list is supplemental to them.
How to build an AI BOM: a seven-step method
- Scope it. One AI BOM per AI system and per version, attached to the system’s record in the AI inventory. If your AI registry already lists models, datasets and components for each system, most of the System level properties cluster exists.
- Generate, do not type. Extract from the model registry, the training pipeline and the build, in the format your SBOM tooling uses. A hand-written document is out of date at the next retraining.
- Fill the seven clusters, and write “unknown” where you do not know. This matters most for third-party models. An honest gap tells a reviewer where the supplier question is.
- Hash and sign. Model files, dataset files, and the document itself. Without hashes, an AI BOM describes a system; with them, it identifies one.
- Link what the AI BOM does not hold. Model card, risk management file, oversight measures, test reports. One identifier per system, so the four missing answers are one click away.
- Put it in contracts. Ask suppliers for an AI BOM at onboarding and at every model version, under Article 25(4) where the system is high-risk. Add it to your vendor due diligence questionnaire.
- Keep it alive. Regenerate on every retraining, fine-tuning, dependency or tool change, feed it to vulnerability management, and keep versions for 10 years where the AI Act or the CRA applies. A changed hash is also the cheapest model drift alarm you will ever get.
Each step leaves a dated record. Together they turn an AI BOM from a file somebody exported once into a control somebody owns.
AI BOM for third-party models and AI agents
Two cases strain the format. Models consumed through an API. There are no weights to hash, so the honest entry is “unknown” plus a link to the provider’s documentation. For general-purpose models, the provider owes downstream providers the Annex XII information, which fills most of the Models cluster: architecture, parameters, modalities, licence, type and provenance of training data. If a supplier cannot produce it, that is a finding in itself. Agents. The G7 “System data flow” element already names external service APIs, multi-agent communication protocols and web grounding. The NIST presentation of May 2026 goes further and sketches an “agentic system BOM” that adds tools, MCP servers, prompts, policies, memory and identity bindings, plus runtime evidence: tool calls, approvals, denied actions. No format standardises that layer today. Until one does, record tools and their scopes in the System components and Infrastructure clusters, and keep runtime logs separately, as described in our guide to agentic AI security. Deployers rarely write an AI BOM. They ask for one, read three things in it (which model and version, which data sensitivity, which external services) and file it with the system record. When a supplier announces an incident, that file is what tells you in an hour whether incident reporting clocks have started for you.
FAQ
What is an AI BOM in simple terms? It is the ingredient list of an AI system: which models it uses and where they come from, which datasets trained or tested them, which software and hardware run them, and how the parts connect. It is machine-readable, so tools can compare it with vulnerability databases, and signed, so a reader knows who wrote it. The G7 agencies fixed a voluntary baseline of 50 elements in May 2026. What is the difference between an AI BOM and an SBOM? An SBOM lists software components and dependencies. An AI BOM adds what software manifests cannot describe: models with their lineage, hash and training properties, datasets with their provenance, licence and sensitivity, and system-level data flows to external services. The G7 guidance is explicit that the two add up: AI systems are also software systems, so you need the SBOM and the AI elements on top. Is an AI BOM mandatory under the EU AI Act? Not by name. The AI Act never uses the term. It does require most of the content: Annex IV for high-risk systems (third-party components, architecture, training data provenance), Annexes XI and XII for general-purpose models, and a written agreement with component suppliers under Article 25(4). The Cyber Resilience Act separately requires a machine-readable SBOM for products with digital elements. Which AI BOM format should I use? CycloneDX or SPDX 3.0. CycloneDX has broader tool support and is what the OWASP generator outputs; SPDX has richer AI metadata but younger tooling. The G7 list prescribes no format. Use the one your existing SBOM pipeline produces, state its name and version in the metadata, and avoid a PDF-only document: the value is in machine readability. Who has to produce an AI BOM, the provider or the deployer? The party that builds or assembles the system, because only it can read the pipeline: the provider in AI Act terms, the manufacturer in CRA terms. A deployer asks for it at procurement and at each new version, checks model identity, data sensitivity and external services, and stores it with the system record. An integrator that assembles a system from third-party models becomes the author. Does an AI BOM replace a model card or the technical documentation? No. It indexes them. The G7 elements point to the model card by link, and our Annex IV reading shows what stays outside: intended purpose and classification, human oversight, test results, the risk management file and the conformity documents. Treat the AI BOM as the component layer of the technical file, not as the file.
Conclusion
What goes into an AI BOM is no longer a vendor’s opinion. Seven clusters, fifty elements, signed by seven agencies: that is the baseline a customer, an auditor or an authority will recognise. What the list does not say is which law applies to you and what else you will be asked for. Annex IV, Article 25(4), Annexes XI and XII and the Cyber Resilience Act answer the first question; your risk file, oversight design and test reports answer the second. Start with one system. Generate the document instead of writing it, state “unknown” where that is the truth, sign it, and link the rest of the file. AI Sigil keeps each AI system as a record with its models, datasets, components, risks, controls and evidence, so the AI BOM has a place to hang and the rest of the file is one click away.