# AIBOM Standards and Templates Compared

> CycloneDX, SPDX 3.0, Croissant, the EU forms and five card templates in one table: who owns each, what it covers, its legal status and who should use it.

Source: https://playciso.com/blog/aibom-standards-templates-compared · Published: 2026-10-29 · Publisher: PlayCISO (https://playciso.com)

---

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 / templateGoverning bodyCoversFormatLegal statusMaturity and toolingBest for CycloneDX ML-BOMOWASP 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 BuffersVoluntaryML support since v1.5; current v1.7 (21 Oct 2025). The widest SBOM tooling ecosystemAppSec, SOC: AIBOM from the same pipeline as the SBOM SPDX 3.0 AI + Dataset profilesLinux Foundation (SPDX project). SPDX 2.2.1 is ISO/IEC 5962:2021; the 3.0 profiles are not part of that ISO textSystem: software packages, models (`AIPackage`) and data (`DatasetPackage`)JSON-LDVoluntaryProfiles new in 3.0; current spec 3.0.1. Less AI tooling than CycloneDX so farGRC and procurement teams already on SPDX MLCommons Croissant + RAIMLCommonsData only: files, record structure, provenance; RAI vocabulary for collection, bias, sensitive data, use casesJSON-LD on schema.orgVoluntaryCroissant 1.1 (29 Jan 2026), RAI 1.0 (6 Mar 2024). Embedded by Hugging Face and Kaggle; OpenML and Dataverse export itData teams publishing or consuming datasets EU AI Act Annex IV technical documentationEU law: Regulation (EU) 2024/1689, Article 11Whole high-risk AI system, including data, testing, risk management and post-market monitoringNo file format prescribed. A simplified form for SMEs and SMCs is to come from the CommissionMandatory for providers of high-risk AI systemsLegal 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 FormEU 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, energyWord form (DOCX)The Code is voluntary; the Article 53 duties it documents are mandatory for GPAI providersPublished July 2025; mirrors Annex XI Section 1 and Annex XIIGRC at a GPAI provider; downstream providers as recipients Hugging Face model and dataset cardsHugging FaceModel (model card) or dataset (dataset card)`README.md` with YAML metadata (`license`, `datasets`, `base_model`, `pipeline_tag`, `model-index`)VoluntaryDe facto format for open-weight models; Hub filters on the metadataAppSec model intake; ML engineers Google Model CardsResearch paper: Mitchell et al., FAT* 2019ModelDocument framework, nine sections (model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, caveats)VoluntaryThe origin of most model-card templates, including Hugging Face’sModel owners writing a readable card Datasheets for DatasetsResearch paper: Gebru et al. (2018; CACM December 2021)DataQuestion list in seven sections: motivation, composition, collection, preprocessing, uses, distribution, maintenanceVoluntaryWidely cited; no tooling needed. Annex IV point 2(d) itself uses the word “datasheets”GRC and data owners Google Data CardsResearch paper: Pushkarna et al., ACM FAccT 2022DataStructured document templateVoluntaryCroissant 1.1 names Data Cards as RAI documentation it can publishData owners writing for non-specialists IBM AI FactSheetsResearch paper: Arnold et al., IBM Research (2018); the fact-capture approach now ships in IBM watsonx.governanceModel and the AI service around it, across its lifecycleMethodology; facts captured in toolingVoluntaryMature inside IBM tooling; no open file formatGRC 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 situationUseWhy You already produce SBOMs in CICycloneDX ML-BOMSame generator, same store, same vulnerability workflow. Add the model and data components to the SBOM you have. Your organisation or a buyer standardised on SPDXSPDX 3.0 AI + Dataset profilesNote 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 datasetsCroissant + RAI, plus a datasheetCroissant for tools, a datasheet or Data Card for people. You approve open-weight models for useRead the Hugging Face card, then record it in your own AIBOMThe card is the supplier’s claim; your AIBOM records the hash and licence you verified. You provide a high-risk AI system in the EUAnnex IV technical documentation, fed by your AIBOMThe 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 marketThe 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 modelAsk for the downstream-provider items of the Model Documentation FormThen 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](/tools/eu-ai-act-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. FactCycloneDX 1.7SPDX 3.0.1Croissant / RAIHugging Face cardAnnex IVGPAI form Base model`pedigree.ancestors` on the model component`descendantOf` relationshipn/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” sectionsPoints 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 informationPoints 2(d), 3“Measures to detect unsuitability of data sources” Integrity`hashes`, `signature``verifiedUsing``sha256` on each `FileObject`No metadata fieldPoint 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](/blog/aibom-parameters-checklist). For how the BOM types differ, see [SBOM vs AIBOM vs MLBOM](/blog/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. DocumentDoes Northwind keep it?What it holds CycloneDX 1.7 ML-BOM for Triage Assistant v2.3Yes: the primary AIBOMLists 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 exportOnly on requestConverted from the CycloneDX file when a customer’s procurement team asks for SPDX. Model card for `northwind/triage-assistant`Yes, internalHugging 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, internal48,210 de-identified tickets, January to December 2025, proprietary licence, how identifiers were removed. Croissant + RAI for the same datasetOptionalWorth it only if Northwind’s data catalogue reads Croissant. The dataset is never published. Annex IV technical documentationNot requiredA reply-drafting assistant is not a high-risk system under the AI Act. The reasoning is in our [Annex IV walkthrough](/blog/eu-ai-act-annex-iv-technical-documentation-template). GPAI Model Documentation FormNeither produced nor receivedNorthwind 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](/blog/gpai-model-documentation-form-explained). _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](/tools/aibom-template) 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](/tools/ai-standards-crosswalk) lines them up, and the documents here become the evidence. Start from the [AIBOM Library hub](/aibom) 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 - CycloneDX specification overview (v1.7, released 2025-10-21) - CycloneDX JSON schemas (bom-1.5 to bom-1.7) - Ecma International, ECMA-424 - SPDX 3.0.1 AI profile: AIPackage - SPDX 3.0.1 Dataset profile: DatasetPackage - Linux Foundation: SPDX 2.2.1 published as ISO/IEC 5962:2021 - MLCommons Croissant 1.1 specification (2026-01-29) - MLCommons Croissant RAI 1.0 specification (2024-03-06) - Hugging Face Hub docs: model cards - Mitchell et al., Model Cards for Model Reporting (FAT* 2019) - Gebru et al., Datasheets for Datasets (CACM, December 2021) - Pushkarna et al., Data Cards (ACM FAccT 2022) - Arnold et al., FactSheets: Increasing Trust in AI Services (IBM Research) - AI Act Annex IV (AI Act Service Desk) - AI Act Service Desk: implementation timeline - European Commission: the General-Purpose AI Code of Practice - Model Documentation Form (DOCX) _Checked on 29 October 2026. PlayCISO is not affiliated with any standards body or vendor named here. This is general information, not legal advice._