Practical AI for Law Firms: the series
Most of what law firms hear about AI sits at one of two extremes. Either the technology is about to replace junior lawyers, or it is a liability waiting to happen because a court somewhere sanctioned a practitioner for citing cases that never existed. Neither view helps a partner decide what to do on Monday morning.
This series is for the people who have to make that decision: managing partners, practice managers, IT managers and the general counsel of firms large enough to have a technology budget and small enough that a bad purchase hurts. We write about the systems we actually build and run, what they cost, where they break, and the work they do not do well.
The ground we cover is the ordinary work of a practice. Document review, where a model can narrow a large set of documents to the ones a lawyer needs to read closely. Research assistants grounded in a firm’s own precedents, advices and closed matter files, so the answer comes from your work product rather than from whatever the model absorbed during training. Intake, conflict checking, file opening and the long tail of billing admin, where the value is usually in recovering hours that nobody currently records.
Confidentiality and professional obligations are a design constraint here, not a compliance section bolted on at the end. Client information cannot leave the jurisdiction or the tenancy it was promised to stay in. Legal professional privilege has to survive whatever the system does to a document. A lawyer remains responsible for advice that a machine helped produce, and the system has to make that responsibility practical rather than notional. These constraints shape the architecture from the first design conversation, which is why we treat them as an engineering problem rather than a policy one.
The hallucinated citation cases are worth keeping in view, and we will refer to them, but the lesson is narrower than the coverage suggests. A general-purpose chatbot asked for authority will produce something shaped like authority. A retrieval system that can only return documents it actually holds, with a link to the source, fails differently and more visibly. The difference is in how the system is built, and that difference is buildable today.
We will be specific about limitations. Some tasks are not worth automating. Some models are wrong often enough that the checking costs more than the drafting. Some projects only make sense once a firm’s documents are in a state where software can find them, and that clean-up is often the real project. We would rather say that up front than sell a pilot that quietly stalls after six months.
PicNet has built software for Australian organisations since 2001. Our team is senior, every manager is an engineer, and we build systems that run in production rather than demos that impress in a boardroom. This series reflects that bias.
PicNet builds production AI systems for Australian organisations - talk to us about what a first project could look like.