Why Anthropic and OpenAI Do Not Publish AIBOMs for Their Models

Anthropic and OpenAI do publish a lot about their models: system cards, model pages, knowledge cutoff dates, safety evaluations and a short prose description of the training data. What neither publishes, on the pages we checked, is an AIBOM: a machine readable, per model list of datasets, sources, licences, versions and provenance in a format like CycloneDX ML-BOM or SPDX 3 AI and Dataset. Neither lab states a reason for that on those pages, so buyers have to record the gap themselves.

This post is a careful audit, not an accusation. We read each lab's own published pages (system cards, the Anthropic Transparency Hub, model documentation, privacy and data usage pages, crawler documentation and statements about the EU Code of Practice), then compared what they say against the fields that the two main AIBOM standards define. The result is a field by field table, an honest list of what is known and unknown, the regulatory context in the EU and US, and a practical way to write the unknowns into your own AIBOM so they are visible, owned and reviewed. For background on AIBOMs first, see our AIBOM explainer.

Key takeaways

• Both labs publish human readable model documentation. Anthropic lists system cards for every Claude model from Claude 2 (July 2023) to Claude Haiku 5.5 (October 2026). OpenAI publishes system cards, including the GPT-5 system card dated 13 August 2025.
• Both describe training data in one paragraph of categories: public web data, licensed or partner data, user or contractor data, and synthetic or internally generated data, plus filtering steps. Neither names individual datasets, versions, licences or proportions.
• Anthropic's Transparency Hub calls the training data for recent models "a proprietary mix". That word describes the data. It is not a stated reason for not publishing an AIBOM, and we found no stated reason on either lab's pages.
• An AIBOM in CycloneDX 1.6 or SPDX 3.0.1 would carry dataset identities, licences, collection processes, sensitive data flags, versions and hashes. Those are the fields that stay empty for closed frontier models.
• The EU AI Act asks general purpose AI providers for a public training content summary using a Commission template. That template is narrative and aggregated by design (size ranges, data source categories, top domain names). It is not an AIBOM.
• The European Commission lists both Anthropic and OpenAI as signatories of the General Purpose AI Code of Practice.
• You cannot fix the gap from the outside. You can record what is knowable, mark the rest as unknown in a standard way, ask the right procurement questions and decide risk acceptance on purpose.
• Safeguard's AI-BOM discovery (early access) inventories the AI assets your own organisation uses, across code (SDK imports), cloud AI services, SaaS use and vector databases. It cannot see inside any vendor's training data.

What is an AIBOM, and what would one contain for a frontier model?

An AI bill of materials applies the SBOM idea to machine learning. A software SBOM lists packages, versions, suppliers, licences and hashes so you can answer "do we ship this component?" in minutes. An AIBOM does the same for models and the data behind them: which model, which version, who supplied it, how it was trained, on which datasets, under which licences, and with what known limitations.

Three efforts define what that looks like in practice.

CycloneDX ML-BOM. CycloneDX supports machine learning models and datasets as first class components. In the 1.6 JSON schema, a component can have the type machine-learning-model or data, and a model component can carry a modelCard object. The model card holds modelParameters (approach, task, architecture family, model architecture, datasets, inputs and outputs), quantitativeAnalysis (performance metrics), and considerations (users, use cases, technical limitations, performance trade offs, ethical considerations, environmental considerations and fairness assessments). Datasets can be inline componentData objects with a type, name, contents, classification, sensitive data, description and governance (owners, stewards and custodians), or references to separate data components. External references include a model-card type for linking human readable documentation. For a deeper walk through, see our CycloneDX ML-BOM implementation guide.

SPDX 3 AI and Dataset profiles. SPDX 3.0.1 has an AI profile with an AIPackage class and a Dataset profile with a DatasetPackage class. AIPackage properties include typeOfModel, domain, informationAboutTraining, informationAboutApplication, modelDataPreprocessing, hyperparameter, metric, metricDecisionThreshold, limitation, modelExplainability, safetyRiskAssessment, standardCompliance, energyConsumption, autonomyType and useSensitivePersonalInformation. DatasetPackage properties include datasetType, dataCollectionProcess, dataPreprocessing, datasetSize, datasetAvailability, datasetUpdateMechanism, datasetNoise, knownBias, intendedUse, sensor, confidentialityLevel, anonymizationMethodUsed and hasSensitivePersonalInformation. Relationships such as "trained on" connect a model to its datasets. Our post on what changed in SPDX 3.0 covers the profile model.

The OWASP AIBOM Initiative. Run under the OWASP GenAI Security Project, the initiative describes its goal as turning the AIBOM concept into practice through open source tooling, "measurable completeness assessment" and practitioner guidance. It maintains an open source AIBOM generator. Its focus on completeness scoring matters here, because a closed model AIBOM will always score low on dataset fields, and a completeness score makes that visible rather than hidden.

So when we say "AIBOM" in this post, we mean a machine readable document, one per model version, that names the model and its supplier, lists the datasets it was trained and evaluated on with their sources, licences, versions and hashes, and records known limitations and risk assessments. That is the yardstick.

What does Anthropic publish about each Claude model?

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

System cards

Anthropic's system cards page says system cards "document the capabilities, safety evaluations, and responsible deployment decisions" for Claude models. The page lists a card for each release, from Claude 2 (July 2023) through the Claude 3 family (March 2024), the Claude 4 family (May 2025), Claude Opus 4.5 (November 2025), the 4.6 models (February 2026), Mythos Preview (April 2026), the 5 family (mid 2026), Claude Opus 5.5 and Sonnet 5.5 (September 2026) and Claude Haiku 5.5 (October 2026). Each card is a long PDF covering evaluations, safety testing and deployment decisions.

The Transparency Hub model report

The Transparency Hub's Model Report, dated 2 October 2026 on the page, gives each model a summary table. For recent models the table includes a model description, a pointer to benchmarked capabilities in the system card, acceptable uses (pointing to the Usage Policy), release date, modalities, a knowledge cutoff date for several models, "Model architecture and training methodology", "Training Data" and "Testing Methods and Results".

The Training Data entry is one paragraph. For Claude Opus 5.5 it reads, in part, that 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 Anthropic used several data cleaning and filtering methods, including deduplication and classification. The Sonnet 5.5 and Haiku 5.5 entries add that the mix may include user data from feedback or bug reports, or data that users explicitly permitted for training.

Older entries carry a little more texture. The Claude Sonnet 4.6 entry says it was trained on public internet information as of May 2025, non public data from third parties, data from data labelling services and paid contractors, data from Claude users who opted in to training, and data generated internally. The Claude 3.7 Sonnet entry says that when Anthropic's general purpose crawler collects public web pages, it follows industry practice on robots.txt instructions, and that this model was not trained on user prompt or output data submitted by users or customers.

Model documentation

Anthropic's models overview in its developer documentation lists, per model, the Claude API ID and alias (for example claude-opus-5-5), the IDs used on cloud platforms, pricing, context window, maximum output, a "Reliable knowledge cutoff" and a "Training data cutoff" (June 2026 for the current 5.x models), and a retirement date given as "Not sooner than" a stated day in 2027. The page points readers to the Transparency Hub for the cutoffs behind each model.

Privacy policy

Anthropic's privacy policy lists the sources it uses to train models: publicly available information via the internet, datasets obtained through commercial agreements with third party businesses, data that users or crowd workers provide (including inputs and outputs, unless users opt out), feedback users explicitly provide, materials flagged for safety, security or policy review, and data generated internally. It also says users can opt out of consumer conversations being used for training through account settings, with stated exceptions for flagged content and explicit feedback.

EU Code of Practice

On 21 July 2025 Anthropic published "Anthropic to sign the EU Code of Practice", stating that it "intends to sign the European Union's General-Purpose AI Code of Practice." The European Commission's Code of Practice page lists Anthropic among signatories.

Summary for Anthropic: per model release dates, IDs, cutoffs, modalities, evaluation results, deployment safeguards and a category level description of training data. No per dataset list, no licences per source, no dataset versions or hashes, no proportions, no machine readable model card in an AIBOM format, at least on the pages we read.

What does OpenAI publish about each model?

Everything in this section comes from OpenAI's own pages and files. Several openai.com and help.openai.com pages refused our scripted requests (HTTP 403), so we worked from OpenAI's system card PDFs on its CDN and its platform documentation. Where a page could not be read, we say so in the FAQ rather than guess its content.

System cards

The GPT-5 system card, dated 13 August 2025, has a section titled "Model Data and Training". It says the GPT-5 models were trained on diverse datasets including information publicly available on the internet, information OpenAI partners with third parties to access, and information that users or human trainers and researchers provide or generate. It describes rigorous filtering for data quality and risk, "advanced data filtering processes to reduce personal information", and the use of OpenAI's Moderation API and safety classifiers to keep harmful or sensitive content out.

The GPT-4o system card, dated 8 August 2024, goes a step further on categories. It says GPT-4o's text and voice capabilities were pre trained using data up to October 2023, sourced from select publicly available data "mostly collected from industry-standard machine learning datasets and web crawls", and proprietary data from data partnerships that give access to non public data such as pay walled content, archives and metadata. It names one image partnership as an example. It then lists key dataset components (web data, code and maths, multimodal data) and the filtering steps applied.

Model documentation

OpenAI's platform models page lists, per model, a model ID (for example gpt-6-astra, gpt-6.1-sol and gpt-6-luna among the current flagship models), reasoning settings, prices, context window, maximum output, a knowledge cutoff date (30 April 2026 for the first two, 18 May 2026 for the third) and supported tools.

Data usage and retention for API customers

OpenAI's "Data controls in the OpenAI platform" guide states that, as of 1 March 2023, data sent to the OpenAI API is not used to train or improve OpenAI models unless the customer explicitly opts in to share data. It also explains that abuse monitoring logs are generated by default and retained for up to 30 days, and that eligible customers can apply for Modified Abuse Monitoring or Zero Data Retention controls, subject to OpenAI's prior approval.

Crawler documentation

OpenAI's "Overview of OpenAI Crawlers" page says GPTBot "is used to crawl content that may be used in training" its generative AI foundation models, and that disallowing GPTBot in robots.txt indicates a site's content should not be used for that training. Separate user agents cover search and user triggered fetches.

EU Code of Practice

The European Commission's Code of Practice page lists OpenAI among signatories. OpenAI's own statement page about the Code returned HTTP 403 to our requests, so we rely on the Commission's list for the signature.

Summary for OpenAI: per model IDs, cutoffs, capabilities, safety evaluations, a category level description of training data, clear API data usage terms and crawler controls. No per dataset list, no licences per source, no dataset versions or hashes, no proportions, no machine readable AIBOM, at least in the documents we could read.

Field by field: what is published versus what an AIBOM holds

Two observations stand out. First, the "identity" half of an AIBOM (name, supplier, version, dates, cutoffs, modalities, evaluations) is well covered by both labs, just not in a machine readable format. You can transcribe it. Second, the "composition" half (named datasets, licences, versions, sizes, hashes, mixtures) is where the gap is, and that is the half that makes a bill of materials a bill of materials.

Where exactly is the gap?

It helps to split the gap into three layers, because each has a different fix.

Layer 1: format

Everything both labs publish is HTML or PDF. Even the facts that are published, such as model IDs and cutoffs, have to be copied by hand into your inventory. This layer is the easiest to close on your side: you transcribe the published facts into CycloneDX or SPDX once per model version, with links back to the source pages.

Layer 2: granularity

Both labs describe training data as a list of categories. An AIBOM wants instances: dataset A, version 3, licence X, collected on these dates, hash Y. A category such as "public and private datasets" tells you the kinds of data involved. It does not let you check whether a particular corpus, licence or source is in the mix. You cannot close this layer from the outside.

Layer 3: change over time

Model IDs change with each release, and both labs publish new system cards with new releases. But there is no published dataset change log. When a new model ships, you get a new prose paragraph, not a diff of datasets added or removed. Your own AIBOM can still track which model version you used when, which is the part of change management you control.

Have Anthropic or OpenAI said why they do not publish AIBOMs?

On the pages we read, no. Neither lab says anything about AIBOMs, ML-BOMs or SPDX AI documents, and neither states a reason for not publishing a per dataset list. The closest relevant wording is Anthropic's description of its training data as "a proprietary mix", which describes the data rather than explaining a disclosure decision. We did not find a stated reason in OpenAI's system cards or platform documentation either.

Because there is no stated reason, we will not suggest one for either company. What we can do is list considerations that are commonly discussed across the industry about publishing full training data inventories for very large models. These are general industry considerations, not attributed to Anthropic, OpenAI or any other company:

• Trade secrets and competitive information. Data mixtures and curation choices are widely treated as valuable know how. The EU AI Act itself recognises this: Article 53(1)(b) expressly preserves the protection of intellectual property rights, confidential business information and trade secrets, and the Commission's explanatory notice for the training content template has a whole section on balancing disclosure with trade secrets.
• Scale of web data. A corpus collected from billions of web pages does not reduce neatly to a list of datasets with licences. The Commission's template responds to this by asking for top domain names rather than every source.
• Security of training pipelines. Detailed data source lists could, in principle, help someone target a source for data poisoning. This is a general argument about publishing pipeline details.
• Legal uncertainty. The law on text and data mining, copyright and personal data in training sets is still developing in several jurisdictions, and detailed lists carry legal weight.
• Contractual limits. Licensed datasets may come with confidentiality terms that limit what the licensee can say about them.

Whether any of these applies to a given lab is for that lab to say. For your risk register, the reason matters less than the fact: the composition fields are empty, so you record them as unknown and decide what that means for each use case.

Why does the AIBOM gap matter to buyers?

A missing dataset list is not abstract. It shows up in concrete questions your organisation already has to answer. Our companion post on training data opacity as a frontier model limit looks at this from the model behaviour side. From a supply chain and governance view, the gap affects five areas.

The right column is not nothing. It is enough for many uses, especially where the model processes your data under clear contract terms and does not make high stakes decisions on its own. It is less comfortable for regulated uses where you have to explain data provenance, and that is where the gap becomes a risk acceptance decision.

How is this different from an open weights model?

Some open weights models ship with dataset cards, data documentation or even links to the training corpora. That is not universal, and "open weights" does not by itself mean "open data". The point for buyers is that AIBOM completeness is a property of each model's documentation, not of whether the model is hosted or downloadable. Score each model you use on the same fields.

What does the EU AI Act require general purpose AI providers to disclose?

The EU AI Act gives the closest thing to a legal AIBOM requirement for model providers, but it is not an AIBOM. This section summarises the primary texts.

Article 53 obligations

Article 53(1) sets four obligations for providers of general purpose AI models:

1. (a) Draw up and keep up to date technical documentation of the model, including its training and testing process and evaluation results, containing at minimum the information in Annex XI, to provide on request to the AI Office and national competent authorities.
2. (b) Draw up, keep up to date and make available information and documentation to providers of AI systems that integrate the model, enabling them to understand its capabilities and limitations, containing at minimum the elements in Annex XII. This is subject to protecting intellectual property, confidential business information and trade secrets.
3. (c) Put in place a policy to comply with EU copyright law, including identifying and complying with reservations of rights under Article 4(3) of Directive (EU) 2019/790.
4. (d) Draw up and make publicly available "a sufficiently detailed summary about the content used for training" the model, according to a template provided by the AI Office.

Note who receives what. The detailed technical documentation in (a) goes to regulators on request, not to the public. The documentation in (b) goes to downstream providers who integrate the model. Only the summary in (d) is public.

The Commission's training content template

The Commission published the Explanatory Notice and Template for the Public Summary of Training Content on 24 July 2025. The template has three sections:

1. General information. Identification of the provider and model, modalities, training data size per modality within broad ranges (for text: less than 1 billion tokens, 1 billion to 10 trillion tokens, or more than 10 trillion tokens) and the type of content.
2. List of data sources. Publicly available datasets, private datasets from third parties (split into datasets commercially licensed by rightsholders and other private datasets), data crawled and scraped from online sources, user data, synthetic data and other sources.
3. Relevant data processing aspects. How the provider respected reservations of rights under the text and data mining exception, how it removed illegal content, and optional other information.

For crawled data, the template asks for the internet domain names in the top 10 percent of all domains by size of content scraped, or for small and medium sized enterprises the top 5 percent or the top 1,000 domains. The notice says the summary should be updated every six months, or sooner if additional training requires a materially significant update. The obligation applies from 2 August 2025; for models placed on the market before that date, providers have until 2 August 2027 to publish the summary. The notice states that supervision and enforcement by the AI Office for the general purpose AI rules start on 2 August 2026. It also says that where a provider of an older model cannot supply parts of the information despite best efforts, it should clearly state and justify those gaps in the summary. That is the regulator's own version of marking a field unknown.

The General Purpose AI Code of Practice

The Commission's Code of Practice page says the code was published on 10 July 2025 and has three chapters: Transparency, Copyright, and Safety and Security. The Transparency chapter comes with a Model Documentation Form. The Transparency and Copyright chapters offer all general purpose AI providers a way to show compliance with Article 53; the Safety and Security chapter applies to providers of models with systemic risk under Article 55. The Commission and the AI Board have confirmed the code is an adequate voluntary tool. As noted above, the signatory list on that page includes both Anthropic and OpenAI.

Is the EU summary an AIBOM?

No, and it is not meant to be. The template is a narrative document with ranges and categories, designed to balance transparency against trade secrets. A good summary will tell you the size band, the categories of sources, the top domains crawled and how opt outs were handled. It will not give you dataset versions, licences per dataset, hashes or a machine readable format. It is a useful input to your AIBOM, not a replacement for one. Our post on EU AI Act supply chain implications covers the wider Act.

Have Anthropic and OpenAI published EU training content summaries?

We could not confirm this from either lab's own pages or from a Commission page during our research. Some secondary commentary claims one or both have filed summaries, and some claims conflict with each other. Because the series rule is to state what a lab published only when the lab or the Commission says so, we make no claim either way. Check each lab's site and the AI Office pages before relying on a summary, and if you find one, record it as an external reference in your AIBOM entry for that model.

What does US guidance say?

There is no US federal law requiring model providers to publish an AIBOM. The most relevant primary guidance is NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework, published on 26 July 2024. It is a voluntary, cross sector companion to AI RMF 1.0 that helps organisations identify and manage risks particular to generative AI, including risks that arrive through third party models and components. For a buyer, the profile gives a recognised vocabulary for writing down why you accepted a model whose training data you cannot see, which is exactly what an auditor will ask.

Step by step: record a closed model honestly in your own AIBOM

You cannot make a provider publish a dataset list. You can make your own AIBOM complete about what is knowable, explicit about what is not, and current. Here is the process we recommend, with CycloneDX 1.6 examples. The same approach works in SPDX 3.

Step 1: inventory every place your code calls a model

Start with your own repositories. Search for SDK imports, API base URLs and model ID strings. A quick first pass from a repository root:

# Find model ID strings and SDK usage across a repository
grep -rnE "claude-[a-z0-9.-]+|gpt-[0-9a-z.-]+" --include=*.{py,ts,js,go,java,yaml,yml,json} .
grep -rnE "^(anthropic|openai)([=<>~! ]|$)" requirements*.txt pyproject.toml 2>/dev/null
npm ls @anthropic-ai/sdk openai 2>/dev/null

Treat the output as leads, not as the inventory. Model IDs often live in configuration, environment variables or a gateway, not in code. Ask each team which provider accounts they use and where calls are routed.

Step 2: pin the exact model identifiers you use

Record the full model ID you call, not a marketing name. Both labs publish IDs on their models pages, and Anthropic also lists IDs for each cloud platform where Claude is offered. If you call a model through a cloud platform, record that platform's ID as well, because it is the identifier that appears in your logs.

Step 3: transcribe the published identity fields

For each model ID, copy from the provider's own pages: supplier, release date, knowledge or training data cutoff, modalities, context window, retirement date where given, and links to the system card and model documentation. Add the date you read them. This closes the format layer of the gap for everything that is published.

Step 4: describe training data at the level the provider gives, and mark the rest unknown

Add a dataset entry that quotes the provider's own category description and links to the page. Then mark the composition as unknown in a way tools can read. CycloneDX has a built in mechanism for this: the compositions array with an aggregate value. Setting "aggregate": "unknown" on the assembly that holds the training data tells every consumer that the list of datasets is not known, rather than leaving them to guess whether an empty list means "none".

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-23T00:00:00Z",
    "component": {
      "type": "application",
      "bom-ref": "app-support-assistant",
      "name": "support-assistant"
    }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model-claude-opus-5-5",
      "supplier": { "name": "Anthropic" },
      "name": "claude-opus-5-5",
      "version": "claude-opus-5-5",
      "description": "Called via the Claude API. Training data cutoff Jun 2026 per provider docs.",
      "externalReferences": [
        { "type": "model-card", "url": "https://www.anthropic.com/system-cards" },
        { "type": "documentation", "url": "https://www.anthropic.com/transparency" }
      ],
      "modelCard": {
        "modelParameters": {
          "datasets": [ { "ref": "data-provider-training-mix" } ],
          "inputs": [ { "format": "text" }, { "format": "image" } ],
          "outputs": [ { "format": "text" } ]
        },
        "considerations": {
          "technicalLimitations": [
            "Training datasets, licences, versions and proportions not published by provider"
          ]
        }
      }
    },
    {
      "type": "data",
      "bom-ref": "data-provider-training-mix",
      "name": "Provider training data (as described by provider)",
      "data": [
        {
          "type": "dataset",
          "name": "Pretraining and post training mix",
          "description": "Provider describes a proprietary mix of public online information, public and private datasets, user data and synthetic data, with deduplication and classification filtering."
        }
      ]
    }
  ],
  "compositions": [
    { "aggregate": "unknown", "assemblies": [ "data-provider-training-mix" ] }
  ]
}

The full version of this example, with more fields and properties for each unknown, is in the Downloads section below. In SPDX 3, the equivalent is an AIPackage with informationAboutTraining quoting the provider, a DatasetPackage whose datasetAvailability and size fields are left unset, and a "trainedOn" relationship whose completeness is set to noAssertion, which is how SPDX 3 relationships say "we do not know whether this list is complete".

Step 5: record your own data flows next to the model

The model's training data is unknown, but your data flows are not. Record which of your data categories go to each model, which provider account and region you use, the data usage setting for that account (for example, OpenAI's statement that API data is not used for training unless you opt in, or the consumer opt out described in Anthropic's privacy policy), and any retention controls you have been approved for. This is often the part auditors care about most.

Step 6: attach evaluation evidence you produced yourself

Link the system card, but also attach your own evaluation results for your use case: accuracy on your test set, refusal behaviour, prompt injection tests and anything else you measured. In CycloneDX these go in quantitativeAnalysis or as an external reference of type evidence. Your evaluations are the main way to compensate for unknown training data, because they test the behaviour you rely on directly.

Step 7: write the risk acceptance down

For each model and use case, record who accepted the unknown training data risk, on what basis, and until when. A short statement is fine: "Accepted for internal summarisation of non personal data; provider training data composition unknown; review on next model version or by date."

Step 8: set a review trigger

Re-run steps 2 to 7 whenever you change model ID, when the provider publishes a new system card or EU training content summary, or every six months, whichever comes first. The six month rhythm matches the update interval in the Commission's template notice, which makes it easy to explain.

Checklist

• Every model call site found and owned by a team
• Exact model IDs recorded, including cloud platform IDs
• Identity fields transcribed with source links and read dates
• Training data entry quotes the provider's own description
• Composition marked unknown in a machine readable way
• Your data flows, account settings and retention recorded
• Your own evaluation evidence attached
• Risk acceptance written with an owner and expiry
• Review trigger set for model changes and every six months

Procurement questions and contract clauses that work

The labs' public pages are the floor, not the ceiling. Enterprise agreements sometimes include more documentation under confidentiality. Ask, and record the answers in your AIBOM as references with the confidentiality level noted.

Questions to ask any closed model provider:

1. Which model IDs and versions does this agreement cover, and how will you notify us of new versions and retirements?
2. Will you provide the EU AI Act training content summary for each model, and the Annex XII documentation if we are integrating the model into an AI system?
3. Can you describe the training data categories for this model in more detail under NDA, including whether licensed datasets were used and in which domains?
4. How do you handle reservations of rights and opt outs for web data, and how can a rightsholder check?
5. What personal data filtering do you apply, and how do you handle data subject requests that relate to training data?
6. Is any of our data used for training under this agreement? What are the default and optional retention periods?
7. Can you supply a machine readable model card or AIBOM, in CycloneDX or SPDX, for this model? If not now, is it on your roadmap?
8. What evaluation results can you share for our use case or domain beyond the public system card?

Clauses to consider (have your counsel adapt them):

• Documentation clause. The provider will supply, for each covered model version, the public system card, the EU training content summary where it exists, and any Annex XII documentation, within a set number of days of release.
• Change notification clause. The provider will notify the customer a set number of days before retiring or materially changing a covered model ID.
• Data use clause. Customer content will not be used to train or improve models without written opt in, with retention limits stated.
• Assistance clause. The provider will reasonably assist with regulatory inquiries about the model's training data, within the limits of trade secrets.
• Format clause (aspirational). Where the provider produces machine readable model documentation, it will make it available to the customer.

Do not expect every clause to be accepted. The value is in knowing which questions got "no", because those become the documented unknowns in your AIBOM.

How does Safeguard fit, honestly?

Safeguard cannot close the composition gap. No outside tool can see what a closed model was trained on, and Safeguard does not claim to.

What Safeguard does is help with the parts of the AIBOM that are about your own systems. 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 a CycloneDX ML-BOM or SPDX AI profile. That covers steps 1 and 2 above, which are the steps teams most often get wrong because model IDs hide in configuration. You then add the provider facts and unknowns yourself.

Generally available today, Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>) and lists the open source dependencies you ship, including AI SDK packages, with vulnerability matching, reachability analysis and policy gates. The apps and SDKs around a model are ordinary software and carry ordinary software supply chain risk. For a wider view of AI supply chain risk, see AI supply chain security risks.

Common mistakes

Treating a system card as an AIBOM. A system card is valuable documentation about evaluations and safety. It is not a machine readable list of components and datasets. Link it from your AIBOM; do not let it stand in for one.

Leaving dataset fields empty instead of marking them unknown. An empty list reads as "no datasets" to some tools and as "not filled in yet" to people. Use CycloneDX compositions with "aggregate": "unknown" or SPDX completeness: noAssertion so the gap is explicit.

Recording a marketing name instead of a model ID. "Our chatbot uses Claude" or "uses GPT" is not an inventory entry. Record the exact ID you call, per environment.

Copying facts without a source and date. Provider pages change with each release. Every transcribed field should carry the URL and the date you read it.

Assuming the EU summary answers procurement questions. The public summary is aggregated by design. It will not tell you whether a specific dataset was used or what its licence was.

Confusing training data use of your inputs with training data of the model. Whether your prompts are used for future training is a contract and settings question you can answer. What the current model was trained on is a separate question you mostly cannot. Record both, separately.

Attributing motives. Writing "the provider hides its data" in a risk register is neither accurate nor useful. Write what is published, what is not, and what you decided.

Never revisiting. Model IDs change several times a year. An AIBOM entry for a retired model is worse than none, because it gives false comfort.

FAQ

Does Anthropic publish an AIBOM for Claude?

Not on the pages we read. Anthropic publishes system cards for each Claude model, a Transparency Hub model report with a short training data description, model IDs and training data cutoffs in its developer docs, and a privacy policy listing training data sources. None of these is a machine readable AIBOM in CycloneDX or SPDX format, and none lists individual datasets.

Does OpenAI publish an AIBOM for GPT models?

Not in the documents we could read. OpenAI publishes system cards with a "Model Data and Training" section, model IDs and knowledge cutoffs in its platform docs, API data usage terms and crawler documentation. None is a machine readable AIBOM with per dataset entries. Several openai.com pages blocked our scripted requests, so check OpenAI's site for anything newer.

What training data do Anthropic and OpenAI say they use?

Both describe categories. Anthropic's recent model entries say a proprietary mix of public online information, public and private datasets, user data and synthetic data, with deduplication and classification filtering. OpenAI's GPT-5 system card says public internet information, data accessed through third party partnerships, and data provided or generated by users, human trainers and researchers, with filtering to reduce personal information.

Is a model card the same as an AIBOM?

No. A model card is human readable documentation of a model's purpose, evaluations and limitations. An AIBOM is a machine readable inventory of the model and its components, including datasets with licences and versions. CycloneDX actually embeds a modelCard object inside an ML-BOM, so a model card can be part of an AIBOM, but not the reverse.

Does the EU AI Act force AI labs to publish their training data?

Not in full. Article 53(1)(d) requires general purpose AI providers to publish a sufficiently detailed summary of training content using the Commission's template. The template asks for size ranges, source categories, main datasets where public or licensed, and top crawled domain names. Fuller technical documentation goes to regulators on request and to downstream providers, not to the public.

Did Anthropic and OpenAI sign the EU General Purpose AI Code of Practice?

The European Commission's Code of Practice page lists both Anthropic and OpenAI as signatories. Anthropic also published a statement on 21 July 2025 that it intended to sign.

Why don't AI companies publish their training datasets?

Neither Anthropic nor OpenAI states a reason on the pages we read. Commonly discussed industry considerations include trade secrets, the scale of web data, security of training pipelines, legal uncertainty about copyright and personal data, and confidentiality terms in data licences. These are general considerations, not statements by either company.

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

No. Training data composition lives inside the provider. Tools can inventory where and how you use a model, scan the software around it and help you test its behaviour, but none can read a closed model's training set. Be wary of any claim that says otherwise.

Is my API data used to train Anthropic or OpenAI models?

OpenAI's platform documentation says API data is not used for training unless you explicitly opt in, as of 1 March 2023. Anthropic's privacy policy describes an opt out for consumer conversations, with exceptions for flagged content and explicit feedback. Check the commercial terms and settings for your own account and record them in your AIBOM.

How should I record unknown training data in CycloneDX or SPDX?

In CycloneDX 1.6, add a data component describing the provider's stated categories, reference it from the model's modelCard.modelParameters.datasets, and add a compositions entry with "aggregate": "unknown" for that component. In SPDX 3, use an AIPackage with informationAboutTraining and a "trainedOn" relationship marked noAssertion for completeness.

Downloads

Direct downloads:

• Download closed-model-aibom-procurement-checklist.md

• Download closed-model-disclosures-vs-aibom-fields.csv

• Download closed-model-ml-bom-example.cyclonedx.json.txt

• closed-model-disclosures-vs-aibom-fields.csv: the field by field table from this post as a spreadsheet, one row per AIBOM field, with what each lab publishes and the source URL for each cell.

• closed-model-ml-bom-example.cyclonedx.json.txt: a complete CycloneDX 1.6 ML-BOM example for one closed model, validated against the official 1.6 schema, with unknown training data marked as unknown. Rename it to .json to use it with tools.

• closed-model-aibom-procurement-checklist.md: the step by step checklist, procurement questions and contract clause starting points from this post in one editable document.

One last point before the remediation options. The AIBOM gap for closed models cannot be fixed from your side, but the software around every model call can. The applications, SDKs, agents and containers that call Anthropic or OpenAI models are built from open source dependencies, and those carry the same vulnerability and upgrade risk as any other code you ship.

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

Connecting a model to your tools is itself a model use you should record in your AIBOM. This demo shows Claude connected to the Safeguard MCP server with OAuth, and choosing which tools Claude can use. The same choices (which model, which tools, which account) are the entries your AIBOM should hold for every assistant integration.

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

This demo is a real Safeguard CLI session: it installs the CLI, opens the interactive terminal, fixes a lodash CVE with approval for each command, and then shows /permissions, /model and /scan .. The /model step is a reminder that assistants let you switch models, so the model in use is a configuration fact worth recording, and /scan . lists the open source dependencies around your AI code.

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

This demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. It suits teams that want to scan repositories that call model APIs without giving an outside service access to the code.

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

To try it yourself, download Safeguard or read the CLI docs.

Quick check

Sources

• Anthropic: Model system cards
• Anthropic: Transparency Hub, Model Report
• Anthropic: Models overview (developer docs)
• Anthropic: Privacy Policy
• Anthropic: Anthropic to sign the EU Code of Practice (21 July 2025)
• OpenAI: GPT-5 System Card (13 August 2025, PDF)
• OpenAI: GPT-4o System Card (PDF)
• OpenAI: Models (platform docs)
• OpenAI: Data controls in the OpenAI platform
• OpenAI: Overview of OpenAI Crawlers
• 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
• CycloneDX: Machine Learning Bill of Materials (ML-BOM)
• CycloneDX 1.6 JSON schema
• SPDX 3.0.1: AI profile
• SPDX 3.0.1: AIPackage class
• SPDX 3.0.1: DatasetPackage class
• OWASP GenAI Security Project: AI Bill of Materials Initiative
• NIST AI 600-1: Generative AI Profile (26 July 2024)

Last reviewed: 23 October 2026.