Detecting and discovering opposing party AI use in litigation

Where AI chats sit in discovery and privilege right now

A recent, widely circulated federal decision that people are calling the “Rakoff” ruling is the written memorandum opinion by Jed S. Rakoff in United States v. Heppner. The court held that “AI Documents” reflecting a criminal defendant’s exchanges with the Claude chatbot were neither attorney-client privileged nor protected work product, even though the defendant later shared the documents with counsel. The court reasoned (among other things) that the documents were not communications between attorney and client because the chatbot was not an attorney, and that the exchanges lacked the confidentiality element because the user had notice from platform terms that user data could be used and disclosed in ways inconsistent with a reasonable expectation of confidentiality.

Two details from Heppner matter for litigators trying to obtain AI-related evidence from an opposing party. First, the “AI Documents” were not produced in ordinary civil discovery; they were reportedly seized by the Federal Bureau of Investigation via a search warrant as part of the criminal investigation, which underscores that AI interactions often exist in multiple places beyond the vendor’s servers (exports, screenshots, saved PDFs, downloaded “reports,” cached files). Second, the court emphasized a classic privilege principle: sharing something unprivileged with counsel does not retroactively “alchemize” it into privileged material.

A second federal decision points the other direction, at least on the work product question and at least in a particular posture. In Warner v. Gilbarco, Anthony P. Patti denied a request to compel sweeping discovery into a pro se plaintiff’s use of ChatGPT in connection with her case, reasoning that the requested AI-related materials reflected internal litigation thought processes and were protected as work product; the order also rejected the idea that using ChatGPT alone constituted a work product waiver under Sixth Circuit law absent disclosure to an adversary or in a manner likely to reach an adversary.

Finally, separate from privilege doctrine, courts are increasingly treating large scale prompt and output logs as ordinary ESI when an AI company itself is a party. In the SDNY copyright MDL against OpenAI, Magistrate Judge Ona Wang ordered production of “20 Million de-identified ChatGPT Logs,” and denied a stay while objections were pending. OpenAI publicly emphasized the privacy sensitivity of those conversations and described the plaintiffs’ demand as seeking indefinite retention of consumer ChatGPT and API content going forward. This matters for your audience because it shows the direction of travel: courts are not reflexively treating “AI chats” as categorically off limits, and they will analyze them through familiar discovery lenses (relevance, proportionality, privacy protections, protective orders, de identification protocols).

Identifying likely AI use without junk science

The first principle is blunt: you usually cannot prove “this text was written by an LLM” from the text alone to an evidentiary standard. Contemporary AI text detectors have material false positive and false negative problems, and some are biased against non-native English writing (like my own!). Even OpenAI’s own public “AI classifier for indicating AI-written text” was discontinued due to low accuracy, which should make lawyers cautious about leaning on third-party “AI detector” scores as a basis for accusations, sanctions motions, or broad discovery expansions.

The practical alternative is an “outside-in” forensic triage: look for process artifacts that make AI use more likely, then use proportional discovery tools to confirm or falsify the hypothesis. That means prioritizing evidence sources that are hard to fake at scale: metadata, enterprise audit logs, account/billing traces, and native exports.

At a high level, your identification workflow should treat “AI suspicion” as a stack of increasingly strong indicators:

Document forensics indicators

If you can obtain native files (not flattened PDFs) you can often learn more about authorship and drafting behavior from metadata than from prose style. Microsoft explicitly describes “document properties” (metadata) such as author, title, and other identifying fields, and those properties commonly travel with Office files unless intentionally scrubbed. In an enterprise environment, eDiscovery systems can also expose metadata fields (including “Author” and other document metadata attributes) at scale, which is frequently more defensible than linguistic inference.

Two niche but real “tells” can appear in document text itself, but they are best framed as anomaly detection, not proof:

Invisible Unicode characters. The Unicode standard defines “zero width” format characters such as U+200B ZERO WIDTH SPACE, which is ordinarily invisible and intended for segmentation and line breaking in specific writing systems. Separately, security and academic literature shows zero width and whitespace variants can be used for text steganography or watermarking. If a produced discovery response or declaration contains clusters of these characters in an English language context, that can justify narrowly asking “what system generated or transformed this text,” but it still does not establish that an LLM authored it because the same artifacts can arise from copy paste pipelines, template systems, or deliberate obfuscation.

Provenance metadata. The Coalition for Content Provenance and Authenticity specification supports embedding signed provenance manifests into formats including PDF and Office-style container formats, which can (where adopted) create machine-checkable records of creation and edits. In the near term, this is more relevant in corporate publishing and media pipelines than in routine civil litigation, but it is the path toward evidence-grade provenance for “what tool produced what.” For example, if you are sent a file by opposing counsel, and the author is “python-docx”: that's AI-made.

Platform level and enterprise logging indicators

If the opposing party is an organization, the strongest “AI use” evidence may be the organization’s own audit and compliance telemetry. For example, Microsoft documentation states that audit logs are generated for user interactions with Copilot, with records containing details about who interacted, when, and what resources were accessed to generate responses. Microsoft also describes using Purview eDiscovery to search Copilot prompts and responses and hold them for investigations, which makes Copilot usage materially easier to discover than a consumer chatbot used on a personal device.

On the vendor side, major AI providers increasingly expose admin grade export mechanisms. OpenAI’s enterprise release notes describe a “Compliance Logs Platform” that exports time windowed immutable JSONL logs, positioned for auditing and compliance. That changes the litigation calculus: if a party used an enterprise instance, “AI activity” is more likely to exist in a structured, exportable log format than in ad hoc screenshots.

Why “watermarks” are not the shortcut people want

Text watermarking is a real research direction: one widely cited approach “softly” biases token selection so output carries a statistically detectable signature. But watermarking is not a universal deployment reality in consumer LLMs, it can be degraded by paraphrasing and formatting changes, and recent work demonstrates practical “watermark stealing” and spoofing attacks against prominent watermark schemes. For litigation, the takeaway is that watermarks are best treated as “if the provider offers a verification service, consider it,” not as an opponent facing forensics silver bullet.

Building a proportional discovery theory that survives objections

If you ask for “all AI chats related to this case,” you will lose credibility fast and often lose the motion. Modern discovery rules push proportionality and reasonableness, and electronically stored information is explicitly part of the expected discovery planning universe. The right approach is to start with a case specific reason why AI use is relevant, then aim your requests at the narrowest evidentiary target that actually matters (knowledge, intent, notice, reliance, state of mind, provenance of specific documents, or spoliation).

A practical framing is:

Relevance hook: “AI interactions are ESI that can show what a party knew, believed, or was trying to accomplish, especially when the AI was used to draft or justify factual assertions later served in discovery or filed with a court.”

Proportionality guardrail: “We do not need ‘everything.’ We need exported records for a defined time window, from defined custodians, about defined subjects, tied to specific produced documents or interrogatory answers.”

Form of production: Push for native or reasonably usable electronic forms when metadata or audit trails matter. Rule 34 explicitly contemplates ESI production forms and requires usability.

Also, be careful with “go image their laptop” energy. The Rule 34 committee notes explicitly caution that inspection/testing of electronic systems is not a routine right and courts should guard against undue intrusiveness. This supports an escalation ladder: start with admissions and exports; only then seek deeper device inspection on a record of need.

What to request from the party, not the AI vendor

The most reliable path in civil litigation is usually to force the party to produce what they can access (exports, screenshots, downloaded archives, enterprise logs), rather than trying to subpoena the chatbot provider first. A key reason is that mainstream providers give end users export tools that create litigation ready archives:

OpenAI documents a user facing export that includes ChatGPT chat history and other account data.

Anthropic documents a Claude “Export data” process through privacy settings.

Google documents exporting Gemini Apps data via Takeout/My Activity, and warns that downloading does not delete server side data.

That means your “AI discovery” requests can be concrete and narrow. Below is a template approach (write it in your own voice and adapt to local rules and your forum’s discovery norms):

The core interrogatory

Ask for identification, not production:

Identify each generative AI system or feature used by you or anyone acting on your behalf to draft, revise, summarize, translate, or generate any content relating to the claims, defenses, discovery responses, witness statements, or documents produced in this action, including the system name, account identifier, device used, date range of use, and whether any chat history or logs are retained, deleted, or exported.

This framing is tailored to proportionality because it seeks a map first, and it aligns with the idea that ESI sources must be identified and discussed.

The targeted RFPs that tend to matter

Instead of “all AI chats,” tie requests to artifacts or topics:

Exports for specific issues. “Produce exported chat transcripts (including prompts, outputs, attachments) for conversations used to create or revise the following produced documents: [list Bates ranges].” The existence of official export mechanisms makes this request more technically feasible and less hand-wavy.

Enterprise audit or compliance logs. If the party is an organization that uses Microsoft Copilot, request the relevant Purview audit and eDiscovery exports for the custodians and date ranges at issue, because Microsoft describes these as the appropriate tools to audit and investigate Copilot interactions.

Retention settings and deletion actions. OpenAI’s help documentation explains that chats persist until deletion and are generally scheduled for deletion within 30 days subject to legal/security exceptions, and OpenAI has stated that legal holds can change retention behavior. Asking for “what settings were in place and when” helps evaluate spoliation and credibility.

Billing and access evidence. If the other side denies AI was used, subscription receipts, reimbursements, and account emails are often more probative than prose analysis because they establish access and opportunity. The litigation lesson from privacy and retention disputes in the OpenAI MDL is that courts will take structured logs and account scale issues seriously when properly framed.

When and how to subpoena AI companies, and the Stored Communications Act trap

Rule 45 authorizes subpoenas commanding production of documents and ESI from nonparties, but that does not override statutory limits and privacy regimes that constrain what a provider can disclose. The biggest U.S. litigation trap here is the Stored Communications Act (SCA), which generally prohibits providers of electronic communication services or remote computing services from divulging the contents of communications to “any person or entity” absent an exception, including lawful consent.

This is why civil subpoenas to providers for message contents have historically been quashed in the email and social media context (for example, O’Grady v. Superior Court and In re Subpoena Duces Tecum to AOL), and why cases like Crispin v. Christian Audigier became foundational for the idea that you often cannot subpoena communications content directly from the platform in civil litigation.

For “AI chats,” the practical implication is:

A third party subpoena for chat content may go nowhere unless you can invoke a statutory exception (most commonly, consent from the account holder) or you are dealing with a context where the provider is itself a party and content is sought via party discovery rather than a third party subpoena.

Subpoenas for non content records (subscriber info, billing, login timestamps, IP session logs) may be more attainable, but you should expect aggressive objections and you must tailor narrowly. The statute’s structure and the long history of SCA litigation is a reminder that “non content” and “content” are treated very differently.

If what you really want is the chat transcript, your best litigation move is often to subpoena the party for exports and backups and then, if necessary, seek an order compelling consent based production, understanding that courts sometimes resist “end runs” around the SCA depending on the mechanism used.

Proving AI use when they deny it, and preserving the record

When an opponent says “my client didn’t use AI,” your objective is not to win an online debate about style. It is to build a circumstantial record that either forces a correction or supports sanctions if they lied and destroyed evidence.

Start with the lowest friction proofs:

Account-level proof: exports, subscription receipts, and enterprise admin logs (Copilot audit, compliance logs) are harder to explain away than “this paragraph sounds like ChatGPT.”

Metadata and native format comparisons: Office metadata fields and eDiscovery metadata reports can show authorship fields and modification chains that support or undermine claimed drafting narratives.

Deposition anchoring: if a discovery response contains technical or legal assertions that look generated, pin the witness to “how was this drafted, what sources were consulted, what tools were used,” then follow with document requests keyed to the answer. This tracks the logic in Warner that courts are wary of intrusive fishing into internal drafting absent a concrete need.

On preservation, courts recognize preservation obligations for ESI and that preservation issues can arise before an action is filed. OpenAI’s own retention explainer and public statements about legal holds show how quickly “delete means delete” assumptions can fail in the AI context, especially where legal obligations override standard deletion windows.

Finally, if you obtain AI logs or exports and want them admissible, think early about authenticity. The Federal Rules of Evidence include self authentication paths for records generated by an electronic process or system (Rule 902(13)) and for certified data copied from an electronic device or file via digital identification (Rule 902(14)), which map cleanly onto “exported logs” and “forensic extractions” when handled correctly.