Closed Model Training Data: What You Don't Know and Why It Is a Risk

When you buy access to a closed AI model, you get a written description of its training data, not a list. Anthropic and OpenAI both publish system cards that describe data categories, filtering and cut-off dates, but neither publishes a machine-readable, per-dataset bill of materials with sources, licences, versions and provenance. Those gaps become intellectual property, privacy, regulatory, security and behaviour risks that you have to assess, record and accept on purpose.

This guide goes one level deeper than our earlier piece on training data opacity in frontier models. It lists exactly what the two labs say about training data in their own documents, sets that against the fields an AI bill of materials (AIBOM) is designed to hold, maps each unknown to a concrete enterprise risk and to the NIST AI Risk Management Framework, and ends with a step by step process for recording the unknowns and accepting the residual risk. Every fact about Anthropic, OpenAI, the EU and NIST comes from a page linked under Sources.

Key takeaways

• Both labs publish more than many buyers realise: per-model system cards, training data descriptions by category, knowledge cut-off dates, filtering methods and clear policies on whether your business data is used for training.
• What neither publishes is a per-dataset inventory in a standard format such as a CycloneDX ML-BOM or an SPDX 3 AI and Dataset profile. The unknowns are concrete: named sources, licence terms, personal data handling per source, poisoning controls per source, dataset versions and post-training data.
• Each unknown maps to a risk you already manage elsewhere: intellectual property exposure, privacy obligations, regulatory evidence, integrity of the supply chain and silent behaviour change between model versions.
• The EU AI Act's public training-content summary will help, but by the Commission's own description it is "generally comprehensive" and narrative, not technically detailed. It is not an AIBOM.
• NIST AI 600-1 already names the core problem ("Value Chain and Component Integration") and gives specific governance actions, such as contract clauses and supplier risk assessment, that fit a closed model purchase.
• You cannot remove the unknowns, but you can record them honestly in your own AIBOM (CycloneDX lets you mark a composition as unknown), bound the use cases that depend on them, test the model yourself and sign a dated risk acceptance.

What Anthropic and OpenAI do publish about training data

Fairness first. Neither lab is silent about training data, and a buyer who has not read the system cards is working with less information than is freely available. Here is what each lab says in its own published material, quoted sparingly.

Anthropic

Anthropic keeps a system cards index that lists a card for each Claude model, going back to Claude 2 in July 2023 and running to Claude Haiku 5.5 in October 2026. Its Transparency Hub adds a Model Report (dated 2 October 2026 when we fetched it) with a short summary table per model, including a "Training Data" field and, for most models, a "Knowledge Cutoff Date" field.

The Claude Opus 5.5 system card, dated 22 September 2026, describes training data in section 1.1. In summary, it says the model was trained on a proprietary mix of:

• publicly available information from the internet,
• public and private datasets,
• user data included in feedback or bug reports, or which users have explicitly permitted for training,
• other sources, such as synthetic data generated by other models.

The same section says Anthropic used "several data cleaning and filtering methods, including deduplication and classification", that its general-purpose web crawler is called ClaudeBot, that the crawler follows website operators' robots.txt instructions, and that it does not access password-protected pages or pages behind sign-in or CAPTCHA checks. It gives a knowledge cut-off of June 2026.

Older entries in the Transparency Hub are more granular about categories. For Claude Opus 4.6, for example, the hub lists publicly available internet information as of May 2025, non-public data from third parties, data from data-labelling services and paid contractors, data from users who opted in, and data generated internally at Anthropic. The hub also separates two dates for some models: Claude Opus 4 and Claude Sonnet 4 have "a training data cutoff date of March 2025" but a "reliable knowledge cutoff date of January 2025". That distinction matters later in this guide.

On customer data, Anthropic's privacy centre article Is my data used for model training? says that by default it will not use inputs or outputs from its commercial products (Claude for Work, the Anthropic API, Claude Gov and others) to train its models, unless you explicitly report feedback or bugs or otherwise choose to allow it. It says thumbs up or down feedback stores the related conversation for up to five years, de-linked from user and customer IDs. For consumer plans, Anthropic's 28 August 2025 announcement explains that Free, Pro and Max users choose whether their chats and coding sessions are used for training, with five-year retention for those who opt in and the existing 30-day retention for those who do not. The announcement states that the change does not apply to services under its Commercial Terms, including API use through third-party clouds.

OpenAI

OpenAI publishes system cards for its models. The GPT-5 system card, dated 13 August 2025, has a "Model Data and Training" section. 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, "advanced data filtering processes to reduce personal information from training data", and the use of its Moderation API and safety classifiers to keep harmful or sensitive content out.

The earlier GPT-4o system card goes further on categories. It says GPT-4o's text and voice capabilities were pre-trained using data up to October 2023, drawn from select publicly available data "mostly collected from industry-standard machine learning datasets and web crawls", and from proprietary data obtained through partnerships for non-public material such as pay-walled content, archives and metadata. It names key dataset components: web data, code and maths data, and multimodal data (images, audio and video).

On customer data, OpenAI's developer documentation page Data controls in the OpenAI platform says 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 explains that abuse monitoring logs are generated by default and retained for up to 30 days, and that Zero Data Retention and Modified Abuse Monitoring are available to eligible customers after OpenAI's prior approval.

A note on what we could fetch: several openai.com pages refused scripted requests when we checked on 23 October 2026, so the OpenAI facts above come from the system card PDFs on OpenAI's own CDN and from its developer documentation. OpenAI has published system cards for later models too; read the card for the exact model version you use.

Side by side

The last row is the gap this series is about. Our earlier posts on the Claude Opus 4.5 system card and the GPT-5 system card cover the safety evaluations in those documents; here we stay on training data.

What an AIBOM would record that the system cards do not

An AIBOM applies software bill of materials thinking to models and data. Two open standards define the fields, and an OWASP community effort is working on how to apply them.

The CycloneDX ML-BOM capability represents "datasets, models, and configurations for AI and machine learning systems" and "documents provenance and ethical considerations for datasets." In practice a model is a component of type machine-learning-model with a model card section, and each dataset can be a data component with its own provenance, licence and classification. Our CycloneDX ML-BOM 1.7 implementation guide walks through the schema.

SPDX 3.0.1 has two relevant profiles. The AI profile defines an AI package with properties such as informationAboutTraining, limitation, safetyRiskAssessment, standardCompliance, typeOfModel, modelDataPreprocessing and useSensitivePersonalInformation. The Dataset profile defines a dataset package with properties including dataCollectionProcess, dataPreprocessing, datasetAvailability, datasetSize, datasetType, datasetUpdateMechanism, hasSensitivePersonalInformation, anonymizationMethodUsed, confidentialityLevel, intendedUse and knownBias. Our explainer From SBOMs to AI BOMs: SPDX 3.0 covers both.

The OWASP AIBOM Initiative, part of the OWASP GenAI Security Project, describes its aim as operationalising the AIBOM concept with open tooling and measurable completeness assessment. Its repository hosts an open source AIBOM generator.

Put a system card next to those fields and the gap becomes specific:

None of this means the labs have broken a rule. It means the documentation sits at a different level of detail from an AIBOM, and that difference is your risk to manage.

The unknowns, one at a time

The topic of this guide is what you do not know. Here are the six unknowns that come up in every closed model assessment, stated as precisely as the published material allows.

1. Which sources, exactly

You know the categories. You do not know which websites, which licensed collections, which partner archives or which public datasets went in, or in what proportion. Anthropic tells you that its crawler respects robots.txt, which tells you something about how web data was gathered. Neither lab gives you a list you could check against your own content or a known problematic source.

Why it matters: if a specific source later turns out to be a problem (unlicensed, poisoned, withdrawn by its owner, or containing your organisation's leaked documents), you have no way to know whether the model you depend on was exposed to it.

2. Under what licence or legal basis

A per-dataset licence field is basic AIBOM content. The cards describe partnerships and public data but do not state the terms under which each source was used. The EU's training-content template, covered below, is explicitly built to help rights holders exercise their rights, which tells you the legal questions are live enough for a regulator to design a disclosure around them.

Why it matters: your exposure is mostly about outputs, not about the vendor's training. But if a model reproduces protected material and you publish it, you are the one who published it.

3. Whose personal data, and how it was handled

OpenAI says it uses filtering to reduce personal information in training data. Anthropic says it used cleaning and filtering methods and that its crawler does not go behind sign-in pages. Both are meaningful statements. Neither tells you what categories of personal data remained, which jurisdictions it came from, or what anonymisation method applied per source. SPDX's Dataset profile has fields for exactly that (hasSensitivePersonalInformation, anonymizationMethodUsed), which shows the information is considered standard in a full inventory.

Why it matters: data protection rules cover processing, and some regulators and customers will ask how your AI supplier handled personal data. "The vendor says it filtered" is an answer, but a thin one for a high-risk use case.

4. How exposed the data was to poisoning

Data poisoning is a recognised attack class. The OWASP Top 10 for LLM Applications entry LLM04:2025 Data and Model Poisoning describes it as pre-training, fine-tuning or embedding data being "manipulated to introduce vulnerabilities, backdoors, or biases", and notes that a backdoor may leave behaviour unchanged until a trigger appears. NIST's adversarial machine learning taxonomy, NIST AI 100-2 E2025 (March 2025), separates targeted poisoning, backdoor poisoning and clean-label variants. Our data poisoning explainer covers the mechanisms conceptually.

Web-scale data is the hardest to control, because anyone can publish to the web. The labs describe filtering and classification, which helps. What you cannot see is per-source integrity evidence: which sources were verified, which were scraped once and trusted, and what controls applied to synthetic data generated by other models (which the Opus 5.5 card lists as a source).

Why it matters: OWASP's own mitigation advice includes "Vet data vendors rigorously". For a closed model, you are the customer of the data vendor's customer, and you only see the summary.

5. Which cut-off, and what it means

Cut-off dates are published, which is good. But read them carefully. Anthropic's hub separates the date the training data runs to from the date up to which knowledge is "most extensive and reliable" (March 2025 and January 2025 for Claude Opus 4 and Sonnet 4). For Claude Sonnet 4.5 the hub gives a knowledge cut-off of January 2025 while describing internet data "as of July 2025". OpenAI's GPT-4o card gives October 2023 for pre-training data. A cut-off is a range of reliability, not a hard edge.

Why it matters: software dependency advice, regulatory requirements and vulnerability knowledge all go stale. A model asked about a library version or a rule published after its reliable cut-off can answer confidently from older data. That is a behaviour risk you can test for.

6. What happened after pre-training

Post-training (fine-tuning, reinforcement learning, preference data, constitution-guided training) shapes behaviour more directly than pre-training. The cards describe these methods. The GPT-5 card explains that its reasoning models "are trained to reason through reinforcement learning"; the Opus 5.5 card describes post-training aimed at aligning behaviour with Claude's constitution. Neither lists the datasets used in post-training, their sources, or how they changed between versions.

Why it matters: when a new model version behaves differently on your workload, the cause is often post-training. Without a dataset list, the only evidence you will have is your own regression tests.

From unknowns to enterprise risks

This is the core mapping. Each row takes an unknown, the risk it creates, a realistic impact and the NIST AI 600-1 risk category it falls under. NIST AI 600-1, the Generative AI Profile published in July 2024, lists twelve risks unique to or worsened by generative AI.

NIST's definition of the Value Chain and Component Integration risk reads almost like a description of this whole guide: "Non-transparent or untraceable integration of upstream third-party components, including data that has been improperly obtained or not processed and cleaned", along with improper supplier vetting and "other issues that diminish transparency or accountability for downstream users."

Intellectual property risk

The practical question is not whether the vendor had rights to its training data. That is between the vendor, rights holders and courts. Your question is narrower: can output from this model put protected material into something you publish or ship? Training data opacity makes that harder to estimate, because you cannot check whether a particular codebase, book or image collection was in the mix.

Controls that work without the list: restrict high-exposure use cases (verbatim long-form text generation for publication, generating large blocks of code that will be distributed), run licence and similarity checks on code that leaves your organisation, and read the vendor's contract terms on intellectual property and indemnity with your counsel. NIST AI RMF subcategory GOVERN 6.1 asks for policies that address third-party AI risks "including risks of infringement of a third-party's intellectual property or other rights", so this is expected governance, not an exotic precaution.

Privacy risk

Two separate privacy questions get mixed up. The first is what happens to the data you send. That one is well documented: both labs state they do not train on business API data by default, and both document retention. The second is what personal data is already inside the model from training. That one is described only at summary level.

For most enterprise uses the first question matters more, and you can answer it from the vendor's pages and contract. For uses where the model's outputs about people drive decisions (screening, investigations, profiling), the second question matters, and the honest answer is "described, not inventoried". Record that in your data protection impact assessment rather than leaving the field blank.

Regulatory risk

Regulators increasingly expect you to show supplier due diligence for AI. If your organisation deploys a system built on a closed model in a regulated context, you will be asked what you know about the model's data. You can answer with the system card, the EU training-content summary once published, and your own testing. What you should not do is claim knowledge you do not have. Our post on AI-BOMs and EU AI Act Article 10 data governance covers the high-risk system side.

Security risk

Poisoning is the obvious one, but the practical exposure for most teams is narrower than headlines suggest. A poisoned behaviour has to be triggered by your inputs, and it has to cause harm through what your system does with outputs. That points at the controls: limit what the model's output can do on its own (no unreviewed code merges, no unreviewed tool calls with write access), validate outputs that feed automated actions, and keep human review on high-impact paths. Opacity about training data is a reason to treat model output as untrusted input, which is good practice anyway.

Behaviour drift risk

Model versions change. The Anthropic system cards index lists more than twenty cards since July 2023. Each new version brings new training data and new post-training. If your application calls a moving alias rather than a pinned version, behaviour can change under you. Pin model identifiers where the vendor allows it, read the new system card before switching, and run your own regression suite. The training data list would explain why behaviour changed; your tests tell you that it did.

Why the detail is not published: general considerations

Neither Anthropic nor OpenAI, in the pages we fetched, gives a stated reason for not publishing a per-dataset AIBOM. So we do not attribute a reason to either company.

What we can describe are general considerations commonly discussed across the industry, not attributed to any company:

• Trade secrets. Data mix and filtering recipes are widely treated as competitive know-how. The EU Commission's own template, discussed next, explicitly balances disclosure against "the need to protect trade secrets and confidential business information".
• Security of the pipeline. A detailed list of sources and filters could help an attacker target the sources most likely to be ingested.
• Scale. Web-scale crawls cover vast numbers of documents and domains. A per-document inventory is a different engineering problem from a per-package SBOM.
• Legal uncertainty. Questions about text and data mining, copyright and data protection are still being worked through in several jurisdictions, which can make detailed public listings sensitive.

These considerations explain why a gap may persist. They do not remove your need to manage it.

What the EU AI Act summary will and will not tell you

The EU AI Act requires providers of general-purpose AI models to publish a summary of the content used for training. The Commission published an Explanatory Notice and Template for the Public Summary of Training Content on 24 July 2025. According to the notice itself:

• The obligation comes from Article 53(1)(d) of Regulation (EU) 2024/1689 and applies to all providers of general-purpose AI models.
• The rules apply from 2 August 2025. For models placed on the market before that date, providers should publish the summary no later than 2 August 2027.
• The summary should be "generally comprehensive in its scope instead of technically detailed", in narrative form.
• It requires a list of the internet domain names in the top 10% of all domains by size of content scraped (top 5% or top 1,000 domains for small and medium-sized enterprises), plus descriptions of crawlers used, their behaviour and collection periods.
• It does not require work-by-work disclosure, and the AI Office enforces whether the summary complies without checking individual works.

The Commission's General-Purpose AI Code of Practice page describes a voluntary code with three chapters: Transparency, Copyright, and Safety and Security. When we fetched it on 23 October 2026, its list of signatories included both Anthropic and OpenAI. Our earlier post on who signed the GPAI Code of Practice has more background.

So what does that give a buyer?

The summary is a real improvement in what the public can know, especially the domain list. It is not designed to be an AIBOM and the Commission says so.

NIST AI RMF and AI 600-1 mapping

The NIST AI Risk Management Framework 1.0 (January 2023) has subcategories written for third-party AI. AI 600-1 adds generative AI specific actions. Here is how a closed model purchase maps:

The point of the mapping is practical: when an auditor asks how you handled the unknowns in a closed model's training data, these are the controls you point to.

Step by step: assess, record and accept the risk

This is the walkthrough. It assumes you already use one or more closed models and want a defensible record within a week.

Step 1: Find every place you call a closed model

You cannot assess what you have not listed. Start with code. A simple search finds most direct calls:

# Find model identifiers and SDK imports in a repository
grep -rEn --include='*.py' --include='*.ts' --include='*.js' --include='*.go' --include='*.java' \
  -e 'from (anthropic|openai) import' \
  -e 'require\(.(@anthropic-ai/sdk|openai).\)' \
  -e 'model["'\'' ]*[:=]["'\'' ]*[a-z0-9.-]+' \
  . | tee model-calls.txt

# Find environment and config files that name endpoints or models
grep -rEn -e 'api\.(anthropic|openai)\.com' -e 'MODEL(_ID|_NAME)?=' \
  --include='*.env*' --include='*.yaml' --include='*.yml' --include='*.json' --include='*.toml' . \
  | tee -a model-calls.txt

Also check cloud consoles for managed model services, and ask teams about SaaS tools with embedded AI features. Those do not show up in your code.

Step 2: Pin versions and record them

For each call site, record the exact model identifier, the provider, the endpoint and whether you call a pinned version or an alias. Change aliases to pinned identifiers where your provider supports that, so behaviour changes only when you decide.

Step 3: Collect the published documentation per model

For each pinned model, save the system card URL and date, the knowledge or data cut-off, the training data description quoted from the card, and the data usage and retention terms that apply to your plan. Save copies with a retrieval date. Pages change, and your record should show what you relied on.

Step 4: Write the AIBOM entry with the unknowns marked

Record what is knowable, and mark what is not. CycloneDX lets you state that a component's composition is unknown, which is the honest way to describe a closed model's training data. Here is a minimal example for one model you call through an API:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-23T00:00:00Z",
    "component": { "type": "application", "name": "support-assistant", "bom-ref": "app" }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model-vendor-a",
      "name": "vendor-a-model",
      "version": "pinned-model-id-2026-09",
      "supplier": { "name": "Vendor A" },
      "externalReferences": [
        { "type": "documentation", "url": "https://example.com/vendor-a/system-card.pdf", "comment": "System card, retrieved 2026-10-23" }
      ],
      "modelCard": {
        "modelParameters": {
          "task": "text-generation",
          "datasets": [ { "ref": "training-data-vendor-a" } ]
        },
        "considerations": {
          "technicalLimitations": [
            "Training data described by category only in the system card",
            "Reliable knowledge cut-off per vendor: 2026-06"
          ]
        }
      },
      "properties": [
        { "name": "internal:training-data-disclosure", "value": "narrative-categories" },
        { "name": "internal:business-data-used-for-training", "value": "no-by-default-per-vendor-policy" },
        { "name": "internal:risk-acceptance-id", "value": "RA-2026-014" }
      ]
    },
    {
      "type": "data",
      "bom-ref": "training-data-vendor-a",
      "name": "vendor-a-training-data",
      "description": "Vendor-described mix: public web, licensed and private datasets, opted-in user data, synthetic data. No per-dataset list published."
    }
  ],
  "services": [
    {
      "bom-ref": "svc-vendor-a-api",
      "provider": { "name": "Vendor A" },
      "name": "vendor-a-inference-api",
      "endpoints": [ "https://api.example.com/v1/messages" ],
      "data": [ { "flow": "bi-directional", "classification": "customer-support-tickets" } ]
    }
  ],
  "compositions": [
    { "aggregate": "unknown", "assemblies": [ "training-data-vendor-a" ] }
  ]
}

The compositions entry with "aggregate": "unknown" is the key line. It tells anyone reading the BOM, and any tool, that the contents of that dataset component are not known, rather than implying the description is complete. Use your real vendor names, model identifiers and system card URLs in your own file.

In SPDX 3, the equivalent is an AI package whose informationAboutTraining and limitation properties carry the vendor's description, with a dataset package that has no per-source detail. Here is a fragment in the JSON-LD serialisation:

{
  "type": "ai_AIPackage",
  "spdxId": "urn:example:model-vendor-a",
  "name": "vendor-a-model",
  "software_packageVersion": "pinned-model-id-2026-09",
  "ai_informationAboutTraining": "Vendor system card describes a proprietary mix of public web data, public and private datasets, opted-in user data and synthetic data. No dataset list published.",
  "ai_limitation": "Reliable knowledge cut-off 2026-06 per vendor. Training data sources, licences and per-source personal data handling unknown.",
  "ai_useSensitivePersonalInformation": "noAssertion"
}

Check property names against the SPDX 3.0.1 model pages linked under Sources before you validate your file, since serialisation prefixes differ between tools.

Step 5: Check the BOM for unrecorded unknowns

A small check keeps this honest over time. This script lists every model component that has no documentation link or no linked composition statement:

jq -r '
  .compositions as $c
  | .components[]
  | select(.type == "machine-learning-model")
  | . as $m
  | {
      name: $m.name,
      version: $m.version,
      has_doc: ([$m.externalReferences[]? | select(.type == "documentation")] | length > 0),
      datasets: [$m.modelCard.modelParameters.datasets[]?.ref]
    }
  | .unknown_marked = ([.datasets[] as $d | $c[]? | select(.assemblies | index($d))] | length > 0)
  | select((.has_doc | not) or (.unknown_marked | not))
  | "\(.name) \(.version): doc=\(.has_doc) composition_recorded=\(.unknown_marked)"
' aibom.cdx.json

Run it in CI so a new model cannot be added to the BOM without a documentation link and an explicit statement about what is known.

Step 6: Classify each use case by how much the unknowns matter

Not every use case carries the same exposure. Use a simple decision table:

Step 7: Send the procurement questions

Ask the vendor what is not on the public pages. Keep the questions specific and answerable:

1. Which system card and training-content summary apply to the exact model identifier we use?
2. Can you provide, under NDA, a list of dataset categories with approximate proportions and any third-party licensed sources?
3. What personal data controls apply to training data, by category?
4. What integrity controls apply to externally sourced and synthetic training data?
5. How much notice do you give before retiring a pinned model version, and where are changes announced?
6. Is our data used for training under our plan, and how do we confirm the setting?
7. What retention applies to our inputs and outputs, and which options reduce it?
8. What intellectual property commitments apply to outputs under our contract?
9. Who do we contact about a suspected data or model integrity issue, and what is the response time?

Some answers will be "we do not disclose that". Record the answer verbatim and its date. A documented "not disclosed" is an input to risk acceptance; a missing answer is a gap in your file.

Step 8: Add contract clauses that match AI 600-1

NIST AI 600-1 action GV-6.1-004 calls for contracts and SLAs that "specify content ownership, usage rights, quality standards, security requirements, and content provenance expectations", and GV-6.1-006 for clauses that "allow an organization to evaluate third-party GAI processes and standards". In plain contract terms, ask your counsel to consider: notice of material model changes, a minimum support period for pinned versions, a commitment to provide regulatory training-content summaries when published, data usage and retention terms in the contract rather than only on a web page, security incident notification, and intellectual property terms for outputs. Whether a vendor accepts them is a commercial question.

Step 9: Test the model yourself

Your evaluation suite is the evidence the training data list would otherwise give you. Build a small set of prompts from your real workload, with expected properties of the answer, and run it on every model version change. Include:

• Cut-off probes: questions about facts in your domain that changed after the model's published reliable cut-off. You want to see whether it hedges or answers confidently with stale data.
• Memorisation probes: prompts that would surface your organisation's confidential identifiers or text if they had leaked into training data. A clean result proves little; a hit is important.
• Domain behaviour checks: formatting, refusal behaviour and accuracy on the tasks you actually run.

A minimal runner can be a few lines:

import json, sys, datetime

def run(cases, call_model, model_id):
    results = []
    for case in cases:
        out = call_model(model_id, case["prompt"])
        passed = all(token.lower() in out.lower() for token in case.get("must_include", [])) and \
                 not any(token.lower() in out.lower() for token in case.get("must_not_include", []))
        results.append({"id": case["id"], "passed": passed})
    return {
        "model": model_id,
        "run_at": datetime.datetime.utcnow().isoformat() + "Z",
        "pass_rate": sum(r["passed"] for r in results) / len(results),
        "results": results,
    }

if __name__ == "__main__":
    cases = json.load(open(sys.argv[1]))
    # call_model is your own wrapper around the vendor SDK
    from my_llm_client import call_model
    print(json.dumps(run(cases, call_model, sys.argv[2]), indent=2))

Store each run's output next to the AIBOM entry for that model version. When the version changes, compare.

Step 10: Sign a dated risk acceptance

Write down, for each model and use case: what is known (with links), what is unknown, the controls in place, the residual risk, who accepts it and when it will be reviewed. Review triggers should include a new model version, a new system card, the vendor's EU training-content summary becoming available, a material change in the vendor's data terms, or a new use case. The downloadable worksheet below follows this structure.

Where Safeguard fits, and where it does not

Be clear about the limit first: Safeguard cannot see inside any vendor's training data, and nothing in this guide should be read as a way to discover what a closed model was trained on. Only the vendor knows that.

What Safeguard's AI-BOM discovery does, in early access today, is inventory your own use of AI: SDK imports in code, managed model services in cloud accounts, AI features in SaaS tools and vector databases, and it emits the result as a CycloneDX ML-BOM or SPDX AI profile document. That covers Step 1 and much of Steps 2 and 4 above, the part of the problem you can actually see. The unknowns about the vendor's data still have to be recorded by hand, using the vendor's own documents, and accepted by a person in your organisation. The software around your model calls (SDKs, frameworks, container images) is ordinary open source supply chain, and that is where Safeguard's generally available scanning and remediation apply.

Common mistakes

• Treating "not used for training" as the whole story. It answers what happens to your data. It says nothing about what is already in the model.
• Leaving training data fields blank in the AIBOM. A blank looks like an omission. Record "described by category only" and mark the composition as unknown.
• Calling a moving alias in production. You lose the link between a behaviour change and a documented version.
• Reading the knowledge cut-off as a hard edge. Some cards give both a data cut-off and a reliable knowledge cut-off. Use the earlier one when you plan tests.
• Expecting the EU summary to be an AIBOM. The Commission describes it as narrative and not technically detailed. Plan for that.
• Attributing motives. Your risk file should say what is and is not published, not why. Speculation does not help an auditor and is unfair to the vendor.
• Accepting risk once and forgetting it. Model versions change several times a year. Tie the acceptance to version changes and a calendar date.
• Giving model output write access without review. Opacity about training data is the clearest reason to treat output as untrusted input.
• Assuming one model's card covers another. Training data descriptions differ by model and version. Read the card for the exact identifier you call.

FAQ

Do Anthropic and OpenAI publish what their models were trained on?

They publish descriptions, not lists. Both publish system cards that describe training data by category (public web data, licensed or partner data, user data that is permitted for training, and, for Anthropic's recent cards, synthetic data), along with filtering methods and cut-off dates. Neither publishes a per-dataset, machine-readable AIBOM.

Is my company's data used to train Claude or GPT models?

According to each vendor's own pages, not by default for business use. Anthropic says it does not use inputs or outputs from its commercial products for training by default, unless you submit feedback or opt in. OpenAI says API data has not been used for training since 1 March 2023 unless you opt in. Check the terms for your specific plan.

What is an AIBOM and how is it different from a model card?

An AIBOM is a structured inventory of a model's components and data, in a standard format such as CycloneDX ML-BOM or SPDX 3 with the AI and Dataset profiles. A model card or system card is a human-readable document about a model's capabilities, evaluations and limitations. A card can feed an AIBOM, but it is not one. See our AIBOM FAQ for more.

Why is unknown training data an enterprise risk?

Because it leaves questions about intellectual property, personal data, integrity and behaviour that you cannot answer from the vendor's documents. NIST AI 600-1 names this "Value Chain and Component Integration" risk and expects organisations to manage it through supplier assessment, contracts and testing.

Will the EU AI Act force labs to publish full training data lists?

No. The Commission's template requires a public summary that is "generally comprehensive in its scope instead of technically detailed", including the top 10% of scraped domains by content size and narrative descriptions of other sources. It does not require work-by-work or dataset-by-dataset disclosure.

Did Anthropic and OpenAI sign the EU GPAI Code of Practice?

The Commission's Code of Practice page listed both Anthropic and OpenAI among signatories when we checked on 23 October 2026. Check the page for the current list.

Can a closed model be poisoned through its training data?

Data poisoning is a recognised attack class, described by OWASP (LLM04:2025) and in NIST AI 100-2. Labs describe filtering and classification of training data. As a customer you cannot verify per-source integrity controls, so treat model output as untrusted input and keep human review on high-impact actions.

How do I record a closed model in my AIBOM if I do not know its training data?

Create a model component with the exact version, supplier and system card link, a data component carrying the vendor's description, and a CycloneDX compositions entry with "aggregate": "unknown" for that data component. In SPDX 3, use the AI package's informationAboutTraining and limitation properties.

What should I ask an AI vendor about training data?

Ask which documents apply to your exact model version, what can be shared under NDA about categories and licensed sources, what personal data and integrity controls apply, how much notice you get before version retirement, how your own data is used and retained, and what intellectual property terms cover outputs. Record each answer and its date.

Can Safeguard tell me what a closed model was trained on?

No. Safeguard's AI-BOM discovery, in early access, inventories where and how your organisation uses models. Only the vendor knows what its training data contains.

Downloads

Three companion files go with this guide:

• closed-model-risk-register.csv: a risk register template with one row per unknown (sources, licences, personal data, poisoning, cut-off, post-training and more), with risk, impact, mitigation, owner and NIST AI RMF and AI 600-1 mapping.
• closed-model-risk-acceptance-worksheet.md: a one-page risk acceptance worksheet covering what is known, what is unknown, controls, residual risk, sign-off and review triggers.
• closed-model-vendor-questions-and-aibom-entry.md: the procurement questions and contract clause checklist from Steps 7 and 8, plus the CycloneDX and SPDX entries from Step 4 with the training data marked unknown.

Direct downloads:

• Download closed-model-risk-acceptance-worksheet.md
• Download closed-model-risk-register.csv
• Download closed-model-vendor-questions-and-aibom-entry.md

Training data opacity is a model supply chain problem, and the software that wraps every model call is a supply chain problem too: the SDKs, frameworks, vector database clients and container images in your AI services are open source components with their own vulnerabilities. That part you can fix today, and this is how Safeguard helps with it.

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

None of these demos shows a vendor's training data, because no tool can. They show the parts of this guide you control: your AI tooling's access, the dependencies around your model calls, and scanning on your own machine.

This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is the same principle as Step 6 above: when you cannot see inside a model, you decide exactly what it is allowed to do.

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

This demo is a real Safeguard CLI session. You ask it to fix the lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow applies to the SDKs and frameworks in the services that call your models.

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

This demo sets up the Safeguard runner on your own machine, approves it with a device code and scans from the terminal. Use it to scan the repositories you found in Step 1 without giving repository access to anything else.

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

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

Quick check

Sources

• Anthropic: Model system cards index
• Anthropic: Transparency Hub, Model Report
• Anthropic: System Card, Claude Opus 5.5 (22 September 2026)
• Anthropic Privacy Center: Is my data used for model training? (commercial products)
• Anthropic: Updates to Consumer Terms and Privacy Policy (28 August 2025)
• OpenAI: GPT-5 System Card (13 August 2025)
• OpenAI: GPT-4o System Card
• OpenAI: Data controls in the OpenAI platform
• European Commission: Explanatory Notice and Template for the Public Summary of Training Content (24 July 2025)
• European Commission: Explanatory Notice and Template, English PDF
• European Commission: The General-Purpose AI Code of Practice
• NIST AI 100-1: AI Risk Management Framework 1.0 (January 2023)
• NIST AI 600-1: Generative AI Profile (July 2024)
• NIST AI 100-2 E2025: Adversarial Machine Learning taxonomy (March 2025)
• OWASP: LLM04:2025 Data and Model Poisoning
• OWASP GenAI Security Project: AIBOM Initiative
• OWASP AIBOM repository
• CycloneDX: Machine Learning Bill of Materials (AI/ML-BOM)
• SPDX 3.0.1: AI profile
• SPDX 3.0.1: Dataset profile

Last reviewed: 23 October 2026. Vendor documentation and EU guidance change often; check the linked pages for the current versions.