AI Extension Process

• 1: 3.5 License Obligations
• 2: 3.6 Transparency Obligations
• 3: 3.9 AI SBOM

1 - 3.5 License Obligations

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 in 3.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

2 - 3.6 Transparency Obligations

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 in 3.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

3 - 3.9 AI SBOM

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 the Tools 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 directory
cdxgen -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 on transformers and torch) 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 the licenses 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 the machine-learning-model component and modelCard in the official CycloneDX spec. If the license is non-standard (has no SPDX ID), state it with name.

{
  "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 the ISO/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 a shall-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 in Governance (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