AI for Law Firms
Most firms do not need AI to practise law. They need it to stop losing matters between the enquiry and the engagement, and to stop paying attorney rates for work that is filing.
The pattern
A firm grows, adds a platform for each new problem, and ends up running eight of them. None of them share a record. Intake lives in one, matters in another, documents in a third, and the connective tissue between them is a person re-typing things.
The cost shows up in two places. Prospects drop out during intake because follow-up depends on somebody remembering. And qualified people spend a meaningful share of the week on administrative handoffs that nobody would pay an attorney rate for if the line item were visible.
Neither of those is a legal problem. Both are operational, which is why they are solvable.
Where it works
These are the candidates that come up repeatedly in firms between roughly ten and a hundred people. Not all four will apply to you, and the order matters more than the list.
Prospects go quiet between the first call and the signed engagement, and nobody notices until the month closes. This is the highest-value candidate in most firms because the work is repetitive, the timing matters more than the wording, and the cost of missing it is a lost matter rather than a slower one.
First-pass categorisation of discovery, medical records, and case files. AI is good at sorting and summarising a large pile so an attorney starts from a shortlist instead of page one. It is not good at deciding what is material, and it should not be asked to.
Where does this case stand, who is waiting on whom, and what has not moved in two weeks. Firms usually answer this by asking three people. A system that assembles it from the tools you already run removes a standing meeting.
Not an AI problem, but it surfaces in the same audit. Eight platforms that do not talk to each other create duplicate entry and no single source of truth. Fixing the seams is often cheaper and higher-value than adding anything new.
Where it does not
A workflow is a poor AI candidate when the process is not agreed. If three people run intake three different ways, automating it just picks one of them and makes the disagreement permanent. Write the process down first; sometimes that is the entire fix.
It is also a poor candidate when the volume is low. A task that happens four times a month rarely repays a build, however annoying it is. And it is the wrong tool when the output carries legal exposure and no one has decided who reviews it before it leaves the building.
Our software consultation exists partly to reach that conclusion cheaply, before a build is scoped.
Evidence
A growing firm was losing roughly one in five prospects during evidence intake and spending about $10,000 a month across eight platforms that did not share a record. We built VADIS, a single operations platform with AI file analysis and automated client outreach behind it.
Work that is high-volume, repeatable, and judged on consistency rather than on legal reasoning. Intake follow-up, first-pass document sorting, status assembly, and internal knowledge retrieval fit that description. Advising a client, deciding what is material, and anything that goes out under an attorney signature do not, and should stay with a person who is accountable for it.
It is a design constraint, not a blocker. It determines where data is processed, which model providers are acceptable, what is retained, and what is logged. The practical effect is that it narrows the architecture early and rules some vendors out, which is why it belongs in the first conversation rather than in a security review after the build.
In the work we have done it has not. The firm in our case study added the equivalent capacity of four attorneys and one paralegal without hiring, because the same people stopped spending their day on administrative handoffs. That is a capacity outcome rather than a headcount one. A firm that wants a headcount outcome should say so at the start, because it changes what gets built.
The first useful output should arrive well before the full system does. We build against one real workflow with real matter data rather than a demo dataset, so the question of whether it works is answered by the people who do the job, on their own files, early enough to change direction cheaply.
Hosting, model usage, maintenance, and the staff time to operate it. Model usage in particular scales with volume, so a document-review workflow that is cheap in a pilot can be materially more expensive at full caseload. We put the running cost in front of you before the build, because discovering it in month four is the most common reason these systems get switched off.
The first conversation is about where the capacity is going, not about what we would build. If the honest answer turns out to be a process change rather than software, you will hear that.