Write AI retention copy users trust: store, keep, train, delete

A user types a question into your chatbot and closes the tab. The sentence may be used to train a model after the conversation ends.

A trustworthy retention statement answers that question before the user has to search for it: what is stored, how long it stays, whether it trains models, and how the user deletes it. That statement belongs in the product, not just in the policy.

Retention copy is a product surface

Users rarely read legal text to decide whether to paste a work email, a medical question, or a customer complaint. They look for a short answer near the place where risk starts. If the answer is buried in a subpolicy, the redesign is a visible card or settings row that says the same thing in plain language.

A Stanford team examined privacy policies for six U.S. AI products: Amazon Nova, Anthropic Claude, Google Gemini, Meta AI, Microsoft Copilot, and OpenAI ChatGPT. The researchers reviewed 28 lengthy documents, including privacy policies, subpolicies, FAQs, and chat-interface guidance, for the six products. The six leading U.S. AI companies return user inputs to their models to improve capabilities and gain market advantage. The six companies default to using chat data for model training, and some developers keep such data indefinitely. Among the six companies studied, some provide an opt-out from model training and some do not. That spread is the entry fee for trust: users need to know where your product sits.

Anthropic revised its customer terms so that Claude chats are incorporated into large-language-model training by default, with an opt-out available. A default can be legitimate, but it must be visible, reversible, and easy to understand in the settings screen.

Build the four-part statement before the settings page

Write the statement as a product decision, then place it where the user can act on it. The order follows the way a user reasons: what happened to my input, what happens next, and what I can do.

• Stored data. List the data types: prompts, responses, metadata, files, account identifiers. Make the finished line a sentence a user can repeat: we store your prompts and the time they were sent.
• Retention period. Specify the period for each data type, or say that some records are kept indefinitely. A table or short list works here: messages are kept for the stated period unless you delete them earlier.
• Training use. Say yes, no, or only with consent, and link the exact control. Name the control: your chats are not used for model training unless you turn on model improvement.
• Deletion path. Name the action, the scope, and the delay. Make the path concrete: delete this conversation from the chat list; it is removed from model training within the stated delay.

Do not write we may use data to improve services as a substitute for a training answer. That phrase is the kind of hedge that makes AI data retention feel like a trap. A product that trains on chats must say so, and a product that does not must say that too.

Put the statement in three places: near the input field, in settings, and in the confirmation after deletion. The near-input version should be one or two lines. The settings version can carry the full table. The confirmation version should repeat the deletion scope, because that is when users decide whether to trust the product.

For team or enterprise plans, add the same four answers for workspace data. Users often assume personal settings cover shared channels, documents, and admin exports. Name separate workspace storage when the product has it. Name admin control over training defaults when it exists.

Make deletion a path, not a promise

AI data deletion is the part of the retention statement users test first. A strong deletion path has three properties: it is reachable without support, it says what is removed, and it says what remains. After a user deletes a conversation, they should know whether the text is gone from the interface, from backups, and from model training.

Use the user's words, not the model's. Chat history is clearer than conversation artifacts. Model training is clearer than service improvement. Delete is clearer than purge when the action is available in the interface.

Design the deletion flow around the same four answers. The interface should show the action, the scope, and the expected timing. A confirmation screen can carry the same language as the retention statement, so the user does not have to translate legal prose into product behavior.

Ship the feature when a user can answer the four questions without opening a policy. Otherwise, rewrite the retention line and move the control closer to the input.