![[Valid RSS]](valid-rss-rogers.png "Validate my RSS feed")
On February 10, 2026, Judge Jed Rakoff of the Southern District of New York issued a ruling in *United States v. Heppner* that should fundamentally change how every lawyer thinks about AI and confidentiality.
The defendant had used a consumer AI tool to generate documents related to a pending criminal investigation. The government moved to compel production, arguing the documents weren't privileged. Judge Rakoff agreed, ruling that neither attorney-client privilege nor the work product doctrine protected the AI-generated materials.
The reasoning was surgical.
The defendant had "disclosed it to a third-party, in effect, AI, which had an express provision that what was submitted was not confidential."
The AI tool's own privacy policy - which permitted the use of inputs for model training and allowed disclosure to third parties - was the basis for finding that the confidentiality requirement for privilege had been destroyed.
This is a case of first impression on what Judge Rakoff called a "nationwide" question: whether communications with a publicly available AI platform during a pending legal matter are protected by privilege.
The answer, as of February 2026: no.
"Just Opt Out of Training. Problem Solved."
Within days of the Heppner ruling, the most common response was: this is a consumer AI problem, not an enterprise one. Anthropic's enterprise and API tiers don't train on customer data - it's the default, not even an opt-out. OpenAI Enterprise is the same. Even on consumer plans, you can disable training with a checkbox.
And the second pushback followed close behind: if disclosing information to an AI tool waives privilege, then every lawyer who's ever used Gmail, Google Drive, or iCloud to communicate with a client has the same problem. The Harvard Law Review noted that Judge Rakoff "assumed sub silentio that Claude was more like a non-attorney human than a tool." Jennifer Ellis put it more bluntly: "If I type my thoughts into a software platform run by a third party, that is not privileged. Nothing about that analysis changes because the platform is labeled 'AI.'"
These are serious arguments. And on the training point specifically, they're right, the "your data trains the model" fear is largely a solved problem for anyone using enterprise AI tiers or checking the opt-out box.
But I think the training argument was always a red herring.
The real privilege question was never "will they train on my data?" It's more fundamental than that, and it applies even when training is completely off the table.
When you opt out of training, or use an enterprise tier that never trains on your data, here's what still happens:
Similar carve-outs exist in cloud storage agreements too. Google can access your Google Docs for abuse detection. Microsoft's enterprise agreements include similar exceptions. And courts have been fine with cloud storage and privilege for 15 years, provided reasonable enterprise agreements are in place.
So why should AI be different? It May Not Be, But We Don't Know Yet
The "Google Docs has the same problem" argument has real force. And if I'm being intellectually honest, there's a plausible future where courts treat enterprise AI tools exactly like cloud storage, as passive technology intermediaries whose role doesn't affect the privilege analysis, provided proper contractual safeguards exist.
But that future doesn't exist yet. And the present is dangerously uncertain.
Here's the critical difference: cloud storage has decades of case law establishing that privilege survives third-party hosting with reasonable enterprise agreements. Courts have addressed the question, developed frameworks, and created predictable outcomes. A lawyer using Google Workspace with a proper enterprise agreement can point to years of precedent supporting privilege preservation.
AI has two rulings from the same week in February 2026 that reached opposite conclusions.
On February 17, 2026, the same week Judge Rakoff issued his written Heppner opinion, Magistrate Judge Anthony Patti in *Warner v. Gilbarco* (E.D. Mich.) reached the opposite conclusion. A pro se litigant had used ChatGPT to help draft legal arguments. Judge Patti held that the AI-assisted work product was *protected*, treating the AI as a tool (like a word processor) rather than a third party capable of receiving confidential information.
The National Law Review published an analysis titled "Same Week, Different Frameworks" and concluded that the two courts adopted "incompatible frameworks for how AI tools relate to privilege and work product doctrine." Both courts may be correct on their specific facts:
- **Heppner** involved a criminal defendant using a consumer AI tool *without counsel's direction*, where the tool's privacy policy permitted training and third-party disclosure. No attorney-client relationship was mediated through the AI.
- **Warner** involved a pro se litigant who functioned as her own counsel, using AI as a drafting assistant. The court didn't engage with ChatGPT's terms of service at all.
The key variables that determined the different outcomes: (1) whether an attorney directed the AI use, (2) whether the court characterized AI as a "tool" or a "third party," and (3) whether the court examined the AI provider's privacy policy.
An enterprise AI agreement with no-training clauses and a Data Protection Addendum addresses several of these factors. The National Law Review article specifically called enterprise-grade terms "the two strongest available defenses." But it also noted: "An enterprise license without documentation infrastructure is effectively compliance theater, not privilege protection."
Let's frame this as a practical question rather than a doctrinal one.
If you're a law firm using an enterprise AI tool with no-training agreements, strong contractual confidentiality protections, and attorney-directed workflows, you probably have a defensible position on privilege. Reasonable lawyers can disagree, but the enterprise safeguards meaningfully reduce risk.
But "defensible" is not the same as "settled." Consider the position you're actually in:
The privilege debate focuses almost entirely on client data - party names, deal terms, dollar amounts. But there's a second category of confidential information flowing into AI tools that receives almost no attention: your firm's own intellectual property.
When a firm configures an AI tool for contract review, it doesn't just feed in the contract. It feeds in the *framework for evaluating that contract*: playbooks, clause libraries, negotiation positions, risk thresholds, fallback language, escalation criteria. These are the artifacts of institutional knowledge - what a senior partner knows about how to negotiate an indemnification cap, what position to take on limitation of liability, when to push back on a governing law clause and when to concede.
This institutional knowledge is, for most firms, their primary competitive asset. It's what clients pay for. It's what takes decades to develop. And it's being uploaded wholesale into AI systems as system prompts, custom instructions, and configuration files.
Consider what's actually being transmitted:
This isn't client data. It's the firm's trade secret. And it's subject to the same retention carve-outs, safety monitoring, and third-party access provisions as any other input to the AI system.
You can replace "Acme Corp" with "PARTY_A" in a contract clause, but you can't pseudonymize a playbook that says "our standard position on consequential damages exclusions is..." because the position itself *is* the confidential information. The content is the IP, and the AI needs to read it in full to apply it.
There's also a technical vulnerability that compounds the risk: system prompt leakage. Security researchers have extensively documented techniques for extracting system prompts from LLMs through adversarial inputs. A counterparty, or anyone with access to the AI tool, could potentially craft prompts that cause the system to reveal the firm's playbook instructions, negotiation parameters, or fallback positions. The system prompt is treated as confidential by the AI provider, but it is not architecturally protected from extraction.
This creates an uncomfortable question: if your firm's playbooks, clause libraries, and negotiation strategies are sitting in an AI provider's infrastructure - subject to safety monitoring, retention carve-outs, and potential prompt extraction - are you protecting client data while inadvertently exposing the institutional knowledge that is your firm's competitive moat?
The firms that think most carefully about AI confidentiality are asking not just "is my client's data protected?" but "is my firm's knowledge protected?" These are different questions with different answers, and the second one is getting almost no attention.
This Isn't Theoretical. Look at the last Week of Mar 26.
Everything we've argued so far could be dismissed as hypothetical risk. "Sure, these attacks are *possible*, but our vendor has strong security practices. The chance of an actual breach is low."
Then look at what happened in the last week of March 2026 - not to fringe startups, but to the AI infrastructure that enterprise legal teams rely on.
Three incidents. Three different attack surfaces. Three reminders that the security of AI infrastructure depends not just on the provider's policies, but on an entire chain of dependencies - npm packages, PyPI libraries, cloud storage configurations, build pipelines, and human operators - any one of which can fail.
The Claude Code leak is particularly relevant to the playbook argument. If Anthropic's own internal system prompts can leak through a packaging error, what about the system prompts that encode your firm's negotiation playbook? The same category of data, instructions that tell the AI how to behave - was exposed not through a policy failure, but through operational error. No amount of contractual protection prevents a misconfigured build script.
And the LiteLLM compromise goes further. Even if you trust your AI provider completely, your data flows through middleware, proxy libraries, and infrastructure dependencies that your vendor doesn't control. A compromised library in the request pipeline can intercept everything - your prompts, your playbook instructions, your contract text - before it ever reaches the AI provider's secured infrastructure. Your enterprise agreement with Anthropic or OpenAI doesn't cover what happens in the libraries between you and them.
These aren't edge cases. They happened in a single week, to companies with sophisticated security teams and enterprise-grade infrastructure. The question isn't whether your AI provider's policies are good. The question is whether the entire operational chain, from your keyboard to the model and back, is immune to human error, supply chain attacks, and infrastructure misconfiguration.
The answer, as of this week, is clearly no.
There's an alternative that doesn't require you to navigate any of this uncertainty.
If the privileged content never reaches the AI provider in the first place: if party names, deal terms, dollar amounts, and identifying details are replaced with consistent pseudonyms before anything leaves your environment, then the privilege analysis never arises. There's no third-party disclosure to evaluate. No privacy policy to parse. No enterprise agreement to defend. No framework conflict between Heppner and Warner to navigate.
Instead of asking "does our enterprise AI agreement adequately protect privilege?" GC's should be asking "why are we sending privileged text to a third party at all, when we don't have to?"
This isn't about fear. Enterprise AI agreements are a meaningful step forward from consumer use, and firms using them are acting responsibly. But there's a difference between a defensible position and an unassailable one. In a profession built on reducing risk for clients, the stronger position is the one where the question simply doesn't come up.
Walk into any legal technology conference in 2026 and the AI privacy conversation follows a predictable script.
Vendor: "We're SOC2 Type II certified, ISO 27001 compliant, and all data is encrypted at rest and in transit with AES-256."
Buyer: "Great. We're comfortable."
This exchange misses the point entirely. SOC2 and ISO 27001 certify that a vendor's infrastructure follows security best practices - access controls, audit logging, incident response. They protect the pipe. But they say nothing about what travels through it.
The Heppner ruling isn't about infrastructure security. It's about a more fundamental question: did privileged information leave the client's control and reach a third party?
If the answer is yes, and for the vast majority of legal AI tools on the market today, it is, then the security certification of the receiving party is legally irrelevant to the privilege analysis. You've made a third-party disclosure. The privilege question turns on whether that disclosure was protected by a reasonable expectation of confidentiality, and whether the third party's terms support that expectation.
Most AI providers' terms don't.
The American Bar Association anticipated this issue. In July 2024, the ABA Committee on Ethics and Professional Responsibility issued Formal Opinion 512, titled "Generative AI Tools."
The opinion applies existing Model Rules - particularly Rule 1.6 (Confidentiality of Information) - to lawyers' use of generative AI. The core requirement: lawyers must make "reasonable efforts to prevent the inadvertent or unauthorized disclosure" of client information when using AI tools.
The opinion spells out what "reasonable efforts" means in this context:
Most commentary on Opinion 512 focused on the first point - training data. But the second and third points are far more consequential. They draw a distinction between securing data that a third party holds (encryption, access controls) and ensuring the third party never holds it at all.
The Heppner ruling enforced exactly that distinction.
The legal profession knows this is a problem. The data is unambiguous:
There's a striking gap between awareness and action. Lawyers know confidentiality is at risk. They don't know what the architecturally sound alternative looks like.
When a legal AI tool needs to process contract text that contains privileged or confidential information, there are fundamentally three architectural approaches:
Most legal AI tools send the full text of your document - party names, deal terms, dollar amounts, matter details - to an LLM provider's API. The text is processed, and the response is returned.
Security certifications protect this text in transit and at rest. Enterprise agreements may include provisions against using the text for model training. But the text still reaches the AI provider's servers in readable form. A human or automated system at the provider could, in theory, access it.
This is the architecture Judge Rakoff ruled against. The provider's privacy policy permitted third-party disclosure. The privilege was waived.
Even with enterprise agreements that are more restrictive than consumer terms, the fundamental structure is the same: privileged text leaves your environment and reaches a third party. The legal defensibility of this approach now has a court ruling working against it.
Some tools attempt to solve this by redacting sensitive information before sending text to the AI. Party names are removed. Dollar amounts are stripped. Identifying details are blanked out.
The problem is that redaction is inherently lossy. Consider this clause:
> "[REDACTED] shall indemnify [REDACTED] for all claims arising from [REDACTED]'s breach of the representations set forth in Section [REDACTED], up to a maximum liability of [REDACTED]."
The AI has almost nothing to work with. It can't evaluate whether the indemnification is mutual or one-sided. It can't assess whether the liability cap is reasonable relative to the deal size. It can't identify which party bears which risk.
Redaction preserves confidentiality at the cost of destroying the semantic context that makes AI analysis valuable. You've protected the text by making it useless.
The third approach replaces sensitive entities with consistent, meaningful placeholders before the text leaves your environment:
> "PARTY_A shall indemnify PARTY_B for all claims arising from PARTY_B's breach of the representations set forth in Section 4.2, up to a maximum liability of AMOUNT_1."
The AI can now reason about the full clause structure. It understands the indemnification is one-sided (PARTY_A indemnifies PARTY_B). It can evaluate the clause against your playbook's standards. It can suggest a redline that makes the indemnification mutual or adjusts the liability cap.
But the actual party names, the real dollar amounts, the specific section references that identify the deal - none of that ever left your environment. A mapping table (PARTY_A = Acme Corp, AMOUNT_1 = $5,000,000) is maintained locally. When the AI's response comes back with placeholder references, you remap them to the real entities on your side.
The result: the AI gets full semantic context. Your privileged information stays with you. And if a court ever examines what was transmitted to the AI provider, it finds pseudonymized text that reveals nothing about the parties, the deal, or the matter.
This is the architecture that most fully satisfies ABA Opinion 512's "reasonable efforts" standard. There's nothing privileged to disclose - because nothing privileged was ever transmitted.
Effective pseudonymization requires more than simple find-and-replace. Contract text contains confidential information in multiple forms:
- Named entities: Party names, individuals, organizations, locations - detectable through Named Entity Recognition (NER) models trained on legal text.
- Structured data: Dollar amounts, dates, email addresses, phone numbers, tax identification numbers - capturable through regular expressions and pattern matching.
- Organization-specific terms: Project codenames, product names, matter IDs, internal references - only identifiable through custom dictionaries maintained by each client.
A robust moderation layer combines all three detection methods. NER catches what regex misses (variations in how parties are named). Regex catches what NER misses (structured identifiers that don't look like entities). Custom dictionaries catch what neither can detect (the internal codename for a deal that appears nowhere in public data).
The result is a multi-layer detection architecture where each layer covers the gaps left by the others.
Read our detailed approach here: https://www.contractken.com/moderation-layer
The Heppner ruling is a leading indicator, not an isolated event. Several forces are converging:
If you're a lawyer using AI tools on client matters, or a client whose lawyers might be, here are three questions that matter more than any security certification:
If the answer to #1 is yes and the answer to #2 is "trust our enterprise agreement," the Heppner ruling just told you what a court thinks about that reasoning.
---
Sources
Review & redline third party drafts, compare redlined drafts and create new drafts using your own precedents.
Built-in, industry leading 'Moderation Layer' to preserve the privacy and confidentiality of contract data.
.avif)
