Client Confidentiality When Your Firm Uses AI Tools

Here is the honest situation in most firms right now. Somebody on your team has already pasted a client document into an AI tool. Maybe it was a paralegal summarising a two hundred page discovery production at nine at night, maybe it was an associate asking for a cleaner version of a paragraph in a settlement agreement, maybe it was you. Nobody announced it, nobody logged it, and there was no policy telling them not to. The work came back faster and better and so it happened again the next week, and by now it is simply part of how the firm operates. That is not a hypothetical risk sitting in a future compliance memo, that is the current state of the practice, and the confidentiality question attached to it has already been answered by default rather than by decision.

What makes this genuinely different from every other software risk your firm has managed is that the exposure is invisible at the moment it happens. When a laptop is stolen you know a laptop was stolen. When an email goes to the wrong recipient you usually find out within the hour. When privileged material is typed into a text box on a website, nothing appears to happen at all, the answer comes back, the work gets done, and the only record of the disclosure sits on infrastructure you do not own and cannot inspect. There is no incident, no alert, no ticket. The question of whether a duty of confidentiality was breached depends entirely on the terms attached to that specific product on that specific day, which almost nobody in the firm has read.

So the useful conversation is not whether your firm should use AI, because that argument is over and the tools are too good to give up. The useful conversation is a much more boring, much more technical one about where the bytes go. Different deployment models route client data to genuinely different places under genuinely different contracts, and the difference between a defensible position and an indefensible one usually comes down to which of those models a staff member happened to click on. Let me walk through the actual paths.

The four deployment models, and where your data lands in each

The first model is the consumer chat interface, the free or personal-tier website that anyone can sign up for with a work email in about forty seconds. Text typed into it travels to the provider's servers, gets processed, and is retained under whatever the consumer terms of service say, which historically has often included some form of human review for safety and quality, and in some cases use of the conversation to improve future models unless a setting is changed. The critical part is that nobody at your firm negotiated those terms, nobody at your firm can change them, and the provider can amend them with notice you will probably not read. This is the model your staff are most likely already using, because it costs nothing and requires no approval from anyone.

The second model is direct API access, where an application your firm controls sends text to the provider programmatically. The commercial terms attached to API and business tiers are frequently different from the consumer terms of the same provider, often with no training on submitted content and shorter retention windows, but the words "often" and "frequently" are doing real work in that sentence and you must confirm the specifics for your provider and your plan rather than assuming the industry norm applies to you. The third model is an enterprise or dedicated tenant, where the provider contractually commits to isolation, defined retention, and usually a data processing agreement your firm can actually sign. The fourth is a model running entirely inside infrastructure you or your practice management vendor control, where the text never leaves the boundary at all. These four are not variations on a theme. They are four different confidentiality postures wearing the same interface.

Why the consumer tier is the specific problem, not AI generally

The reason the consumer tier deserves singling out is not that the underlying model is less capable or less secure in any technical sense. It is that the relationship is wrong. Your firm has no contract, no data processing agreement, no defined retention period, no named subprocessor list, and no ability to demand deletion in a form that would satisfy a regulator asking questions later. You are a member of the public using a product, and privileged client material is being handled under the same terms as somebody asking for a lasagne recipe. That mismatch is the entire issue, and no amount of confidence in the provider's engineering fixes it, because engineering quality is not what a bar regulator will ask you about.

There is a second problem that firms underestimate, which is that consumer accounts are personal. The associate who used their own account to summarise a witness statement takes that account with them when they leave for a competitor, along with a conversation history containing your client's material. You cannot audit it, you cannot revoke it, and you will never know what is in it. Compare that to how your practice management system handles a departing employee, where access is revoked centrally, documents stay encrypted under a per-firm key, and the record of who touched what remains inside the firm's control. Shadow AI use quietly creates a category of firm data that lives outside every control you have built.

The training question, and the answer you should insist on

Every vendor will tell you they do not train on your data. That sentence, on its own, is close to meaningless, and you should treat it as the beginning of the conversation rather than the end of it. Ask which entity the commitment binds, because a practice management vendor promising not to train on your data says nothing about whether the model provider sitting behind their product has made the same promise. Ask whether the commitment is in the contract you sign or only on a marketing page, because the marketing page can be edited on a Tuesday afternoon and the contract cannot. Ask whether it covers all of your content or only content you submit through certain features.

Then push one level further and ask about human review, which is a genuinely separate question from training. A provider can truthfully say your data does not train the model while still allowing employees or contractors to read submissions flagged for safety, abuse, or quality evaluation. That is a person reading your client's material, which is exactly the disclosure your duty of confidentiality is concerned with, regardless of whether a model weight changed as a result. Ask what triggers review, who performs it, whether they are employees or contractors, what jurisdiction they sit in, and whether your firm can opt out. A vendor who cannot answer those five questions crisply has not thought about legal customers, and that is information worth having before you sign anything.

Retention is the question that quietly matters most

Retention is where the confidentiality analysis usually breaks, because it is the least glamorous question and the one vendors answer most vaguely. If a provider holds submitted content for thirty days for abuse monitoring, then your client's material sits on third party infrastructure for thirty days regardless of how good the training promise is. If they hold it indefinitely until you delete it, then every document any staff member has ever submitted is still there. Ask for a number in days, ask what happens to that data during those days, and ask whether deletion propagates to backups and logs or only removes the item from the interface you can see.

The reason this matters beyond the abstract duty is discovery, subpoenas, and government access requests. Data that exists can be compelled, and data held in a jurisdiction where your firm has no standing to object can be compelled without you ever being told. A firm that cannot say where a client's material is physically stored cannot answer the question a sophisticated client will eventually ask during their own vendor review. Firms that handle regulated industries, government work, or cross border matters should treat data location as a hard requirement rather than a preference, and should confirm what applies under their own regime, because data residency obligations differ substantially between the United States, the United Kingdom, the European Economic Area, Canada, and Australia.

AI features inside software you already trust are still deployments

Here is the part firms consistently miss. The AI risk assessment does not only apply to tools somebody deliberately went and signed up for. It applies to every feature quietly added to software your firm already runs, the document summariser that appeared in your email client, the meeting notes generator switched on in your video conferencing tool, the drafting assistant that showed up in your word processor after an update. Each of those is a data flow out of your firm, and each was enabled by a product decision made by a vendor rather than a risk decision made by you.

The right move is to inventory the tools your firm already pays for and check, for each one, whether an AI feature has been enabled by default and where its processing happens. Many of these features can be disabled at the tenant level by an administrator, which is a five minute task that meaningfully reduces surface area. The ones you decide to keep should be documented in the same place as your deliberately chosen tools, so that when a client asks what AI touches their matter, the answer is a list rather than a guess.

The confidentiality duty does not care which tool you used

The professional obligation here is not new and no regulator has invented a special AI exception to it. In United States jurisdictions that follow the ABA Model Rules, Rule 1.6 requires reasonable efforts to prevent unauthorised disclosure of information relating to the representation, and the technology competence commentary attached to Rule 1.1 has been adopted in most but not all states. In England and Wales the SRA Standards and Regulations impose confidentiality duties that do not soften because a tool was convenient. Canada, Australia, and other common law jurisdictions carry their own equivalents through their law societies and conduct rules. Several bars and law societies have published guidance specifically on generative AI, and the position continues to move, so confirm your own regulator's current position rather than relying on a general summary including this one.

What is genuinely consistent across those regimes is the shape of the standard, which asks whether the firm took reasonable steps given the sensitivity of the information and the available alternatives. That is a standard you can actually meet, and it is also a standard you can visibly fail if you never looked at the question at all. A firm that evaluated three tools, chose one with a signed data processing agreement, disabled the risky defaults elsewhere, and trained its staff has a defensible answer. A firm that never asked has nothing to say when the question arrives, and the absence of any assessment is itself the finding.

When client consent is the right call, and when it is not enough

Consent is a genuine tool and firms should use it more deliberately than they do, but it needs to be the right kind of consent. Blanket language buried in an engagement letter saying the firm may use technology in performing services is close to worthless, because it does not describe anything the client could meaningfully agree to. Consent that actually does work is specific, naming the category of tool, the kind of material that would be submitted, and the safeguards in place. That is a paragraph you can write once and reuse, and clients who are themselves running AI programmes internally will often be relieved to see it addressed rather than avoided.

Consent is the right call when the material is sensitive enough that reasonable steps alone leave a residual question, when the client is sophisticated and will ask anyway, when the engagement involves a third party's confidential information covered by a protective order or NDA, or when the matter touches a regulated sector with its own vendor approval requirements. Consent is not enough, and should not be sought as a substitute, when the underlying deployment is simply inadequate. A client cannot meaningfully consent to a risk you have not characterised, and getting a signature on a vague permission does not convert an unmanaged consumer account into a defensible practice. Some material should never leave the firm's controlled environment regardless of what anyone signed, and the policy should say so plainly.

Protective orders, court rules, and third party confidences

There is a category of material where the analysis is not about your client at all. Documents produced under a protective order, material covered by a non disclosure agreement your client signed, sealed filings, and information belonging to opposing parties or third parties all carry restrictions that your client cannot waive on your behalf. Submitting that material to an external processor may breach the order or the agreement directly, and the fact that your own client was comfortable with AI use is not a defence. Read the protective order in every matter where you plan to use AI on the production, because many of them contain disclosure limitations broad enough to cover exactly this.

Courts have also begun addressing AI use directly through standing orders and practice directions in some jurisdictions, mostly around disclosure of AI assisted drafting and certification of citations, and these vary enormously between courts even within the same country. This is a per court, per judge question rather than a national one, so check the standing orders that apply to your specific matters. The practical habit worth building is to treat the AI question as part of matter opening, recorded against the matter itself alongside the conflict check and the fee arrangement, rather than as a firm level policy that nobody consults when it counts.

Internal exposure, because not every leak goes outside the firm

Firms focus almost entirely on data leaving the building and underweight what happens inside it. If an AI feature indexes your document store to answer questions, the boundary that matters is what that index respects. A tool that ingests everything and then answers a question by drawing on a matter the asking user is walled off from has just defeated your ethical wall, and it will have done so in a way that looks like helpfulness rather than a breach. This is the specific reason Casely enforces ethical walls at the server and data access layer rather than in the interface, so a walled user genuinely cannot reach a restricted matter by any route, including search, calendar, or a link somebody forwarded them.

The same principle applies to conflicts. A conflict check is only worth something if it searches the full contact and matter history, every role a party played, including closed matters, which is how Casely handles it. An AI assistant sitting on top of a partial index will produce a confident answer built on incomplete data, which is worse than no answer because it carries the appearance of diligence. When you evaluate any AI feature offered inside your practice management system, the question to ask is not how good the summaries are. It is whether the feature respects the same permission and wall boundaries as the rest of the system, enforced at the same layer, verified rather than assumed.

What a workable firm policy actually contains

A policy that works is short, names specific products, and answers the question a paralegal has at nine at night. It should list the approved tools by name, state plainly that personal accounts are not to be used for firm work, define the categories of material that may never be submitted to any external tool regardless of approval, and name the person who approves an exception. It should also say what happens when someone finds a new tool they want to use, because the alternative to a clear request path is not compliance, it is quiet use. Anything longer than two pages will not be read and therefore will not be followed.

The other half of a workable policy is a record. Every document in Casely carries a comment field recording what changed and why, and that same instinct should extend to AI use, so that a matter file shows where AI assisted with drafting or review and under what tool. This is not bureaucracy for its own sake, it is the artefact that lets you answer a client question, a regulator question, or an insurer question two years later with something better than recollection. Firms that already log substantive decisions against the matter will find this a small addition, and firms that do not have a bigger problem than AI.

The standard your firm should hold itself to

Strip away the novelty and this is the same discipline your firm should already apply to every vendor that touches client data. You ask where the data goes, you ask who can read it, you ask how long it stays, you get the answers in writing, and you write down the decision you made. AI tools feel different because they arrived quickly, because the interface is a text box rather than a procurement process, and because they are useful enough that people adopt them before anyone reviews them. None of that changes the analysis, it just means the analysis has to catch up to behaviour that has already started.

The firms handling this well are not the ones that banned AI, because those bans are being ignored inside the firms that issued them. They are the ones that picked a deployment model they could defend, sanctioned specific tools, disabled the defaults nobody chose, wrote two pages that people actually read, and built the record as they went. That is a week of work, not a project, and it converts an open ended exposure into a documented decision. The same logic should apply to the system holding your matters underneath all of it, which is why encryption with a per-firm key, walls enforced at the data layer, and a privilege filtered client portal matter more once AI is in the picture, not less.

If you have not done the inventory yet, start there this week, because you cannot write a policy about tools you have not listed. Casely is cloud native with nothing to install and a free plan to start at zero, so a firm can see how walls, conflict checking across the full matter history, and per-matter isolated ledgers behave before committing to anything. Whatever system you land on, make the AI question part of matter opening rather than a memo nobody opens, and confirm the specific rules that apply in your jurisdiction with your own regulator, since the guidance in this area is still moving and differs meaningfully between them.