Somewhere in the middle of last year, a legal team that had spent considerable effort evaluating AI platforms, run the demos, compared the feature sets, and signed off on a subscription, found itself six months in with almost nobody using the tool. The lawyers were still running searches the way they always had. The research was still going out to external counsel on the same timeline. The tool existed. It had no place in how the team worked.
This is not an unusual story. Across in-house legal functions, AI procurement has accelerated while adoption has stalled, and the gap between the two tells you something worth understanding clearly before you spend another dollar.
The prevailing assumption in the market is that legal AI adoption is a product problem. Buy the right tool and your team will use it. Get the procurement decision right, the thinking goes, and the downstream behaviour follows. This is why evaluation cycles obsess over feature comparisons. Which platform has the better interface? Which one covers more jurisdictions? Which one produces the cleaner output? If you choose correctly, adoption takes care of itself.
We think this assumption is wrong, and the evidence accumulates everywhere you look. Legal teams that have purchased capable, well-reviewed AI products are reporting minimal engagement. Tools are installed and then bypassed. Lawyers return to familiar workflows because the new tool has no obvious place in how they do their work, regardless of how it performed in the demo. The problem is organisational, sometimes behavioural. The product is rarely the explanation.
When a lawyer sits down to work, they follow a sequence of steps shaped by years of practice, by what their manager expected, by the tools available at the start of their career, and by whatever workarounds proved reliable under time pressure. That sequence is explicit only in its absence from any process document. It is how the work gets done. And it is remarkably resistant to a software licence arriving in an onboarding email.
Legal AI tools, even very good ones, do not insert themselves into existing workflows. They require deliberate redesign of how work moves through a team: which tasks go where, at what stage, in what order. Without that redesign, the tool sits adjacent to the workflow rather than inside it. Lawyers recognise it as something that exists but don't reach for it by habit, because there is no habitual moment in their day when it clearly belongs.
This is the part that procurement doesn't solve. You can evaluate a tool with great rigour and still fail to specify how it fits into the sequence a junior counsel follows when a question comes in, or what the trigger is for a GC to reach for it rather than call external counsel. Those are design questions, and they require different work than vendor selection.
Nowhere is this clearer than in how in-house teams use external counsel. The pattern is well established: a question arrives, the GC's office has limited bandwidth to research it thoroughly, so it gets escalated. External counsel bills for research that the in-house team could, with the right tool and the right workflow, handle itself. The cost accumulates. The delay compounds. And the cycle repeats, not out of any lack of capability, but because the sequence of events has never been redesigned to accommodate a different first step.
AI legal tools, properly placed, can function as a first-line intelligence layer before that escalation decision. The GC reaches for the tool, gets a substantive answer grounded in primary law, and then decides whether the matter requires external specialist input or whether it has been resolved. That changes the economics of the team materially. It only works if the workflow has been deliberately redesigned to include that step. If the tool is available but the trigger for using it is undefined, the escalation still goes out by habit.
We have watched this play out with GCs who adopted Habeas after treating implementation as a workflow question, not a procurement one. Foundational research processes that used to take a full morning can now be completed in minutes, and the downstream effect on external counsel spend is significant: the questions that used to go straight out to firms are being resolved internally, with specialist escalation reserved for the work that warrants it.
That outcome is contingent on design. It required a deliberate decision about where in the daily sequence the tool sits, what kind of question should trigger it, and what the threshold is for going further. Without that design work, the tool would have remained a feature of the procurement catalogue rather than a feature of the practice.
We are not arguing that implementation requires a months-long change management programme. We are arguing that it requires more thought than licence activation.
The practical version of this is modest. It starts with naming the specific moments in the working day when the tool should be the first step. This means being specific: which research tasks, arising in which contexts, at what point in the matter lifecycle. A GC covering employment, privacy, contractual compliance, and regulatory questions across a business faces a constantly shifting surface. The AI tool earns its place by being the reliable first step for a defined category of those questions, handled before anything else happens.
From there, adoption tends to build on itself. A GC who reaches for the tool on employment questions and gets a substantive answer quickly, grounded in Australian authority with traceable citations, extends that reflex to other areas. The tool becomes part of the sequence because it has earned a position in the sequence. That process starts with specificity, not aspiration.
This is also why the "try it and see" approach so often fails. Giving a team access and telling them to experiment is not workflow design. Experimentation without a defined use case produces patchy engagement and then disengagement. The team hasn't been given a concrete workflow reason to reach for the tool repeatedly, and without that reason, it stays dormant.
We have a stake in saying this clearly: buying Habeas is not sufficient. A subscription does not improve a legal team's output. A workflow that includes Habeas, built deliberately and with some attention to where in the sequence it belongs, can change how a team works in ways that are measurable. The GC who reshaped how her team handles first-line queries, and who recovered material external counsel spend in the process, achieved that by treating implementation as a design problem. The tool was necessary; the design was the variable.
This is the honest version of what AI adoption looks like in a legal function. The product has to be capable. The citations have to be traceable, the sources have to be real, and the answers have to hold up when a lawyer reads them carefully. Those are table stakes, and they are not trivial. They are also the beginning, not the sum of it.
The legal AI market has a tendency to collapse the distinction between purchase and use, because vendors benefit from doing so. The harder truth is that the two are different problems requiring different attention. Most organisations have become reasonably good at the first. Very few have addressed the second with the same rigour.
The teams getting genuine value from legal AI tools are not distinguished by the thoroughness of their procurement process. They are distinguished by what they did after procurement: asked, concretely, where this tool sits in how we do our work. That question produces a different set of decisions than the evaluation process does, and those decisions determine whether the tool earns its place.
If you are a GC or a legal operations lead with a tool that is underused, the product is probably not the problem. The sequence is. Working out where the tool belongs in the sequence, and making that concrete enough that lawyers reach for it by reflex rather than by effort, is the work that adoption requires.
We are happy to show you how other in-house teams have approached that design problem. Book a demo at habeas.ai and we can start with the workflow rather than the feature list.
The legal research in this article was conducted and every citation verified using Habeas, the Australian legal AI research platform.
