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?
• Have you prepared the public summary of training content? (EU AI Act Article 53, on the Commission’s template)
• Have you set out your copyright policy? (respecting text and data mining opt-outs, and so on)
• 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 filled in all seven sections of the model card? (model description, intended use, out-of-scope use, limitations and bias, training data, evaluation, contact)
• If there is a base model, is it declared in base_model?

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 and how to run it are both in AI SBOM.

What a tool can check stops at what the model card and the repository metadata reveal. 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: Qwen/Qwen2.5-7B
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.

Contact

Where questions and reports should go. Someone has to be assigned to answer them after release.

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

• What reaches you when you release a general-purpose model is Article 53. It asks for technical documentation, a copyright policy, and a public summary of training content, and it already applies.
• Fine-tuning someone else’s base model may leave you outside those duties. The Commission’s guidelines use a third of the original training compute as the dividing line.
• Releasing the weights and the architecture under an open-source licence exempts the technical documentation, but the copyright policy and the public summary of training content remain. The summary follows a template the Commission provides.
• Article 11 and Annex IV attach to the high-risk system your model ends up in, not to the model.
• 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, the cybersecurity agencies of the G7 jointly published “Software Bill of Materials for AI — Minimum Elements”, with Germany’s BSI and Italy’s ACN leading the work. It defines 50 minimum elements in seven clusters that an AI system’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.
• BomLens reports these 50 as 51 checks, because it scores model openness on its own line.
• The technical documentation the EU AI Act asks for corresponds to the G7 system-level, model, and dataset clusters. That correspondence is BomLens’s reading.
• 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 reads the model card and the repository metadata; it does not download the weight files themselves.)

• Setup, usage and how to read the reports are covered in the BomLens AI model guide.
• It needs a Docker engine, and pulls the AI-model scanning image (about 3.5 GB) once.
• 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.

• Create a read-scoped token under Access Tokens in your Hugging Face account settings. A fine-grained token needs read access to that repository granted explicitly.
• 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 a report looks like before running anything, open the conformance report from a sample model scan. It opens with coverage per cluster and the licences flagged for review, then works down to the per-check verdicts.

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)
• Timeline for the implementation of the EU AI Act (European Commission)
• AI Framework Act (Korea)

Contact

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