An ML-BOM should describe the model itself, the datasets behind it, the software it depends on, and how it was configured and trained. CycloneDX defines ML-BOM as a bill of materials for AI and machine learning that represents models, datasets and configurations.
What CycloneDX says it is for
The CycloneDX page describes ML-BOM as model and dataset transparency for security, privacy, safety and ethical considerations. It says ML-BOM can document dataset provenance and ethical considerations, describe how models are trained and how frameworks are configured, and help organizations identify risks related to bias, data integrity and model security.
That gives a useful frame: the document is for people who need to judge the model, not only the code.
A practical field list
| Section | What to record |
|---|---|
| Model identity | Name, version, owner, license, where it was published |
| Origin | Base model if fine tuned, source repository, pinned commit |
| Artifacts | File names, formats, SHA-256 of each weight file |
| Datasets | Name, source, version, license, known limits, collection notes |
| Training setup | Framework and version, key configuration, date |
| Software | Packages and versions needed to run it |
| Intended use | What it is for, what it is not for |
| Known issues | Evaluation limits, bias findings, open risks |
| Contacts | A person or team to ask |
How to build one without a big project
- Start from the artifact register you keep for your own project. Our guide to building an ML dependency inventory shows one.
- Add dataset entries. Even a short line with the source and license is better than nothing.
- Export the software part from your normal SBOM tooling.
- Merge into a standard format so a customer can read it with their tools.
- Review it before each release, and version it with the model.
What not to put in
- Claims you cannot support. If you did not test for bias, say so instead of implying you did.
- Internal secrets, private paths or credentials.
- Statements of certification or compliance that you do not hold.
Honest gaps are more useful to a reader than a polished page with blanks hidden.
Who asks for this
Procurement and security teams increasingly ask what is inside an AI feature. A regulated customer may want dataset provenance. An internal reviewer may want to know the base model. An incident responder will want to know which products contain a given model when something is found. An accurate document turns each of those into a lookup instead of a scramble.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies for the software side of an AI product, and its compliance and evidence automation can help you keep records organized. Run a free scan at gold.safeguard.sh/scan. Related reading: AI BOM standards.
Quick check
Is an ML-BOM the same as an SBOM?
No. An SBOM lists software components. An ML-BOM extends the idea to models, datasets and configurations. Many teams keep both.
Do I need one for a model I only fine tuned?
It is a good idea. Record the base model and its revision, plus your own data and changes, so the lineage is clear.
Sources
Last reviewed: 19 October 2026.
