An AI System Bill of Materials is a structured inventory of every component that goes into an AI system — models, datasets, APIs, libraries, and services — with provenance and licensing. It extends the software SBOM concept to AI supply chains as encouraged by NIST AI RMF and emerging regulation.

You cannot manage risk in components you have not catalogued. An AI-SBOM is the basis for licence compliance, vulnerability response, vendor-exit planning, and demonstrating governance to auditors and regulators.

What fields matter most?

Type, supplier, version, and license are the core. Version lets you respond to vulnerabilities and deprecations; supplier and license drive compliance and exit decisions; type lets you reason about the whole stack at once.

Is the data stored anywhere?

No. The inventory is built and exported entirely in your browser. Nothing is uploaded, which matters because the SBOM itself can be sensitive.

How often should I update it?

Treat it as living documentation — update whenever you add, upgrade, or remove a model, dataset, or dependency. Stale SBOMs give false assurance, so tie updates to your release process.

What is the AI System Bill of Materials Generator?

Build an AI System Bill of Materials (AI-SBOM) documenting models, datasets, APIs, libraries, and third-party components in your AI stack — following NIST AI RMF guidance on supply chain transparency. It runs free in your browser on Gera Tools, with nothing uploaded.

AI System Bill of Materials Generator

Name: AI System Bill of Materials Generator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

AI system bill of materials generator

A modern AI system is a supply chain: foundation models, fine-tunes, training and evaluation datasets, vector stores, third-party APIs, and a stack of libraries — each with its own supplier, version, and licence. If you cannot list them, you cannot manage their risk. This generator helps you build an AI-SBOM: a structured inventory you can export, audit, and keep current, aligned with NIST AI RMF guidance on supply-chain transparency.

Why an AI-SBOM is different from a regular software SBOM

A standard software SBOM catalogues packages and their dependency trees. An AI-SBOM goes further because the risk profile is different: a model’s behaviour depends on its training data and fine-tuning history, not just its code version. Two components warrant particular care that software SBOMs often ignore:

Datasets — what data the model was trained or fine-tuned on, where it came from, and whether the licence covers that use.
Third-party model APIs — when you call an external model, its provider’s data-retention, training-use, and breach-notification terms become part of your risk posture, whether you have catalogued them or not.

This tool captures both alongside the conventional software-supply-chain entries.

How it works

You add one row per component and tag it by type — model, dataset, API, library, or service — with its supplier, version, and licence. The tool tracks completeness, flagging any component missing a supplier, version, or licence, since those gaps are exactly where supply-chain risk hides. When you’re done it renders the inventory two ways: human-readable Markdown for documentation and machine-readable JSON for governance tooling, both copyable. Everything stays in your browser because an SBOM can itself reveal sensitive architecture.

What to include and why

Component type	What to capture	Typical risk
Foundation model	Provider, model ID, version/snapshot date	Deprecation, behaviour change, licence scope
Fine-tune or adapter	Base model, dataset used, training date	Data-licence violation, capability shift
Training / eval dataset	Source, licence, collection date	Copyright, consent, bias risk
Third-party model API	Provider, endpoint, data-processing terms	Data residency, retention, training-use
Orchestration library	Package name, version, licence	Dependency CVEs, breaking updates
Vector database	Provider or self-hosted version	Data-residency, access control

A common first-pass mistake is listing only the model and forgetting the datasets. Regulators and enterprise buyers increasingly ask about training-data provenance; having it recorded means you can answer in minutes rather than days.

Tips and notes

Capture versions. Without them you can’t respond to a vulnerability or a deprecation cleanly.
Don’t leave licences blank. Unknown-licence components are a flag, not a default — chase them down.
Include the boring parts. Vector DBs, embedding APIs, and orchestration libraries are part of the chain too.
Keep it living. Update on every release; a stale SBOM is worse than none because it gives false assurance.
Connect it to your exit plan. An SBOM is the prerequisite for a vendor-exit plan: you cannot plan a migration if you have not mapped the dependencies first.