Summary This report analyzesArtificial Intelligence System Bill of Materials — Compliance Management Guide for the Supply Chain, written by the AI Work Group (OpenChain AI Work Group) of the OpenChain Project under the Linux Foundation. The guide carries the methodology of ISO/IEC 5230, the international standard for software license compliance, over to the artificial intelligence (AI) supply chain, defining the core requirements a quality AI SBOM compliance program must meet. Its purpose is to provide a common baseline for trust between organizations that exchange AI solutions, and it extends traditional SBOM compliance by pulling not just code but model weights, training datasets, and the licensing and transparency obligations of the Model Tree into the scope of tracking. For Korean companies and practitioners preparing for AI supply chain governance, it serves as a checklist asking “what must be documented and demonstrated.”

The text this report analyzes is a working copy (RFC draft) from the/docs directory of theOpenChain-Project/AI-WG repository on GitHub. As confirmed in the trend research, the same document went through six weeks of public comment and was formally published as OpenChain AI SBOM Compliance Guide Version 1 on October 20, 2025A9. This report therefore covers not the formal Version 1 but an earlier draft snapshot. The citable formal edition is published as PDF and Markdown in the OpenChain Reference-Material repositoryA9·A12. A full-text comparison of the two documents on July 20, 2026 found that the nine normative (shall) provisions covered below and the section structure remain identical in wording in the formal edition. However, four definitions (2.5 Identified License, 2.6 Program, 2.7 Program Participant, 2.8 Supplied Software) were reworded in the formal edition, so these definitions should be checked directly against the formal text when cited.

1. Document Overview

This guide defines the core requirements a quality AI SBOM compliance program must meet. It was published by the AI Work Group of the OpenChain Project under the Linux Foundation, and is the product of an open working group operated through a mailing list anyone can join for free and regular workshopsA1·A2. The license the document specifies is Creative Commons Attribution 4.0 (CC-BY-4.0)A1.

The guide’s design intent is clear from its overview. It focuses on the “what” and “why” of a program rather than the “how” and “when,” leaving flexibility for organizations of different sizes operating in different markets to choose the specific policies and procedures that fit their own scale, goals, and scopeA1. The guide states that it drew inspiration from OpenChain ISO/IEC 5230, applying its lessons to the market need for AI SBOM management in the supply chain. In preparing it, ISO/IEC 5230:2020, ISO/IEC 42001:2023, and ISO/IEC 5962:2021 were cited as reference standardsA1.

The document’s status is an RFC (Request for Comments) draft. The NOTICE at the top states plainly that it is not a production release but “a working document for interested parties to share ideas” and a “living document”A1. The relationship between the draft and the formal edition is a matter of timing. After reviewing the draft, the OpenChain AI Work Group opened a public comment period on July 7, 2025, closed it and reviewed the comments on August 18, 2025, and, following a decision by the Governing Board, formally published Version 1 on October 20, 2025A10·A11·A9. The RFC.docx inAI-WG/docs that this report covers is that working copy, and the formal edition for external citation is published separately in the Reference-Material repositoryA12. The difference in license notation between the two texts (the working copy is CC-BY-4.0 per the document’s NOTICE) stems from the difference in distribution stage.

2. Background: Extending the OpenChain Methodology to AI

The OpenChain Specification is a process management standard that defines the requirements a quality open source license compliance program must meet. Developed by roughly 100 contributors between 2014 and 2016, it launched as Version 1.0 in October 2016, then, through ISO/IEC JTC 1’s Publicly Available Specification (PAS) Transposition procedure in April 2020, became the international standard ISO/IEC 5230:2020 in December of the same yearA14·A3. OpenChain also extended the same framework into the security domain, standardizing an open source security assurance specification focused on checking for disclosed security vulnerabilities as ISO/IEC 18974:2023A13.

The core of the 5230 methodology is the structure it uses to describe requirements. Each requirement consists of Verification Materials — the records that must be produced to demonstrate that the requirement was met — and a Rationale explaining why the requirement is neededA14. This design, which fixes only the outcome and purpose while leaving the means of implementation open, is the basis for its non-prescriptive character, which allows organizations of different sizes and markets to shape a program that fits them. The fact that the AI SBOM guide repeats the “Verification Materials + Rationale” structure in every section is a direct carryover of this methodology.

In AI systems, what must be tracked extends beyond code. Model weights, the datasets used for training, testing, and validation, and even the Model Tree — which represents the relationship of one AI system being derived from several others — can each carry their own license. This is why the guide’s License Obligations (3.5) and Transparency Obligations (3.6) discuss code, weights, and datasets together. Where open source compliance asks “which component came in under which license,” AI requires extending that same question to models and data. The process-centered, non-prescriptive philosophy of 5230 suits this extension well. In an environment where the regulatory landscape is splitting rapidly by jurisdiction, fixing only “what must be demonstrated” instead of pinning down specific procedures lets organizations under different regimes — the European Union, the United States, China — share the same common baseline.

A Software Bill of Materials (SBOM) is a formal record of the components that make up a piece of software and their supply chain relationships. In the United States, Executive Order 14028 on Improving the Nation’s Cybersecurity directed the definition of SBOM minimum elements in May 2021, and the National Telecommunications and Information Administration (NTIA) publishedMinimum Elements for a Software Bill of Materials on July 12, 2021D4·D1. Traditional SBOMs are designed to identify and track software components, making them ill-suited to representing training processes, data, and model behavior as such. The AI SBOM the guide defines is “a list of components that make up part or all of an AI system, and related information about them,” explicitly including models and datasets. The industry also calls the same concept an AI BOM or a Machine Learning Bill of Materials (ML-BOM). The names diverge because each standard has set its own terminology. The guide specifies AI SBOM as its abbreviation in definition clause 2.2A1, while the G7 cybersecurity working group calls the same thing SBOM for AI, and CycloneDX calls it ML-BOM. This report uses AI SBOM when referring to the guide, and uses AI BOM only when discussing the general concept without tying it to a specific standard.

In terms of format, the guide leaves the door open to SPDX, CycloneDX, or any other format. SPDX (System Package Data Exchange) is an exchange standard internationalized as ISO/IEC 5962:2021; SPDX 3.0, released on April 16, 2024, introduced an AI Profile and a Dataset Profile that let it express information such as model type, hyperparameters, training data preprocessing, energy consumption, and safety risk assessmentsA5·B6·B2. CycloneDX is a full-stack BOM standard maintained by OWASP; it introduced ML-BOM in version 1.5, requiring documentation of datasets and models, configuration and training data provenance, ethical considerations, bias, and model security risksB5. The two formats use different representation models but target the same problem by treating models and datasets as first-class components.

It is also worth noting that the guide’s footnotes repeatedly reference ISO/IEC 42001:2023. 42001 is the first international standard for an AI Management System (AIMS), specifying the requirements for establishing, operating, and improving one, and its Annex B describes how to implement controls by stage of the AI lifecycleA4. If the OpenChain methodology defines “what must be demonstrated,” 42001 Annex B supplies the specific control items for “what must be documented and operated to demonstrate it.” The guide does not replace 42001; rather, it cites specific clauses of Annex B (B.2.2, B.3, B.4.2, B.4.6, B.5.3, B.6.2, B.8.5, B.9.3, and others) and main text clause 7.3 as the rationale for its Competence, Awareness, Resources, Governance, and SBOM sectionsA4.

3. Structure and Requirements of the Guide

The body of the guide (Chapter 3, Guidance) consists of ten requirement sections. Every section repeats the three-part 5230 pattern: requirement statement, verification materials, and rationale. As a footnote notes, what a specification would call “Requirements” this document calls “Guidance,” to make clear that the items are recommendations rather than normative mandatesA1.

Grouping the requirements by meaning yields two families. One is the program governance skeleton inherited directly from ISO/IEC 5230 (Policy, Competence, Awareness, Scope, Resources, Access); the other is the territory newly extended because of AI (License Obligations, Transparency Obligations, AI SBOM, AI Governance). Figure 1 shows this cluster structure.

Figure 1. Six inherited, four extended for AI(based on OpenChain AI SBOM Compliance Guide body 3.1-3.10, as of 2026-06-12)

Table 1 summarizes the core of each requirement. The “Enforcement Level” column carries over the RFC 2119 keywords (shall, should, and so on) that the guide’s body text uses; their definitions are drawn, per the guide’s Chapter 2, from IETF RFC 2119A1·A6.

Table 1. Summary of the guide’s ten requirements(based on OpenChain AI SBOM Compliance Guide body 3.1-3.10, 2026-06-12)

The License Obligations (3.5) section best reveals the character of the AI extension. The review scope covers not just code but the licenses of weights, training/test/validation datasets, and the AI system itself, and it requires reviewing and documenting the obligations, restrictions, and rights spanning upstream and downstream on the Model TreeA1. This section cites 5230:2020 Section 3.3.2 as its basis and references 42001 Annex B.2.2 as an example. The AI SBOM (3.9) section leaves the format open — SPDX, CycloneDX, or otherwise — but requires at the shall level that inbound materials (models, datasets, and the like flowing in from third parties) be reflectedA1·B2. The Governance (3.10) section names the EU AI Act, the Hiroshima AI Process, and China’s Global AI Governance Initiative directly as examples of emerging regulation, and covers the ability to monitor the AI system lifecycle alongside ethical considerations, risk management, and transparencyA1.

4. Regulatory and Governance Trends

All three pillars named in the guide’s Governance section saw meaningful progress around the research reference date (2026-06-12). Above all, the guide itself was published as Version 1 on October 20, 2025A9.

The EU AI Act (Regulation (EU) 2024/1689) is the first pillar. It applies in stages, and as of the research reference date only some provisions had come into effect. Table 2 summarizes the application schedule.

Table 2. EU AI Act phased application schedule(source: Regulation (EU) 2024/1689 Article 113 / EUR-Lex, European Commission, accessed 2026-06-12)

Obligations for General-Purpose AI (GPAI) model providers began applying on August 2, 2025, but the point at which the European Commission can actually exercise its enforcement powers, including fines, is August 2, 2026C1·C6. Annex III high-risk AI system obligations and transparency obligations also apply from the same date. This August 2026 application date is the backdrop for why the guide’s Section 3.6 requires reviewing “transparency obligations imposed by regulation.” Its point of contact with AI SBOM is the technical documentation required under Article 11 and Annex IV of the AI Act; this requirement, which takes effect from August 2026, is cited as a driver pushing AI BOM from an optional security artifact toward a de facto procurement requirementC1.

The second pillar, the Hiroshima AI Process, began during Japan’s G7 presidency in 2023 and produced the International Code of Conduct for organizations developing advanced AI; the Organisation for Economic Co-operation and Development (OECD) operates the HAIP Reporting Framework as its implementation-tracking mechanismC4. Version 1.0 launched on February 7, 2025, and the OECD announced Reporting Framework 2.0 on May 28, 2026, on the occasion of the G7 Digital and Technology Ministers’ Meeting in ParisC4·C7. Version 2.0 simplified procedures to broaden participation by small and medium-sized enterprises and introduced a role-based structure distinguishing model developers, application developers, and deployers; more than 50 organizations have indicated they will report under the new framework (the next analytical review submission deadline is 2026-09-01)C7. What the guide calls “Hiroshima AI Process compliance” refers to participation in this voluntary reporting framework.

The third pillar, China’s Global AI Governance Initiative, is a policy declaration announced in October 2023 on the occasion of the Belt and Road Forum for International Cooperation in Beijing. Unlike the EU AI Act or the Hiroshima Process, it does not define a specific reporting format or compliance deliverable, so there is currently no directly corresponding obligation item from an AI SBOM standpoint. The guide mentions it only in passing, as one example of emerging AI regulation.

Format standards have moved as well. SPDX introduced its AI and Dataset profiles with SPDX 3.0 in April 2024, and CycloneDX introduced ML-BOM in v1.5 in June 2023, then released v1.7 (ECMA-424 2nd edition) in October 2025 as the final release of the 1.x seriesB6·B5. Generation tools have also appeared. In 2025, OWASP released the OWASP AIBOM Generator, which automatically generates a CycloneDX-format AI SBOM from a Hugging Face model and scores its completenessB7, and CycloneDX’s cdxgen also supports a dedicated AI BOM modeB8. However, these tools merely carry over the license stated on a model card without guaranteeing its accuracy, and the OWASP AIBOM project is separately assessing the gap where SPDX and CycloneDX do not yet fully cover AI-specific use casesE6.

5. Significance and Limitations

The value of this guide lies in specifying “the minimum requirements an AI supply chain compliance program must meet” on top of a methodology already validated as an ISO international standard. Thanks to the 5230-style structure that attaches verification materials and rationale to every section, an organization can turn each requirement into its own checklist and directly check “do we have this artifact.” The non-prescriptive design — leaving the format open to SPDX, CycloneDX, and others, and delegating the specifics of procedure to the organization — is a practical choice that provides a common baseline in an environment where regulation is splitting by jurisdiction.

The limitations are also clear. The license and transparency tracking the guide requires is difficult in practice. One study that quantified license drift — the loss of obligations as a model propagates downstream — reports that about 35.5% of transitions from model to application lose their restrictive clauses and get reassigned to a permissive license, and that machine-learning-specific obligations are preserved in only 0.4% of cases after downstream integrationE4. The Responsible AI License (RAIL) family and the Llama Community License carry behavioral use clauses that keep them from meeting the Open Source Initiative (OSI)’s Open Source Definition, and tools to track compliance with these non-standard licenses are still lackingE8·E5. The guide’s Section 3.5 requirement to review licenses beyond code, down to weights and datasets, is a design that reflects this reality. Several tools already exist to generate AI SBOMs automatically, but verifying whether the licenses in a generated bill of materials are accurate, and whether the usage restrictions of non-standard licenses are being honored, is still left to people and policy. As of 2026, what remains between requirement and feasibility is not a generation gap but a verification gap.

It is both a limitation and a feature that the guide defines itself as a living document and, by numbering itself Version 1, presupposes future revisions. Because this is a domain where regulation and format standards change quickly, the guide too is not a fixed specification, and as of the research reference date no schedule for the next revision had been published.

6. Process Requirements and Data Item Requirements

What this guide defines is the process layer of compliance. It focuses on the minimum requirements a program must meet — does a policy exist, are competence and resources assigned, is there a procedure to generate and manage AI SBOMs. A distinct, separate layer is data items. What items regulation actually requires an AI BOM to contain — as with the technical documentation required by Article 11 and Annex IV of the EU AI Act — must be worked out through separate mapping workC1. Only by combining the procedures the guide’s Sections 3.5 (License Obligations), 3.6 (Transparency Obligations), and 3.9 (AI SBOM) require in the abstract with the specific items each regulatory provision requires to be recorded do process requirements and data item requirements connect into a single system.

References

Only the sources cited in the body text are organized here as paragraphs, following the unified label scheme in 03-references.md. For the full source list and automated verification notes, see 03-references.md in the same folder.

A. Primary Source and OpenChain/Standards

A1. OpenChain Project AI Work Group (2024).Artificial Intelligence System Bill of Materials — Compliance Management Guide for the Supply Chain (RFC Draft, CC-BY-4.0 per document NOTICE). GitHubOpenChain-Project/AI-WG,/docs directory.https://github.com/OpenChain-Project/AI-WG/tree/main/docs (accessed: 2026-06-12). — The primary source document for this report.↩

A2. OpenChain Project AI Work Group.AI-WG repository (working group home).https://github.com/OpenChain-Project/AI-WG (accessed: 2026-06-12). — Basis for the guide’s publication context and the working group’s operation.↩

A3. ISO/IEC (2020).ISO/IEC 5230:2020 — Information technology — OpenChain Specification.https://www.iso.org/standard/81039.html (accessed: 2026-06-12, automated verification limited: iso.org blocks bots). — The parent standard from which the guide draws inspiration. Basis for the reference to Section 3.3.2 in the License Obligations (3.5) section.↩

A4. ISO/IEC (2023).ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system.https://www.iso.org/standard/81230.html (accessed: 2026-06-12, automated verification limited: iso.org blocks bots). — The standard the guide’s footnotes repeatedly reference (Annex B, Section 7.3).↩

A5. ISO/IEC (2021).ISO/IEC 5962:2021 — Information technology — SPDX Specification V2.2.1.https://www.iso.org/standard/81870.html (accessed: 2026-06-12, automated verification limited: iso.org blocks bots). — The SBOM format standard referenced directly in the overview.↩

A6. Bradner, S. (1997).RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels. IETF, BCP 14.https://www.ietf.org/rfc/rfc2119.txt (accessed: 2026-06-12). — Source for the MUST/SHOULD/MAY interpretation in Chapter 2’s terms and definitions.↩

A9. OpenChain Project (2025-10-20).Welcoming the OpenChain AI System Bill of Materials Compliance Guide.https://openchainproject.org/news/2025/10/20/welcoming-the-openchain-ai-system-bill-of-materials-compliance-guide (accessed: 2026-06-12). — Primary source for the Version 1 formal publication date (2025-10-20), the document’s nature (a reference guide), and its distribution formats (PDF, Markdown).↩

A10. OpenChain Project (2025-07-07).Public Comment Period Announced: Artificial Intelligence System Bill of Materials – Compliance Management Guide for the Supply Chain.https://openchainproject.org/news/2025/07/07/public-comments-ai-system-bill-of-materials (accessed: 2026-06-12). — Primary confirmation of the six-week public comment period’s opening (2025-07-07) and closing (2025-08-18).↩

A11. OpenChain Project (2025-08-20).Review of Public Comments and Next Steps: Artificial Intelligence System Bill of Materials – Compliance Management Guide for the Supply Chain.https://openchainproject.org/news/2025/08/20/ai-bom-next-steps (accessed: 2026-06-12). — The comment review outcome and the Governing Board’s publication decision process.↩

A12. OpenChain Project.Reference-Material repository — AI-SBOM-Compliance/en (formal edition distribution location).https://github.com/OpenChain-Project/Reference-Material/tree/master/AI-SBOM-Compliance/en (accessed: 2026-06-12). — The actual distribution location of the citable formal edition.↩

A13. OpenChain Project (2023-12-19).OpenChain Welcomes ISO/IEC 18974:2023, The International Standard For Open Source Security Assurance.https://openchainproject.org/news/2023/12/19/openchain-welcomes-iso-iec-18974 (accessed: 2026-06-12). Standard text:https://www.iso.org/standard/86450.html. — Basis for OpenChain’s extension into the security domain (ISO/IEC 18974:2023).↩

A14. OpenChain Project (2020).OpenChain ISO/IEC 5230:2020 Specification (en). GitHub License-Compliance-Specification.https://github.com/OpenChain-Project/License-Compliance-Specification/blob/master/Official/en/ISO-5230-2020/ISO-5230-2020.md (accessed: 2026-06-12). — Primary source for the “Verification Materials + Rationale” structure and the statement that it “focuses on what and why, leaving how and when non-prescriptive.”↩

B. AI BOM Formats

B2. SPDX Project.SPDX 3.0.1 Specification — AI Profile.https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (accessed: 2026-06-12). — The primary specification for the concrete data elements that go into an AI SBOM.↩

B5. CycloneDX.Capabilities — Machine Learning Bill of Materials (ML-BOM).https://cyclonedx.org/capabilities/mlbom/ (accessed: 2026-06-12). — The ML-BOM specification. History from its introduction in v1.5 (2023-06) through v1.7 (2025-10, ECMA-424 2nd edition).↩

B6. The Linux Foundation (2024-04-16).SPDX 3.0 Revolutionizes Software Management in Systems with Enhanced Functionality and Streamlined Use Cases (press release, Seattle).https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases (accessed: 2026-06-12). — Primary source for the SPDX 3.0 release date (2024-04-16) and the new AI Profile use cases.↩

B7. OWASP Gen AI Security Project.OWASP AIBOM Generator.https://genai.owasp.org/resource/owasp-aibom-generator/ (accessed: 2026-06-12). — Primary source for the public tool that automatically generates a CycloneDX-format AI SBOM from a Hugging Face model and scores its completeness.↩

B8. cdxgen Project (OWASP CycloneDX).AI/ML-BOM generation (AI_BOM.md). GitHubcdxgen/cdxgen.https://github.com/cdxgen/cdxgen/blob/master/docs/AI_BOM.md (accessed: 2026-06-12). — Primary source for how to use cdxgen’s dedicated AI BOM mode (Hugging Face URL, Modelfile, GGUF input).↩

C. Regulation and Governance

C1. European Parliament and Council (2024).Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal of the EU, 2024/1689, 13.6.2024 (published in the Official Journal 2024-07-12, entered into force 2024-08-01).https://eur-lex.europa.eu/eli/reg/2024/1689/oj (accessed: 2026-06-12). — The EU AI Act text specified in the Governance (3.10) section. Primary regulatory source for the phased application dates of Article 113 and for the transparency and risk management obligations.↩

C4. OECD.Hiroshima AI Process (HAIP) Reporting Framework (transparency.oecd.org).https://transparency.oecd.org/ (accessed: 2026-06-12, automated verification limited: connection refused/bot blocked). — The submission platform for the HAIP corporate reporting framework. Basis for the 1.0 stage.↩

C6. European Commission.AI Act | Shaping Europe’s digital future (Regulatory framework for AI).https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (accessed: 2026-06-12). — Primary confirmation that GPAI obligations apply from 2025-08-02. Cross-reference, together with the EUR-Lex text (C1), for the application date and scope of obligations.↩

C7. OECD.AI (2026-05-28).OECD launches Hiroshima AI Process Reporting Framework 2.0.https://oecd.ai/en/haip-2-launch (accessed: 2026-06-12). Press release:https://www.oecd.org/en/about/news/press-releases/2026/05/oecd-launches-streamlined-hiroshima-ai-process-reporting-framework-to-help-small-and-medium-sized-enterprises-participate.html (automated verification limited: oecd.org blocks bots). — Basis for the HAIP Reporting Framework 2.0 launch date (2026-05-28, Paris G7 Digital and Technology Ministers’ Meeting), its focus on small and medium-sized enterprises, its role-based structure, participation by more than 50 organizations, and the next review deadline (2026-09-01).↩

D. SBOM Policy Background

D1. NTIA, U.S. Department of Commerce (2021).The Minimum Elements For a Software Bill of Materials (SBOM) (implementing Executive Order 14028 §10(j), 2021-07-12).https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf (accessed: 2026-06-12, automated verification limited: .gov blocks bots). — The SBOM minimum elements policy baseline from which AI SBOM descends.↩

D4. NIST.Software Security in Supply Chains: Software Bill of Materials (SBOM) — Executive Order 14028. Information Technology Laboratory.https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 (accessed: 2026-06-12). — The primary NIST page that carries Executive Order 14028’s SBOM definition and recommends compliance with SPDX, CycloneDX, and SWID and meeting the NTIA minimum elements.↩

E. Supplementary (Academic/Industry)

E4. Jewitt, J., Li, H., Adams, B., Rajbahadur, G. K., Hassan, A. E. (2025).From Hugging Face to GitHub: Tracing License Drift in the Open-Source AI Ecosystem. arXiv:2509.09873.https://arxiv.org/abs/2509.09873 (accessed: 2026-06-12). — Academic source quantifying license drift (35.5% loss of restrictive clauses in model-to-application transitions, 0.4% preservation of ML-specific obligations).↩

E5. arXiv (2025).New Tools are Needed for Tracking Adherence to AI Model Behavioral Use Clauses. arXiv:2505.22287.https://arxiv.org/abs/2505.22287 (accessed: 2026-06-12). — Notes the lack of tools to track compliance with the behavioral use restrictions in RAIL/OpenRAIL and the Llama Community License.↩

E6. Jin, S. et al. (2025).Building an Open AIBOM Standard in the Wild. arXiv:2510.07070 (accepted at ICSE 2026 SEIP).https://arxiv.org/abs/2510.07070 (accessed: 2026-06-12). — Discusses the OWASP AIBOM project’s standardization approach and the gap in representing AI datasets and training artifacts.↩

E8. JUN Legal (2025-03-18).Responsible AI Licenses (RAIL).https://jun.legal/en/2025/03/18/responsible-ai-licenses-rail-verantwortungsvolle-ki-nutzung-durch-lizenzierung/ (accessed: 2026-06-12). — Industry/legal commentary explaining that RAIL/OpenRAIL and the Llama Community License fail to meet the OSI Open Source Definition because of their behavioral use restrictions.↩

This section covers open source tools that automate AI SBOM compliance. It summarizes each tool’s key features, installation, and usage together with actual execution results. This elaborates, tool by tool, on the categories seen in the automation maturity map in3.9 AI SBOM.

There is a boundary worth stating honestly. Tools generate a BOM automatically, but they cannot guarantee that the license information in the generated BOM is accurate or that no components are missing. In the tool comparison below, OWASP AIBOM Generator fills in license information from model cards, while cdxgen quickly identifies dependencies but leaves the license field empty. Look at this difference when choosing a tool.

Tools at a Glance

Each tool automates part of the generation, analysis, or management stage. No single tool solves everything, so combine tools that generate AI SBOMs (OWASP AIBOM Generator, cdxgen) with tools that analyze security (Lab700x, Trivy) and a tool that manages them (Dependency-Track).

This guide explains, one by one, each requirement ofAI System Bill of Materials — Compliance Management Guide for the Supply Chain (Version 1.0), published by the OpenChain AI Work Group. It walks through what verification material each clause requires, how to comply with it, and what samples and tools are ready to use.

This specification carries the same structure as ISO/IEC 5230, the open source license compliance standard — requirements, verification material, and rationale — over into the AI supply chain. It brings into scope not only code but also the licensing and transparency obligations of model weights, training datasets, and the Model Tree.

Author : OpenChain Korea Work Group /CC BY 4.0

Intended Audience

• Compliance staff at organizations that develop AI systems or exchange them through the supply chain
• Practitioners who have an open source compliance (ISO/IEC 5230) program in place and want to extend it into AI
• Legal, security, and development staff who need to check the licensing and transparency obligations of AI models and datasets

How to Use This Guide

Phased Implementation Roadmap

The 10 requirements are divided into four phases by implementation priority. Phase 1 establishes the program’s foundation, Phase 2 builds AI-specific compliance processes, Phase 3 puts operational structures in place, and Phase 4 establishes governance.

Phase 1 — Program Foundation

Goal: Define the program’s scope, establish policy, and secure competence and awareness.

Phase 2 — AI Extension Processes

Goal: Build AI-specific licensing, transparency, and SBOM processes that cover not just code but also models, weights, and datasets. This is the area where the AI SBOM Guide expands most on ISO/IEC 5230.

Phase 3 — Operational Structure

Goal: Create a channel for responding to external compliance inquiries, and assign accountability and resources to the program.

Phase 4 — Governance

Goal: Put in place a governance framework spanning the full AI system lifecycle, and reflect emerging AI regulation.

Full Clause Checklist

The body of the AI SBOM Compliance Guide consists of10 clauses and 19 verification material items in total (by this guide’s verification material numbering).

Total: 10 clauses / 19 verification material items

Automation Maturity Map

This is an honest breakdown of how far each AI SBOM compliance task is automated by tools today. For “generation,” usable open source tools already exist. Interpreting license obligations and tracking compliance with non-standard licenses, on the other hand, remain the work of people and policy. Each clause page follows this line to distinguish “what a tool handles” from “what a person must fill in.”

The installation and use of each tool is covered with execution screens and command output in theTools section.

Relationship to Other Standards

Original Specification

This is stage 4 of the implementation roadmap. It brings the preceding clauses together to establish a governance framework across the full AI system lifecycle, and reviews it regularly to reflect emerging AI regulations (3.10).

1. Clause Overview

Program scope determines how far compliance extends. If the scope is ambiguous, it becomes unclear which AI systems need an SBOM and which models’ licenses need review. Scope must be declared first so that every subsequent clause knows what it applies to.

3.4 requires declaring the scope of application for each program. Scope can differ by organization. Some organizations cover a single product line; others cover an entire department or the whole organization. In AI, scope determination covers not only self-developed models but also externally sourced models and datasets, and the external release of in-house models.

2. Required Activities

• Define what the program applies to (externally deployed AI systems, externally sourced models and datasets, external release of in-house models, and so on).
• Record what is excluded from application and the rationale for the exclusion.
• Keep the scope statement consistent with the scope of application in the policy document.
• Review and update the scope periodically as the business environment changes.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.4.1 Program scope statement

Compliance Method

State the program’s scope and limits in writing. Clearly note what is included, what is excluded, and if excluded, on what grounds. An AI SBOM program becomes clearer when it declares what it applies to by breaking it down into material types and activities. The table below is an example of organizing scope.

Table 1. Example of an AI SBOM program scope declaration

Considerations

• Consistency with policy: The scope statement should not conflict with the scope of application in3.1 Policy.
• Grounds for exclusion: Record the rationale for excluded items. Even an internal experimental model falls into scope once it moves to external deployment, so put a review procedure in place for that transition point.([Recommendation of this guide])
• Periodic review: Update the scope whenever a new product line or new AI service is introduced.

Sample (Scope Statement)

## AI SBOM Compliance Program Scope
### Applies To
This program applies to all AI systems, models, and services that the company deploys
externally, and to pretrained models and datasets sourced externally. It also covers
activities that release in-house models externally.
### Excluded
Models used solely for internal experimentation or research and not deployed externally
are excluded. However, if such a model transitions to external deployment, it is brought
into scope through the intake review procedure.
### Review Cycle
Scope is reviewed and updated at least once a year, or as the business environment
changes.

5. See Also

• Scope of application in the policy:3.1 Policy
• AI SBOM for material within scope:3.9 AI SBOM
• ISO/IEC 5230 scope example:ISO/IEC 5230 Compliance Guide — 3.1.4 Program Scope

This is stage 3 of the implementation roadmap. It establishes a channel to respond to external AI SBOM compliance inquiries (3.7) and assigns responsibility, personnel, and funding to the program (3.8).

This page introduces analysis and identification tools that complement AI SBOM generation. Where the generation tools (OWASP AIBOM Generator, cdxgen) record “what is in it,” these tools look at “whether it is safe” and “what version it is.” The commands and features below are organized based on each tool’s official documentation (the tools actually run in this guide areOWASP AIBOM Generator andcdxgen).

Lab700x AI SBOM Scanner — Static Analysis of Model Binaries

A tool that statically analyzes AI model files themselves to extract information. It performs deep introspection on model binaries such as.safetensors,.pt (PyTorch), and.pkl (Pickle) without executing them.

• Key features: Because it examines internal structure without executing the model, it can detect malicious code hidden in a model file (such as Pickle injection), vulnerabilities, or license violations before deployment.
• Role in AI SBOM: Used to inspect externally sourced models at the intake gate. Combined with the inbound metadata enforcement of3.5 License Obligations, it lets metadata verification and binary safety checking be performed together.

Pickle-format models carry a significant supply-chain risk because arbitrary code can execute during deserialization. Inspecting the model without executing it is the core of this tool.

Trivy — Scanning LLM Inference Server Containers

An open source scanner from Aqua Security that checks vulnerabilities in container images and filesystems. It recently added awareness of AI model infrastructure.

• Key features: Scans LLM inference server containers such as Ollama and LocalAI to collect the open source libraries they contain and their container vulnerabilities.
• Usage:

# Scan a container image (vulnerabilities)trivy image ollama/ollama:latest# Generate an SBOM (CycloneDX)trivy image --format cyclonedx --output sbom.json ollama/ollama:latest

Used in environments that deploy AI models as containers, to leave a record of the inference server’s vulnerabilities and components as an SBOM.

Syft — Identifying AI Packages and Virtual Environments

An SBOM generator from Anchore that scans containers, filesystems, and virtual environments.

• Key features: Analyzes Python virtual environments to collect the exact versions of packages used to run AI, such as PyTorch and Transformers. Outputs in SPDX and CycloneDX format.
• Usage:

# Scan a directory and output CycloneDXsyft scan dir:. -o cyclonedx-json=sbom.json# Scan a container imagesyft scan registry:python:3.11-slim -o spdx-json

Its role overlaps with cdxgen’s, so an organization already using the Anchore toolset (Syft, Grype) would naturally generate the dependency SBOM of an AI application with Syft and check vulnerabilities with Grype.

Recommended Tool Combination

No single tool solves everything. In practice, combine tools by dividing up their roles.

See Also

• AI SBOM generation and management procedure:3.9 AI SBOM
• Execution results of generation tools:OWASP AIBOM Generator,cdxgen

1. Clause Overview

An AI SBOM (AI System Bill of Materials) is a list capturing the elements that make up an AI system and the information about them. Where a traditional SBOM records software components, an AI SBOM adds models, weights, datasets, and hyperparameters on top. 3.9 requires a procedure for generating and managing the AI SBOM.

The format is left open. The specification states that SPDX, CycloneDX, or any other format is acceptable. There is, however, one obligation: the AI SBOM shall account for inbound materials from third parties. If pre-trained models and datasets brought in from outside are left out, the basis for tracking license obligations (3.5) and transparency obligations disappears.

The AI SBOM area is where the line “generation is automated by tools, but accuracy and compliance judgment are filled by people” is sharpest. This page walks through the procedure along that line.

2. Activities to Perform

• Establish a procedure for identifying, tracking, reviewing, approving, and archiving the components of an AI system (models, datasets, etc.).
• Decide on an AI SBOM format (SPDX 3.0 AI Profile or CycloneDX ML-BOM recommended).([Guide Recommendation])
• Ensure models and datasets brought in from third parties are always included in the AI SBOM.
• Wire a generation tool into CI/CD to regenerate the AI SBOM repeatedly.([Guide Recommendation])
• Have a person review whether the license and provenance fields of the generated AI SBOM are accurate.([Guide Recommendation])
• Retain records (generation history, approval history) demonstrating that the procedure was followed.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.9.1 AI SBOM Management Procedure (Identification, Tracking, Review, Approval, Archiving)

How to Comply

Design the AI SBOM procedure around four stages: generation, review, approval, and archiving. Automate the generation stage with tools, and leave the review and approval stages to people. Even when a tool copies a license field straight from a model card, it cannot judge whether that license actually fits the use case, or whether something is missing or misstated.

The figure below shows the flow from AI SBOM generation to archiving.

Figure 1. Procedure from AI SBOM generation to archiving

Tool Mapping

Below are open source tools usable at each stage. “Automation level” indicates how far a tool handles that task on its own.

Installation, usage, and execution screens for each tool are covered in detail in theTools section (OWASP AIBOM Generator,cdxgen,Model/Container Scanners).

The command to generate an AI BOM with cdxgen is as follows. You can pass a Hugging Face model URL and purl, a Modelfile, or a GGUF artifact directly (cdxgen AI-BOM docs).

# Generate an AI BOM from the AI project directorycdxgen -t ai -o aibom.json .# Generate including AI/ML metadata (formulation)cdxgen -t ai --include-formulation -o aibom.json .

The OWASP AIBOM Generator takes a Hugging Face model as input, builds a CycloneDX-format AIBOM, and scores its completeness. It is maintained by the OWASP Gen AI Security Project and is also available as a Hugging Face Space (OWASP AIBOM Generator).

Hands-On — Generating with cdxgen

This is the result of actually running cdxgen against a summarization app (depending ontransformers andtorch) that loads a pre-trained model (facebook/bart-large-cnn). The tool automatically identifies 5 dependencies and produces a CycloneDX 1.7-format BOM.

$ cdxgen -t python --include-formulation -o aibom.json .CycloneDX Generator 12.5.1 (Node.js)Generated components — 5 items (CycloneDX 1.7): transformers 4.44.2 pkg:pypi/transformers@4.44.2 license: empty torch 2.4.0 pkg:pypi/torch@2.4.0 license: empty numpy 1.26.4 pkg:pypi/numpy@1.26.4 license: empty tokenizers 0.19.1 pkg:pypi/tokenizers@0.19.1 license: empty huggingface-hub 0.24.6 pkg:pypi/huggingface-hub@0.24.6 license: empty

One component from the generated BOM looks like this. The identification evidence is filled in, but thelicenses field is empty.

{"name":"transformers","version":"4.44.2","purl":"pkg:pypi/transformers@4.44.2","type":"library","evidence":{"identity":[{"field":"purl","confidence":0.5,"methods":[{"technique":"manifest-analysis","value":"requirements.txt"}]}]}}

Figure 2. cdxgen 12.5.1 execution output(run on 2026-06-13,-t python --include-formulation)

Format Sample (CycloneDX ML-BOM)

Below is a shortened example of the model component structure in a CycloneDX 1.6 ML-BOM. The key structure follows themachine-learning-model component andmodelCard in theofficial CycloneDX spec. If the license is non-standard (has no SPDX ID), state it withname.

{"bomFormat":"CycloneDX","specVersion":"1.6","components":[{"bom-ref":"model-llama31-8b","type":"machine-learning-model","group":"meta-llama","name":"Llama-3.1-8B","version":"1.0","licenses":[{"license":{"name":"Llama 3.1 Community License"}}],"modelCard":{"modelParameters":{"task":"text-generation","architectureFamily":"llama","datasets":[{"type":"dataset","name":"Public pretraining corpus","classification":"public"}]},"considerations":{"useCases":["Internal document summarization"],"technicalLimitations":["Potential for hallucination","Performance variance in Korean"]}}}]}

If you use SPDX 3.0, the AI Profile and Dataset Profile express the same information (SPDX 3.0 AI Profile). The concrete fields of each format and the technical details of generation tools are covered in theISO/IEC 42001 Guide — AI SBOM.

Considerations

• Reflect inbound materials (specification obligation): Set up a procedure that generates an SBOM entry at intake time so that models and datasets brought in from outside are never missing from the AI SBOM. This is ashall-level obligation.
• Generation by tool, review by people: Generation tools copy the license written on the model card as-is. Because model cards themselves commonly have missing or incorrect license information, have a person check the license and provenance fields of the generated AI SBOM against the original source.
• Format consistency: Pick either SPDX or CycloneDX as the organization’s default format and operate tools and repositories around it consistently. Both formats treat models and datasets as first-class components.
• CI/CD integration: The AI SBOM is not a one-time deliverable. Wire it into the pipeline so it is regenerated whenever a model or dataset changes.

3.9.2 Records Demonstrating Procedure Compliance

How to Comply

Verification material 3.9.2 is the record showing the procedure was actually followed. Alongside the AI SBOM file itself, keep a history of who generated, reviewed, and approved it and when. If it is generated automatically in CI/CD, the build logs and the generated SBOM artifact become the record, and the upload history to a management tool such as Dependency-Track also serves as evidence.

Considerations

• Retain generation history: Keep the AI SBOM from each point in time for every version of the supplied AI system to maintain traceability.
• Approval record: Record who reviewed and approved it. This connects to the lifecycle review inGovernance (3.10).

5. References

• License obligation review procedure:3.5 License Obligations
• Technical details of AI SBOM formats and generation tools:ISO/IEC 42001 Guide — AI SBOM
• SBOM management tools:Dependency-Track,cdxgen + Dependency-Track integration
• Governance and lifecycle review:3.10 Governance

1. Clause Overview

If competence (3.2) addresses “can they do it,” awareness addresses “do they know why they should.” It is not enough for participants to merely know that a policy exists. Compliance functions in practice only when participants also know how their own work contributes to the program and what happens if they fail to follow it.

3.3 requires ensuring that program participants are aware of four things: the AI SBOM policy, relevant business objectives, their own contribution to the program’s effectiveness, and the implications of not following the program’s requirements. In AI, the implications of non-conformance extend beyond copyright disputes to regulatory violations and breaches of usage restrictions, so participants must clearly recognize this.

2. Required Activities

• Ensure participants know the AI SBOM policy and where to find it.
• Communicate relevant business objectives (building trust, regulatory compliance, meeting supply-chain requirements).
• Inform participants how their own work contributes to the program.
• Inform participants of the implications of non-conformance (regulatory violations, contract termination, breaches of usage restrictions).
• Assess participants’ awareness and preserve evidence of that assessment.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.3.1 Evidence of assessed participant awareness

Compliance Method

Assess whether participants actually understand the four awareness elements and keep evidence of that assessment. If policy dissemination (3.1.2) proves that participants “were informed,” the awareness assessment proves that they “understood.” Assess through post-training comprehension quizzes, acknowledgment signatures, or interviews. Make sure the assessment does not omit the three elements the standard specifies in its verification material: the program’s objectives, one’s own contribution, and the implications of non-conformance.

Considerations

• Cover all four elements: In addition to policy awareness, include objectives, contribution, and the implications of non-conformance in the assessment. Omitting even one can be flagged during a certification audit.
• Emphasize AI-specific implications: Include regulatory violations (the EU Artificial Intelligence Act, Korea’s AI Basic Act) and breaches of non-standard license usage restrictions among the implications of non-conformance.
• Differentiate by role: Data staff and developers contribute differently, so tailor the assessment content to each role.
• Retain evidence: Preserve assessment results and acknowledgment signatures for use as verification material.

Sample (Awareness Assessment Log)

| Participant (Role) | Policy Awareness | Objectives Awareness | Contribution Awareness | Non-conformance Awareness | Assessment Method | Assessment Date |
|-------------|:--------:|:--------:|:--------:|:---------------:|----------|--------|
| Lee OO (Development) | Met | Met | Met | Met | Post-training check | 2026-03-10 |
| Park OO (Data) | Met | Met | Met | Met | Interview + signature | 2026-03-11 |

Sample acknowledgment signature form:

I have been informed of and understand our company's AI SBOM compliance policy, the program's
objectives, my own contribution, and the implications of non-conformance (regulatory violations,
license usage restriction breaches, contract termination).
Name: ____ Role: ____ Signature: ____ Date: ____

5. See Also

• Policy and dissemination procedure:3.1 Policy
• Competence by role:3.2 Competence
• ISO/IEC 5230 awareness example:ISO/IEC 5230 Compliance Guide — 3.1.3 Awareness

Overview

cdxgen is the official SBOM generator of the OWASP CycloneDX project. It supports more than 20 languages and package managers, and the latest version offers a dedicated AI BOM mode. It automatically identifies the dependencies of AI applications (PyTorch, Transformers, and so on) and integrates well with CI/CD pipelines.

From an AI SBOM standpoint, cdxgen’s strength is speed and automation. Its weakness is that it does not fill in license information in a default run. This trait shows up in the execution result below. Where OWASP AIBOM Generator centers on model card metadata, cdxgen centers on code and dependencies. Using both together covers both models and dependencies.

Key Features

• Identifies dependencies from source code and container images to generate a CycloneDX SBOM.
• Includes AI/ML metadata (formulation) with AI BOM mode (-t ai).
• Takes Hugging Face model URLs, Modelfiles, and GGUF artifacts directly as input.
• Automatically submits SBOMs to a Dependency-Track server for continuous management.

Installation

# One-off run (requires Node.js)npx @cyclonedx/cdxgen@latest --version# Global installnpm install -g @cyclonedx/cdxgen

Usage — Generating an AI BOM

Run in AI BOM mode from the AI project directory.

# Generate an AI BOMcdxgen -t ai -o aibom.json .# Generate including AI/ML metadata (formulation)cdxgen -t ai --include-formulation -o aibom.json .

Below is the actual result of running cdxgen against a summarization app (transformers,torch dependencies) that loads a pretrained model (facebook/bart-large-cnn). It automatically identifies 5 dependencies and produces a CycloneDX 1.7 BOM.

$ cdxgen -t python --include-formulation -o aibom.json .CycloneDX Generator 12.5.1 (Node.js)Generated components — 5 entries (CycloneDX 1.7): transformers 4.44.2 pkg:pypi/transformers@4.44.2 license: empty torch 2.4.0 pkg:pypi/torch@2.4.0 license: empty numpy 1.26.4 pkg:pypi/numpy@1.26.4 license: empty tokenizers 0.19.1 pkg:pypi/tokenizers@0.19.1 license: empty huggingface-hub 0.24.6 pkg:pypi/huggingface-hub@0.24.6 license: empty

Figure 1. cdxgen execution output(cdxgen 12.5.1, run 2026-06-13)

One of the generated components looks like this. The identification evidence is filled in, but thelicenses field is empty.

{"name":"transformers","version":"4.44.2","purl":"pkg:pypi/transformers@4.44.2","type":"library","evidence":{"identity":[{"field":"purl","confidence":0.5,"methods":[{"technique":"manifest-analysis","value":"requirements.txt"}]}]}}

What the Execution Result Shows

See Also

• AI SBOM generation and management procedure:3.9 AI SBOM
• Generator centered on model metadata:OWASP AIBOM Generator
• SBOM management:Dependency-Track,cdxgen + Dependency-Track integration
• Official:cdxgen AI-BOM documentation

This is stage 2 of the implementation roadmap. It is the area where the AI SBOM guide extends most significantly beyond ISO/IEC 5230, covering licensing obligations (3.5), transparency obligations (3.6), and AI SBOM generation and management (3.9).

1. Clause Overview

If competence (3.2) defines who should be able to do what, effective resourcing is what actually attaches people, time, and budget to those roles so the program runs. When policy and procedures exist only on paper and no resources back them, compliance is a name only.

3.8 requires assigning accountability for program tasks and allocating adequate resources. There are five verification materials, covering the naming of role holders, the provision of staffing and funding, access to legal expertise, an internal responsibility-assignment procedure, and a non-conformance remediation procedure. The specification references the resource-related sections of ISO/IEC 42001 Annex B (B.4.2, B.4.6) and the human oversight determination section (B.9.3).

2. Activities to Perform

• Assign accountability for the successful execution of program tasks.
• Allocate sufficient time and funding to the tasks.
• Make legal expertise on AI SBOM compliance accessible to those who need it.
• Have a procedure for reviewing and updating the policy and its supporting tasks.
• Have a procedure for reviewing and remediating non-conformances.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.8.1 Document Identifying Role Holders

How to Comply

Document, by name, the people, groups, or functions holding program roles. Including the job title alongside the name is more stable against personnel changes. The AI SBOM program needs, in addition to the usual open source roles, an AI governance lead, an AI SBOM verification owner, and a model/dataset license review owner.

Sample

| Role | Holder (Job Title) | Contact |
|------|-------------|--------|
| AI Governance Lead | Kim, OO (AI Ethics & Governance Lead) | ai-gov@company.com |
| AI SBOM Verification Owner | Lee, OO (Platform Engineer) | sbom@company.com |
| License Review Owner | Park, OO (Open Source Legal) | oss-legal@company.com |
| Security Owner | Choi, OO (Product Security) | psirt@company.com |

3.8.2 Staffing and Funding

How to Comply

Show that identified roles are actually staffed and that budget has been allocated. Record the time allocation (e.g., 30%) and the basis for the annual budget. AI SBOM compliance takes time for model/dataset review and tool operation, so estimate the per-role time allocation realistically.

Considerations

• State the time allocation: For a shared role, record the percentage of time allocated to AI SBOM work.
• Tool budget: Include the cost of AI SBOM generation/management tools and legal counsel in the budget.

Sample

| Role | Holder | Time Allocation | Annual Budget Basis | Approver / Approval Date |
|------|--------|----------|---------------|--------------|
| AI Governance Lead | Kim, OO | 30% | Personnel cost + regulatory counsel | CTO / 2026-01-15 |
| AI SBOM Verification Owner | Lee, OO | 50% | Personnel cost + tool operation | CTO / 2026-01-15 |

3.8.3 Access to Legal Expertise

How to Comply

Make legal expertise on AI SBOM compliance accessible to those who need it. Because interpreting non-standard licenses and determining regulatory obligations is legal’s job, specify the access path — internal legal counsel or an outside firm. Also define escalation criteria (which matters get escalated to legal).

Sample

- Internal: Open Source Legal Owner (Park, OO) — first-pass license review
- External: XX Law Firm, AI/IP team — non-standard license disputes, regulatory interpretation
- Escalation criteria: a license not on the policy's prohibited/conditional lists, determining
downstream disclosure obligations, matters where new regulation newly applies

3.8.4 Internal Responsibility Assignment Procedure

How to Comply

Document the procedure for assigning internal responsibility for AI SBOM compliance. Vague responsibility leads to gaps, so a RACI matrix distinguishing Responsible (R), Accountable (A), Consulted (C), and Informed (I) per task is effective.

Sample (RACI Matrix)

R Responsible, A Accountable, C Consulted, I Informed

3.8.5 Non-Conformance Review and Remediation Procedure

How to Comply

Have a procedure for reviewing and remediating non-conformances (e.g., a prohibited-license model brought in, a missing AI SBOM, a failure to meet transparency obligations). Vary the handling deadline by severity. In AI, a licensing problem sometimes surfaces after a model has already been deployed, so prepare a remediation path that includes recall or replacement.

Sample (Remediation Procedure and Severity Criteria)

Remediation procedure: identify/report → assess severity → root-cause analysis → corrective
action → recurrence prevention → record
| Severity | Example | Handling Deadline |
|--------|------|----------|
| High | A prohibited-license model is included in a product shipped externally | Immediate response (contain/replace review within 48 hours) |
| Medium | An inbound model is missing from the AI SBOM | Backfill within 7 days |
| Low | Some model card metadata is missing | Handle at the next periodic review |

5. References

• Competence definitions per role:3.2 Competence
• Governance review linked to non-conformance remediation:3.10 Governance
• ISO/IEC 5230 resourcing model:ISO/IEC 5230 Compliance Guide — 3.2.2 Effectively Resourced

1. Clause Overview

If license obligations (3.5) ask “do we have the right to use this material,” transparency obligations ask “what must we disclose about this material.” The two obligations come from different sources. License obligations are imposed by the rights holder through a contract; transparency obligations are imposed by regulation through law.

3.6 requires having a procedure to review whether there are transparency obligations imposed by regulation. The scope of review includes training, testing, and verification datasets, taking into account the model’s intended use. If the use case for the training data creates a transparency issue (e.g., a disclosure obligation to downstream recipients), appropriate risk mitigation measures must be taken. As the EU Artificial Intelligence Act begins full enforcement of transparency obligations from August 2026, the practical weight of this clause is growing.

2. Required Activities

• Maintain a procedure to identify the transparency regulations that apply to AI systems being adopted or developed.
• Review whether training, testing, and verification datasets carry disclosure obligations, based on their intended use.
• Determine risk mitigation measures where a disclosure obligation to downstream recipients exists.
• Document the transparency measures taken.
• Regularly update and reflect the latest transparency obligations set by regulators.([Recommendation of this guide])

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.6.1 Procedure to review and document transparency obligations

Compliance Method

Transparency obligations differ by regulation, so first identify which regulations apply. Once the applicable regulations are determined, derive the disclosure items each one requires and reflect those items in the AI SBOM or model card. Unlike license obligations, transparency obligations center on “disclosure,” so the output must be organized in a form that can be delivered externally.

The table below lists the main transparency obligations that intersect with the AI SBOM. The regulatory timeline and broader context are managed together in the regulatory matrix in3.10 Governance.

Table 1. Transparency obligations that intersect with the AI SBOM (as of June 2026)

The figure below shows the review flow that derives transparency obligations from a material’s intended use.

Figure 1. Transparency obligation review flow

Considerations

• Dataset provenance is central: Most transparency obligations attach to training data. A dataset’s provenance and license must be recorded in the AI SBOM to fulfill disclosure obligations. This connects directly to the AI SBOM (3.9).
• Intended use is the criterion: The same model can carry different transparency obligations depending on the use case. High-risk uses or services aimed at the general public carry heavier obligations.
• Downstream disclosure obligations: When supplying a model or system externally, review what information the recipient must be told. Risk mitigation can be fulfilled through a public summary of training data or contractual notice.
• Reflect regulatory change: Since the EU Artificial Intelligence Act applies transparency obligations from August 2026, update the procedure to match the timeline. Responsibility for the update is managed by governance (3.10).

Sample (Transparency Obligation Review Procedure)

Below is a sample of the core part of a transparency obligation review procedure document. This procedure document becomes verification material 3.6.1.

## Transparency Obligation Review Procedure
### 1. Identify Applicable Regulations
Identify applicable regulations based on the AI system's intended use and deployment
region.
(e.g., EU market deployment → EU Artificial Intelligence Act; domestic high-impact AI →
Korea's AI Basic Act)
### 2. Derive Disclosure Items
Organize each regulation's transparency obligations into disclosure items.
- Training data summary (EU Artificial Intelligence Act Article 53)
- AI-generated / interaction labeling (EU Artificial Intelligence Act Article 50, Korea's
AI Basic Act)
- Data provenance disclosure (Korea's AI Basic Act)
### 3. Downstream Review
Review the information to be conveyed to recipients on external supply, and determine the
necessary risk mitigation measures.
### 4. Reflection and Documentation
Reflect the derived disclosure items in the AI SBOM and model card, and record the
measures taken.
### 5. Responsibility and Cycle
- Review: Legal and AI governance lead
- Update: On changes to regulatory enforcement timelines, and at least semiannually

5. See Also

• Distinction from license obligations:3.5 License Obligations
• AI SBOM to hold disclosure items:3.9 AI SBOM
• Regulatory timeline and governance:3.10 Governance
• AI model licenses and labeling obligations:Enterprise Open Source Management Guide — AI Compliance

1. Clause Overview

If policy (3.1) defines what must be done, competence ensures there are people who can do it. AI SBOM compliance demands broader knowledge than open source compliance, which dealt only with code licensing. It requires judgment on the licensing of model weights and datasets, interpreting model cards, emerging AI regulation, and the usage restrictions of non-standard licenses.

3.2 requires identifying the roles and responsibilities that affect the program’s performance, determining the competence each role needs, and ensuring participants have it. The specification specifies competence in governance, security, safety, privacy, development, and supplier management functions where relevant to the use case.

2. Activities to Perform

• Identify and document the roles that affect the program’s performance and their responsibilities.
• Define the competence required for each role (governance, security, safety, privacy, development, supplier management).
• Add AI-specific competence (model/dataset licensing, model card interpretation, AI regulation) to the role-level competence definitions.
• Ensure participants are competent on the basis of education, training, and experience.
• Retain competence assessment evidence, and periodically check that the list stays up to date.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.2.1 List of Roles and Responsibilities

How to Comply

Document the roles involved in the program and the responsibilities of each. In addition to the usual open source roles, an AI SBOM program includes an AI governance role and roles that review models and datasets. Writing responsibilities out specifically makes the later work of defining competence (3.2.2) and assigning accountability (3.8.4) clearer.

Sample

| Role | Responsibility |
|------|------|
| AI Governance Lead | Approves the framework, determines regulatory obligations, chairs periodic reviews |
| AI SBOM Verification Owner | Generates, reviews, and approves the AI SBOM; reflects inbound materials |
| License Review Owner | Determines licensing obligations for models, datasets, and the model tree |
| Data Owner | Manages the provenance and licensing of training/validation datasets |

3.2.2 Competence Required per Role

How to Comply

Define the competence each role must have. Of the six functions the specification lists (governance, security, safety, privacy, development, supplier management), select the ones that apply to the role and use case, and add AI-specific competence. For example, the license review owner needs the competence to interpret the usage restrictions of non-standard licenses (Llama Community, OpenRAIL).

Sample

| Role | Required Competence |
|------|----------|
| AI Governance Lead | Governance, understanding of AI regulation (EU AI Act, Korea's AI Basic Act), risk management |
| AI SBOM Verification Owner | Development, SPDX/CycloneDX formats, model card interpretation, generation tool operation |
| License Review Owner | Supplier management, interpreting open source and non-standard licenses, model tree tracing |
| Data Owner | Privacy, dataset licensing, provenance management |

3.2.3 Competence Assessment Evidence

How to Comply

Assess whether each participant actually has the competence their role requires, and retain the evidence. Training completion, qualifications, and hands-on experience serve as the basis. Since AI regulation and licensing change quickly, periodically check the list to keep it current.

Considerations

• Diversify the basis for assessment: Use not only training completion but also practical work products (e.g., license review records) as competence evidence.
• Periodic checks: Re-review competence requirements when new regulation takes effect or new license types emerge.
• Fill gaps: When an assessment reveals a competence gap, close it with training or outside expertise (3.8 Effectively Resourced).

Sample (Competence Assessment Log)

| Participant (Role) | Role | Assessment Item | Basis | Result | Assessment Date |
|-------------|------|----------|----------|------|--------|
| Lee, OO | AI SBOM Verification Owner | Writing CycloneDX ML-BOM | Internal training + work products | Met | 2026-03-10 |
| Park, OO | License Review Owner | Interpreting non-standard licenses | 5 years of OSS legal experience | Met | 2026-03-10 |

5. References

• Procedure for attaching resources to roles:3.8 Effectively Resourced
• Securing participant awareness:3.3 Awareness
• ISO/IEC 5230 competence model:ISO/IEC 5230 Compliance Guide — 3.1.2 Competence

This is stage 1 of the implementation roadmap. It defines the program’s scope (3.4), establishes policy (3.1), and secures the competency and awareness of participants (3.2, 3.3). All subsequent clauses operate on top of this foundation.

Overview

OWASP AIBOM Generator is an open source tool that takes a Hugging Face model ID as input, fetches model card metadata, and generates an AI SBOM in CycloneDX format. It is maintained by the OWASP Gen AI Security Project, and its distinguishing feature is scoring how complete the generated BOM is.

Where cdxgen identifies dependencies quickly but leaves the license fields empty, this tool fills in the license, author, and external references recorded in the model card. It works well as a starting point for the license review required by3.5 License Obligations.

Key Features

• Fetches metadata from Hugging Face models and generates an AIBOM in both CycloneDX 1.6 and 1.7 format.
• Evaluates the completeness of the generated BOM with a score (0–100) and a profile, broken down section by section.
• Displays model information, the model card, license, and external references in a human-readable view.
• Available both as a web UI and a command-line interface (CLI).

Usage A — Web UI

The simplest approach: just enter a model ID in the browser. Use the Hugging Face Space provided by the OWASP Gen AI Security Project, or clone the repository and run it locally.

First, enter a Hugging Face model ID (e.g.,facebook/bart-large-cnn) on the input screen and click generate.

Figure 1. OWASP AIBOM Generator input screen(GenAI Security Project, captured 2026-06-13)

Once generation finishes, the result screen shows an AIBOM summary, the completeness assessment, download buttons (CycloneDX 1.6 and 1.7), AI model information, and the model card. The completeness assessment at the top of the screen shows at a glance whether the BOM has the minimum fields needed for identification.

Figure 2. Generation result screen — model information, license (MIT), completeness assessment (Basic)(captured 2026-06-13)

The result screen offers a Human-Friendly View along with a field checklist, a score report, and a JSON view tab. Check the items needed for license obligation review and AI SBOM retention directly on screen, and download the CycloneDX file.

Usage B — Command Line (CLI)

The CLI is convenient for embedding in CI/CD or batch-processing multiple models. After installation, pass the model ID as an argument.

# Install (a Python virtual environment is recommended)pip install"git+https://github.com/GenAI-Security-Project/aibom-generator"# Generate an AIBOM from a model IDaibom facebook/bart-large-cnn -o aibom.json

Below is the actual execution result. It generates CycloneDX 1.6 and 1.7, passes schema validation, and shows the completeness score broken down by section.

$ aibom facebook/bart-large-cnn -o aibom.json✅ Successfully generated CycloneDX 1.6 SBOM — Schema Validation (1.6): Valid✅ Successfully generated CycloneDX 1.7 SBOM — Schema Validation (1.7): Valid📊 Completeness Score: 58.7/100 Profile: Basic - Required Fields: 20/20 - Metadata: 8/20 - Component Basic: 17.1/20 - Component Model Card: 6.7/30 - External References: 10/10

Figure 3. CLI execution output(aibom CLI, model facebook/bart-large-cnn, run 2026-06-13)

The model component in the generated BOM has its license and model card filled in. Unlike cdxgen’s output, thelicenses field is not empty.

{"type":"machine-learning-model","name":"bart-large-cnn","purl":"pkg:huggingface/facebook/bart-large-cnn","licenses":[{"license":{"id":"MIT"}}],"authors":[{"name":"facebook"}],"modelCard":{"modelParameters":{},"considerations":{}}}

What the Execution Result Shows

See Also

• AI SBOM generation and management procedure:3.9 AI SBOM
• License obligation review:3.5 License Obligations
• Another generation tool:cdxgen
• Official:OWASP AIBOM Generator

1. Clause Overview

Organizations that exchange AI systems in the supply chain need to verify each other’s compliance. That requires a publicly available channel for external inquiries, and readiness on the organization’s side to respond to them. Access secures both directions.

3.7 requires two things: publicly identifying a means by which a third party can make an AI SBOM compliance inquiry, and maintaining an internal procedure to respond effectively to that inquiry. In AI, AI-specific information — model and dataset licenses, training data provenance, model cards — is added to the subject matter of such inquiries.

2. Required Activities

• Publicly identify a means (e.g., a public email address) by which a third party can make an AI SBOM compliance inquiry.
• Post the public means somewhere externally discoverable, such as a product notice or website.
• Document the internal procedure for receiving, classifying, and responding to external inquiries.
• Define the responsible party and the response deadline.
• Record the history of inquiries and responses.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.7.1 Publicly identified means of external inquiry

Compliance Method

Identify a public contact means that anyone can find. A role-based email address (a job function address, not an individual) is stable. Post it in locations such as the product notice, the open source/AI policy page on the company website, or the contact field of the model card. Stating a response deadline alongside it builds trust.

Sample

AI Compliance Inquiries: ai-compliance@company.com
We accept inquiries regarding the components of the AI systems we provide, model and
dataset licenses, and AI SBOMs. We send an initial reply within 14 business days of
receipt.
(Posted at: product notice, company website AI policy page, model card contact field)

3.7.2 Internal inquiry response procedure

Compliance Method

Document the internal procedure from receiving an external inquiry to answering it. Define the stages of intake, classification, assignment, review, reply, and recording, with a deadline for each stage. Because AI SBOM inquiries need to reference model cards or license review records, the AI SBOM verification lead and the license review lead respond together.

The figure below shows the external inquiry response flow.

Figure 1. External AI SBOM compliance inquiry response flow

Considerations

• Set deadlines: Define both an initial reply deadline (e.g., 14 days) and a final answer deadline (e.g., 60 days).
• Protect AI-specific information: Set a standard for how far to disclose sensitive information such as model weights or training data when answering inquiries. Define the boundary between trade secrets and transparency obligations (3.6).([Recommendation of this guide])
• Retain history: Record the inquiry content, the reply, and the processing time as verification material.

Sample (Response Procedure Outline)

## AI SBOM Compliance Inquiry Response Procedure
1. Intake: Register inquiries received at ai-compliance@.
2. Classification: Classify as AI SBOM request / license inquiry / transparency
obligation inquiry.
3. Assignment: Assign to the AI SBOM verification lead or the license review lead based
on classification.
4. Review and Reply: Reply after checking the relevant AI SBOM and model card. Follow the
disclosure standard for sensitive information. Involve legal review if needed.
5. Record: Retain the inquiry, reply, and processing time.
Deadlines: 14 days for the initial reply, 60 days for the final answer.

5. See Also

• Role and resources of the response lead:3.8 Effective Resource Allocation
• AI SBOM used in replies:3.9 AI SBOM
• Disclosure scope and transparency obligations:3.6 Transparency Obligations
• ISO/IEC 5230 external inquiry example:ISO/IEC 5230 Compliance Guide — 3.2.1 Responding to External Inquiries

1. Clause Overview

License obligations are where the AI SBOM Guide expands most on ISO/IEC 5230. Where traditional open source compliance reviewed the licenses of code, AI expands the review to four fronts: an AI system’s code, model weights, datasets (including training, testing, and validation datasets), and the license of the AI system itself. It is common for a model to be derived from several other models, so each parent model sitting in the Model Tree can carry its own distinct license.

3.5 requires a procedure for reviewing these licenses to determine, in light of the AI system’s intended use, the obligations, restrictions, and rights each license grants. The review covers both obligations inherited from upstream and obligations passed downstream.

2. Activities to Perform

• Establish a procedure for identifying the licenses of code, weights, datasets, and the AI system itself.
• Track the license of each parent model in the model tree, and document the obligations, restrictions, and rights of each license.
• Perform an initial identification pass on source code and dependencies with automated scanning tools.([Guide Recommendation])
• Route model weights, datasets, and non-standard licenses to legal or governance review.([Guide Recommendation])
• Set up an intake procedure that requires license metadata to accompany any model or dataset brought in from outside.([Guide Recommendation])
• Record the review results (obligations, restrictions, rights) in the AI SBOM for tracking.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.5.1 License Obligation Review and Documentation Procedure

How to Comply

Design the review procedure around the premise that the level of automation differs by material type. Source code and dependency licenses can be identified to a large degree with automated scanning tools such as FOSSology, ScanCode, and the OSS Review Toolkit. But the licensing of model weights and datasets, and the derivation relationships in the model tree, fall outside the reach of these tools or are identified with low accuracy. The usage-purpose restrictions of non-standard licenses require human interpretation. A realistic division of labor is therefore to do an initial identification pass with automated scanning, and route models, datasets, and non-standard licenses to legal or governance review.

The figure below shows the decision flow for determining license obligations as materials come in.

Figure 1. Decision flow for license obligation review

Considerations

• Enforce metadata at the intake gate: The largest cause of missed license obligations is license drift — the loss of provenance and license information as a model propagates downstream. One study reports that a substantial share of restriction clauses disappear in the transition from model to application (arXiv:2509.09873). Rather than trying to reconstruct this downstream, it is more effective to block the intake of materials lacking license metadata at the internal model/dataset registry.([Guide Recommendation])
• Decide non-standard licenses through policy in advance: The behavioral use restrictions of the Llama Community License or the OpenRAIL family are hard to track automatically for compliance after the fact. Decide them at intake time using the allowed/prohibited lists in3.1 Policy.([Guide Recommendation])
• Trace the model tree: Check the model card to see which parent model an incoming model was derived from, and review whether the parent model’s license obligations propagate downstream.
• Check dataset usage restrictions: Check whether a non-commercial-licensed dataset such as CC-BY-NC was used to train a commercial product. Dataset license omissions and misstatements are common, so cross-check against the original text.
• Recognize the limits of automation: Do not treat automated scan results as the final judgment. Tools help with identification; people handle the interpretation of obligations and conflict determination.

Sample

Below is a sample of the core part of a license obligation review procedure document. This procedure document becomes verification material 3.5.1.

## AI License Obligation Review Procedure
### 1. Scope of Review
- AI system code and dependencies
- Model weights (imported models, fine-tuned models)
- Datasets (training, testing, validation)
- Licenses of parent models in the model tree
### 2. Review Steps
1) Automated identification: scan code and dependencies for licenses using an SCA tool.
2) Metadata collection: collect licenses for models and datasets from model cards and
datasheets. Hold intake if metadata is missing.
3) Classification: check identified licenses against the policy's allowed/conditional/
prohibited lists.
4) Legal review: route non-standard or unclear licenses to legal/governance review to
interpret the obligations.
5) Recording: record upstream and downstream obligations, restrictions, and rights in
the AI SBOM.
### 3. Responsibility and Frequency
- Initial identification: development staff
- Interpreting obligations: legal / AI governance lead
- Re-review: when a model or dataset is replaced, and at least once a quarter

5. References

• Policy for allowed/prohibited license lists:3.1 Policy
• AI SBOM for recording review results:3.9 AI SBOM
• Automated scanning tools:Tools — FOSSology,SCANOSS
• AI model/dataset licensing strategy:Enterprise Open Source Management Guide — AI Compliance

1. Clause Overview

Governance is the framework that ties all the preceding clauses together to ensure the AI system’s lifecycle is developed, deployed, and managed responsibly from end to end. Where policy (3.1) sets the principles and license obligations (3.5) and the AI SBOM (3.9) build individual processes, governance manages these so they keep operating consistently through regulatory change and model replacement.

3.10 requires an AI governance framework, policies, and practices. The specification emphasizes compliance with emerging AI laws such as the EU AI Act, the Hiroshima AI Process, and China’s Global AI Governance Initiative, and addresses ethical considerations, risk management, and transparency together. The core is to review a framework, once built, periodically so it reflects the latest regulation and model changes.

2. Activities to Perform

• Write a governance framework document that spans the full AI system lifecycle.
• Include emerging AI regulation tracking, risk management, transparency, and ethical considerations in the framework.
• Have a procedure for periodically reviewing and updating the framework.
• Monitor the risks that come with the ongoing use of AI systems and training data.
• Reflect events such as model tree changes, regulatory enforcement, and OSAID classification changes in governance.([Guide Recommendation])

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.10.1 AI Governance Framework and Periodic Review Procedure

How to Comply

The governance framework covers three things: tracking emerging regulation to derive obligations, monitoring the AI system lifecycle, and a procedure for periodically reviewing the framework itself. Because regulation changes quickly, the framework must be a living system built for updates, not a fixed document.

The three axes the specification names differ in character. The EU AI Act imposes concrete, article-level obligations; the Hiroshima AI Process runs voluntary transparency reporting; and China’s initiative is closer to a policy declaration. Governance distinguishes these differences and tracks each accordingly.

The table below lists the major regulations to track from an AI SBOM perspective. The full regulatory matrix and its ISO/IEC 42001 context are covered inISO/IEC 42001 Guide — Organizational Context and Leadership.

Table 1. Major AI regulations intersecting with AI SBOM (as of 2026-06)

Lifecycle monitoring means placing governance checkpoints along the flow from development to retirement. The figure below shows lifecycle governance built around the AI SBOM.

Figure 1. Lifecycle governance built around the AI SBOM

Considerations

• Assign regulatory-tracking responsibility: Specify in governance who tracks emerging regulation and derives obligations from it. The EU AI Act’s obligations expand in stages in August 2026 and 2027, so manage the timing.
• Manage model tree changes: When an imported model moves to a new version or a parent model is replaced, license obligations can change. Register the change as a governance review event.([Guide Recommendation])
• Update OSAID classification: The distinction between “open source AI” and “open weight” (OSAID 1.0) affects model licensing judgments. Include classification changes in the periodic review.
• State the review cycle: Review model and dataset changes quarterly, and regulation and the overall framework annually. Record the review completion date and reviewer.
• Connect to other clauses: Governance ties together the regulatory review under the transparency obligation (3.6) and the lifecycle management under the AI SBOM (3.9) from above. Connect them rather than building duplicate procedures.

Sample (Governance Framework and Annual Review Plan)

Below is a sample of the core part of a governance framework document and periodic review plan. This document becomes verification material 3.10.1.

## AI Governance Framework
### 1. Scope and Purpose
Manages licensing, transparency, risk, and regulatory compliance across the full
lifecycle of an AI system — intake, development, deployment, operation, and
retirement.
### 2. Governance Structure
- AI Governance Lead: approves the framework, makes the final call on regulatory obligations
- Regulatory Tracking Owner: monitors emerging AI regulation, derives obligations
- AI SBOM Verification Owner: runs the generation, review, and approval procedure
- Legal: interprets non-standard licenses and regulation
### 3. Periodic Review Plan
| Frequency | Review Item | Owner | Deliverable |
|------|----------|------|--------|
| Quarterly | Model/dataset changes, model tree licensing | AI SBOM Verification Owner | Change review record |
| Semiannual | Non-standard license classification, OSAID updates | Legal | Updated classification |
| Annual | Regulatory enforcement schedule, overall framework, policy alignment | AI Governance Lead | Revised framework |
### 4. Change Management
When a model tree change, new regulation taking effect, or a license policy change
occurs, convene an ad hoc review rather than waiting for the periodic review. Record
the review outcome and action taken in the change history.

5. References

• Policy foundation:3.1 Policy
• Transparency obligations and regulatory review:3.6 Transparency Obligations
• AI SBOM lifecycle management:3.9 AI SBOM
• Full regulatory matrix and ISO/IEC 42001 context:ISO/IEC 42001 Guide — Organizational Context and Leadership

1. Clause Overview

Without an AI SBOM policy, an organization ends up deploying AI systems while developers remain unaware of the licensing obligations attached to models and datasets. In AI, what needs to be tracked goes beyond code. Model weights, training datasets, and the model tree derived from other models each carry their own license, and non-standard licenses that restrict the purpose of use — such as the Llama Community License or the RAIL family — are common. Missing these obligations leads to copyright disputes, violations of usage restrictions, and terminated business contracts.

To prevent this risk, 3.1 requires establishing a documented policy that governs AI SBOM compliance and communicating it so that program participants are aware of its existence. This policy must reflect business strategy, the legal requirements of relevant jurisdictions, and the level of risk appropriate to the use case. All subsequent clauses (competence, license obligations, AI SBOM, governance, and so on) operate on top of this policy.

2. Activities to Perform

• Draft and formalize a policy document that governs AI SBOM compliance.
• Define the scope of application in the policy (AI systems deployed externally, external models/datasets brought in, internal models released publicly, etc.).
• Reflect business strategy, the legal requirements of relevant jurisdictions, and the risk level for each use case in the policy.
• Include in the policy a list of licenses allowed or prohibited for models and datasets.([Guide Recommendation] Because compliance with non-standard licenses is hard to track automatically after the fact, decide it through policy at intake time.)
• Establish and document a procedure for communicating the policy to program participants (development, legal, security, data staff, etc.).
• Retain records that prove the policy was communicated (training completion, notice history, etc.).
• Include in the policy a procedure for periodically reviewing it and re-communicating it when it changes.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.1.1 Documented AI SBOM Policy

How to Comply

The AI SBOM policy is a formal document that captures the principles and procedures by which the organization manages the licensing and transparency obligations of its AI systems. The policy should include its purpose, scope, roles and responsibilities, principles for reviewing model and dataset licenses, AI SBOM management, how transparency obligations are addressed, and the review cycle. Because this document itself is verification material 3.1.1, manage it as a formal document with recorded version and approval history.

For an organization that already has an ISO/IEC 5230 open source policy, it is more efficient to add an AI-related section to the existing policy than to create a separate new one. Add that models and datasets fall within the scope of license review, how non-standard licenses are handled, and what format is used to manage the AI SBOM.

A policy is not a document to be written once and left alone. Because the AI regulatory landscape changes quickly, conduct a periodic review at least once a year and record the change history.

Considerations

• State the AI-specific scope explicitly: Clearly state in the policy that license review covers not only code but also model weights, training/testing/validation datasets, and the derivation relationships in the model tree.
• Allowed/prohibited license lists: Divide model and dataset licenses into allowed and prohibited lists, based on whether commercial use is permitted and whether there are behavioral use restrictions, and set this in the policy in advance.([Guide Recommendation])
• Approval procedure: Have the legal team or the AI governance lead give final approval, and record the approval date and approver.
• Version control: Maintain the document version and change history so that previous versions can be compared during an audit.
• Periodic review: Review at least once a year, and record the review completion date and reviewer.

Sample

Below is a sample of the scope of application and the allowed/prohibited license lists for an AI SBOM policy. This text becomes a core component of verification material 3.1.1. Check the actual terms of each license against its original text, then classify it to fit the organization’s use case.

## 1. Purpose and Scope
This policy defines the compliance principles and procedures for the company to
develop and deploy AI systems safely and responsibly. It is designed to satisfy
the requirements of ISO/IEC 5230 (open source license compliance) and the
OpenChain AI SBOM Compliance Guide.
Scope:
- All AI systems, models, and services distributed externally.
- Pre-trained models and datasets brought in from outside.
- Activities that release internal models to the outside.
## 2. Model/Dataset License Classification
Licenses for models and datasets being brought in are reviewed against the
classification below. A license not in this classification goes through review
by the AI governance lead before being brought in.
- Allowed (commercial use permitted, no behavioral restrictions): Apache-2.0, MIT, BSD, CC-BY-4.0, etc.
- Conditionally allowed (use after review): licenses with restrictions on purpose or
scale of use, such as the Llama Community License, the Gemma Terms of Use,
and the OpenRAIL family
- Prohibited (non-commercial only, etc.): using a CC-BY-NC dataset in a commercial product, etc.

3.1.2 Policy Awareness Procedure

How to Comply

Writing the policy document alone is not enough. A communication procedure must be established and documented so that program participants actually become aware the policy exists. This communication procedure document itself is verification material 3.1.2. Because AI systems involve not just developers but also data staff, legal, and security, design the channel so the policy reaches all of them.

Include AI SBOM policy guidance in onboarding for new hires, and use internal wiki postings and email notices for existing employees. To prove that the policy was communicated, retain evidence such as notice history and training completion records for at least three years.

Considerations

• Use multiple channels: Use two or more channels, such as an internal wiki, email notices, and onboarding training.
• Include AI-related roles: Include dataset owners and model operators as recipients as well.
• When the policy changes: Have a separate procedure to notify participants of changes immediately.
• Retain evidence: Keep notice history and training completion certificates for at least three years.

Sample

Below is a sample policy communication notice email. Retaining the send history serves as evidence for verification material 3.1.2.

Subject: [AI Compliance] AI SBOM Policy Notice and Acknowledgment Request
To: Employees involved in AI system development, operations, and data
From: AI Compliance Officer
Hello,
Our AI SBOM compliance policy has been established (or revised).
All employees involved in using, bringing in, or deploying AI models and
datasets are asked to review and familiarize themselves with the policy
document below.
- Policy document: [internal portal link]
- Key contents: model/dataset license classification, license obligation
review procedure, AI SBOM management, transparency obligation response
- Policy version: v1.0 (effective date: YYYY-MM-DD)
Contact: AI Compliance Officer (ai-compliance@company.com)

5. References

• License obligation review procedure:3.5 License Obligations
• Basic structure of an open source policy:ISO/IEC 5230 Compliance Guide — 3.1.1 Policy
• AI license management strategy:Enterprise Open Source Management Guide — AI Compliance