Start from the record, not the marketing page
A disclosure is easier to keep accurate when every sentence comes from a record your team has checked. Before writing, collect one record per AI feature: what it does, which model and provider sit behind it, what customer data it touches, and who checked each fact and when.
What a records-based disclosure usually contains
For each feature it covers:
- The feature’s name and what it does for the customer.
- Whether it is on by default, and how customers or their admins control it.
- The model and provider, as your team recorded them.
- Which customer data it processes, and what is never sent.
- How long the provider and your company keep prompts and outputs.
- Whether customer content is used to train or improve models, with the date the setting was checked.
- Human oversight: who reviews, edits or can reject an output.
- Known limitations.
Under the features: Last reviewed (the date and the reviewer’s role), a Limits and open items section listing everything still unconfirmed, and a line saying the page describes current records and is reviewed when a feature changes.
Write each sentence from a field
In the fictional Cedar Cloud Software example, F-01 · Smart Reply records the provider as Northwind Models API, business tier, training on customer content as Off (checked Oct 6, 2026), and retention as 30 days at the provider and 90 days at Cedar. A sentence such as “Smart Reply suggestions are generated by Northwind Models API, business tier; the provider keeps prompts for 30 days” points to those fields. A sentence such as “We never keep your data” does not: the record says 90 days.
Leave out what you cannot support
If a fact is still Unverified, do not state it. Put it under Limits and open items instead. A feature with an unverified provider setting waits: in the example, F-03 · Workspace Summaries is held because provider retention is Unverified for the summary model.
When a feature may involve a decision about a person or business
This feature may involve a decision about a person or business. Record a specialist review (name or role, date) before marking it Customer-ready. The kit does not decide whether any rule applies.
Record who reviewed it (name or role) and the date before the feature appears in a disclosure.
Keep it current
Log the changes that should send a feature back for a check: a new model or provider, a change in which customer data reaches the model, or a change to a retention or training setting. Check the record again, then update the disclosure and its Last reviewed date. A published feature that needs a re-check stops being described as current until the check is done.
Check the draft before it goes out
Read every sentence against the record. Flag any sentence the record does not back, and any that goes further than it. Two examples from the fictional Cedar Cloud draft: “We never keep your data” against 30 days and 90 days retention, and “No third party sees your tickets” against F-01, which sends ticket text to an outside provider.
Do this now
Record one feature
Fill in the one-page starter for one feature with the person who built it. Free. No email.
When you need it on record
AI Feature Record Kit, Software edition
Keep every feature, its evidence, its changes and the reviewed disclosure in one local workspace.
Common questions
Should we publish a disclosure for every AI feature?
That is your team’s decision. This guide covers how to write one from your records when you choose to publish it, and how to keep it accurate afterwards.
What if a provider setting cannot be confirmed yet?
Keep it out of the disclosure, list it under Limits and open items, and hold the feature until someone checks it and records the date.
Can an AI assistant write the disclosure?
It can draft wording from a verified record. Every sentence still has to match a field your team checked, and a person reviews the draft before it is published.
This guide is not legal advice. Your contract, legal and regulatory questions need your normal specialist review.