Field notes / 02 · Privacy in practice
Chat History, Memory and Training: Three Different Controls
Deleting a conversation, removing a remembered fact and opting out of training answer different questions. Build a category-by-category record before treating any one control as a full reset.
Use a ledger, not one “data” checkbox
| Category | Question that changes your decision |
|---|---|
| Visible chat history | Does the control remove the conversation from the interface, active storage, or both? |
| Saved memory / profile | Are personalization records separate, and can you inspect or remove them? |
| Training or evaluation material | What is included, which organization uses it, and does an opt-out cover future or previous content? |
| Images and voice | Do uploads, recordings and generated outputs follow the same retention rules? |
| Logs and backups | Which records contain content, and what starts their retention clock? |
| Account and support records | Which identifiers, billing records or tickets remain after closure? |
One preference, several possible records
Imagine you type, “Call me Morgan.” The sentence is part of a chat. A service might also store a preferred name in a profile or personalization record. Depending on its documented practices, an interaction could enter other processing workflows. These are possible categories to investigate, not a claim that every app creates all of them.
Removing the visible sentence tells you something about the interface. It does not by itself show what happened to a separate profile field, backup or dataset. Conversely, a companion using a name again does not identify the source: remaining context, a profile or another visible record may explain it. A chatbot’s own answer about storage is not a substitute for documentation or a verified support response.
Read purpose and retention together
Candy.ai’s privacy notice, section 2, describes human review as a possible part of preparing de-identified or anonymized interactions for training. It separately describes a 30-day lifecycle for debugging logs. Those clauses concern different purposes; the log period should not be presented as a universal deadline for all conversations.
Use the structure category → purpose → recipient → retention trigger → control → exception. “Thirty days” is incomplete until the record says thirty days for which category and from which event. If two clauses appear inconsistent, keep both references and ask which governs the data you mean.
When you want a correction rather than an exit
Start with the smallest documented control that fits the goal. To stop an outdated preference shaping replies, look for a personalization control. To remove a conversation, inspect history controls. To limit future training, check the stated scope of the relevant setting. If several categories contain the fact, list each in your request.
Use a fictional preference for any interface check. Record only what you observed: for example, “the memory entry no longer appears in this screen.” Do not call that verified server deletion. If you want to leave entirely, the export and deletion plan handles the broader sequence.
Make it practical
Keep your own record
Download the blank worksheet and fill it in privately. No account or upload is needed; nothing you write in the downloaded file is sent to this site.
Download worksheet · CSVScope: editorial guidance and official documentation checked on September 18, 2026. No in-app deletion tests or infrastructure audit were performed. Illustrative scenarios are fictional. Evidence method · Website privacy