The AI-BOM: A Bill of Materials for Models, Weights and Training Data

You can produce a software bill of materials for the service in minutes. Now answer a harder question: what model is running inside it, trained on what data, under whose licence? For most firms, nothing on file can say.

The software bill of materials, or SBOM, has become a settled expectation. Procurement teams ask for one, security teams generate one on every build, and when a library like Log4j catches fire the SBOM is what tells you in an afternoon whether you are exposed. It is a machine-readable inventory of the components that make up a piece of software. The trouble is that when the software in question is an AI system, the SBOM describes the wrong half of it. It lists the Python packages and the container base image faithfully, and says nothing at all about the thing that actually makes decisions: the model, its weights, and the data it was trained on.

What the SBOM leaves out

An SBOM treats a model as an opaque file. If the weights are shipped as a package dependency they might appear as a name and a version; more often they are pulled from a model registry or a hub at build time and never recorded anywhere the inventory can see. So the questions a regulator, a customer, or your own incident responder will eventually ask go unanswered. Which base model is this fine-tuned from? What version of the weights is in production right now, and does it match what was evaluated in the model risk review? What datasets was it trained on, and were any of them scraped, licensed, or subject to a restriction that forbids commercial use? If a training set is later found to be contaminated or unlawfully collected, which deployed systems inherited the problem?

These are supply-chain questions, and they are exactly the questions the SBOM was invented to answer for software. The reason they matter more for AI is that the risk does not live in the code. It lives in the weights and the data, which is precisely where the ordinary inventory is blind. This is the same gap I have written about in the security of the AI supply chain: the model file is the artefact everyone trusts and nobody can describe.

What an AI-BOM has to record

An AI bill of materials extends the same idea to the parts an SBOM cannot see. At minimum it should record, as first-class inventory items:

• The model itself — name, version, the task it performs, its architecture, and a cryptographic hash of the weight artefact so you can prove which weights are deployed.
• Lineage — the base model it was derived from and the fine-tuning or quantisation steps applied, so a defect in an upstream model can be traced to everything downstream of it.
• The datasets — each training, validation and evaluation set, with its source, its data classification, and its provenance and governance status.
• Licences and restrictions — for the weights and every dataset, because model and data licences carry commercial-use, attribution and output restrictions that a package licence scanner will never surface.
• Evaluation evidence — the performance and fairness metrics recorded at the point the version was approved, so the inventory and the risk assessment describe the same object.

None of this is exotic. It is the information a competent MLOps team already holds in scattered form — a model card here, a data-catalogue entry there, a licence noted in a README. The AI-BOM’s contribution is to make it one machine-readable document, generated alongside the system rather than reconstructed under pressure a year later.

The schema already exists

You do not need to invent a format. OWASP CycloneDX added machine-learning support in version 1.5 and carried it into 1.6: a component type of machine-learning-model with a modelCard block, and a component type of data for datasets, all sitting in the same BOM your build already produces. The Linux Foundation’s SPDX 3.0 offers a parallel route with its AI and Dataset profiles. Either gives you a standard, tooling-supported schema rather than a bespoke spreadsheet. Here is a trimmed CycloneDX ML-BOM for a fine-tuned classifier, its training set, and the framework it depends on.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:6f5a9c2e-0b1d-4e3a-9c77-2a1b3c4d5e6f",
  "version": 1,
  "metadata": {
    "timestamp": "2026-09-30T09:00:00Z",
    "component": {
      "type": "application",
      "bom-ref": "svc-credit-triage",
      "name": "credit-triage-service",
      "version": "3.2.1"
    }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model-risk-scorer",
      "name": "risk-scorer",
      "version": "2026.09",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [
        { "alg": "SHA-256", "content": "9b74c9897bac770ffc029102a200c5de" }
      ],
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "supervised" },
          "task": "classification",
          "architectureFamily": "gradient-boosted-trees",
          "modelArchitecture": "XGBoost 2.1 (fine-tuned from base-scorer 2025.03)",
          "datasets": [{ "ref": "dataset-loan-apps" }]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [{ "type": "AUC-ROC", "value": "0.87" }]
        },
        "considerations": {
          "technicalLimitations": ["Not validated on applicants outside the EU/UK"],
          "ethicalConsiderations": [
            { "name": "proxy-bias", "mitigationStrategy": "Protected attributes excluded; disparate-impact tested quarterly" }
          ]
        }
      }
    },
    {
      "type": "data",
      "bom-ref": "dataset-loan-apps",
      "name": "loan-applications-2019-2025",
      "data": [
        {
          "type": "dataset",
          "name": "loan-applications-2019-2025",
          "classification": "PII-restricted",
          "contents": { "url": "https://registry.internal/datasets/loan-apps" },
          "governance": { "owners": [{ "contact": { "name": "Data Owner, Credit Risk" } }] }
        }
      ]
    },
    {
      "type": "library",
      "bom-ref": "lib-xgboost",
      "name": "xgboost",
      "version": "2.1.1",
      "purl": "pkg:pypi/xgboost@2.1.1",
      "licenses": [{ "license": { "id": "Apache-2.0" } }]
    }
  ],
  "dependencies": [
    { "ref": "svc-credit-triage", "dependsOn": ["model-risk-scorer"] },
    { "ref": "model-risk-scorer", "dependsOn": ["dataset-loan-apps", "lib-xgboost"] }
  ]
}

The dependencies graph is the part that earns its keep. It states, in a form a machine can traverse, that the service depends on the model, and the model depends on a specific dataset and a specific framework version. Ask "which deployed services were trained on the loan-applications set" and the answer is a query, not an archaeology project.

Generate it, do not write it

An AI-BOM maintained by hand is worthless within a sprint, for the same reason a hand-maintained SBOM is: the artefact drifts from reality the moment someone retrains a model or swaps a dataset and forgets to update the document. The only version worth having is generated by the training and release pipeline itself. When a model is registered, the pipeline emits the BOM: it hashes the weight file it just produced, reads the dataset references and licences from the data catalogue, pulls the evaluation metrics from the run that gated the release, and writes the whole thing out as a build artefact stored beside the model. The generation step becomes a release gate — no BOM, no promotion to production — exactly as build systems already refuse to ship without an SBOM.

Done this way the AI-BOM stops being documentation and becomes evidence, produced as a by-product of doing the work rather than a report written after it.

Why this stops being optional

The regulatory direction of travel points straight at this inventory. The EU AI Act’s technical-documentation duties for high-risk systems, and its data-governance requirements, both assume you can describe your training data and its lineage — the substance I set out in data governance under Article 10. General-purpose model providers face their own training-data transparency obligations, and disclosure regimes such as the California training-data laws are pushing the same information into the open. None of these regimes asks for a CycloneDX file by name. All of them assume you already hold the facts one would contain. The firm that can generate an AI-BOM has the answers as a query; the firm that cannot will be reconstructing them from memory and Slack history while a deadline runs down.

Software earned a traceable inventory because we learned the hard way what it costs not to have one. AI is the part of the estate that now makes the decisions, and for most firms it is the part with no inventory at all. Give it one before someone makes you.