Where do your client's documents go when you use an AI tool?

When you paste a client's document into a cloud AI tool, it leaves your office. It crosses a network, lands on a server, and on some plans it can be used to train the model. What decides which of those happens is not the product's name or its marketing page. It is the contract attached to the plan you are on.

Where does a document go after you hit enter?

A prompt is not a private thought. It travels to the vendor's servers, gets processed there, and, depending on the plan, is stored for some window and may be added to the pool the model learns from. None of that shows up on screen.

That is the trap. A free consumer chatbot and a business tool configured for confidentiality can look identical in the browser and do completely different things with the same document underneath. The interface tells you nothing about where your client's file just went.

Why does the plan tier matter more than the product name?

Often the model is the same across tiers, and the contract is the only thing that changes. OpenAI runs several layers under the ChatGPT name. The free tier and ChatGPT Plus default to training on what users type, with an opt-out toggle in the settings. The Business, Enterprise, and API tiers default to not training on customer data. Same model, different terms.

Microsoft is the sharpest example, because the name barely changes. Microsoft Copilot is the consumer assistant. Microsoft 365 Copilot is sold both as a consumer add-on and as an enterprise product with stronger data protections, governed by whatever contract the customer signed. The marketing page shows one product. The contract shows which one you actually bought.

Do the legal-specific tools solve it?

Somewhat. The purpose-built legal tools, Westlaw's CoCounsel, LexisNexis Protégé, and the rest, tend to publish stronger defaults than a consumer chatbot: commitments not to train on your data, short retention windows, model partners held to the same terms. The defaults are better. The documents that prove it, the data processing agreement and the security attestations, usually sit behind a login, and the job of actually reading them does not disappear because the marketing sounds reassuring.

Isn't a line in my engagement letter enough?

The American Bar Association took that up in Formal Opinion 512. Its language is blunt: “merely adding general, boiler-plate provisions to engagement letters purporting to authorize the lawyer to use GAI is not sufficient.” The opinion also flags that many tools are “self-learning,” meaning what goes in can resurface later, and it treats genuine client consent, not buried boilerplate, as the baseline before client information goes into such a tool. The contract and the configuration are what make confidentiality real. One sentence in the engagement letter does not.

What should you look at before trusting a tool?

Three things sit underneath the marketing: which tier you are actually on, what the contract says about training and retention, and where the data lives and who can reach it. Reading a vendor's data terms the way a lawyer has to read them, and checking them against what the tool is doing in your firm, is slow and unglamorous. It is also the part most solo and small firms never find time for.

This is a setup problem, not a reason to avoid AI. The same tools, on the right tier with the right contract and configuration, can handle sensitive work with client data kept inside a boundary you control. Checking an existing setup for where data could leak, and closing those gaps, is what a configuration audit is for. If you cannot say what your current tools do with your clients' files, that uncertainty is the place to start.