Releasing an AI Model

• 1: AI Model Pre-Release Checklist
• 2: Writing the Model Card
• 3: AI SBOM and Regulation

1 - AI Model Pre-Release Checklist

Read through this when you start writing the model card, not on the day you publish. Some items here can only be fixed by training again.

1. The right to publish

Settle this first. If it fails here, the rest of the preparation is wasted.

• If you fine-tuned a base model, does its license permit distributing derivatives?
• Have you identified what the base model license requires of derivatives (naming, license inheritance, passing on use restrictions)?
• Do the licenses of your training datasets permit distributing what was trained on them?
• If purchased or contracted data is involved, does the contract allow publication?
• Are there patent filings covering the model or the training method?

2. Choosing a license

• Have you chosen a license for the model weights?
• If the base model forces a particular license, does your choice honour it?
• If you need use restrictions, have you documented why? (RAIL-family licenses)
• If you publish the training dataset too, has it been licensed separately?
• Does the model card’s license field carry the exact identifier?

For the characteristics of each license, see AI Model Licenses, the Llama 2 guide and the RAIL guide.

3. Data and sensitive material

• Have you checked whether the training data contains personal data?
• If it does, has the privacy team reviewed it?
• Have you checked whether the training data contains third-party copyrighted works?
• Is internal documentation or customer data absent from the training set?
• Have you considered the risk of the model reproducing its training data verbatim?
• Are the files you are about to publish free of API keys, internal hostnames and credentials? (see the sensitive information checklist)

4. Model card

For how to write it, see Model card.

• Have you stated the intended use and scope?
• Have you stated what the model should not be used for?
• Have you stated the known limitations and biases?
• Have you disclosed the training datasets?
• Have you given evaluation results and how they were measured?
• If there is a base model, is it declared in base_model?
• Is there a contact point for questions?

5. Files and identifiers

• Does the list of weight files match what you intended to publish (no stray checkpoints)?
• Do you have a hash (SHA-256) for each weight file?
• Has the model name passed internal naming rules and a trademark check? (see Choosing a project name)
• Have you decided on a versioning scheme?

6. Approval and afterwards

• Have you obtained approval from your organization’s executive or leader?
• Have you requested an OSRB review? (stage A of the release process)
• Is someone assigned to answer questions after release?
• Is there a route for reporting vulnerabilities or misuse?
• Have you decided what would make you withdraw or revise the model?

Checking it automatically

The model card, license and dataset items above can be checked with a tool. Give BomLens a model id and it reads the model card, then reports what is missing and how to supply it. Why it matters is in AI SBOM; setup and usage are in the BomLens AI model guide.

What a tool can check stops at what the model card says. Whether personal data ended up in the training set, or whether a contract allows publication, is a judgement a person has to make.

Related pages

• Releasing an AI model — the whole path
• Model card — how to write it
• AI SBOM — documenting for regulation

Contact

For items you are unsure about, contact the OSRB (opensource@sktelecom.com).

2 - Writing the Model Card

A model card is not a separate form. It is the README.md file in the model repository. The YAML block at the top is the metadata machines read; the Markdown below it is the description people read.

It is the first thing users read after release, and it is also where documentation for regulation starts. Anything absent from it cannot be verified by any tool either.

File structure

---
license: apache-2.0
language:
  - ko
  - en
base_model: meta-llama/Llama-3.1-8B
datasets:
  - HuggingFaceFW/fineweb
pipeline_tag: text-generation
library_name: transformers
---

# Model name

Description, intended use, limitations and evaluation results.

Metadata fields

The YAML block drives search and filtering, and it is what a tool reads when building an AI SBOM. These four fields matter most.

For a non-standard license, set license: other and give the name and a link.

license: other
license_name: License name
license_link: https://example.com/license

Declare datasets as far as you can even when you are not publishing the data itself. If something cannot be disclosed, saying so in the body — and why — is better than leaving it blank.

What belongs in the body

Start from the model card template that Hugging Face provides. These sections connect directly to documentation duties, so it is worth not leaving them empty.

Model description What the model does, how it is built, and roughly how many parameters it has.

Intended use The situations the model was built for. This corresponds to the part of the EU AI Act’s technical documentation that states a system’s purpose.

Out-of-scope use Where it should not be used. Naming high-consequence domains explicitly — medical diagnosis, credit scoring — is more useful than a general disclaimer.

Limitations and bias The performance limits and biases you know about. If an area went unverified, write that it went unverified. Disclosing a known problem is safer than omitting it.

Training data What you trained on, and how you preprocessed and filtered it. If you filtered out personal data or copyrighted works, say how.

Evaluation What you measured, against what, and with what result. Name the evaluation datasets and metrics.

When to write it

Leaving the model card until the end means reconstructing details from training time, which makes it inaccurate. Recording as you go is far easier.

1. Before training, record the dataset list, provenance and licenses.
2. During training, record hyperparameters and evaluation results.
3. While preparing the release, move these into the model card and add intended use and limitations.
4. Confirm what is left with the pre-release checklist.

Related pages

• Pre-release checklist — checking model card items
• AI SBOM — what gets built from the model card
• Model Cards — Hugging Face documentation

Contact

For anything you are unsure about, contact the OSRB (opensource@sktelecom.com).

3 - AI SBOM and Regulation

An AI SBOM is a machine-readable inventory of a model, its training datasets, and their provenance and licenses.

• Where a software SBOM carries package dependencies, an AI SBOM also covers what a software SBOM leaves out: model weights and training data.
• It is built from what the model card says, so a thin model card leaves an AI SBOM with that many empty entries.

Why produce one

It serves two purposes.

1. For the publisher it is a self-check on how complete the documentation is. Seeing what is missing as a list means you can close the gaps before release.
2. For the recipient it is evidence for a review. Just as SK Telecom asks suppliers for an SBOM, other organizations have begun asking the same of AI models.

Key regulations

• The EU AI Act is specific about technical documentation through Article 11 and Annex IV: it must cover a system’s purpose and architecture, the provenance and processing of its training data, and its performance and limits.
• Korea’s AI Framework Act keeps its detailed documentation requirements in the enforcement decree, so it is less specific than the EU’s. Article 32 (safety) applies only to systems trained above a compute threshold set by that decree, so a linked element points at the subject of the duty rather than establishing that the duty applies.

The G7 minimum elements

In May 2026, CISA and G7 partners jointly published “Software Bill of Materials for AI — Minimum Elements”, led by Germany’s BSI and Italy’s ACN. It defines 50 minimum elements in seven clusters that a model’s inventory should carry. It is a non-binding recommendation, not a regulation.

• Thirteen of the 50 have no automated source. Things like the intended application area or the sensitivity of the training data cannot be proven by any model card field, so a person has to supply them.
• The documentation Annex IV of the EU AI Act asks for corresponds to the G7 system-level, model, and dataset clusters.
• Advisory as they are, the elements overlap substantially with the documentation those regulations require. Filling the G7 side also builds most of what a regulatory submission needs.

Producing an AI SBOM

Give BomLens, SK Telecom’s open-source SBOM generator, a model id and it reads the model card, builds a CycloneDX AI SBOM, and reports G7 element coverage alongside the regulatory mapping. (It fetches model-card metadata only and does not download the weights.)

• Setup, usage and how to read the reports are covered in the BomLens AI model guide.
• The command below assumes BomLens is already installed.

./scripts/scan-sbom.sh --project my-llm --version 1.0.0 \
  --model "my-org/my-llm" --generate-only

A private repository needs a token with read access.

• How to pass it as HF_TOKEN, and what a gated repository additionally requires, are in Private and gated models.

You get:

• an AI SBOM covering the model and its datasets
• per-element coverage, and how to supply what is missing
• the mapping to the EU AI Act and Korea’s AI Framework Act
• components whose license needs human review

Checking the result

An overall pass does not mean every G7 element is filled. G7 elements are all advisory and do not move the verdict. Read the covered count and the gap count separately.

• Gaps come in two kinds: those you close by writing in the model card, and those a person has to judge. Start with the first kind.
• To see what the reports look like before running anything, open the conformance report and the AI compliance profile from a sample model scan.

Related pages

• Model card — the input to an AI SBOM
• Pre-release checklist — what to confirm before release
• What is an SBOM — SBOMs in general
• BomLens AI model guide — setup, usage, reading the reports
• BomLens — the tool, and its supplier-facing usage

References

• Software Bill of Materials for AI — Minimum Elements (G7, May 2026)
• Regulation (EU) 2024/1689 (AI Act)
• AI Framework Act (Korea)

Contact

For questions about producing or reading an AI SBOM, contact the OSRB (opensource@sktelecom.com).