How to permanently delete what an AI knows about me?
Deleting a conversation and deleting a memory are two different operations, and in most assistants with a memory feature the first one does not do the second: the transcript is one object, the memory entry extracted from that transcript is another, and erasing the chat leaves what the assistant learned from it sitting in a separate store. So the short answer to "does the AI still remember deleted chats" is usually yes, and the fix is to delete the entry, not the thread. Once you are aimed at the right object, the second question is how deep the delete goes: retrieval is stopped while the row stays, the entry is marked invalid so it no longer feeds new answers while past outputs stay as they were, or the row is actually removed and only backups age out on their own schedule. Most products call all three of these "delete" without saying which one you got, so the reliable move is to test it: store one unique fact, delete it, open a fresh conversation, and ask a question that can only be answered if that fact is still there.
Before asking how permanent a deletion is, ask what it is pointed at. Products use the word delete for three different objects, and which one you hit decides whether anything went away at all.
Reversibility falls off sharply down that list: the first is an ordinary delete, the second is a real delete only if the product built it as one, and the third is a one-way door for practical purposes. So a product whose only control is a single “delete all my data” button has handed you the least useful of the three, because the middle object is the one doing the remembering.
Memory that survives across sessions is not your chat history being re-read. Systems that remember you write a small, separate record at the moment something looks worth keeping — a short statement plus metadata such as where it came from, when it was written, and how sure the system is — and at answer time they retrieve those records instead of replaying everything you ever said. That is what makes long-term memory practical at all: the context window is finite, and reloading full history on every turn is both slow and expensive.
The consequence is the part that rarely makes it into the settings screen. The record is a copy made at write time, so the original transcript stops being load-bearing the moment the copy exists. Deleting the transcript changes what you can read back; it does not change what the assistant can retrieve. The same structure is also what makes precise deletion possible — you cannot remove one fact from an undifferentiated blob, but you can remove one row. Whether a product lets you is a separate question from whether it could. How an AI remembers you across chats covers that layering in more detail.
Support pages are worth reading, but this is cheap enough to just run, on any assistant with a memory feature — ours included.
The criterion is blunt, and you can apply it to any product: if you cannot open the entry, read what it says, and then watch it disappear from that list, you did not delete it — you hid it. An assistant that still answers the sideways question is holding a copy you never reached. From the outside you cannot tell whether that copy is the transcript, a derived summary, or an index that was never rebuilt; you can tell that the confirmation message you were shown was not true.
Be equally clear about what this test cannot see. It says nothing about backups, nothing about whether the text was already used in training, and nothing about copies held by an infrastructure provider. No test run from the outside can reach those. For that part you are relying on what the operator has written down, and on whether they will state it plainly instead of answering a different question.
Once you are aimed at the right object, deletion still comes in depths, and the same word is used for all of them.
None of the three is wrong in the abstract. An organization under a records-retention obligation cannot offer the deepest one for everything, and a user who simply wants the assistant to stop bringing something up is well served by the shallowest. The failure mode is not that products pick a shallow option; it is that all three are labeled with the same word, so someone asking for erasure is given a retrieval filter and shown a confirmation that says deleted. If your test above failed, this is usually where it failed.
“How long do you keep my data” is the first row of a table with several rows, and most help pages answer only that row. Ask about each store separately, because the answer for one says nothing about the others.
Some of this is genuinely unsettled, and a page that pretends otherwise is selling you something.
Backups are the clearest split. One camp holds that data unreachable by the live system is effectively gone, and that forcing erasure through every backup generation buys little for what it costs. The other holds that a copy which can be restored is a copy, full stop. Both are weighing real risks, just weighing them differently. A second split is about past outputs: if an answer was generated using a memory you later delete, some people want that answer retracted too, while others point out that rewriting delivered history is its own kind of dishonesty. And in some jurisdictions retention is not the operator’s choice at all, which caps how much erasure anyone can honestly promise.
The one place we take a firm position is the access log. A deletion that can erase the record of who looked at your data is not a stronger privacy guarantee, it is a weaker one: the log exists to hold the operator accountable to you, and an accountability record that can be wiped is not evidence of anything. So the receipt trail is deliberately not deletable — a trade-off we would rather state out loud than leave looking like an omission.
OneOneTalk (also called 11Talk, two names for the same product) keeps long-term memory as individual entries rather than as a pile of chat logs. Each entry carries four pieces of metadata — source, time, confidence, and scope — and can be viewed, corrected, frozen, restored, or forgotten one at a time.
Forget is the delete. The server removes that row from your memory table, and the copy needed to power undo is handed back to your browser rather than parked in a second place on our side. Freeze is deliberately a different action: the entry is taken out of use without being removed, which is the honest option when you are not sure yet. Correcting an entry replaces its content and records that the change came from you. And when a newer memory supersedes an older one, the older entry’s validity ends that day — it stops being retrieved, and it stays on the record so you can look back at what your twin believed before.
Three limits worth stating plainly, because the section above says you should ask for them. There is no time-based expiry: entries do not fade after a period, and there is no place for you to set a retention window or an expiry date yourself. Scope is metadata you can read, not a dial you can turn — it is shown on every entry, but no screen or endpoint today lets you change it per entry. And what lands in memory is narrower than “everything about you”: entries come from what you said or confirmed in conversation, not from harvesting your files, accounts, or other apps. Deleting one is therefore a small, specific act, which is the only kind of deletion that can be checked.
More on the product in the English overview, and a fuller walk through viewing and correcting entries in Can You Actually View, Correct, and Delete What an AI Remembers?
The public primary material this page is built on. We do not restate their conclusions as our own evidence — they are listed so you can check for yourself.