Deleting a conversation answers one privacy question immediately: can you still see it in your chat history? It does not, by itself, tell you whether the companion can still use a fact from that conversation, whether its provider keeps another copy, or whether the conversation was used to train a model.
Imagine telling a companion about a move you are considering, then deleting that chat. You might want the conversation off your screen. You might also want the companion to stop bringing up the move. Those are different outcomes, and the control that delivers one may not cover the other.
The useful starting point is to split a deletion promise into four questions. This is my framework for evaluating documentation and controls, not a description of every companion’s architecture.
| Layer | Question to ask | What you can check |
|---|---|---|
| Chat history | Has the conversation disappeared from my history? | Open the history and look. |
| Reusable memory | Can the companion still use information from it? | Inspect available memory controls and run a limited behavioral probe. |
| Backend retention | Which copies remain, for how long, and under which exceptions? | Read the provider’s documentation and ask what evidence supports its promises. |
| Training influence | Was the conversation used in training, and what does deletion change? | Check the scope of the training policy. A reply cannot establish what a trained model retains. |
Check what feeds memory
OpenAI’s Memory FAQ gives a concrete example. Its current memory summary does not show everything used for personalization. The documentation tells users removing information to address every source where it appears, including chats, files, the memory summary, and connected apps. Clearing memory does not delete past chats; remaining conversations can supply information again.
The same FAQ describes its legacy saved-memory system separately: saved memories are stored apart from chat history, so a deleted chat can leave a saved memory available for future replies.
These are documented ChatGPT designs, not findings from testing companion apps. The question they suggest is useful anywhere: which sources can still supply the information after this control is used? My memory explainer covers how stored records can be selected and brought into a reply.
Separate retention from training
Anthropic’s consumer data-retention page, dated July 1, 2026, distinguishes immediate removal from chat history from deletion from backend storage within 30 days. It also describes exceptions involving safety flags, legal or dispute obligations, feedback, and anonymized or de-identified data. The standard period is not an unconditional promise about every copy.
The page separately says disabling model improvement or deleting a chat prevents its use in future training. It explicitly excludes training already underway and models already trained from that assurance.
This example concerns Anthropic’s consumer products. It is not the policy for every app using its models, and I have not audited whether the documented operations happen as described.
When reading a companion’s policy, ask separately about retention and training. A training opt-out needs to say which uses it stops. A deletion policy needs to say which records it covers and when removal occurs. Neither answer should stand in for the other.
A refusal cannot certify erasure
A companion that stops mentioning your plan has given you a useful behavioral observation. It has not shown you its provider’s storage systems.
Model-level forgetting poses a different verification problem. In Unlearning Isn’t Deletion, Xu and colleagues report that apparent forgetting could be reversed through minimal fine-tuning in the language-model setups they studied. Their abstract also identifies a case of seemingly irreversible targeted forgetting. The result cautions against treating task-level forgetting scores as sufficient evidence of erasure; it does not establish that unlearning is impossible.
The paper does not test companion delete buttons or establish what any named provider stores. My separate methodological point is narrower: a conversation test observes a response, while a storage-deletion claim concerns records that the chat window does not expose.
A limited probe you can run
Use an existing account and an invented, harmless test fact. Do not use real sensitive information to test privacy. Use this protocol to separate a change in replies from deletion of stored data.
- Record the starting conditions. Note the date, account type, and available memory and training settings. Introduce an unusual fictional name, such as a name for an imaginary pet, and keep a private note of it.
- Establish a baseline. In a fresh conversation, ask for the name without supplying it. If it does not return, record the probe as inconclusive. You have not established recall that a later deletion could change.
- Clear the known sources. Use the documented controls to remove the original conversation and the baseline conversation, which may now contain the name too. Address any other source identified by the documentation, such as a memory entry, summary, file, or connected app.
- Probe again in a fresh conversation. Ask without repeating the name. Record the response and the time since deletion, including any waiting period the documentation specifies.
If the name returns, check for an overlooked source or a hint in your question. A chance match is possible too. The result warrants investigation; it does not identify the storage location or prove that training used the fact.
If the name does not return, you have observed non-retrieval under those conditions. You have not demonstrated that every copy was removed. Keep that limit beside the result, as my methodology requires when separating documented promises from observed behavior.
Ask what a deletion promise covers
Before sharing something you would later need removed, look for answers to these questions:
- Does deleting a chat also remove derived memories, or is there a separate control?
- Which records are covered: conversation history, files, logs, backups, and records held by downstream processors?
- When does deletion happen, and which exceptions extend retention?
- What does opting out change about future training, training underway, and models already trained?
- What completion record or audit evidence can support a deletion request?
If the policy leaves any of these questions open, ask support which copies of a deleted conversation remain and when each one is removed. The reply tells you what the provider promises. It does not verify that those copies were removed. Until you know what deletion covers, keep anything you would need fully erased out of the chat.