Does Your E-Discovery AI Train on Your Case Data?

E-discovery vendors have developed a standard answer to a standard question: does your AI train on my case data? The answer arrives, across platforms, in variations of the same confident reassurance. "We never use client data to train our models." "Your documents remain entirely private." "Case data is never used to improve shared AI systems."

The assurance is real. The word "training" is doing an enormous amount of work.

"Training," in machine-learning terminology, refers to a specific process: fitting a model to a large dataset by adjusting its internal parameters to minimize prediction error. When vendors say they don't train on your data, they mean your documents were not included in that initial process. Technically, this is true. The problem is that training is not the only way an AI system learns from your data. And the gap between what "we don't train" means and what buyers assume it means is precisely where your privilege logs, your litigation strategy, and your client's competitive secrets are currently sitting.

What the Word "Training" Actually Means in E-Discovery AI

Training, in machine learning, is a specific computational process. A model is shown a large dataset, makes predictions, receives feedback on whether those predictions were correct, and adjusts its internal parameters to reduce error. Repeat this billions of times across hundreds of billions of text tokens, and you get a foundation model capable of answering questions, summarizing documents, and coding relevance decisions. This process produced the models that power your e-discovery platform. It is precisely what vendors mean when they say they do not train their models on your data.

Note, precisely, what is being excluded. Your documents were not in the initial dataset used to build the foundation model. That is the claim. That is all the claim covers.

What "Training" Is Not

Modern AI deployments are not static after the training step. Between the trained model and your document review interface, at least three other adaptation mechanisms operate. None of them are typically called "training" in vendor communications. All of them can learn from your case data.

• Fine-tuning is the process of taking a pre-trained model and adapting it to a specific task using a smaller, targeted dataset. When reviewers mark documents as relevant or not relevant, those labeled pairs are exactly the kind of data used for fine-tuning relevance classifiers. One large matter can produce hundreds of thousands of such labeled pairs. Fine-tuning is not pre-training. Vendors do not describe it as "training on your data." It can, however, use your case data directly to improve the platform's models.
• Retrieval-Augmented Generation (RAG) is a technique in which the model retrieves relevant text segments from a database before generating responses. Your documents are chunked into segments, converted into vector embeddings (numerical representations of their semantic content), and stored in a vector database. The embeddings are not your original text. They are derived from it. They encode meaningful information about your matter's concepts, entities, and arguments, and they persist in storage after the retrieval step completes.
• Reinforcement Learning from Human Feedback (RLHF) is a method in which a model learns to generate outputs that users prefer, based on signals from how users interact with its results. Which suggestions your reviewers accept, which they reject, which follow-up questions they ask: all of this is feedback. Under some definitions, it qualifies as a form of training. Under standard vendor FAQ definitions, it does not. The practical question of whether it uses your case data is not resolved by what vendors choose to call it.

The e-discovery practitioner community has been debating these distinctions for years. One thread captures the problem precisely: a commenter distinguishes "NLP after fine-tuning to create a domain specific LLM" from what they call "true Generative AI," while another responds that the distinction between these categories is unclear and possibly meaningless from a data-exposure standpoint. Both are right. The categories are genuinely contested, which is precisely why vendor FAQ language that relies on one of them to do all the reassurance work is inadequate.

Reveal's 2026 eDiscovery Buyers Report puts the market's concern directly: every RFP now asks "two questions that used to be separate line items and have become one and the same: where does the data live, and whose AI model is touching it?" The market has correctly identified the two-part question. Most vendor answers address only half of it.

In summary: "Training" names one specific process. Vendors who say they don't train on your data are accurately excluding that one process. They are not addressing fine-tuning, RAG embeddings, or RLHF feedback loops, all of which can use your case data without qualifying as "training" under the standard vendor definition.

How Your Case Data Can Still Shape an AI Model Without "Training"

Let me describe four mechanisms by which your case data can affect an AI platform's behavior, none of which meet the technical definition of "training on client data."

Mechanism 1: Persistent Vector Embeddings

Every e-discovery AI platform that uses semantic search or AI-assisted review begins by processing your documents into embeddings. These are compressed numerical representations of each document's semantic content, calculated by passing the document text through the model. They are stored in a vector database and used at query time to find conceptually similar documents.

Embeddings are not your original text. They are, however, derived from it, and they encode meaningful information about your matter's themes, entities, and arguments. The question is what happens to those embeddings after your matter closes.

Standard data retention terms address document deletion. They typically do not separately address embedding deletion. A vendor can truthfully delete your original documents while retaining the embeddings derived from them. In a multi-tenant system, those embeddings occupy the same vector space as every other client's. The probability of cross-client influence is low but not zero, and there is no standard mechanism to measure it.

Mechanism 2: Reviewer Feedback as Labeled Training Data

When a contract attorney marks document A as responsive and document B as not responsive, that action produces a labeled pair: Label A - relevant. Label B - not relevant. Document feature: the embedding. This is precisely the format used to fine-tune relevance classification models. One large matter generates hundreds of thousands of such pairs. A platform's entire client base generates hundreds of millions.

Most e-discovery platforms have relevance models that improve over time. The improvement comes from somewhere. Whether vendors describe that source as fine-tuning, supervised learning, active learning, or "platform improvement" is a matter of internal nomenclature. What matters is that your reviewers' judgments about your privileged documents are the signal being used to improve the platform for everyone.

Mechanism 3: The "Platform Improvement" Clause

Open your current e-discovery vendor's Terms of Service and search for the word "improvement." You will find it. You will find language about using anonymized, aggregated, or statistical data to improve platform performance. You will find language about feedback and usage patterns. You will almost certainly not find a definition of what "aggregated" means in the context of document embeddings, or what "anonymized" does or does not include when applied to vector representations of your case materials.

Bloomberg Law has documented the emerging legal exposure in this space, specifically flagging the need for "contractual controls" against "client/confidential data in LLM training" as a required element of legal team AI governance. The clause types described are standard in enterprise AI agreements. What is not standard is actually negotiating them out before signing.

Mechanism 4: Data Retention After Matter Close

Ask your vendor when your data is fully deleted. You will receive an answer. Then ask what "data" means in that answer: does it include embeddings, usage logs, reviewer feedback patterns, and fine-tuned model weights derived from your matter? That question, in most standard contracts, does not have a specific answer, because those data types are not specifically defined.

Practitioners discussing AI data risks have specifically called out "details of ongoing litigation" as an obvious exclusion from what can safely be processed even by enterprise AI tools. The concern is correct. The standard contract terms most firms sign do not yet reflect it.

In summary: four mechanisms can use your case data without qualifying as "training": persistent embeddings, reviewer feedback capture, platform improvement provisions, and data retention ambiguity. The vendor FAQ addresses none of them.

The Contract Clauses That Permit What the FAQ Denies

A vendor FAQ is written for reassurance. A vendor contract is written for operational flexibility. These documents serve different purposes, and they do not always say the same thing.

In my review of publicly available terms for major e-discovery platforms, every single one contains language broad enough to permit the use of reviewer behavioral data for model improvement. None explicitly prohibit it. The following is a checklist of specific provision types that appear routinely in standard e-discovery SaaS agreements and that permit data uses clients have generally not understood or consented to with full information.

The Case-Confined Tuning Clause Checklist

The pattern is consistent: limiting language in vendor contracts creates exceptions broad enough to encompass precisely the practices the marketing FAQ is designed to rule out. This is not necessarily intentional deception. SaaS contracts are written by lawyers trying to preserve product flexibility. The result, however, is a systematic mismatch between client expectation and contractual reality.

The audit mechanism that would close this gap, one that would let you verify your matter's embeddings were actually deleted and your reviewer feedback was actually excluded from model improvement, does not exist in standard contracts. You are asked to trust the FAQ.

Practitioners in the e-discovery community have begun to notice. A recent discussion on recognizing vendor AI hype flagged this problem directly: the disconnect between vendor marketing language and what the actual product does is "a pattern worth documenting before you sign anything."

In summary: seven contract provision types routinely permit data uses the FAQ appears to exclude. Platform improvement, aggregate data carve-outs, model enhancement rights, ambiguous retention definitions, feedback logging permissions, third-party AI sub-processor rights, and anonymization definitions that cover embeddings. Your current agreement probably addresses fewer than two of them with any specificity.

What Single-Tenant Deployment Actually Prevents

The cleanest architectural answer to the cross-client learning problem is physical isolation: a deployment in which your data, your embeddings, your fine-tuned models, and your reviewer feedback never touch infrastructure that any other client, or the vendor itself, can access without your explicit permission. In practice, this means deploying the entire AI stack inside an environment you control.

What "Own-Cloud" Actually Means

When a vendor offers deployment inside your own AWS environment, or your own Azure or GCP tenancy, four things change:

• Your vector database instance. Embeddings of your documents are stored in an instance inside your cloud tenant. They are not in a shared vector database alongside other clients' embeddings. There is no architectural pathway by which they influence another client's retrieval results, because they are in a different account entirely.
• Model weights isolated to your tenant. If the platform fine-tunes relevance models on reviewer feedback, those model weights exist inside your cloud environment. They do not propagate back to the shared platform. Deleting them is an operation you can verify because the storage is in your account, not the vendor's.
• Reviewer feedback logs in your control. The logs of reviewer decisions, queries, and interactions are written to storage you own. The vendor cannot access them without explicit permission. They cannot be used for platform improvement without your explicit consent, because they are not in the vendor's environment to access.
• Compute isolation. AI inference runs on compute instances in your account, not on shared vendor infrastructure. There is no shared compute through which side-channel information could pass.

At Relevant Discovery, processing runs single-tenant or inside the client's own AWS account under the client's own encryption keys, with no vendor data retention and no model training on client documents. The practical consequence is that nothing a client loads onto the platform trains anyone else's model or contributes to platform improvement programs, because there is no shared infrastructure on which those programs operate. This is an architectural guarantee, not a policy promise.

What "Single-Tenant on Vendor Infrastructure" Does Not Prevent

Note the distinction, carefully, between "own-cloud deployment" and "single-tenant on the vendor's infrastructure." The second is a softer form of isolation. It means your data is in a separate database from other clients' data. It does not mean:

• The vendor cannot access your data for their own purposes
• Fine-tuned model improvements derived from your data cannot be incorporated into shared platform models
• Your reviewer feedback is not logged and retained in vendor-accessible storage
• Embeddings derived from your documents are not in a namespace the vendor can reach

A single-tenant database on vendor infrastructure prevents other clients from querying your data. It does not prevent the vendor from using your data. These are not the same guarantee.

The market has noticed this distinction. According to Reveal's 2026 eDiscovery Buyers Report, 91 percent of buyers have seen their share of matters requiring private or on-premises deployment grow over the past 24 months. That shift reflects exactly this understanding: buyers have learned that "multi-tenant SaaS" promises and "contractually isolated" promises are not equivalent to architectural isolation.

The only architecture that makes cross-client learning provably impossible is one in which your data, your models, and your logs never touch infrastructure the vendor controls. That is the standard worth asking for.

In summary: own-cloud deployment isolates the full AI stack (embeddings, fine-tuned model weights, reviewer logs, compute). Single-tenant on vendor infrastructure isolates data from other clients but not from the vendor itself. These are different guarantees, and the difference matters for privilege protection.

What to Ask Your Vendor Before You Sign

The verification gap is the actual problem. Vendors make promises. Buyers have no standard mechanism to confirm them. The following questions are designed to force vendors to be precise, and to help you read their answers accurately.

Architecture Questions

Ask these in writing and request written responses. Specific, verifiable answers indicate a real architecture. "In a secure, isolated environment" does not.

• "Where are my document embeddings stored, and in what database technology?" A specific, named database product in a specific cloud account or region is an answer. "In our secure infrastructure" is not an answer to a technical question.
• "Are reviewer feedback actions logged? If so, to what system, and who has access to those logs?" The existence of a feedback log is not automatically a problem. Who can access it and what they are permitted to do with it is the question.
• "Does any fine-tuning of relevance or classification models occur during or after my matter? If so, where do the fine-tuned weights reside, and are they isolated to my matter?" This question most directly exposes the gap in standard "we don't train" assurances. Insist on a direct, specific answer.
• "Is your AI using any third-party foundation model APIs (OpenAI, Anthropic, Google, Cohere)? If so, what data is sent to those APIs, and what are their data retention terms?" If your documents are being sent to a third-party model API, your vendor's own data promises cover only one layer of the problem.

Contractual Rights Questions

• "What does 'data' mean in your data retention schedule? Does it specifically include embeddings, interaction logs, and derived model weights?" Get the definition in writing before signing.
• "Can I opt out of the platform improvement and model enhancement provisions in your standard ToS? What is the process, and can it be documented in the main agreement?" Some vendors will address this in the main agreement. Others require a separate addendum. Know the answer before signing.
• "Do you provide a deletion certification that specifically covers embeddings and derived model outputs, not just original documents?" A deletion certificate for "all client data" that does not define what "data" includes is not a meaningful guarantee.
• "Do I have audit rights to verify that deletion occurred?" The answer under standard terms is almost always no. Push for it anyway. Document the refusal if you receive one, and note it in your vendor evaluation record.

Reading the Answers

Specific, verifiable answers are good. "We take data security very seriously" is not an answer to a technical question about architecture. "We are SOC 2 Type II certified" is not an answer to a question about model training practices. SOC 2 covers controls around availability, confidentiality, and processing integrity. It addresses none of the practices described in this article.

ABA Opinion 512 establishes "reasonable efforts" as the governing standard under Model Rule 1.6 for attorney AI use and confidentiality. Reasonable efforts to protect client data include getting specific contractual representations about how your data is used, not accepting marketing FAQ language as a substitute for contractual protection.

Law firms navigating AI transformation, as Thomson Reuters documented in a September 2026 analysis of the process, consistently identify data governance as one of the harder operational questions. That difficulty is real. The answer is not to defer it; it is to ask the specific questions now, while you have negotiating leverage, before you load your privilege log onto a platform whose data practices you have not verified.

In summary: ask about embeddings storage, reviewer feedback logging, fine-tuning practices, third-party sub-processors, data retention definitions, and audit rights. Get all answers in writing. Assume that anything not specifically addressed in writing is not contractually protected.

Sample Data Use Restriction Addendum Language

Addendum to Master Services Agreement
Data Use Restrictions for AI Processing


Definitions.
“Client Data” means all data provided by Client,
including without limitation: documents, metadata,
vector embeddings derived therefrom, reviewer feedback
logs, relevance classifications, query logs, and any
model weights fine-tuned or otherwise adapted using
Client Data.


Prohibited Uses.
Vendor shall not use Client Data for any purpose
outside of delivering the Services to Client, including
but not limited to: (a) improving shared or multi-client
AI models; (b) fine-tuning shared relevance or
classification models; (c) benchmarking platform
performance; or (d) any purpose that would benefit
Vendor’s other clients or products.


Deletion Certification.
Within 30 days of matter close or contract termination,
Vendor shall provide written certification of deletion
covering all Client Data as defined in Section 1,
signed by an authorized officer.


Audit Rights.
Client may request, no more than once per contract
year, third-party verification of deletion compliance
at Client’s expense.

Note: This is a starting framework, not a substitute for qualified legal review. Counsel should adapt this language to your specific jurisdiction, matter type, and vendor relationship before use.

What Will Matter Most in the Next 12 to 24 Months

Three regulatory and market developments will change the e-discovery AI data landscape within the next two years. Attorneys who understand them now will be positioned to protect clients before they become requirements.

The EU AI Act's High-Risk Classification

The EU AI Act, effective August 2026 for high-risk AI systems, classifies AI used in the administration of justice and legal processes as potentially high-risk. E-discovery systems that process personal data for litigation purposes, particularly those deployed for EU-based matters or by EU-headquartered firms, are directly in scope. High-risk systems must maintain technical documentation, usage logs, and human oversight mechanisms. Vendors will need to produce documentation of their training data, model behavior, and data retention practices to satisfy compliance audits.

Vendors who can answer your architecture questions today are the ones who have already built the compliance infrastructure the Act requires. The ones who respond to technical questions with marketing language have not.

ESI Technical Standards and Transparency Documentation

The Sedona Conference published a public comment draft of updated Technical Specifications for the Production of Electronically Stored Information in September 2026, with comments due October 2026. These specifications increasingly address AI-assisted processing transparency. The broader trend, toward requiring documentation of how AI tools processed, categorized, and retained ESI before production, is already visible in case law and is likely to become a standard element of discovery protocols within 24 months.

Model cards, standardized documents describing a model's training data, intended use, and known limitations, are becoming an expected standard in enterprise AI procurement. Ask your e-discovery vendor now whether they can produce one for their relevance classification model. The answer is informative.

Audit Rights as a Competitive Differentiator

The most significant near-term shift is this: audit rights that are currently absent from standard contracts will become a differentiating feature. Vendors who can provide verifiable deletion certifications, third-party audits of model training data, and architecture documentation supporting independent review will win enterprise and regulated-industry clients at premium pricing.

This is a prediction about market pressure, not vendor altruism. Law firms will begin requiring audit provisions as standard practice, probably by 2027, and the vendors who have built the capability early will be best positioned to meet that demand. Ask for audit provisions now, while you still have negotiating leverage. Document the response either way.

Thomson Reuters documented in September 2026 that law firms navigating AI transformation consistently identify data governance as one of the harder operational questions in the process. The firms that ask the hard questions now, before a matter produces a sanctions motion over AI data practices, will be in a measurably better position when the regulatory and contractual standards catch up to the current market reality.

In summary: the EU AI Act, Sedona Conference ESI transparency standards, and emerging audit right demands are converging to make the verification gap documented in this article a near-term regulatory and market problem. The question is not whether these standards will arrive. The question is whether you will have negotiated for them before they are required.

The "we don't train on your data" promise is not a lie. It is a narrow technical truth deployed to address a broad client concern, and the gap between the two is where most e-discovery deployments currently leave your client's information protected by nothing except a vendor's stated intention.

The verification mechanism that would close that gap is, for now, largely absent from the market. The vendors who can speak precisely about their architecture, who can show you where your embeddings live, confirm in writing that reviewer feedback is excluded from shared model improvement, and provide auditable deletion certification are the vendors worth the premium for sensitive matters.

I'd recommend using the due diligence questions in this article as a baseline, getting the answers in writing before any agreement is finalized, and looping in qualified counsel before AI processes any privilege-bearing material on your behalf. The verification gap is a real problem. Asking precise questions is how you find out which vendors have already solved it.