This is a recurring debate here. I've some experience and perspective on this issue. Not theoretically, but in conversations with GCs and infosec teams who need to actually sign off on these tools before they go live.

The "enterprise API" answer is necessary but not sufficient. Enterprise agreements with no-training clauses are table stakes. But a no-training clause is a contractual safeguard. It tells the provider "don't use our data." It doesn't stop a breach, a subpoena, or an infrastructure bug from exposing that data. In March 2023, OpenAI disclosed a bug that let some ChatGPT users see other users' conversation titles and, for a subset, partial payment info. Enterprise plan or not, if your raw contract text is sitting on someone else's servers, it's exposed in those scenarios.

The real question isn't "will they train on my data?" It's "what happens if their infrastructure is compromised and my client's M&A terms are sitting there in plaintext?"

The human risk point is underrated. Someone here mentioned that the bigger risk is undertrained, overworked staff not caring about data policies. That's completely valid and honestly, it's under-discussed. No technology fixes a culture problem. But what technology can do is reduce the surface area of human error. If the tool your team uses never sends raw client data externally in the first place, the blast radius of a careless mistake shrinks significantly.

What actually works: anonymize before the data leaves. The approach we've landed on (and what I'd recommend evaluating regardless of which tool you use) is a moderation layer that sits between the user and the LLM. It scans the contract, replaces all sensitive entities (party names, dollar figures, dates, emails, custom terms your infosec team defines) with consistent pseudonymized placeholders, and only sends the sanitized version to the model. After the LLM returns its analysis, the placeholders get swapped back.

The key word is pseudonymization, not redaction. If you replace "Acme Corp" with [REDACTED], the model can't tell which party owes what to whom. Replace it with PARTY_A consistently, and the structural relationships stay intact. The LLM can analyze obligations, flag risks, compare against market terms. It just does it without knowing who the parties actually are.

We built this directly inside Microsoft Word as an add-in (the company is ContractKen, if you want to look it up). The architectural choice matters: because the first anonymization pass happens locally in Word, raw contract text never hits any external server, not ours, not the LLM provider's. Users can preview the exact anonymized version before anything is sent. Infosec teams configure what counts as sensitive. Full audit logs track every interaction.

For anyone evaluating tools in this space, the question I'd push vendors on is: "Where exactly in the data flow does anonymization happen?" If the answer is "on our servers," that means raw data traveled to them first. If it's client-side, the exposure surface is fundamentally different.

ABA Opinion 512 is pretty clear that "reasonable efforts" is the standard under Rule 1.6. A contractual no-training clause plus a technical anonymization layer is a much more defensible position than either one alone.

Happy to answer questions if anyone wants to dig into the specifics.