An AIBOM is a structured inventory of what an AI system is made of: the models and how their weights were produced, the datasets used across the model lifecycle, the infrastructure it runs on, the security controls around it, and the performance figures it was signed off against. An AI bill of materials does for a model pipeline what a parts list does for a machine, and over the past year it moved from research papers into procurement. That shift shows up directly in our own large language model development work, where the inventory increasingly gets built alongside the model rather than assembled after a customer asks for it.
In May 2026 the cybersecurity agencies of the G7 published joint minimum-elements guidance for exactly this artifact, running to 50 named elements across seven clusters. That list is now the vocabulary an enterprise buyer’s security team reaches for when it asks what is inside the product you are selling. Below is where the requests originate, every field that belongs in the record, which fields a pipeline emits on its own, and where the software-inventory analogy stops being useful.
Where AIBOM Requests Are Coming From
The document behind the current wave is Software Bill of Materials for AI: Minimum Elements, published on 12 May 2026 by seven national cybersecurity agencies together with the European Commission: 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. It came out of a G7 Cybersecurity Working Group work stream that ran from August 2025 to February 2026.
Its own framing is unusually direct about its limits, stating that the minimum elements “are not mandatory; do not create requirements, standards, or legislation.” That disclaimer explains the speed at which it spread: a voluntary field list carrying seven government signatures is close to free for a procurement team to paste into a questionnaire. It reaches a vendor through one of four routes:
- A security questionnaire at vendor onboarding, with an AI section bolted onto an existing software-inventory question.
- A contractual deliverable in an enterprise master services agreement, phrased as an obligation to maintain an AI component inventory.
- An internal governance program at the customer, where somebody reports AI usage to a board, an auditor, or a regulator.
- Diligence during an acquisition or funding round, where the buyer asks whether your model provenance survives scrutiny.
Two of those routes end in a technical review of your codebase and model pipeline rather than a document exchange, which is much closer to an enterprise AI implementation audit than to filling in a form. The guidance also notes that in some jurisdictions its elements “may already be, or may be expected to be, addressed through legal requirements and obligations,” a sentence that does a great deal of work for anyone selling into the EU. For a closer look at what that technical review actually checks and why regulators are the ones pushing it, see our breakdown of what an AI audit covers and why regulators care.
What Goes Inside an AIBOM, Field by Field
Here is the full set, cluster by cluster, using the guidance’s own element names. Treat this as your AIBOM template and remove nothing without a reason you would defend in front of a customer’s security lead.
Metadata (10 elements) describes the record rather than the system: SBOM author, SBOM version, SBOM data format name, SBOM data format version, SBOM author signature, SBOM tool name, SBOM tool version, SBOM generation context, SBOM timestamp, and SBOM dependency relationship. The element people skip is generation context, which records whether the inventory came from source, from the build, or from a shipped binary. Those three disagree in predictable ways, and the reader needs to know which they hold.
System Level Properties (9 elements) covers the system as a whole: system name, system components, system producer, system version, system timestamp, system data flow, system data usage, system input/output properties, and intended application area. System data flow is where multi-agent protocols, external service APIs, and bidirectional web-grounding traffic get declared, so this is the cluster that reveals whether your product quietly calls somebody else’s model at inference time. That is precisely the layer our agentic AI workforce transformation engagements have to map first, since an agent calling three other models on your behalf means three more entries this cluster has to carry.
Models (13 elements) is the largest cluster: model name, model identifier, model version, model timestamp, model producer, model description, model hash value, model hash algorithm, model properties, model input-output properties, model training properties, model license, and model external references. The hash pair carries the most weight here, because without a hash value and the algorithm that produced it, every other claim in the cluster is an assertion the recipient cannot test.
Datasets Properties (10 elements) covers dataset name, dataset description, dataset content, dataset identifier, dataset hash, dataset provenance, dataset statistical properties, dataset sensitivity, dataset dependency relationship, and dataset license. This is the cluster that starts internal arguments, since it applies to every dataset across the model life cycle, including evaluation and fine-tuning sets. Untangling that lineage is usually a data engineering problem before it is a documentation one, since you cannot record provenance you never tracked in the first place.
Infrastructure (2 elements) covers infrastructure software and infrastructure hardware, plus a link to a Hardware Bill of Materials where one exists.
Security Properties (4 elements) covers security controls, security compliance, cybersecurity policy information, and vulnerability referencing.
Key Performance Indicators (2 elements) covers security metrics and operational performance KPIs. These three short clusters are the ones most often shipped empty, which reads as an inventory that gave up early.
Auto-Generated vs Human-Authored Fields
Guidance on how to create AIBOM records tends to present the file as a single deliverable with one owner. Fifty elements spanning code, data, infrastructure, security, and legal is cross-functional by construction, and splitting them by who can produce them turns one stalled project into two tractable ones. By our count, 27 elements fall straight out of tooling most teams already run, and the remaining 23 need a human judgment no scanner can make.
Fields the Pipeline Emits
Everything identity-shaped and everything hash-shaped belongs to the pipeline. The Metadata cluster is almost entirely a by-product of the generation step, since the tool knows its own name and version, the timestamp, the data format, and the lifecycle phase it ran in. Model and dataset identifiers, versions, timestamps, and hashes come out of your model registry and object storage, and the Infrastructure cluster comes from the infrastructure-as-code definitions that already provision your accelerators.
The two performance-indicator elements belong here on one condition: your evaluation harness writes results somewhere durable. Emit them from CI on every model release and they are correct by construction, while retyping them quarterly into a spreadsheet puts them wrong within a week of the next deployment.
Fields a Human Writes
The remaining elements are judgments, and a scanner has no basis on which to make them. Each needs a named owner:
- Intended application area. Declaring that a classifier runs in a medical, financial, or cybersecurity context is a scoping decision with regulatory consequences, and no amount of static analysis infers it.
- Dataset provenance and sensitivity. Provenance claims where data came from and on what terms, and sensitivity claims what a leak would cost. Both belong to data governance and legal, and both are what a serious reviewer probes first.
- Model training properties and limitations. The useful version states the conditions under which the model degrades, precisely the material vendors instinctively soften.
- Security controls, compliance, and policy information. These reference an existing control framework, so they get copied from your security program rather than generated from the codebase.
- The author signature. A signature is a key-management decision about which entity stands behind the contents, and it turns a description into a commitment.
Fields in this group go stale silently, because nothing breaks in production when they become wrong. Give each an owner and a review trigger tied to model retraining rather than a calendar date.
SBOM Analogy and Where It Ends
The AIBOM vs SBOM comparison holds up well at the level of purpose and comes apart at the level of verification. Both are ingredient lists that let a consumer reason about risk in something they did not build, and the G7 document is explicit that AI systems are also software systems, so the AI clusters sit on top of a conventional software inventory.
Unit of inventory
Software components and packages
Models, datasets, and the system that composes them
Identity evidence
Component name, version, hash
Model hash value plus hash algorithm, dataset hash and identifier
Provenance
Supplier and dependency relationship
Dataset provenance across the whole model life cycle
Runtime behavior
Outside scope
System data flow, input/output properties, intended application area
Legal surface
Component license
Model license and dataset license, including open-weight status
Performance
Outside scope
Security metrics and operational performance KPIs
Recipient can verify alone
Usually, by re-hashing the package
Partly: weights hash cleanly, training data does not
Verification is where the analogy ends. A dependency claim is cheap to test: pull the package, hash it, compare. A training-data provenance claim stays untestable by a recipient holding neither the data nor the compute to recreate the weights. Sanchit Vir Gogia put the limit precisely in CSO Online: “Minimum elements create visibility. They do not create assurance. They tell the buyer what the vendor says exists.”
The G7 authors reach the same place from the opposite direction, stating that an inventory of this kind “by itself is not sufficient for increasing cybersecurity along the supply chain” and works only when wired into vulnerability scanning and management tooling. For a buyer, that makes the document a starting point for questions, and the natural follow-up is an independent review of the codebase and model pipeline standing behind the claims. For a vendor, fields you can back with a hash or a signed artifact are worth far more in a negotiation than fields you can only assert.
From Paperwork to Product Artifact
Teams that stop dreading this request are the ones that move the artifact into the build. The mechanics are unremarkable: pick a machine-readable format, generate the automatic fields in CI on every model release, keep the human fields in version control beside the code so they pass review, and publish the result as a signed artifact on the release.
Format choice is settled enough to be boring. OWASP’s CycloneDX carries a machine-learning-model component type and a model-card external reference built for this purpose, and version 1.7 of the specification shipped in October 2025, so the tooling exists today rather than sitting on a roadmap. SPDX is the credible alternative, and the G7 guidance points at SPDX and CycloneDX fields as acceptable homes for model licensing information.
Two design decisions do most of the work. Generate per release instead of per quarter, because an inventory whose timestamp trails your deployed model tells a reviewer your process is decorative. Treat human-authored fields as reviewed code, so downgrading a sensitivity classification needs sign-off from somebody accountable for it.
This is ordinary release-artifact automation, which is why engineering teams adding AI features to an existing product are best off designing the generation step alongside the inference path. The teams that struggle are the ones where nobody owns the model registry, and that is an organizational gap wearing a documentation costume.
Demand for this artifact keeps climbing, and the field list is stable enough now to build against with confidence. Produce the inventory once as a by-product of your release process and an awkward question turns into a link you paste into a questionnaire. If you would like a hand wiring that generation step into a pipeline you already run, contact us and we will start from what you have rather than a blank page.
FAQ
What is an AIBOM?
It is a structured inventory of an AI system’s components: the models and how their weights were produced, the datasets used across the model life cycle, the infrastructure it runs on, the security controls applied to it, and its performance indicators. The G7 minimum-elements guidance organizes it into seven clusters holding 50 named elements, one describing the document itself and six describing the system.
What is the difference between SBOM and AIBOM?
A software inventory lists components, versions, and dependency relationships. The AI version adds clusters for models, datasets, infrastructure, security properties, and key performance indicators, which the G7 guidance treats as additions rather than a replacement. The practical difference is verifiability: a package hash can be re-checked by whoever receives it, while a training-data provenance claim usually cannot.
What should an AIBOM include?
At minimum the seven clusters from the G7 guidance: Metadata, System Level Properties, Models, Datasets Properties, Infrastructure, Security Properties, and Key Performance Indicators. The fields carrying most weight in a buyer’s review are the model hash value and hash algorithm, dataset provenance and sensitivity, system data flow, intended application area, and the author signature.
Is an AIBOM mandatory?
The G7 minimum elements are voluntary and say directly that they do not create requirements, standards, or legislation. The obligation arrives contractually instead, through security questionnaires, procurement terms, and vendor risk programs, and the guidance notes that in some jurisdictions the same elements may already sit inside existing legal requirements.
What checking under the hood actually finds: 80+ improvements and security risks in a mobile marketplace
