Information, Not Advice
Every useful piece of legal software lives on a line it must not cross. Designing for that line — rather than pretending it is not there — is the whole craft.
Legal design · Governance
There is a boundary that runs through the middle of every legal-tech product, and most of them pretend it is somewhere else. On one side is information: facts, structure, organisation, the surfacing of relevant questions. On the other is advice: the application of law to a specific situation to reach a conclusion the person can rely on. The first is something software can and should do. The second, in most jurisdictions, is the unauthorised practice of law if it comes from anything other than a licensed human.
You can resent this line. You can argue it protects lawyers more than clients. But if you are building, the productive move is not to argue with the boundary — it is to design as if it were a load-bearing wall, because it is.
The line is not where intuition puts it
The naive reading is that advice means anything legal and helpful, and information means anything generic and useless. That gets it backwards. A tool can be enormously specific, deeply tailored, and richly useful while staying firmly on the information side — as long as it stops short of telling the person what to conclude about their own situation.
Consider the difference between these two outputs. The first: Based on your answers, your system is a high-risk AI system and you must do X. The second: Systems used for the following purposes are classified as high-risk under Annex III; here are the purposes you described, here is the relevant text, and here is the question a lawyer would need to resolve. The first reaches a conclusion the person will rely on. The second hands them an organised version of the problem and points at the door marked get a human.
Design choices that keep you honest
The boundary is not maintained by a disclaimer at the bottom of the page. Disclaimers are necessary and almost worthless; nobody reads them, and a court would not be impressed by one slapped under a tool that plainly functions as a lawyer. The boundary is maintained by what the product actually does.
A few choices do most of the work. Surface questions rather than answers wherever a real judgement is required — the tool’s job is to make sure the right question gets asked, not to answer it. Keep the human in the loop by design, not as an afterthought: the most valuable thing a governance tool can do is escalate well. Show your sources so the person is reading the law, not the tool’s paraphrase of it. And refuse to conclude on the questions that genuinely require a licence — not reluctantly, but as a feature, because a tool that knows what it should not say is more trustworthy than one that answers everything.
Why the constraint makes better products
It would be easy to read all of this as a tax — a set of things you are not allowed to do, eroding the product. I have come to see it the other way. The constraint forces a kind of honesty that users can feel. A tool that organises a hard problem and tells you clearly where it ends is more useful, and more trusted, than one that confidently answers questions it has no business answering.
The line is not the enemy of good legal software. It is the spine of it. Build along it, not around it.
Milos Kresojevic · Editor, AI.Legal