Second installment of our series on security and privacy in legal AI tools. The first post covered the risk of training models on user data. This one covers data retention, specifically the difference between who controls what is kept. The third post will cover encryption of the data that is retained.
Part I: The problem
The question that matters: who decides that data is kept?
When we talk about data retention in AI tools, the conversation usually focuses on how long conversations are stored. That is the wrong metric.
The right question is not how long: it is who decides that they are stored.
There are two fundamentally different retention models:
Provider-controlled retention. The provider stores conversations in its systems to show history to the user, generate system logs, analyze usage, or pursue other purposes of its own. The user may or may not be able to delete the visible history, but the data the provider retains in its backend systems exists independently of what the user does in the interface. While that data exists in the provider's systems, it is under the provider's law, subject to court orders, government requests, and security incidents beyond the user's control.
User-controlled retention. The user actively decides what to keep and what to delete. The provider does not keep logs of conversation content in its own systems. What exists in the system is what the user chose to exist, and when the user deletes it, it is truly deleted.
The difference between the two models may not look technical on the surface, but it has radically different legal and security consequences.
The case that illustrates the risk of provider retention
On February 17, 2026, Judge Jed Rakoff of the Southern District of New York published his opinion in United States v. Heppner, the first federal ruling on confidentiality and conversations with AI.
Bradley Heppner had used a public AI tool to prepare analysis of his defense strategy in a fraud case. He did not make an active decision to save those conversations as a permanent record. He simply used the tool.
The tool, like most AI tools on the market, retained conversation history on its servers by default. When the FBI seized Heppner's devices and investigated his digital activity, those conversations existed in the provider's systems, subject to the same legal jurisdiction as any other data held by a third party.
The judge ordered that they be turned over to the prosecution. Among the reasons for the ruling, one related directly to retention: the tool's privacy policy allowed sharing data with government authorities. The existence of provider-retained data was the vector that made disclosure possible.
If the tool had not retained those conversations in its systems, if the content had not existed on the provider's servers, there would have been no data to order disclosed.
What "logs" means in practice
The concept of "system logs" is technical, but its implications are direct. Software systems keep records of the operations they run. Those records can range from pure metadata (timestamps, resource usage, errors) to the full content of conversations.
On most AI platforms, system logs record at least fragments of conversation content, for debugging, content moderation, or security auditing. Those logs have their own retention periods, often longer than the user's visible history, and they are governed by internal engineering policies that the user neither controls nor, in most cases, even knows about.
The distinction that matters for legal privacy is this: logs that record conversation content are data in the provider's possession. They are data the provider can be compelled to produce. They are data that can be exposed in a security breach. And they are data that exist independently of what the user does in the interface.
The second problem: deleting visible history does not delete backend data
A common misunderstanding among AI tool users is believing that deleting the visible history in the interface equals deleting the data from the system.
On most platforms, it does not.
The history shown in the interface is the presentation layer, what the system chose to show the user. Backend data is the storage layer: the actual records in databases, logs, backup systems, and caches. Deleting visible history often unlinks the conversation from the user's interface without removing it from the underlying storage systems.
This has a direct implication: a user who "deleted" their conversations from an AI tool's interface may have deleted nothing that exists on the provider's servers. And if those servers are the subject of a court order or a security incident, the data may still be available even though the user believed it was gone.
Why provider retention is especially problematic for legal data
Every type of data has a specific risk profile. Legal data has characteristics that make retention not controlled by the user especially problematic:
It is strategically sensitive to adversarial parties. Legal strategy conversations, contractual position analysis, and risk assessments have concrete economic value to the counterparty in litigation or negotiation. An attacker's motivation to access that data scales with that value.
It can be subject to discovery directed at the provider. As Heppner showed, discovery orders can be aimed at the provider directly, not at the lawyer. If the provider retains data, that data is potentially reachable through that channel even if the lawyer never imagined it was possible.
Its confidentiality has specific professional consequences. ABA Model Rule 1.6 requires lawyers to make "reasonable efforts to prevent the inadvertent or unauthorized disclosure" of client information. Using a tool that retains conversation data in provider systems without user control is difficult to reconcile with that standard.
Part II: The solution
The model LexBuddy implements: no logs, with user control
LexBuddy does not implement a zero-retention model in the sense that conversations disappear immediately. Conversations in LexBuddy can be saved, because a lawyer working on a matter for weeks needs to be able to pick up the thread.
What LexBuddy implements is a different model, with two elements that together change the risk architecture:
Element 1: No logs of conversation content
LexBuddy does not maintain system logs that record the content of what users write. The platform's technical logs record operational metadata (timestamps, system states, technical errors), but not the text of conversations.
This has a concrete implication: LexBuddy does not hold in its systems a copy of conversation content that exists independently of the user's will. If LexBuddy received a court order for the content of a user's conversations, there would be no logs to produce, because those logs do not exist.
That is fundamentally different from the situation in Heppner, where the tool held user data in its systems that could be the subject of a disclosure order.
Element 2: The user decides what is saved and when it is deleted
Conversations in LexBuddy can be saved in the user's workspace, because that is functionally useful for legal work. The difference is who controls that decision.
In LexBuddy, the user decides which conversations to keep and which to delete. When a user deletes a conversation, that conversation is deleted from LexBuddy's systems. There are no backend copies that persist after a user deletion. There is no conversation cache that survives the decision to delete.
What exists in LexBuddy's systems is what the user chose to exist. Nothing more.
The difference from the Heppner model
In Heppner, the problem was not that the defendant had chosen to save his conversations as a record. The problem was that the provider saved them by default, regardless of the user's intent, and those conversations remained in the provider's systems subject to the laws governing third-party-held data.
In LexBuddy, the logic is inverted: what exists in LexBuddy's systems exists because the user chose it. And when the user deletes it, it is truly deleted.
That does not automatically create attorney-client privilege. Privilege depends on other legal factors beyond the reach of any technology tool. But it does eliminate the specific vector that made disclosure possible in Heppner: the existence of data in the provider's systems that could be the subject of a disclosure order without the user knowing or being able to prevent it.
What saved conversations need: the role of encryption
User-controlled retention answers the question of who decides what exists. But it raises a second question: when the user does decide to save a conversation, how is it protected?
That question is answered by LexBuddy's encryption architecture, which is the subject of the third post in this series. Conversations the user chooses to keep in their workspace are encrypted with the organization's encryption key, so that not even the LexBuddy team can access their content. User-controlled retention and organization-level encryption are two complementary layers of protection: the first defines who decides what exists, the second protects what exists.
Two questions in sequence: first, does the tool have system logs that record the content of my conversations? And second, if I delete a conversation from the interface, does it disappear from every backend system? If the answer to the first is "yes" or "I don't know," or if the answer to the second is "no" or "we're not sure," the provider retains data over which the user has no real control.
Next in the series: Organization-level encryption and MFA, how what the user chooses to keep is protected.
This article is for informational purposes only and does not constitute legal advice. For guidance specific to your practice, consult a professional-responsibility specialist in your jurisdiction.
Sources
| Source | Link |
|---|---|
| Harvard Law Review Blog: United States v. Heppner | harvardlawreview.org |
| Gibson Dunn: AI privilege waivers, SDNY rules against privilege for consumer AI outputs | gibsondunn.com |
| Akin Gump: SDNY rules that a public AI platform is not protected by privilege | akingump.com |
| Perkins Coie: Heppner and Gilbarco, courts apply privilege and work product to AI | perkinscoie.com |
| ABA: 2024 Legal Technology Survey Report | americanbar.org |
| ABA Formal Opinion 512 (PDF, July 29, 2024) | americanbar.org |
| GDPR: Article 5, principles relating to processing of personal data | gdpr-info.eu |
| GDPR: Article 17, right to erasure | gdpr-info.eu |