Program Foundation

• 1: 3.1 Policy
• 2: 3.2 Competence
• 3: 3.3 Awareness
• 4: 3.4 Program Scope

1 - 3.1 Policy

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

2 - 3.2 Competence

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

3 - 3.3 Awareness

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

4 - 3.4 Program Scope

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