Publishing a training data transparency disclosure

The content of a training data disclosure gets most of the attention. Placement and maintenance decide whether it works. A disclosure is judged by three practical questions: can a stranger find it, can they read it without talking to anyone, and can they tell whether it is current. All three are operational decisions, and all three are usually made badly.

The decisions below apply whether the driver is the EU requirement for general-purpose model providers to publish a training content summary, a state transparency law, or a customer's own procurement process.

Where it lives

Placement rules that determine whether the disclosure ever gets read:

• A stable public URL, linked from the model's documentation and from the site's legal or trust section. The two places a reviewer will look.
• Reachable without a login, a form or a sales conversation. Anything gated is not a public disclosure.
• HTML rather than a PDF-only document. PDFs change address between revisions and cannot be linked to a section.
• One page per model family, not one page for the whole company. Readers arrive holding a specific model.
• Linked from the security questionnaire responses you send to enterprise customers, so the same facts are maintained once and reused.

What the page carries

Beyond the summary text itself, a working disclosure page carries five elements:

• The summary: what data, from which source categories, on what rights basis.
• The systems the data feeds, by name and version.
• The date of the last review, and the date of the next one.
• A changelog of material changes, with dates.
• A monitored contact point for questions.

What counts as a material change

Update triggers for the changelog:

• A new data category or source type entering the corpus.
• A change in the rights basis for any category, for example, a source moving from licensed to commissioned.
• Expansion to a new language, region or subject population.
• A change in what the model is used for, since the use determines which data questions matter.
• A new supplier or subprocessor that changes where the data is processed.

The update rhythm

Attach the review to model releases rather than to the calendar. A disclosure reviewed in a quiet month documents nothing new; a disclosure reviewed as part of the release checklist documents exactly what changed, while the people who made the change still remember why.

Make it a gate: no public model release ships without a signed-off disclosure update. Gates survive release pressure; good intentions do not. If releases are rare, add a floor (a review at least once a year), so a dormant model does not carry a disclosure from three years ago. Cosmetic edits, such as typos or reordering, do not need a changelog entry; a changelog that records everything stops being read.

Failure modes worth naming

The same four mistakes account for most disclosures that exist but do not work:

• The disclosure exists only as an annex to the enterprise contract, invisible to everyone who is not already a customer.
• The page was written at launch and the model has been fine-tuned repeatedly since, with no corresponding update.
• The page describes the company's commitment to responsible AI and never lists a single data category.
• Every revision gets a new URL, so old references rot and readers find the wrong version.

Who actually reads it

A disclosure written for one reader tends to serve none of them. There are four, and they arrive with different questions.

• A regulator or compliance reviewer is checking whether the required categories are present and whether the rights basis is stated. They read for completeness and for the presence of a date.
• An enterprise procurement team is trying to close a security review. They need something they can attach to a file and cite, which means a stable URL and a version they can reference.
• A researcher, journalist or civil society group is looking for specifics: named source categories, scale, and whether anything is being left out. Vague language reads as evasion to this reader even when it is not.
• An end user is asking one question, usually whether their own content was used. They need the summary in plain language near the top, not a definitional section.

Writing the summary so it is usable

The recurring tension is granularity. Too coarse, and the disclosure says nothing checkable. Too fine, and it discloses commercially sensitive supplier relationships that the company has a legitimate reason to keep.

The resolution that holds up is to name source categories precisely and named sources only where the relationship is public. "Licensed corpora from commercial data providers" is a category; naming the providers is a business decision, not a transparency requirement, and a disclosure that names categories while stating the criteria for inclusion is answering the question that was actually asked.

Two practices make the difference between a disclosure that is read and one that is skimmed. First, put the summary in a table with one row per data category, because a table forces each category to have an entry and makes an omission visible. Second, write the limitations section honestly. A disclosure that states what the corpus does not cover, which languages are thin, and where coverage is known to be weak is more credible than one that only lists strengths, and credibility is the only thing a disclosure has.