AI Governance for Law Firms: What to Write Down, What to Buy, and What to Build
Most firms I talk to are somewhere in the same place. Someone is already using a chatbot, nobody has written anything down, a vendor has been in touch about a platform that costs more than the firm spends on research, and the managing partner has a vague sense that this should have been addressed six months ago. That is not a technology problem. It is a governance problem, and it is tractable.
This piece is for lawyers and firm administrators rather than clients. I have written separately about what clients should ask their lawyer about AI use. What follows is the other side of that conversation: what a firm actually has to decide, in what order, and what the decisions cost.
The decision you have already made by default
Every firm has an AI policy. Most of them are unwritten and the policy is "whatever individual lawyers decide to do, without telling anyone." That is a position, it is just not a considered one, and it is the one with the most exposure, because the firm carries the obligations whether or not it knows what is being done in its name.
The obligations are not new. Competence under RPC 1.1 has always covered the tools you choose to use. Confidentiality under RPC 1.6 does not change because the disclosure is to a server instead of a person. Supervisory duties under RPC 5.1 and 5.3 reach the work of people and resources a lawyer directs. Nothing about AI required a new rule in order to be governed.
The reason to write a policy is not that the rules changed. It is that an unwritten policy cannot be supervised, and supervision is the actual duty.
What a usable policy contains
Short ones work better than long ones, because long ones are not read. A policy that fits on two pages and is actually followed beats a twenty-page document that lives in a shared drive.
It needs to answer five questions. Which tools are approved, and who approves a new one. What categories of information may be entered into which tool, stated concretely enough that someone can apply it at four in the afternoon. What has to be verified before it leaves the office, and by whom. What gets recorded, so that a question six months later has an answer. And what happens when someone gets it wrong, which should be a reporting path rather than a penalty, because a policy that punishes disclosure produces silence.
Notice that only one of those five is about the technology.
Five questions. Only one of them is about the technology.
The vendor question, which is a confidentiality question
When a firm evaluates an AI product, most of the meaningful diligence is contractual rather than technical. The questions that matter are where the data goes, who can see it, whether it trains anything, how long it is retained, what happens on termination, where it is hosted, and what the vendor is permitted to do with it in the gaps.
The gaps are where the problems are. A term that promises your data will not be used for training, and then permits use for "service improvement" or "any other lawful purpose," has given the promise back. A default-on data sharing setting is a different product than the same product with it off. An indemnity that is capped below the cost of a single confidentiality incident is a number, not a protection.
This is ordinary contract review, and it happens to be work I do. It is also work most firms skip, because the agreement arrives looking like a click-through and gets treated like one.
Verification has to be a workflow, not an instruction
The failure that produces discipline is uncritical reliance on an output that was never checked. Telling people to check is not a control, because the moment of risk is the moment someone is in a hurry.
What works is structural. Nothing cites to an authority that has not been pulled and read in the original. Nothing goes out over a signature without a named human having confirmed the parts that can be confirmed. The firm keeps a record of what was used where, so that the question can be answered later instead of reconstructed.
None of this is about distrusting the tool. It is the same discipline a firm applies to a first-year associate memo, which is also useful and also checked.
Build or buy, and the third option nobody names
Buying is right when the problem is common, the product is mature, and the work it does is not where your firm differentiates. Research platforms and document review tools are usually in this category.
Building is right when the problem is yours specifically, the data is yours, and the value is in the arrangement rather than the model. A firm with twenty years of its own forms, its own matter history, and its own way of handling a recurring transaction can get more out of a modest system built around that material than out of an expensive general platform that knows nothing about it.
The third option is assembly, and it is where most small and mid-sized firms actually land. You are not building a model and you are not buying a monolith. You are connecting components you control, keeping your material on your own hardware where it needs to stay, and adding only the pieces that earn their place. It is less impressive on a slide and it is frequently the correct answer.
The question that decides it is not technical ambition. It is whether the thing you want is a commodity or is specific to how you practice.
- The product is mature
- The work is not where you differentiate
- Research and document review usually sit here
- Your forms, your matter history
- Value is in the arrangement, not the model
- Beats a general platform that knows nothing about your material
- Components you control
- Your material stays on your hardware
- Add only the pieces that earn their place
Reading the product market without being sold to
The category is loud and the claims are hard to compare because vendors describe different things with the same words.
A few questions cut through most of it. What does this replace, specifically, and what did that cost before. What does it do when it does not know, and can it tell you. Where does the output come from, and can a human follow it back to a source. What happens to our material if we leave in a year. Who is liable when it is wrong.
A product that cannot answer the fourth and fifth questions clearly is not ready for a firm that owes duties to clients, whatever it does in a demo.
Billing, disclosure, and the client relationship
Fees must be reasonable under RPC 1.5, and that rule does the work here without needing an AI-specific gloss. A firm that completes in one hour what used to take four has to decide, deliberately, how that shows up on a bill, and the defensible answers are the ones the firm can explain out loud to the client it is billing.
On disclosure, the trend among sophisticated clients, particularly institutional ones, is to ask in the engagement letter and sometimes to restrict. Outside counsel guidelines increasingly address AI directly. A firm that has already decided its position answers that question in a sentence instead of scrambling.
Where firms actually get stuck
Waiting for certainty. The rules are not going to resolve into a checklist before you have to act, and the firms doing this well made reasonable decisions early and revisited them.
Buying first and governing later, which produces a tool nobody is allowed to describe to a client.
Writing a policy that bans everything, which moves the use onto personal devices where it cannot be seen at all.
Treating it as an IT project. The decisions are professional responsibility decisions, and they belong to lawyers.
What I do in this area
Three things, and they are separable.
Governance. Drafting the written policy, the intake and approval process for new tools, the verification workflow, and the client-facing language, sized to the firm rather than to a template.
Vendor and contract review. Reading the agreement that actually governs where your clientsâ information goes, and telling you what it permits in the gaps rather than what the sales page says.
Systems. Helping a firm decide between buying, building, and assembling, and where building is the answer, designing something that keeps the firmâs material under the firmâs control, logs what it did, and does not act without a human. I build and run systems of this kind in my own practice, which is the only reason I am willing to advise on them.
About my practice
I am an independent attorney in downtown Spokane, at 601 W. 1st Ave., Suite 1400, admitted in Washington and in Oregon. Alongside real estate, land use, business, and civil litigation work, I advise firms and small businesses on AI governance, technology vendor agreements, and the design of internal systems that have to hold confidential material. I also speak and write on AI governance for the profession.
If you want to talk
The first conversation is usually short and mostly diagnostic: what is already being used at your firm, what is written down, what you are being asked by clients, and what you are being sold. That is normally enough to say whether you need a policy, a contract read, a system, or simply a decision.
Disclaimer
This article is general information for lawyers about professional responsibility and technology, not legal advice, and reading it does not create an attorney-client relationship. Rules of professional conduct differ by jurisdiction and change. Confirm the rules in your own jurisdiction before relying on any of this.
This article is general information about Washington law, current as of publication. It is not legal advice, it does not create an attorney-client relationship, and the law changes. For advice on your own situation, speak to a lawyer.