The question comes up in every enterprise sales conversation we have: what happens to the contracts we upload? It's a reasonable question, and the fact that it's asked so consistently tells you that a lot of AI legal tools haven't been clear enough about the answer.
This is also a question that matters differently depending on your role. For in-house counsel reviewing your own vendor agreements, the concern is primarily confidentiality of deal terms and counterparty information. For law firm counsel reviewing client contracts, there's an added dimension: you may have professional responsibility obligations around client confidential information that make data handling a compliance issue, not just a preference.
The Three Questions That Actually Matter
When evaluating any AI tool that processes your documents, the relevant questions are:
1. Is your data used to train the model? This is the question most people ask first, and for good reason. A model that trains on uploaded contracts can, in theory, surface information from those contracts in responses to other users. In practice, modern training pipelines have safeguards against this, but "we don't train on your data" is a meaningful and important commitment that should be clearly stated in the vendor's data processing agreement, not just on a marketing page.
2. Where is your data stored, and for how long? Even if a vendor doesn't train on your data, contracts uploaded to a cloud service exist somewhere. You want to know: what region are the servers in, how long is data retained after you process it, and what deletion rights do you have? For law firms with clients subject to EU data protection rules, the GDPR implications of processing documents on US-based infrastructure with unclear retention periods are not hypothetical.
3. Who has access to your documents? Can vendor employees see uploaded contracts? Under what circumstances? What access controls exist? "No human review of uploaded documents" is a different policy than "human review only for trust and safety purposes" which is different from "standard customer support access." The distinction matters when the documents contain sensitive deal terms or client information.
What "We Don't Train on Your Data" Actually Means
This phrase has become common in AI tool marketing, but it covers a range of practices that are meaningfully different. The most common variation is: the vendor uses a third-party model (say, a large language model API) for inference, and the third party's terms say they don't use API inputs for training. That's a reasonable answer, but it means the commitment is upstream — from the API provider, not the legal tool vendor itself.
A second variation: the vendor fine-tunes or trains its own model on customer data in aggregate, but with privacy protections intended to prevent any individual contract's information from being surfaced. This is a different claim than "we don't train on your data" — it's more accurate to say "we train on anonymized or aggregated patterns, not individual documents." Whether that's acceptable depends on what "anonymized" actually means and how confident you are in the de-identification.
The cleanest answer for enterprise legal applications is: inference only, no training or fine-tuning on customer documents, customer data is processed transiently, stored only as long as needed to return results, and deleted on a specified schedule with customer-controlled deletion available. That's what you want to see in the data processing agreement.
Attorney-Client Privilege and Third-Party Services
The attorney-client privilege question is distinct from the data security question, though they're often discussed together. The concern is: does uploading a privileged document to a third-party service waive privilege?
The general rule is that voluntary disclosure of privileged information to a third party can waive privilege, but courts have recognized a "common interest" exception and have generally not found that using software tools for document processing constitutes a waiver, particularly when there's a reasonable expectation of confidentiality in the service arrangement. The relevant professional responsibility rules (Model Rules 1.6 and 5.3, and their state equivalents) require reasonable measures to protect client information — not absolute prohibition on third-party service use.
We're not offering legal advice here, and you should evaluate this with your own ethics counsel if you're making firm-wide decisions about AI tool adoption. The practical point is that a data processing agreement with clear confidentiality terms, explicit non-disclosure obligations, and appropriate technical controls has been the standard framework for addressing this concern in the professional services context — the same framework law firms have used with e-discovery vendors, translation services, and other third parties handling client documents for years.
What Winpathio's Data Handling Actually Is
Since we're writing this post, it would be dishonest not to say where we stand. When you upload a contract to Winpathio, it is processed to extract clause structure, key terms, and risk flags. That processing happens on infrastructure in the US. Documents are not stored permanently — they're held in a session context for the duration of processing and for a short retention window for support and audit purposes, after which they are deleted. We do not use uploaded contracts for model training. The specifics are in our data processing addendum, which we'll share with any customer who asks.
We know this is table stakes for legal tool adoption — not a differentiator. We're being explicit about it because we think vendors who aren't explicit have a problem they're avoiding, not a feature they're protecting.
What to Actually Ask Vendors (and What Good Answers Look Like)
When you're evaluating a contract review tool or any AI service that will process your documents, the documents to request are: the data processing addendum (DPA), the information security policy summary, and the subprocessor list. These three documents will answer the questions above more reliably than any marketing language.
In the DPA, look for: explicit statement on training data use, data retention periods and deletion mechanisms, data residency commitments, and the process for requesting deletion of your data. If the DPA doesn't clearly address training data, ask specifically. "Our privacy policy covers this" is not a data processing addendum.
The subprocessor list tells you which third-party services process your data. An AI tool built on a third-party LLM API will have that API provider as a subprocessor. You can then review that provider's API terms to understand their data use policies. This is the multi-layer check that matters for highly sensitive use cases.
For law firm IT and risk teams evaluating these tools, a standard security questionnaire (SOC 2 Type II report is the baseline to request) plus DPA review plus subprocessor check is the standard diligence pattern. Vendors who have done enterprise deployments before will have all of this ready. Vendors who haven't will fumble the request — that's useful information too.
The contracts you're reviewing contain real obligations, real deal terms, and sometimes real competitive information. The service you use to review them should be able to account clearly for what it does with those documents. If it can't, the right answer is not to proceed until it can.
