Attorney-Client Privilege and AI: What Legal Departments Need to Think Through

Legal departments have moved quickly to adopt AI tools for document review, contract analysis, and legal research. Far fewer have moved as quickly to work through what happens to privilege when client matter data passes through a third-party AI system. This is not a theoretical gap. It is a live exposure most legal departments have not fully addressed, and it does not announce itself until a discovery dispute or a malpractice claim forces the question.

Why AI tools create a privilege problem in the first place

Attorney-client privilege depends on confidentiality being maintained and reasonable steps being taken to protect it. When client matter data is processed by an AI tool, that data typically leaves your controlled environment and passes through a vendor's infrastructure, potentially through additional subprocessors, and in some architectures, into logs, caches, or training pipelines the vendor controls, not you. Every one of those handoffs is a point where a court could later ask whether confidentiality was actually maintained, or whether the organization waived privilege by disclosing protected material to a third party without adequate safeguards. The convenience of the tool does not answer that question. Only the data handling architecture underneath it does.

The questions most legal departments have not asked their vendors

Before any AI tool touches client matter data, we push legal departments to get concrete, contractual answers to a specific set of questions, not general assurances about security.

• Is client matter data used to train or fine-tune the vendor's models, for this client or any other, and is that contractually prohibited, not just a stated policy that can change?
• Where does the data reside, who can access it, and does the vendor's own staff have standing access to the content, not just the metadata?
• What is the data retention period, and can the firm force deletion of a specific matter's data on demand, verifiably?
• Does the vendor's subprocessor chain introduce additional parties who touch the data, and has the firm actually reviewed that chain rather than accepting a summary?
• In the event of a subpoena or discovery request directed at the vendor, what is the vendor's obligation to notify the firm before producing anything?

If a vendor cannot answer these in specific, contractual terms, the honest conclusion is that the tool is not ready for privileged matter data, regardless of how well it performs.

Building a defensible data handling posture

The legal departments that get this right do not treat AI vendor selection as a procurement decision handled by IT. They treat it as a privilege decision that happens to involve technology, and they build a defensible position in three layers. First, data segmentation: privileged and non-privileged matter data are not treated identically, and higher-sensitivity matters may be explicitly excluded from certain AI tools until the data handling architecture is verified. Second, access control: the tool's access to matter data is scoped as narrowly as the task requires, not granted broadly for convenience. Third, a documented reasonable-steps record: the firm can show, if ever asked, exactly what due diligence was performed on a vendor before privileged data was exposed to its systems, because "we assumed it was fine" is not a defense a court will credit.

None of this is a reason to avoid AI tools in legal work. It is a reason to treat the underlying data architecture with the same rigor legal departments already apply to outside counsel guidelines and conflict checks. Privilege was never protected by good intentions. It was protected by demonstrable, reasonable steps, and that standard does not change because the third party in question is a model instead of a person.