AI for Law Firms: The Pilot Most Firms Run First
Most of what is written for this audience is a tour of products. Here are the research tools, here are the drafting tools, here is the review platform, here is the one your competitors bought. The tours are accurate and they answer a question that comes second. What decides whether any of it is worth having is which workflow you point it at, and that is a firm level decision rather than a tool level one.
There is also a pattern in which pilot gets chosen first, and it is close to the worst available option. The first pilot is almost always legal research, because it is the most visible use, the one every vendor demonstrates, and the one that requires no change to how anybody works. It is also the workflow where a result is hardest to see, for reasons that have nothing to do with how good the model is.
Why research is the wrong first pilot
Research is attractive because it looks like the central skill of the job. The trouble is everything around measuring it.
A research task has no fixed scope, so there is no before figure. Nobody records how long it took to answer a question last quarter, and the answers differ in quality in ways that are not written down anywhere. When the pilot ends, the honest report is that it felt faster, which is not a finding and will not survive a partners' meeting.
The verification burden also lands in the worst place. Any research output has to be checked against the authority itself before it goes anywhere near a client, and the checking is done by the person whose time the pilot was meant to save. Where the output is mostly right, the check is still a full check, because you cannot know which part is the wrong part without reading all of it. A tool that is right most of the time and must be verified every time has moved the work rather than removed it.
Then there is the failure mode everybody has now heard about. A fabricated citation in a filing is a professional problem, not a software problem, and one incident costs more than the whole pilot was ever going to save. That risk is manageable, and managing it means a verification step, which brings you back to the paragraph above.
None of this says research tools are useless. It says they are a poor place to find out whether your firm can get value from this, because the answer will be unmeasurable either way.
Sort the work by how the output is checked
The axis that predicts whether a workflow pays is not how hard it is or how clever it looks. It is how the result gets verified, and how much of the original work the verification repeats.
Verifiable against a source you already hold. Clause extraction from a contract, finding every instance of a defined term, pulling dates and parties out of a bundle, checking a signed version against the agreed version. The check is a comparison against a document in your possession, it is faster than doing the task by hand, and a miss is visible. This is where the reliable savings are, and it is the least exciting category in the room.
Verifiable by a person who was going to read it anyway. A first summary of a long document for somebody who will then read the document, a chronology from a bundle, an index, a draft of a routine letter from a precedent. The output removes a blank page rather than removing the review, and because the review was already in the plan, the saving is real and does not create a new obligation.
Verification repeats the work. Research memoranda, advice on an unsettled point, anything where the output is a judgement rather than a fact. Checking means doing the analysis, so the time saved is the typing. This is the category every demonstration uses and the last one to pilot.
Must not be delegated at all. Advice given to a client, a position taken in a filing, anything with a signature on it. The question here is not accuracy, it is who is responsible, and the answer never changes.
Sort your own practice that way and the shortlist is usually short, unglamorous and in the document heavy parts of the firm. The same sorting logic applies outside law, and the document processing piece sets out the measurement side of it in more detail.
Confidentiality is an architecture question, not a vendor promise
Every platform in this market will tell you that client data is not used for training, is isolated from other customers and does not leave the environment. Those claims are usually true and they are also not the part that is yours to get right.
The questions that change what you can build are the ones about your own obligations rather than the vendor's practices. Whether client information may be sent to a third party at all, under your engagement terms and the rules you practise under. Whether any of it is subject to restrictions on where it is processed. What your own retention schedule says, and what happens to a prompt and a response under it, since both are now records containing client information. Whether privilege is affected by a third party processing the material, and what your professional indemnity insurer expects you to have in place first.
Those answers decide the architecture before any product is chosen. A firm that may not send client material outside its own systems is not shopping for the same thing as a firm that may, and finding that out after the procurement is the expensive order to do it in. Rules here differ by jurisdiction and are actively changing, so this is a question for your own regulator's current guidance rather than for a vendor's compliance page.
One practical consequence worth planning for: the restriction is usually about content, not about the task. A workflow that can be run on a redacted or structurally extracted version of a document is often permissible where the same workflow on the raw file is not, and that distinction tends to be more useful than a search for a tool with better security marketing.
Run the pilot as a measurement, not as a trial
The reason pilots end inconclusively is that they are set up to produce an impression. A pilot that produces a number has a short list of requirements.
Pick one workflow from the first category above, where the check is a comparison against something you already hold. Capture the current state before anything is installed: how long the task takes, how often it is done, and what is currently missed when it is done by hand. That baseline is the whole pilot, and it is the step that gets skipped. Define what a wrong output costs in this specific workflow, because a missed renewal date and a clumsy sentence in a draft are not the same category of error. Then decide in advance what result would justify going further, and what result would mean stopping.
The part to resist is scope. A pilot that covers three workflows to look serious produces three sets of partial evidence and no decision. One workflow, measured properly, settles the question for the firm.
What this looks like in practice is closer to a process audit than a technology project, which is also why the firms that get the most out of it tend to be the ones that treated it as one. If the question in front of you is who should do that work rather than what it should cover, the piece on choosing between consulting firms sorts the kinds of help available, and the AI readiness assessment walks the same ground a scoping conversation opens with.
What to do with the result
A pilot that shows a saving in one document heavy workflow has told you something narrow and genuinely useful: this firm can get value here, and the next workflow in the same category is worth doing. That is how this compounds, one verified workflow at a time, and it is considerably less interesting than the version in the vendor deck.
A pilot that shows nothing is also a result, and it is worth more than the inconclusive one. It usually means the workflow chosen was in the third category, where verification repeats the work, and the sorting above will point at a better candidate. The firms that end up with nothing are not the ones whose pilot failed. They are the ones whose pilot had no baseline, so it could neither succeed nor fail, and the subject quietly went away for a year.
If the appetite is broader than one workflow, the honest sequencing is the same as it is anywhere else: a short view of where the work actually is before any build, which is what AI strategy work is for, and then a single narrow thing built properly rather than a platform bought in anticipation. What a custom build is good for is exactly the case where the workflow is specific to how your firm works, which in a law firm is most of them.