Choosing & Deploying AI Tools in a Law firm: What Decides Whether It Works
The things worth checking before you sign, and how to make sure the tool you buy actually gets used.
Choosing an AI tool for a law firm is harder than it first looks…
…and not because the tools are bad – most of them do broadly what they say.
The difficulty is that the things deciding whether a purchase works out are rarely the things a demo puts in front of you: how it copes with your real matters rather than a tidy example, whether it fits the way people already work, what the contract says about your data once the enthusiasm has worn off, and whether anyone is still using it come the new year.
We build AI tools for law firms ourselves, so we’ve sat on both sides of this – the selection meeting and the sales meeting. What follows is the set of questions we’d want a firm to work through before committing to anything, ours included. None of it is complicated. It’s mostly the things that are easy to lose sight of when a tool is impressive and everyone’s keen to get on with it.
What decides whether a tool works out
A demo shows you what a tool can do at its best. What you live with is how it behaves on a difficult matter, late in the day, in the hands of someone inexperienced.
Buyer thinking across the profession has moved the same way: the question used to be how good the underlying model is, and it’s now become whether a tool is dependable in real use, whether it fits how the firm works, and whether people will actually reach for it.
A demo shows you what a tool can do at its best. What you live with is how it behaves on a difficult matter, late in the day, in the hands of someone inexperienced.
The question to ask before you talk to any vendor
It may sounds obvious, but it’s the step most often skipped. A great deal of legal AI gets bought because AI is what firms feel they ought to be buying – there’s a sense of being left behind, a demo was impressive, a competitor mentioned using it at a conference. None of those is a problem the tool solves; they’re reasons to feel you should act. And a tool bought to answer a feeling rather than a need is the one most likely to end up unused.
The firms that buy well start from the other end. They can name the actual friction – onboarding that takes too long, a document review that eats junior time, a bottleneck everyone complains about – and they judge a tool by whether it removes that specific friction in their specific setup. That framing changes what “good” even means: the best tool isn’t the most capable one in the abstract, it’s the one that fits the way this firm already works and takes a real pain away.
A tool that solves a problem you don't have is worse than no tool, because you'll pay for it, roll it out, and probably end up resenting it.
This is also where fit does more work than features. A tool that drops into the case management and document systems you already run clears a far lower bar than one that asks the firm to work somewhere new – not because integration is inherently virtuous, but because a tool that lives where the work already happens is the one people actually use.
If a purchase requires everyone to change how they work to accommodate it, that cost belongs in the decision from the start, weighed honestly against the problem it’s meant to solve.
So, before the demos, before the comparison, two questions worth answering plainly: what would this fix that’s genuinely hurting us now, and does it fit how we already work (or are we reaching for AI because it feels like the thing to do)? A clear answer to the first, and an honest one to the second, will tell you more than any vendor ever will.
The contract questions AI adds to the usual list
What’s worth drawing out is the handful of questions AI adds on top, the ones a standard IT security review wasn’t built to catch, and that sit in the contract and the data processing agreement rather than on the website.
The first is the model provider behind the tool, which is almost always a sub-processor in its own right, so its terms reach your data by extension, and “who processes this, and on what terms” becomes a question about a company whose name may not appear on the tool at all.
The second is the training opt-out, and whether it’s a contractual default or a setting someone has to find and switch off, because those are very different promises once client data is involved.
The third is what becomes of your firm’s own work – whether the outputs, and the matters behind them, help improve a model that other firms will also draw on. None of these surface in a general supplier review, and all three are worth having answered in writing before a signature goes anywhere.
The UK’s direction for now is regulation through individual regulators rather than a single AI Act, so your footing rests on obligations you already understand.
Can it show its work?
Does it fit how the firm already works?
Both models exist and neither is automatically right. Some firms are ready to replace a core system, but most aren’t. A tool that fits alongside what’s already there asks far less of people than one that adds another login and another place to remember to look.
It’s worth weighing honestly against your own appetite for disruption, and treating “everyone has to change how they work” as a real line in the cost of a tool rather than something you discover once your team starts using it.
The tool is only as good as the data under it
Point a good tool at messy data and it returns answers that are confident, plausible and every so often wrong (and in our experience these are the most expensive ones to trust, because they’re the hardest to spot).
That’s why data readiness belongs in the buying decision.
Before committing, it’s worth understanding how much of the likely outcome rests on the state of your own data as opposed to the tool itself, because a pilot that underwhelms is sometimes a data problem in a software problem’s clothing, and changing vendors won’t fix it.
Buying is the easy part: getting it used
The tool worked perfectly well; it simply ended up as shelfware with an invoice attached, bought and launched and then left to gather dust once the novelty faded. What decides the outcome is usually whether the firm treated the rollout as an actual change to be managed.
The tools that take hold tend to share the same unglamorous ingredients: a real owner for the rollout, training aimed at the people using it rather than the people who chose it, a few early wins on problems everyone recognises, and a way for difficulties to surface and get fixed before they put people off for good.
A capable tool nobody opens is worse value than a modest one everybody does.
Where this fits
If you’re setting the wider rules alongside a selection, our guide to AI governance for law firms covers what needs to be in place before anything goes live, and our guide to building an AI policy covers where these decisions get written down.
As we said at the start, we build AI tools for UK law firms, made to work inside the case management and document systems firms already run rather than replace them.
If you’re weighing up your options and would like a straight conversation about where we do and don’t suit a firm like yours, we’re always glad to have one.
We already have Microsoft Copilot, do we need a specialist legal AI tool as well?
Increasingly the real question. Since Microsoft’s Legal Agent and Claude arrived in Word, a fair amount of drafting and summarising now sits in software many firms already license. Purpose-built legal tools can still differ on citation discipline, legal tuning, verifiability and what’s promised in the contract, but the honest test is what a tool does that the assistant you already own doesn’t, shown on your own work rather than asserted.
What should a law firm check before buying an AI tool?
Beyond whether it’s capable: where your data lives and who processes it, whether the training opt-out is contractual and on by default, the retention and breach terms, whether outputs can be checked against source, how well it fits your existing systems, and what leaving would involve. The contract and the data processing agreement answer far more of these than a website does.
How do we know if an AI tool is accurate enough for legal work?
Should we choose a tool that integrates with our systems, or replace the systems?
Why do AI tools fail in law firms?
Usually because they stop being used, having been launched without the change management that makes them stick. Capability is seldom the problem; adoption is the real work. A named owner, proper training and a few early wins tend to do more than any feature list.