Writing a Law Firm AI Usage Policy That Staff Will Follow

The conversation about an AI policy almost always starts too late. By the time a managing partner raises it at a Monday meeting, a paralegal has already been pasting deposition excerpts into a free chatbot for four months to get faster summaries, a junior associate has run a first draft of a settlement letter through a consumer tool, and someone in accounts has uploaded an ageing report to see whether the model could spot patterns in slow payers. None of those people thought they were doing anything wrong. Nobody told them otherwise, and the tools are one browser tab away on a machine the firm issued them.

That is the situation a policy has to walk into. It is not a greenfield exercise where you decide whether the firm will use AI. The firm is already using it. The only real question is whether the use is visible, bounded and documented, or invisible and entirely dependent on the private judgement of whoever happens to be under deadline pressure at four in the afternoon. Policies that pretend otherwise get signed and ignored, because everyone reading them knows the document does not describe the building they work in.

The policies that actually change behaviour share a shape. They are short, they are written around specific moments in the working week rather than around abstract principles, they say plainly what is forbidden and what is permitted instead of hiding behind "as appropriate", and they attach the obligations to the matter file rather than to a PDF in a shared drive nobody opens. What follows is the content that belongs in one, in the order a firm should think about it.

Start by Mapping What Is Already Happening

Before you write a single rule, spend a week finding out what tools people are already using and for what. Do this without any threat attached, because the moment staff believe the answer will be held against them you will get a clean sheet of paper and a completely false picture. Ask the question in one-to-one terms rather than in a group meeting, and ask about tasks rather than product names. People do not think of themselves as "using AI" when they ask a chatbot to tidy up the tone of a client email, but that is exactly the behaviour your policy has to govern, and it will not surface if you ask whether anyone is using generative AI.

The map you build from that exercise is the single most useful input you have. It tells you which categories of work are genuinely under pressure, which is where the shortcuts appear. Summarising long records, drafting routine correspondence, translating an opening paragraph into plainer language, generating a first pass at chronologies, cleaning up a rough set of notes into something billable. Once you can see the pattern, the policy stops being a theoretical document about a technology and starts being a specific set of answers about the eight or nine tasks your firm actually uses these tools for. That specificity is what makes staff follow it, because they can find their own job in the text.

Confidentiality Is the Line That Matters Most

Every other section of the policy is downstream of this one. The duty of confidentiality does not have an exception for convenience, and in most common-law jurisdictions it covers everything relating to the representation, not merely the facts a client explicitly asked you to keep quiet. Anonymising a name does not fix this. A fact pattern involving a specific commercial dispute in a specific city over a specific contract is identifying even with every proper noun removed, and if the matter has been covered anywhere in the press, the model does not need the client's name to work out who you are talking about. Redaction as a confidentiality strategy is wishful thinking dressed up as diligence.

So the policy needs a hard, unambiguous statement of what must never enter a public consumer tool. Client documents in any form, whether uploaded, pasted or transcribed. Case facts specific enough to identify a party. Privileged communications. Settlement figures and negotiating positions. Personal data of clients, opposing parties, witnesses or staff. Anything under a protective order, sealing order or confidentiality undertaking. Financial records, including trust account information. Write that as a list of prohibited inputs in plain words, put it on one page, and make that page the thing new joiners read on day one. The general prohibition on "sharing confidential information with third parties" that already sits in your staff handbook will not do the job, because nobody experiences typing into a text box as sharing information with a third party.

Classify the Tools, Not Just the Tasks

The most common structural mistake is writing a policy that governs tasks while staying silent on tools. "You may use AI to draft correspondence" tells a paralegal nothing about whether they should use the free chatbot on their phone or the drafting feature inside the firm's practice management system, and those are radically different risk positions. A policy has to sort the tools into tiers and then say which tier is allowed for which category of information. That is the structure people can hold in their head, and holding it in their head is the entire point.

The practical split for most firms is three tiers. Public consumer tools with no firm agreement, which may be used only with entirely generic content and never with anything drawn from a matter. Contracted tools where the firm has a written agreement covering data handling, training exclusion and retention, which may be used with matter content subject to the verification and logging rules. And tools embedded inside systems the firm already controls, where the content never leaves the security boundary you have already accepted. That last tier is where confidentiality risk is lowest, because the document is sitting inside the same encrypted store it always was. In Casely, documents carry AES-256 encryption under a key held per firm, and every document carries a comment field recording what changed and why, which means an AI-assisted edit leaves the same trail as a human one rather than appearing as an unexplained new version.

Client Consent and the Engagement Letter Question

Whether you must tell clients that AI is used in their matter is genuinely unsettled and varies by jurisdiction. Bar and regulatory guidance in the United States, England and Wales, Canada and Australia has moved at different speeds and reached different emphases, and some individual courts have issued their own standing orders requiring disclosure or certification for filings prepared with generative tools. Do not let anyone in the firm tell you there is a single global answer. Check your own regulator's current position, check the standing orders of the courts you actually appear in, and check whether any of your institutional clients have imposed their own outside counsel requirements, because in-house legal departments have been far quicker to write AI clauses into their guidelines than most bars have been to write rules.

What you can decide internally, ahead of any of that, is a default posture. The workable default is that general-purpose use of firm-controlled tools for internal drafting and organisation does not require specific consent, while any use that involves sending client confidential information to an outside provider does. Build the disclosure into the engagement letter as standard language rather than treating it as a per-matter conversation, because a per-matter conversation gets skipped under pressure. And write a standing exception into the policy: if a client has told you not to use these tools on their work, that instruction overrides everything else in the document, and it needs to be recorded where the team will see it. A contact label on the client record and a note on the matter file is the difference between an instruction that is honoured and one that is technically on file somewhere.

Verification Duties Have to Be Written as Work, Not Warnings

Every AI policy in circulation says something about verifying output. Almost none of them say who verifies, against what, and by when. That gap is where the failures happen. A warning that "all AI output must be checked for accuracy" is a statement of hope. A rule that says every citation in any document touched by an AI tool must be pulled up in the primary source by the person who is signing the document, before it leaves the firm, is a task. Tasks get done. Warnings get nodded at.

Be specific about the failure modes, because they are not evenly distributed. Fabricated or misdescribed authority is the one that has ended careers, and it deserves its own rule with no discretion in it. Beyond that, watch for confidently wrong procedural deadlines, quiet omissions where the model summarised a document and dropped the paragraph that cut against your position, jurisdictional drift where the output describes the law of a place your matter is not in, and arithmetic in damages or interest calculations that looks tidy and is wrong. A verification standard that names these five things gives a reviewer something concrete to do. A verification standard that says "check the output" gives them permission to skim.

Record-Keeping That Survives a Complaint

Two years after the fact, when a client complains or an insurer asks questions, the firm's position rests entirely on what it can show. That means the policy has to say what gets recorded and where it lives. The minimum is that the matter file shows which documents had AI assistance in their preparation, which tool was used, who reviewed the output and when they signed off. That is not a heavy record. It is a line in the document history, and it takes seconds if the system you use captures it as a matter of course rather than requiring someone to remember to write a memo.

Where firms go wrong is keeping this log in a separate spreadsheet. A separate spreadsheet is a compliance artefact that survives exactly as long as the enthusiasm of the person who created it. Attach the record to the matter instead, so it is discoverable in the same place as everything else about that piece of work. In Casely every document version carries a comment field recording what changed and why, so an AI-assisted draft and its review sit in the same version history as the rest of the file. Corrections work the same way across the platform. A voided trust transaction stays visible rather than being deleted, and that principle is the right instinct to carry into AI record-keeping too. You want the record of what happened, including the corrections, not a tidy final state that hides its own history.

Billing for AI-Assisted Work Without a Fight

This is the section most firms skip and then regret. If a task that used to take three hours now takes forty minutes, what goes on the invoice? For hourly work the honest answer in most jurisdictions is that you bill the time you actually spent, including the time spent verifying, and you do not bill the client for hours that were never worked. Attempting to bill the old number for the new task is the fastest route to a fee dispute you will lose, and it is exactly the kind of thing that reads badly in a complaint file. Say it in the policy in one sentence so nobody has to guess.

The harder question is whether efficiency should be captured somewhere else. Some firms respond by moving more work to flat fees, where the client buys an outcome and the firm keeps the benefit of doing it faster. That is a legitimate business answer, and it needs the billing system to support hourly, flat-fee, contingency and blended arrangements natively rather than by workaround, which is how Casely handles it. Whichever way you go, the policy should also address whether any AI tool cost is passed through as a disbursement. If your jurisdiction treats software as overhead rather than a recoverable expense, and many do, then quietly adding it to a bill as a line item is a problem waiting to surface. Confirm the position locally rather than assuming.

Vendor Diligence and the Terms Nobody Reads

Before a tool moves into your permitted tier, someone has to read the contract properly. Four questions decide it. Does the provider train models on your inputs, and is the opt-out contractual or a setting that can quietly change? How long is data retained, and can you require deletion? Where is it processed, which matters enormously if you handle European personal data or act for clients with data residency requirements? And will the provider sign terms that acknowledge the confidential and privileged nature of what you are sending, including a duty to notify you promptly of any breach or any legal demand for the data?

The answers determine the tier, not the marketing. A tool sold specifically to lawyers is not automatically safer than a general one, and a general one on a properly negotiated enterprise agreement can be safer than a legal-branded product on standard consumer terms. Write the diligence questions into the policy as a gate, name the person who owns the decision, and forbid anyone else from adding a tool to the approved list. Firms that skip the named owner end up with a shadow estate of trial subscriptions bought on personal cards, each one a separate confidentiality exposure nobody is tracking.

Ethical Walls and Access Boundaries Do Not Bend for AI

An AI tool that can read across your document store will happily surface a document from a matter the person asking has no right to see. This is the quietest risk in the whole subject and the one most policies miss entirely, because it does not feel like a disclosure. Nobody sent anything anywhere. Someone simply asked a question and got an answer drawn from material behind a wall. If your access controls are cosmetic, hiding items from a menu while leaving them reachable by other routes, an AI layer on top will find those routes without meaning to.

The policy should state that no AI capability may be granted access broader than the individual user's own permissions, and that walls apply to AI-assisted retrieval exactly as they apply to a person walking into a file room. This is only enforceable if the underlying system enforces access at the data layer rather than in the interface. Casely applies ethical walls at the server and data-access layer, so a walled user genuinely cannot reach a restricted matter by any path, including search, the calendar, or a link someone forwarded them. The same discipline applies to conflict checking, which searches the full contact and matter history including every role a party has played and every closed matter, because a conflicts process that only looks at open matters was never complete in the first place.

Training That Changes Behaviour

A policy delivered as an email attachment with a read receipt has taught nobody anything. Training that works is short, repeated, and built around examples from your own practice. Take a real anonymised task from the map you built in the first week, show the wrong way and the right way side by side, and let people ask the awkward questions in the room. The single most valuable session most firms run is one where a partner walks through an output that looked completely convincing and was materially wrong, because that does more to calibrate trust than any number of paragraphs about limitations.

Set the cadence in the policy so it does not depend on anyone remembering. Onboarding for every new joiner including temporary and contract staff, a refresher twice a year, and an immediate update whenever a tool is added to or removed from the approved list. Keep an attendance record, because if a complaint ever arrives the firm's ability to show a functioning training programme is part of its answer. And make sure the training reaches the people who are not lawyers. Support staff, bookkeepers and marketing all handle client information, and in practice they are often the ones with the least guidance and the most time pressure.

Enforcement, Amnesty and the Review Cycle

A policy with no consequences is a suggestion, and a policy with only consequences drives the behaviour underground where you cannot see it. You need both halves. State plainly that a confidentiality breach involving an unapproved tool is a serious matter handled through the firm's existing disciplinary process, and in the same document offer a genuine amnesty for anyone who reports their own past use before a set date. The amnesty is not softness. It is the only way you will ever find out what has already gone into which tool, and that knowledge is worth far more than the satisfaction of disciplining someone for something the firm never told them not to do.

Then set a review date and keep it. This field moves faster than your policy document does, and a rule written around what tools could do eighteen months ago will be quietly wrong in ways nobody notices until it matters. Twice a year, the named owner reviews the approved tool list, checks whether any regulator or court in the jurisdictions you practise in has issued new guidance, reads the incident log, and updates the document. Version the policy and keep the old versions, because if you ever need to show what the rule was at the time of a particular piece of work, "the current policy" is not an answer.

Write the First Version This Month

The perfect AI policy does not exist and waiting for one is itself a decision, made in favour of the status quo where everyone improvises privately. Write a first version in a fortnight. One page of prohibited inputs, one page of approved tools by tier, a verification standard with named steps, a record-keeping rule that attaches to the matter, a billing paragraph, and a review date. Six pages at most. Circulate it, run one training session, and accept that version two will be better because it will be informed by the questions people actually ask.

The part that determines whether any of it holds is the system underneath. If access permissions are cosmetic, if document history does not record who changed what and why, if conflict checks only reach open matters, then the policy is asking staff to maintain by memory what the software should be enforcing by default. Getting the foundation right is a prerequisite, not a nice-to-have, and it is worth auditing your legal document management software and your conflict checking process against the policy you are about to write rather than the other way around.

Start with the confidentiality page, because it is the one that prevents the failure you cannot undo. Everything else in the policy protects the firm's position after something has gone wrong. That page stops it going wrong in the first place, and it costs nothing but an afternoon and the willingness to write down, in plain words, the things nobody should ever paste into a box.