A consultant finishes an engagement and deletes every AI conversation relating to that client. Tidy, and it feels like closing a file. The harder question arrives a week later from their DPO: what exactly went, and where did it go?
Answering that requires knowing what a chat history is made of, because it is not a file.
It does not live with you
First correction: your conversation history is not on your computer. It is a row in a database at the provider, keyed to your account identifier.
You can observe this two ways. Log in from a different machine and your history is simply there. Clear your browser data and nothing about your history changes. Whatever sits locally is a cache for speed.
The practical consequence: deleting data is always a request to the provider rather than an action you perform. What happens next depends on four layers.
Layer 1: what you see
The conversation list in the sidebar. This is a view, not storage. Delete here and the item is out of sight. That is the only thing you know with certainty.
Layer 2: the database
Beneath the view sits the actual storage: per conversation, a sequence of messages with timestamps, tied to a user id, usually alongside any files you attached.
Deletion in almost every system works in two steps. First a flag ("this row is deleted"), after which it is no longer served anywhere. Then a cleanup job comes through and removes the data for real. At most AI services the gap between the two is around thirty days.
This is not sloppiness. The delay exists so accidental deletions can be recovered and so abuse reported later can still be investigated. It does mean "deleted" and "gone" become true at different moments, and a data subject request lands somewhere in between.
Layer 3: the technical logs
Alongside the conversation, services log its use. Account, timestamp, model, volume of text, error conditions. For API traffic that frequently includes the request payload.
These logs sit apart from your conversation history. They carry their own retention period, they are not visible in the interface, and they do not disappear when you delete a conversation. In a record of processing activities this is a separate activity needing its own basis and period.
Layer 4: the backups
Every serious service takes backups. Yesterday's backup contains the row you deleted today, and that backup is not scanned to honour your deletion. It ages out on its own schedule.
This is standard practice across the software industry and regulators accept it, provided the periods are reasonable and restored data gets re-processed for deletion. It is also why a provider can rarely promise "immediately and everywhere".
When every clock stops
There is one situation in which none of the four layers behave as documented, and it is not hypothetical.
In the New York Times litigation, OpenAI was ordered to preserve output log data that would otherwise have been deleted, including temporary chats and API requests. The preserved data went into a separate, access-controlled system for legal review. Enterprise customers and API customers holding zero-retention agreements sat outside the order.
The lesson generalises. A retention period is a vendor policy operating inside a legal system. While nobody demands otherwise it is honoured. The moment a court demands otherwise it does not apply. That is not a criticism of one provider; it holds for any service subject to a jurisdiction, which is all of them.
Turning this into questions
For a DPIA or an Article 28 negotiation, the four layers produce four questions:
- What is the interval between flagging and permanent removal?
- Which technical logs exist, what do they contain, and how long do they persist?
- Can I configure the retention period, and does it govern the logs as well?
- What is your process on receiving a legal demand or preservation order, and will I be told?
For everyday practice the conclusion is simpler. Deleting afterwards is a decent gesture with a delay, four layers and an exception attached. Text that was never in there needs no cleanup at all, and that is the only part of this entirely within your control.
