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.