How to Build an AIBOM for Closed AI Models, and What to Ask Vendors

You cannot write a full AIBOM for a closed model you call over an API, because its training datasets, licences and provenance are not published in machine-readable form. You can build an AIBOM of your own use: model IDs, endpoints, data flows, retention settings, system card links and evaluations, in CycloneDX or SPDX, plus written vendor answers.

That split is the whole method. Part of the bill of materials is yours to know and record exactly. Part belongs to the provider and reaches you only as prose in a system card, a transparency page or a contract. A good AIBOM keeps the two apart, marks which fields came from where, and records the gaps honestly instead of leaving them blank or guessing.

This post is the practical part of a short series on the closed model AIBOM gap. Companion posts compare what Anthropic and OpenAI publish against the AIBOM standards, map training data unknowns to enterprise risk, and set out what the EU AI Act now requires general purpose model providers to disclose. Here we build the document, write the questionnaire and set the review cadence. For background on the format itself, see our engineering guide to AIBOMs and our post on model cards and AI SBOM transparency.

Key takeaways

• Split the AIBOM into two layers: facts you control and can verify (model IDs, endpoints, data flows, settings, your own evaluations) and facts the provider asserts (training data description, cut-off dates, safety testing). Label every field with its source.
• Pin model versions. Anthropic documents that from the Claude 4.6 generation onward a model ID is a fixed snapshot whose weights and configuration it does not update. OpenAI lists snapshot IDs on each model page and publishes minimum notice periods before retirement. Record the exact ID your code sends, not a family name.
• Model the hosted model as two things in CycloneDX: a machine-learning-model component carrying what you know of the model card, and a service carrying the endpoint, trust boundary and data flows. In SPDX 3, use an AIPackage and record unknown dataset details as absent rather than inventing them.
• Retention and training use are the facts buyers most often get wrong. Both labs publish default retention windows and conditions for zero data retention. Record the setting you actually have, with the date you confirmed it.
• Ask vendors the questions an AIBOM cannot answer, in writing, and decide in advance what counts as an acceptable answer. Put change notice, retention, training use and sub-processor terms in the contract.
• Re-review on events (new model ID, deprecation notice, new system card, policy change) and on a calendar, at least quarterly.
• Safeguard's AI-BOM discovery is in early access. It inventories the AI assets your own organisation uses, across code (SDK imports), cloud AI services, SaaS use and vector databases, and can output a CycloneDX ML-BOM or SPDX AI profile. It cannot see inside a vendor's training data, and nothing can from the outside.

Why an AIBOM for a model you do not own

An SBOM answers "what is inside the software we ship". For a hosted closed model you do not ship the model, so the question changes to "what do we depend on, how is it configured, what data crosses the boundary, and what do we know about where it came from". That is still a bill of materials question, and the standards bodies have built fields for it.

CycloneDX describes its ML-BOM capability as representing "models, datasets, and their dependencies", including dataset provenance and training methodology, so that organisations can assess "bias, data integrity, or model security". The SPDX 3.0.1 specification adds an AI profile and a Dataset profile for the same purpose. The OWASP AIBOM Initiative, run under the OWASP GenAI Security Project, works on practical generation and completeness assessment.

None of these formats require you to own the model. They require you to say what you know. For a closed model, much of the model card section will hold short, sourced prose or nothing at all, and that is a legitimate and useful state for the document to be in. An AIBOM that says "training datasets: not disclosed by provider; provider description at URL, retrieved on date" is more honest and more useful in an audit than one that leaves the field out.

There are four practical reasons to do the work anyway.

1. Incident response. When a provider announces a deprecation, a policy change or a safety issue with a specific model, you need to know within minutes which applications send traffic to that model ID, in which environments, with what data. That is an inventory query, not a research project.
2. Regulation. The EU AI Act puts documentation duties on providers of general purpose AI models under Article 53, including information for downstream providers who integrate the model. If you build a system on top of a closed model, your own obligations depend on knowing exactly what you integrated.
3. Risk management frameworks. The NIST AI Risk Management Framework and its Generative AI Profile, NIST AI 600-1, both expect organisations to inventory AI systems and to manage third party components. An AIBOM is the record that makes those actions repeatable.
4. Change control. Hosted models are retired on published schedules. Your code keeps sending the old ID until someone changes it. An AIBOM with retirement dates turns a surprise outage into a planned migration.

What a provider publishes, and what an AIBOM standard asks for

Before you build anything, separate the sources. The table below lists, at a category level, the kinds of material Anthropic and OpenAI publish in their own documentation, and where each lands in an AIBOM. The detail on each lab's pages is covered in the next two sections; here we only need to know where to file it.

The last row is the gap the series is about. Everything above it you can fill today.

The two layers of a closed model AIBOM

Think of the document as two layers stacked on one component.

Layer one: your use. This is fully knowable. It covers the model IDs your code calls, the SDK packages and versions that call them, the endpoints and regions, the platform (the provider's own API or a cloud marketplace that hosts the same model), the authentication method, the data classifications that cross the boundary, the settings you chose (retention, storage flags, logging), your evaluation results, your approval record and the owner. If any of these fields is empty, it is your gap, and you can close it.

Layer two: provider assertions. This is what the provider says about the model: the training data description, cut-off dates, the system card's safety results, the intended uses and limitations. You cannot verify it independently. You record it with a link, a retrieval date and, where possible, a hash of the document you read, so you can tell later whether it changed.

Keeping the layers apart matters in three situations. In an audit, you can show which statements you tested and which you relied on. When a provider updates a page, you can see exactly which of your fields depended on the old text. And in a risk acceptance, the person signing can see that a field such as "training data licences" is not "unknown because nobody looked" but "not disclosed by the provider, requested in writing on a date, answer attached".

What Anthropic documents that you can record

Everything in this section comes from Anthropic's own published pages, retrieved on 23 October 2026.

Model identifiers and snapshots. Anthropic's model IDs and versioning page explains that starting with the Claude 4.6 generation, model IDs use a dateless format, and that a dateless ID "maps to a single, fixed model snapshot". It states that Anthropic does not update the weights or configuration of an existing model ID, and that an updated version ships under a new ID. Earlier models carry a snapshot date in the ID, and on the Claude API those older models also have shorter aliases that point to the most recent dated snapshot for that minor version. The page also notes that on Google Cloud's Google managed offering the date separator is an @ sign, and that every model ID has its own deprecation and retirement schedule.

For your AIBOM this means two things. For current generation models, the ID in your request is the version. For older models, record the dated snapshot your code sends, and if your code sends an alias, flag it, because the snapshot behind an alias can move.

Lifecycle. The model deprecations page defines three states, Legacy, Deprecated and Retired, and says requests to retired models fail. It states that Anthropic gives "at least 60 days' notice" before retirement for publicly released models, that the dates apply to Anthropic operated platforms, and that partner operated platforms such as Amazon Bedrock set their own retirement schedules. It also describes an audit of your API usage to find calls to deprecated models. Record the state and the tentative retirement date per model ID, and record which platform you call through, because the date can differ by platform.

Model and system cards. Anthropic's system cards page lists a system card per model or model family, from Claude 2 in July 2023 to Claude Haiku 5.5 in October 2026, and describes them as documenting "capabilities, safety evaluations, and responsible deployment decisions". The Transparency Hub has a Model Report with a per-model summary. For Claude Opus 5.5, the training data section says the model was trained on "a proprietary mix of publicly available information from online sources, public and private datasets, user data, and synthetic data generated by other models", and that data cleaning and filtering included deduplication and classification. The models overview points readers to the Transparency Hub for each model's reliable knowledge and training data cut-off dates.

That is a category level description of sources, which is exactly what belongs in layer two with a link and retrieval date. It is not a per-dataset list with licences and versions, so the dataset components in your AIBOM stay marked as not disclosed.

Retention. Anthropic's privacy centre article on how long it stores organisation data says that for API users it deletes inputs and outputs on the backend within 30 days, with exceptions: services with longer retention under your control such as the Files API, a zero data retention agreement, Usage Policy enforcement, and legal requirements. It states that inputs and outputs flagged by trust and safety systems as violating the Usage Policy may be kept for up to 2 years, with classification scores for up to 7 years, and that feedback submissions are kept for 5 years. Record which of these applies to each integration, including whether anyone in your organisation can submit feedback through a product surface.

What OpenAI documents that you can record

Everything in this section comes from OpenAI's own developer documentation, retrieved on 23 October 2026.

Training use and retention. OpenAI's data controls guide states that as of March 1, 2023, data sent to the OpenAI API "is not used to train or improve OpenAI models" unless you explicitly opt in. It says abuse monitoring logs, which may contain prompts and responses, are generated for all API usage by default and retained for up to 30 days unless longer retention is required by law or reasonably necessary to protect services or third parties. Eligible customers can apply for Zero Data Retention or Modified Abuse Monitoring; both are subject to prior approval. Under Zero Data Retention, the store parameter for the Responses and Chat Completions endpoints is always treated as false, and the guide includes a per-endpoint table showing which endpoints are eligible and which may still store application state. Controls can be set at organisation level and overridden per project.

For your AIBOM, the per-endpoint detail matters. Record the endpoints you call, not just "OpenAI API", and record the organisation and project setting in force, because a project can inherit, override or disable the organisation default.

Lifecycle. OpenAI's deprecations page states minimum notice periods before retirement, unless safety or compliance concerns require a faster timeline: at least 6 months for generally available models, at least 3 months for specialised variants, and much shorter, such as 2 weeks, for preview models identified by "preview" in the name. It describes a shutdown_date field on the List models and Retrieve model endpoints for monitoring shutdowns programmatically. Record the date per model ID and automate the check (we do this in the walkthrough below).

Model catalogue. OpenAI's models page lists current models and links a page per model. Each model page, for example the one for GPT-6.1 Sol, shows the context window, a knowledge cut-off date (30 April 2026 for that model) and a Snapshots section listing the IDs you can send. The deprecations page lists retirements by model family and snapshot. Record the exact ID your code sends. If it ends in latest or is a family name rather than a fixed snapshot, flag it in the AIBOM the same way you would flag an unpinned dependency.

System cards. OpenAI's Deployment Safety Hub collects its system cards and addenda, describing it as sharing how deployed models perform in evaluations and the risks it measures. Recent entries listed there include the GPT-6 Astra system card (3 September 2026) and an addendum covering GPT-6.1 Sol (29 September 2026). Treat them as layer two sources: link, retrieval date, the sections you relied on.

The point of both sections is not to compare the labs. Each publishes lifecycle rules, retention terms and model documentation in its own structure. Your AIBOM normalises those into the same fields so that every model you use is described the same way.

Building the AIBOM in CycloneDX 1.6

CycloneDX (also published as Ecma International standard ECMA-424) has two constructs that fit a hosted closed model well.

• A component of type machine-learning-model with a modelCard. The model card has modelParameters (approach, task, architecture family, datasets, inputs, outputs), quantitativeAnalysis (performance metrics) and considerations (users, use cases, technical limitations, ethical considerations, fairness assessments, environmental considerations).
• A service describing the hosted endpoint, with endpoints, authenticated, x-trust-boundary, and a data array where each entry has a flow direction (inbound, outbound, bi-directional or unknown) and a classification.

The component holds what you know about the model. The service holds how you reach it and what data crosses. A dependency entry ties your application to the service, and properties tie the service to the model component.

Here is a trimmed example for a support assistant that calls one hosted model. The full, schema validated file is in the downloads section below.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:5f4b1d3e-2c7a-4b8e-9a61-0d2f7c3e8b10",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-23T09:00:00Z",
    "component": {
      "type": "application",
      "bom-ref": "app:support-assistant",
      "name": "support-assistant",
      "version": "3.4.0"
    }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model:claude-opus-5-5",
      "supplier": { "name": "Anthropic", "url": ["https://www.anthropic.com"] },
      "name": "claude-opus-5-5",
      "version": "claude-opus-5-5",
      "description": "Hosted closed model called through the provider API. Weights and training datasets are not available to the deployer.",
      "modelCard": {
        "modelParameters": {
          "task": "text-generation",
          "datasets": [
            {
              "type": "dataset",
              "name": "provider-training-data",
              "description": "Not disclosed at dataset level. Provider description: proprietary mix of public web information, public and private datasets, user data and synthetic data. Source: Transparency Hub, retrieved 2026-10-23.",
              "classification": "unknown"
            }
          ]
        },
        "considerations": {
          "technicalLimitations": [
            "See provider system card for documented limitations."
          ]
        }
      },
      "properties": [
        { "name": "aibom:layer", "value": "provider-asserted" },
        { "name": "aibom:lifecycle-state", "value": "active" },
        { "name": "aibom:retirement-date", "value": "not announced" },
        { "name": "aibom:pinned", "value": "true" }
      ],
      "externalReferences": [
        { "type": "documentation", "url": "https://www.anthropic.com/system-cards", "comment": "System card index, retrieved 2026-10-23" },
        { "type": "documentation", "url": "https://www.anthropic.com/transparency", "comment": "Model Report, retrieved 2026-10-23" }
      ]
    }
  ],
  "services": [
    {
      "bom-ref": "svc:anthropic-messages-api",
      "provider": { "name": "Anthropic" },
      "name": "messages-api",
      "endpoints": ["https://api.anthropic.com/v1/messages"],
      "authenticated": true,
      "x-trust-boundary": true,
      "data": [
        { "flow": "outbound", "classification": "customer-support-text" },
        { "flow": "inbound", "classification": "generated-text" }
      ],
      "properties": [
        { "name": "aibom:model-ref", "value": "model:claude-opus-5-5" },
        { "name": "aibom:retention", "value": "provider default, 30 days; no ZDR agreement" },
        { "name": "aibom:retention-confirmed", "value": "2026-10-23" }
      ]
    }
  ],
  "dependencies": [
    { "ref": "app:support-assistant", "dependsOn": ["svc:anthropic-messages-api"] },
    { "ref": "svc:anthropic-messages-api", "dependsOn": ["model:claude-opus-5-5"] }
  ]
}

A few choices in that example are deliberate.

• The dataset entry exists and says it is not disclosed. A missing datasets array reads as "nobody checked". An entry that quotes the provider's description, with a source and date, reads as "checked, and this is what is available".
• The aibom:layer property marks provider asserted content. CycloneDX properties are free form name and value pairs. Pick a namespace for your organisation and use it consistently so that tooling can filter on it.
• The retention line names the setting and the date it was confirmed. Retention is a contract and configuration fact that drifts; the date tells a reviewer how stale it is.
• The model version equals the model ID. For a provider that ships each update under a new ID, the ID is the most precise version string you have.

Building the AIBOM in SPDX 3

SPDX 3.0.1 approaches the same record through profiles. The AI profile defines an AIPackage class with properties including autonomyType, domain, energyConsumption, hyperparameter, informationAboutApplication, informationAboutTraining, limitation, metric, metricDecisionThreshold, modelDataPreprocessing, modelExplainability, safetyRiskAssessment, standardCompliance, typeOfModel and useSensitivePersonalInformation. The Dataset profile defines a DatasetPackage class with properties such as dataCollectionProcess, datasetAvailability, datasetSize, datasetType, hasSensitivePersonalInformation, intendedUse, knownBias and anonymizationMethodUsed.

For a closed hosted model, a sensible mapping is:

Two fields deserve care. useSensitivePersonalInformation and autonomyType describe your deployment more than the model, and they are fields you can fill accurately even when the training data side is opaque. And informationAboutTraining is a free text field: resist the temptation to paraphrase a provider's description into something more specific than it is.

If your organisation has standardised on SPDX for software SBOMs, keep AI entries in the same document set so that one query covers both. If you use CycloneDX for software and SPDX elsewhere, pick one format for the AIBOM and convert at the edge; dual maintenance is where drift starts. Our SPDX 3 explainer and CycloneDX ML-BOM implementation guide go further into each format.

Step by step: build and maintain the AIBOM

This walkthrough assumes a repository that calls one or more hosted models through official SDKs. Adapt the commands to your stack.

Step 1: find every call site

Start with the dependency manifest, then the code. SDK packages show up as ordinary dependencies.

# Python
pip show anthropic openai 2>/dev/null | grep -E '^(Name|Version)'
grep -rnE 'anthropic|openai' requirements*.txt pyproject.toml poetry.lock 2>/dev/null

# Node
npm ls @anthropic-ai/sdk openai 2>/dev/null

# Any language: model IDs as string literals
grep -rnoE '"(claude|gpt|o[0-9])[a-z0-9.\-]*"' --include='*.py' --include='*.ts' --include='*.js' --include='*.go' --include='*.java' .

String search finds literals, not IDs loaded from configuration or environment variables, so also search your configuration repositories, infrastructure code and secret manager key names (names only) for model settings.

Step 2: confirm what is actually sent

Code can lie; logs do not. Add the model ID, endpoint and platform to your structured request logs if they are not there, and query a week of production traffic.

# Example: count model IDs seen in JSON request logs
jq -r 'select(.event=="llm_request") | [.service, .platform, .model] | @tsv' requests.jsonl \
  | sort | uniq -c | sort -rn

Compare the result with step 1. Every model ID in logs that is not in code points to configuration you missed. Every ID in code that never appears in logs may be dead code, or a fallback path that only fires under failure, which is worth knowing before a retirement date.

Step 3: record lifecycle state from the provider

Both providers expose lifecycle information you can check. OpenAI documents a shutdown_date field on its models endpoints. A minimal check:

curl -s https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | jq -r '.data[] | [.id, (.shutdown_date // "none")] | @tsv' \
  | grep -Ff our-openai-model-ids.txt

For Anthropic models, record the state and tentative retirement date from the deprecations page, and use the API usage audit described there to confirm no traffic still goes to deprecated IDs. Whichever provider, store the date you checked.

Step 4: map data flows and classify them

For each call site, write down what goes out (user text, retrieved documents, tool results, images, files) and what comes back, with your existing data classification labels. If retrieval adds documents to the prompt, the classification of the prompt is the highest classification of anything retrieval can add. This is where most AIBOMs understate exposure.

Step 5: record retention and training use settings

For each provider and each organisation or project:

• the default retention that applies under the provider's published policy;
• whether you have a zero data retention or modified monitoring arrangement, and for which endpoints it is effective;
• whether any feature you use stores state (files, stored responses, conversation threads);
• whether any user can opt into sharing data for training or submit feedback that the provider retains.

Attach the evidence: a screenshot or export of the setting, the agreement reference, and the date.

Step 6: attach provider documents as layer two

For each model ID, link the system card, the model report or model page, and the data policy. Save a copy or a hash of each page as retrieved.

url="https://www.anthropic.com/system-cards"
curl -sL "$url" -o evidence/anthropic-system-cards-2026-10-23.html
shasum -a 256 evidence/anthropic-system-cards-2026-10-23.html

When the page changes later, a new hash tells you to re-read it.

Step 7: run your own evaluation and record it

The provider's evaluations describe the model in general. Yours describe it on your task. Keep a fixed test set that reflects your real inputs, including adversarial ones such as prompt injection through retrieved content, and record pass rates per model ID in quantitativeAnalysis (CycloneDX) or metric (SPDX). Re-run on every model ID change.

Step 8: generate and validate the document

Generate the AIBOM from your inventory data rather than writing it by hand, and validate it in CI.

# Validate a CycloneDX 1.6 JSON document against the official schema
pip install check-jsonschema
curl -sLO https://raw.githubusercontent.com/CycloneDX/specification/1.6/schema/bom-1.6.schema.json
curl -sLO https://raw.githubusercontent.com/CycloneDX/specification/1.6/schema/spdx.schema.json
curl -sLO https://raw.githubusercontent.com/CycloneDX/specification/1.6/schema/jsf-0.82.schema.json
check-jsonschema --schemafile bom-1.6.schema.json aibom.cdx.json

Step 9: gate changes in CI

Fail a build when a new model ID appears in code without an AIBOM entry, or when an AIBOM entry has a retirement date within your migration window.

# .github/workflows/aibom.yml
name: aibom
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Model IDs in code must be in the AIBOM
        run: |
          grep -rhoE '"(claude|gpt|o[0-9])[a-z0-9.\-]*"' src | tr -d '"' | sort -u > ids_in_code.txt
          jq -r '.components[] | select(.type=="machine-learning-model") | .name' aibom.cdx.json | sort -u > ids_in_bom.txt
          missing=$(comm -23 ids_in_code.txt ids_in_bom.txt)
          if [ -n "$missing" ]; then echo "Not in AIBOM: $missing"; exit 1; fi

Step 10: assign an owner and a review date

Every model entry needs a named owning team and a next review date. A bill of materials without an owner is a snapshot that starts to decay the day it is written.

The vendor questionnaire

An AIBOM records what you know. The questionnaire is how you learn more, and how you document that you asked. The full version, with acceptable answers and evidence to request, is in the downloadable CSV. These are the questions that matter most, grouped by the AIBOM field they feed.

Model identity and change

1. Does a given model ID always refer to the same weights and configuration? If not, how are changes communicated?
2. What minimum notice do you give before deprecating or retiring a model ID we use, and through which channel?
3. Do lifecycle dates differ when we access the same model through a cloud marketplace rather than your own API?
4. Is there a machine-readable way to check a model's lifecycle state?

Training data

5. What categories of data was this model trained on, and where is that description published?
6. Can you provide a dataset-level list with sources, licences and versions, under NDA if necessary? If not, can you state why?
7. Is data we send through the API used for training, by default or under any setting we could enable by mistake?
8. What is the training data or knowledge cut-off date for this model ID?
9. What filtering is applied to training data for personal data, and for copyrighted or licence restricted content?
10. Have you published a public summary of training content as required for general purpose AI models placed on the EU market, and where?

Data handling

11. What is the default retention for inputs and outputs on each endpoint we use?
12. Which endpoints and features are eligible for zero data retention, and which store state regardless?
13. Under what conditions are inputs or outputs reviewed by people?
14. Which sub-processors handle our data, and in which regions?

Evaluation and safety

15. Where is the system card or model card for this exact model ID?
16. Which evaluations were run before release, and which were run by third parties?
17. How do you notify customers of safety relevant changes or incidents affecting a model ID?

Security

18. What security attestations or reports cover the service we use, and can we see them under NDA?
19. How do you protect the integrity of model weights and the training pipeline?
20. How should we report a security issue in a model's behaviour?

Two rules make the questionnaire useful. First, decide the acceptable answer before you send it. If any answer to question 6 is acceptable, the question is ceremony. Write down what you will accept (for example "category description plus written statement of reasons" may be acceptable for a low risk internal use, and not for a regulated decision), and what you will do if the answer falls short. Second, request evidence, not adjectives. A link to a published page, a contract clause or a report beats "we take data seriously".

Many questions will be answered by pointing at a published page. That is a good outcome: it means the answer is public, stable and citable, and you can link it in the AIBOM.

Contract clauses that make the AIBOM true

Policies on a website can change. A contract term is what keeps a recorded setting true. The downloadable Markdown file holds sample wording; it is not legal advice and your counsel will adapt it. The topics to cover are:

Many providers publish standard commercial terms and data processing addenda that already cover some of these. Map each clause topic to the existing term and negotiate only the gaps.

Review cadence when models change

Models change on the provider's schedule, not yours. Tie AIBOM reviews to events and backstop them with a calendar.

For the event triggers, subscribe to the provider's deprecation pages and changelogs, and wire the lifecycle check from step 3 into a scheduled job. For the quarterly review, the page hashes from step 6 tell you which provider documents to re-read.

Risk acceptance when the training data is unknown

Some fields will stay empty for closed frontier models. The question then is whether the remaining uncertainty is acceptable for this use. A short, structured acceptance works better than a long memo.

NIST AI 600-1, published in July 2024, lists risks specific to or worsened by generative AI, among them Data Privacy, Information Integrity, Information Security, Intellectual Property and Value Chain and Component Integration, and it suggests actions for each. The last of these is the one an AIBOM serves most directly: it covers third party components, including models and data, whose origin and quality are not fully transparent to the deployer. A risk acceptance that cites the relevant risk categories, the controls you applied, and the specific fields that remain unknown is easy to defend and easy to revisit. Our post on training data opacity as a model limit goes deeper into the security side.

What the EU AI Act adds to the record

Article 53 of the AI Act requires providers of general purpose AI models to keep technical documentation, to make information and documentation available to downstream providers who integrate the model into their own AI systems, to put in place a policy to comply with Union copyright law, and to publish a sufficiently detailed summary of the content used for training, following a template provided by the AI Office. The Commission published an explanatory notice and template for that public summary on 24 July 2025, and the General Purpose AI Code of Practice, published on 10 July 2025, which the Commission describes as a voluntary tool providers can use to show compliance with the Act's obligations on safety, transparency and copyright. Whether a given provider signed it is something to check on the Commission's signatory list and the provider's own statements, not to assume.

For a deployer's AIBOM, this means two practical additions. Add an external reference to the provider's public training content summary for each general purpose model you use, where one exists, with a retrieval date. And file the downstream provider documentation you receive alongside your AIBOM, because it is the closest thing to a provider authored model card you will get under a legal duty. The Commission describes the template as a common minimal baseline for the information to be made public; a public summary is not a dataset-level, machine-readable AIBOM. Our post on EU AI Act software supply chain implications covers the wider obligations.

Where Safeguard's AI-BOM discovery fits

Safeguard's AI-BOM discovery is in early access. It inventories the AI assets your organisation uses, across code (SDK imports), cloud AI services, SaaS use and vector databases, and can output the result as a CycloneDX ML-BOM or SPDX AI profile. That covers the layer one work in steps 1 and 2 above and keeps it current as code changes. It cannot see inside a vendor's training data, and it does not reveal what a closed model was trained on; no outside tool can. Layer two still comes from the provider's own documents and your questionnaire.

Separately, Safeguard's generally available SBOM and dependency scanning lists the SDK packages your services use (for example the official client libraries) as ordinary components, matches them against vulnerability databases and shows every project that carries a given version. That is the software half of an AI integration, and it is the half most teams can fix today.

Common mistakes

Recording the family, not the ID. "Claude" or "GPT" is not a version. Record the exact string your code sends. If your code sends an alias or a name ending in latest, the AIBOM should say so and flag it.

Treating provider prose as verified fact. A training data description in a system card is a provider assertion. Store it as one, with a source and date. Do not upgrade it into a dataset component with invented names.

Leaving unknown fields out. Omitted fields look like missed work. Fields marked "not disclosed by supplier; requested on date" show the gap and the effort.

Forgetting the platform. The same model reached through the provider's API and through a cloud marketplace can have different lifecycle dates and different data terms. Record the platform per call site.

Recording retention once. Retention settings live in account and project configuration and can be changed by anyone with admin access. Re-confirm on a schedule and after any account change.

Ignoring retrieval. The prompt's data classification is set by the most sensitive document retrieval can add, not by what the user typed.

Evaluating once. Your evaluation applies to one model ID. A new ID is a new component and needs a new run, even if the provider describes it as a minor update.

Writing the AIBOM by hand. Hand written documents drift on the first change. Generate from inventory data and validate in CI.

Asking questions without acceptance criteria. A questionnaire that accepts any answer is paperwork. Decide what is acceptable for each risk tier before you send it.

Assuming a tool can fill layer two. No scanner can read a closed model's training corpus from the outside. Any tool that claims to should prompt questions, not trust.

FAQ

Can I build an AIBOM for a model I only call through an API?

Yes. You build an AIBOM of your use of it. You record the model ID, endpoint, platform, data flows, settings, evaluation results and the provider's published documentation. The fields about training datasets stay marked as not disclosed unless the provider gives you more.

What is the difference between an AIBOM and a model card?

A model card is a document about one model, usually written by whoever trained it. An AIBOM is an inventory of AI components in your system and their relationships, in a machine-readable format such as CycloneDX or SPDX. A CycloneDX ML-BOM can carry model card content inside a modelCard object, so the two fit together.

Should I use CycloneDX or SPDX for an AIBOM?

Use whichever your organisation already uses for SBOMs, so one query covers software and AI. CycloneDX 1.6 has a machine-learning-model component type with a modelCard and a service type for hosted endpoints. SPDX 3 has an AI profile with AIPackage and a Dataset profile with DatasetPackage. Both can record a hosted closed model.

How do I record the version of a closed model?

Use the exact model ID your code sends. Anthropic documents that from the Claude 4.6 generation a model ID is a fixed snapshot and updates ship under new IDs. OpenAI's model pages list the snapshot IDs for each model, and its deprecations page publishes minimum notice periods before retirement. Avoid aliases and names ending in latest in production, and flag them in the AIBOM if you use them.

Do Anthropic and OpenAI use my API data for training?

According to their own published policies, OpenAI states API data is not used to train its models since March 1, 2023 unless you opt in, and Anthropic's privacy centre describes API retention and deletion terms. Check the current pages and your contract, and record the setting and the date you confirmed it.

What questions should I ask an AI vendor about training data?

Ask what categories of data the model was trained on and where that is published, whether a dataset-level list with sources and licences exists, whether your data is used for training, what the cut-off date is, how personal data and copyrighted content were filtered, and whether a public training content summary under the EU AI Act exists. Decide in advance what answer you will accept.

How often should an AIBOM for AI models be updated?

Update on events: a new model ID in code, a deprecation notice, a new system card, a policy change, or a change in the data you send. Backstop with a quarterly review of every entry older than 90 days.

Does the EU AI Act require my vendor to give me an AIBOM?

No. Article 53 requires general purpose AI model providers to keep technical documentation, provide information to downstream providers, maintain a copyright policy and publish a training content summary following the Commission's template. None of that is a dataset-level, machine-readable AIBOM. It is useful input to yours.

Can any tool tell me what a closed model was trained on?

No. Tools can inventory which models you use and how. The training data of a closed model is known only to its provider, and you learn about it only through what the provider publishes or tells you.

What should I do if a vendor cannot answer a training data question?

Record the question, the date and the answer or non-answer in the AIBOM. Then decide whether the use case's risk tier tolerates the gap, with compensating controls such as your own evaluation, output review and data minimisation. If it does not, choose a different model or a different design.

Downloads

Direct downloads:

• Download closed-model-vendor-questionnaire.csv

• Download closed-model-sample-contract-clauses.md

• Download support-assistant-aibom.cyclonedx.json.txt

• support-assistant-aibom.cyclonedx.json.txt: a complete CycloneDX 1.6 AIBOM, in plain JSON, for an application that calls two hosted closed models, with model, service, data flow, lifecycle and provider evidence fields, validated against the official CycloneDX 1.6 schema. Rename it to .json before loading it into a tool.

• closed-model-vendor-questionnaire.csv: the vendor questions from this post, each with why it matters, what an acceptable answer looks like and what evidence to request, ready to open in a spreadsheet or import into a procurement tool.

• closed-model-sample-contract-clauses.md: example wording for model change notice, version stability, training use, retention, sub-processors, documentation, regulatory cooperation, incidents and audit evidence. Not legal advice.

An AIBOM for a hosted model sits on top of ordinary software: the SDK client libraries, HTTP stacks, retrieval pipelines and container images that carry every call to the provider, and those are open source components with their own vulnerabilities. The model's training data stays outside your reach, but the code around it is yours to keep patched, so the usual supply chain hygiene still applies.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Each demo below is a recorded walkthrough of a real Safeguard surface. None of them shows AI-BOM discovery itself, which is in early access; they show the flows you would use around it.

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how to choose which tools Claude is allowed to use. That choice is itself an AIBOM fact worth recording: which assistant can reach which tools, with which permissions.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: the assistant reads a finding and its advisory, asks before each command, upgrades a vulnerable dependency, runs the install and tests with approval, and pushes nothing. The same flow applies to the SDK client libraries behind your model calls, which are ordinary dependencies in your SBOM.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with a device code and scans from the terminal. Running the scan in your own environment is a practical way to produce the software half of an AI integration's bill of materials without sending source code anywhere new.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard or read the CLI documentation.

Quick check

Sources

• CycloneDX: Machine Learning Bill of Materials (AI/ML-BOM)
• CycloneDX 1.6 JSON schema reference
• CycloneDX 1.6 JSON schema file (GitHub)
• SPDX 3.0.1: AI profile
• SPDX 3.0.1: AIPackage class
• SPDX 3.0.1: DatasetPackage class
• OWASP GenAI Security Project: AIBOM Initiative
• Anthropic: Model IDs and versioning
• Anthropic: Models overview
• Anthropic: Model deprecations
• Anthropic: Model system cards
• Anthropic: Transparency Hub
• Anthropic Privacy Center: How long do you store my organization's data?
• OpenAI API docs: Data controls in the OpenAI platform
• OpenAI API docs: Deprecations
• OpenAI API docs: Models
• OpenAI API docs: GPT-6.1 Sol model page
• OpenAI Deployment Safety Hub
• EU AI Act, Article 53: Obligations for providers of general-purpose AI models
• European Commission: Explanatory notice and template for the public summary of training content (24 July 2025)
• European Commission: The General-Purpose AI Code of Practice
• NIST AI 100-1: AI Risk Management Framework 1.0
• NIST AI 600-1: Generative AI Profile

Last reviewed: 23 October 2026. Provider pages change; check the linked documentation for current terms before relying on any setting described here.