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.

AI System Bill of Materials Generator

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.

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.

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.