Seriesaibom-library

AIBOM Standards and Templates Compared

aibom cyclonedx spdx croissant model-cards eu-ai-act ai-governance

October 29, 2026 · PlayCISO

TL;DR

There is no single AIBOM standard. CycloneDX ML-BOM and SPDX 3.0 are the machine-readable bills of materials, Croissant describes datasets, and model cards, datasheets, Data Cards and FactSheets are documents for people. The EU AI Act’s Annex IV documentation and the GPAI Model Documentation Form are legal duties that those formats feed, not file formats; most teams need one BOM format plus a card per model and dataset.

Put it into practice

See one field across every format

The AIBOM Format Field Map (Pro) lines up the same fact in CycloneDX, SPDX 3.0, Croissant and the EU forms, so you can fill one and convert to the others.

Open the Field Map

There is no single AIBOM standard. Two formats are machine-readable bills of materials (CycloneDX and SPDX 3.0), one describes datasets (Croissant), five are documentation templates written for people, and two are EU legal duties. This page puts all ten in one table, then says which to use in which situation.

Who this is for: AppSec and AI-security engineers choosing a format, GRC leads deciding what documentation to require, CISOs setting the policy, and SOC analysts who will read these files during an incident.

What kinds of AIBOM standard are there?

Three kinds, and they are not substitutes for each other:

Bills of materials. Machine-readable inventories of a whole system: CycloneDX and SPDX 3.0. Tools generate, validate, diff and query them. This is what an AIBOM usually means.
Cards and sheets. Documents about one model or one dataset, written for people: Hugging Face cards, Google Model Cards, Datasheets for Datasets, Data Cards, IBM FactSheets. Croissant sits between the two: it is machine-readable, but only for datasets.
Legal documentation. What the EU AI Act requires certain providers to hold: Annex IV for high-risk AI systems, Annexes XI and XII for general-purpose AI (GPAI) models. The law sets the content, not the file format.

The comparison table

Versions and dates were checked against each owner’s own specification on 29 October 2026.

Standard / template	Governing body	Covers	Format	Legal status	Maturity and tooling	Best for
CycloneDX ML-BOM	OWASP Foundation; standardised by Ecma TC54 as ECMA-424 (1st ed. June 2024 = v1.6; 2nd ed. December 2025 = v1.7)	System: software, services, models (`machine-learning-model` + `modelCard`) and data (`data` components)	JSON, XML, Protocol Buffers	Voluntary	ML support since v1.5; current v1.7 (21 Oct 2025). The widest SBOM tooling ecosystem	AppSec, SOC: AIBOM from the same pipeline as the SBOM
SPDX 3.0 AI + Dataset profiles	Linux Foundation (SPDX project). SPDX 2.2.1 is ISO/IEC 5962:2021; the 3.0 profiles are not part of that ISO text	System: software packages, models (`AIPackage`) and data (`DatasetPackage`)	JSON-LD	Voluntary	Profiles new in 3.0; current spec 3.0.1. Less AI tooling than CycloneDX so far	GRC and procurement teams already on SPDX
MLCommons Croissant + RAI	MLCommons	Data only: files, record structure, provenance; RAI vocabulary for collection, bias, sensitive data, use cases	JSON-LD on schema.org	Voluntary	Croissant 1.1 (29 Jan 2026), RAI 1.0 (6 Mar 2024). Embedded by Hugging Face and Kaggle; OpenML and Dataverse export it	Data teams publishing or consuming datasets
EU AI Act Annex IV technical documentation	EU law: Regulation (EU) 2024/1689, Article 11	Whole high-risk AI system, including data, testing, risk management and post-market monitoring	No file format prescribed. A simplified form for SMEs and SMCs is to come from the Commission	Mandatory for providers of high-risk AI systems	Legal text. Annex III high-risk rules apply from 2 Dec 2027 (Annex I products: 2 Aug 2028)	GRC, CISO at a high-risk system provider
EU GPAI Model Documentation Form	EU AI Office; part of the General-Purpose AI Code of Practice, Transparency chapter (published 10 July 2025)	General-purpose AI model: properties, licence, uses, training, data, compute, energy	Word form (DOCX)	The Code is voluntary; the Article 53 duties it documents are mandatory for GPAI providers	Published July 2025; mirrors Annex XI Section 1 and Annex XII	GRC at a GPAI provider; downstream providers as recipients
Hugging Face model and dataset cards	Hugging Face	Model (model card) or dataset (dataset card)	`README.md` with YAML metadata (`license`, `datasets`, `base_model`, `pipeline_tag`, `model-index`)	Voluntary	De facto format for open-weight models; Hub filters on the metadata	AppSec model intake; ML engineers
Google Model Cards	Research paper: Mitchell et al., FAT* 2019	Model	Document framework, nine sections (model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, caveats)	Voluntary	The origin of most model-card templates, including Hugging Face’s	Model owners writing a readable card
Datasheets for Datasets	Research paper: Gebru et al. (2018; CACM December 2021)	Data	Question list in seven sections: motivation, composition, collection, preprocessing, uses, distribution, maintenance	Voluntary	Widely cited; no tooling needed. Annex IV point 2(d) itself uses the word “datasheets”	GRC and data owners
Google Data Cards	Research paper: Pushkarna et al., ACM FAccT 2022	Data	Structured document template	Voluntary	Croissant 1.1 names Data Cards as RAI documentation it can publish	Data owners writing for non-specialists
IBM AI FactSheets	Research paper: Arnold et al., IBM Research (2018); the fact-capture approach now ships in IBM watsonx.governance	Model and the AI service around it, across its lifecycle	Methodology; facts captured in tooling	Voluntary	Mature inside IBM tooling; no open file format	GRC teams on IBM governance tooling

Which one should I use?

Pick by situation. Most organisations land on one bill-of-materials format plus a readable card for each model and dataset; the EU documents only enter when the law applies to you.

Your situation	Use	Why
You already produce SBOMs in CI	CycloneDX ML-BOM	Same generator, same store, same vulnerability workflow. Add the model and data components to the SBOM you have.
Your organisation or a buyer standardised on SPDX	SPDX 3.0 AI + Dataset profiles	Note that ISO/IEC 5962:2021 is SPDX 2.2.1; the AI profile is SPDX 3.0. Do not promise an “ISO AIBOM”.
You publish or buy datasets	Croissant + RAI, plus a datasheet	Croissant for tools, a datasheet or Data Card for people.
You approve open-weight models for use	Read the Hugging Face card, then record it in your own AIBOM	The card is the supplier’s claim; your AIBOM records the hash and licence you verified.
You provide a high-risk AI system in the EU	Annex IV technical documentation, fed by your AIBOM	The BOM formats supply points 1, 2 and parts of 3; risk management, the declaration of conformity and post-market monitoring come from elsewhere.
You place a general-purpose AI model on the EU market	The Model Documentation Form (or your own equivalent)	It is the easiest way to cover Annexes XI and XII. Open-source models are exempt from those two annexes unless they carry systemic risk.
You integrate someone else’s general-purpose model	Ask for the downstream-provider items of the Model Documentation Form	Then copy what you received into your AIBOM so the facts travel with your system.

If you are unsure whether the EU documents apply, the EU AI Act Role & Risk Classifier works out your role (provider, deployer and so on) and risk tier first.

The same fact in seven formats

The formats overlap far more than their names suggest. Here is one fact per row, with the exact field each format uses for it. Field names are from the CycloneDX 1.7 JSON schema, SPDX 3.0.1, Croissant 1.1 and RAI 1.0, the Hugging Face Hub docs, the AI Act text and the Model Documentation Form.

Fact	CycloneDX 1.7	SPDX 3.0.1	Croissant / RAI	Hugging Face card	Annex IV	GPAI form
Base model	`pedigree.ancestors` on the model component	`descendantOf` relationship	n/a (data only)	`base_model` (+ `base_model_relation`)	Point 2(a)	“Model dependencies”
Training data	`modelCard.modelParameters.datasets` + `data` components	`trainedOn` relationship to a `DatasetPackage`	The dataset description itself	`datasets`	Point 2(d)	“Information on the data used for training, testing and validation”
Licence	`licenses`	`hasDeclaredLicense` relationship	`license`	`license`	Not named directly	“License”
Intended use and limits	`modelCard.considerations.useCases`, `technicalLimitations`	`informationAboutApplication`, `limitation`	`rai:dataUseCases`, `rai:dataLimitations`	“Uses” and “Bias, Risks, and Limitations” sections	Points 1(a), 1(h), 3	“Intended uses”, “Acceptable Use Policy”
Evaluation results	`modelCard.quantitativeAnalysis.performanceMetrics`	`metric`, `metricDecisionThreshold`	n/a	`model-index`	Point 2(g)	No field in the form; evaluation results are a systemic-risk item (Annex XI, Section 2)
Sensitive personal data	`data[].sensitiveData`	`hasSensitivePersonalInformation` (dataset), `useSensitivePersonalInformation` (model)	`rai:personalSensitiveInformation`	Dataset card section on personal and sensitive information	Points 2(d), 3	“Measures to detect unsuitability of data sources”
Integrity	`hashes`, `signature`	`verifiedUsing`	`sha256` on each `FileObject`	No metadata field	Point 2(h) (cybersecurity)	“Model authenticity” (AI Office and authorities only)

Three traps the table hides:

SPDX datasetSize is in bytes. A record count such as “48,210 tickets” does not belong there; put it in the description or the dataset’s own metadata.
The ISO number belongs to SPDX 2.2.1. ISO/IEC 5962:2021 predates the SPDX 3.0 AI and Dataset profiles. A buyer who asks for “the ISO format” for an AIBOM should be told that the ISO text does not include the AI profiles, then asked what they actually need.
The GPAI form has no evaluation-results field. Evaluation results are only required of providers of GPAI models with systemic risk. If you need a vendor’s benchmark numbers, ask for the model card.

For the full field list behind a good AIBOM, see the AIBOM parameters checklist. For how the BOM types differ, see SBOM vs AIBOM vs MLBOM.

Worked example: what Northwind Health keeps

Northwind Health (fictional) ships Triage Assistant v2.3, a customer-support assistant. It is a LoRA fine-tune of mistralai/Mistral-7B-Instruct-v0.3 (Apache-2.0) served with vLLM, with a RAG index over the public help centre and one MCP tool server that reads and writes tickets. Here is which of the ten documents it keeps, and why.

Document	Does Northwind keep it?	What it holds
CycloneDX 1.7 ML-BOM for Triage Assistant v2.3	Yes: the primary AIBOM	Lists vLLM 0.6.x, the base model, the LoRA fine-tune `northwind/triage-assistant` 2.3.0, both datasets, the help-centre RAG index and the `ticketing-mcp` server, with hashes and licences.
SPDX 3.0 export	Only on request	Converted from the CycloneDX file when a customer’s procurement team asks for SPDX.
Model card for `northwind/triage-assistant`	Yes, internal	Hugging Face layout. Intended use: drafting replies for a human agent. Out of scope: medical advice, autonomous sending. Fictional results: answer-accuracy 0.87 on `triage-eval-v4`, toxicity rate 0.2%.
Datasheet for `northwind/support-tickets-2025`	Yes, internal	48,210 de-identified tickets, January to December 2025, proprietary licence, how identifiers were removed.
Croissant + RAI for the same dataset	Optional	Worth it only if Northwind’s data catalogue reads Croissant. The dataset is never published.
Annex IV technical documentation	Not required	A reply-drafting assistant is not a high-risk system under the AI Act. The reasoning is in our Annex IV walkthrough.
GPAI Model Documentation Form	Neither produced nor received	Northwind is not a GPAI model provider, and its open-weight Apache-2.0 base model is exempt from Annexes XI and XII. See the form explainer.

Northwind Health and its Triage Assistant are a fictional example used across the PlayCISO AIBOM Library. All names, figures and evaluation results for it are invented for illustration.

Northwind’s rule of thumb: one machine-readable source (the CycloneDX file), with the cards and any export generated from it, so the documents never disagree. The AIBOM Template & Model Card Generator produces the AIBOM and the card from one form.

How the AI standards fit with ISO/IEC 42001 and NIST AI RMF

None of the ten formats is a management-system standard. ISO/IEC 42001 and the NIST AI Risk Management Framework ask you to know and document your AI systems; the formats above are how you hold that knowledge. If you are mapping controls across those frameworks, the AI Standards Crosswalk lines them up, and the documents here become the evidence. Start from the AIBOM Library hub for the reading path for your role.

Frequently asked questions

What is the standard format for an AIBOM?

There is no single one. The two machine-readable bill-of-materials formats with AI support are CycloneDX (ML-BOM, from version 1.5) and SPDX 3.0 with its AI and Dataset profiles. Croissant covers datasets only. Model cards, datasheets, Data Cards and FactSheets are human-readable documentation, and the EU AI Act documents are legal duties rather than file formats.

Is CycloneDX an ISO or Ecma standard?

CycloneDX is an Ecma International standard, ECMA-424. The first edition (June 2024) is CycloneDX 1.6 and the second edition (December 2025) is CycloneDX 1.7. It is not an ISO standard. SPDX is the one with an ISO number: ISO/IEC 5962:2021 is SPDX 2.2.1, which predates the SPDX 3.0 AI and Dataset profiles.

Should I use CycloneDX or SPDX for an AI bill of materials?

Use the one your software supply-chain tooling already produces, because the AIBOM should come out of the same pipeline as the SBOM. CycloneDX has machine-learning-model and data component types and a modelCard object. SPDX 3.0 has AIPackage and DatasetPackage classes with fields such as typeOfModel, limitation and hasSensitivePersonalInformation. Convert when a customer asks for the other.

Is a model card the same as an AIBOM?

No. A model card is a human-readable document about one model: what it is for, how it was evaluated and where it fails. An AIBOM is a machine-readable inventory of every model, dataset and software component in a system, with versions, licences and hashes. CycloneDX can embed model-card content in a component, but you still want the readable card for people.

Does the EU AI Act require an AIBOM?

The AI Act does not use the term. It requires technical documentation: Annex IV for providers of high-risk AI systems, and Annexes XI and XII for providers of general-purpose AI models. Those documents ask for the model, data, version, licence and testing facts that an AIBOM already holds, so an AIBOM is the easiest way to produce them, but it does not replace them.

Which dataset documentation format should I use?

Use Croissant with the RAI vocabulary when tools need to read the dataset description, for example on Hugging Face, Kaggle or OpenML, which embed or export Croissant. Use a datasheet (Gebru et al.) or a Data Card when people need to understand how the data was collected, cleaned and should be used. Many teams keep both, generated from one source.

Sources

Checked on 29 October 2026. PlayCISO is not affiliated with any standards body or vendor named here. This is general information, not legal advice.

See one field across every format

The AIBOM Format Field Map (Pro) lines up the same fact in CycloneDX, SPDX 3.0, Croissant and the EU forms, so you can fill one and convert to the others.

Open the Field Map