AI drafting features and confidentiality risk

AI drafting features are the newest part of legal technology, and they raise the oldest question in the industry, confidentiality, in a form most teams have not thought through carefully. This page covers why the risk is real, what it looks like concretely, and what isolation has to mean in practice.

Why AI features change the confidentiality calculation

The American Bar Association's own guidance on generative AI and lawyer confidentiality is direct about this: AI features that retain and reuse input or prompt data across sessions pose a heightened confidentiality risk compared to older technology, because prompts containing client information can be inadvertently disclosed or cross-used in other matters [1]. That risk is a direct consequence of how a lot of AI-powered features are architected by default, not an unlikely edge case that only shows up under attack.

Consider a drafting assistant that helps a lawyer write a section of a contract by learning from examples of similar language the lawyer has used before. If that learning process pools examples across every customer using the product, rather than isolating each firm's, or each matter's, examples from every other one, then one client's confidential contract language can shape the suggestions offered to a different client at a different firm, with neither party aware it happened. That is not a security breach in the conventional sense of an attacker gaining access. It is the feature working as designed, in a design that did not account for the confidentiality boundary that has to exist between matters.

Where the risk actually lives

Three places in a typical AI drafting feature carry this risk, and each needs a different answer.

Cross-session memory within one account. A feature that remembers what a user discussed in a previous session, to make later interactions feel more contextual, needs that memory scoped to the specific matter, not the whole account. A lawyer working two unrelated cases for two different clients under one login should not have the assistant's suggestions for one case shaped by facts from the other, since that crosses the same confidentiality line Rule 1.6(c) exists to protect even though both matters belong to the same firm.

Cross-customer training or fine-tuning. If a vendor improves its underlying model using data from customer interactions, the confidentiality question becomes whether any customer's client information could influence output shown to a different customer. This is the sharpest version of the risk, because it means one firm's confidential information could shape a suggestion delivered to a competing firm, and it needs an explicit, verifiable answer, not a general assurance that the vendor "takes privacy seriously."

Third-party model providers. Many AI features are built on top of a third-party model provider's API rather than a model the vendor trained itself. That arrangement raises the question of what the third-party provider does with the data sent to it: whether it is retained, for how long, and whether it is used to improve the provider's own models. A legal software vendor's confidentiality obligation does not stop at its own infrastructure. It extends to every place client data actually travels, including a subprocessor's servers.

What isolation has to look like

The answer to all three is architectural isolation, verified rather than assumed. Data used to inform one matter's suggestions should not be retrievable, even indirectly through a fine-tuned model's learned weights, in a different matter's session. That is a stronger requirement than typical multi-tenant data isolation, because it is not enough to separate the stored records; the isolation has to hold through any process that uses those records to shape a model's behavior, which is a much easier property to violate accidentally than simple database scoping.

A concrete design principle: any feature that uses customer data to improve outputs, whether through retrieval, fine-tuning, or few-shot examples in a prompt, needs an explicit boundary defined at the matter or account level, and that boundary needs to be testable the same way any other confidentiality control in this guide is testable. A test that creates two client matters with distinct confidential facts, exercises the drafting feature in both, and asserts that facts from one never appear, even indirectly, in the other's output is the kind of check that belongs in the eval suite covered on evals as legal compliance evidence.

For third-party model providers, the practical requirement is a data processing agreement that specifies retention and training use in terms specific enough that a firm's vendor due diligence review, covered on technology competence duty and what it means for vendors, can actually rely on it, rather than a general statement that data is "handled securely."

Accountability does not transfer to the model

There is a temptation, when something goes wrong with an AI feature, to treat the failure as an unexplainable property of the model rather than a design decision the team made. That framing does not hold up, and it does not satisfy a firm's confidentiality obligations either. If a drafting feature surfaces one client's information in another client's session, the cause is a design choice, whether or not anyone intended it: a memory scope set too broadly, a training pipeline that pooled data across customers, a third-party integration whose data handling was never verified. The team that built the feature is accountable for that design, in the same way our broader position on regulated industry software treats accountability as belonging to the team, not to a claim that the model behaved unpredictably.

This also connects to the broader question of what it means to take AI-generated code to production responsibly, covered in our AI-generated code to production guide: a feature built by AI, running in production, still needs the same independent verification as any other feature, and in legal software specifically, that verification has to include the confidentiality boundary described here.

What this does not resolve

Whether a specific AI drafting feature's design satisfies a specific bar's confidentiality expectations, and whether a specific third-party model provider's data handling meets a firm's own risk tolerance, are questions that need review from counsel and from the firm's own compliance function respectively. What this page describes is the shape of the risk and the kind of isolation a product needs to have built in before that review happens, so the review is confirming a real design rather than discovering a gap. Get in touch if you are building an AI drafting feature and want help designing the isolation boundary before it ships.