What lawyers actually want from legal AI tools

01.1. Citations

Lawyers do not accept an answer they cannot trace. If a tool says a contract has no limitation of liability, the next question is: where did you look? A good tool shows the clause, the page and the paragraph behind every statement, and lets the user click through to read it in context.

In practice this means keeping source positions during document processing, not only the text. It also means saying clearly when nothing was found, rather than inventing a reference. A missing citation should be treated as a failed answer.

02.2. Control

Lawyers carry the professional responsibility, so they want the last word. The interface should let them accept, edit or reject each suggestion in one click, and see what changed. Bulk actions are fine for low-risk items, but never for anything that alters a position.

An example: a tool suggests replacing a one-sided indemnity with the team's standard wording. The lawyer should see the original, the proposed text and the rule it came from, then choose. If the tool applies changes automatically, it will be switched off within a week.

03.3. Confidentiality

Client data is the one thing a legal team cannot afford to lose. Lawyers want to know where documents are processed, who can see them, how long they are kept and whether they are used to train anyone's model. They want those answers in writing before a pilot starts.

Good practice includes role-based access that follows matter permissions, audit logs of who saw what, and private deployment where the client or the firm requires it. Data protection laws also apply, so involve your privacy lead early.

04.4. My playbook

Every team has its own standards. A tool that applies a generic idea of "market" will flag things the team accepts and miss things the team cares about. Lawyers want the tool to use their preferred wording, their fallbacks and their escalation rules.

This is why a playbook workshop is the first step of a sound project. It also exposes gaps. Teams often find that two senior lawyers handle the same clause differently. Better to learn that before a model learns both.

05.5. Fits Word and email

Lawyers live in Word, Outlook and a document management system. A new tool that needs a separate login, a separate upload and a separate copy-paste step adds friction. Adoption follows convenience.

Where possible, bring the assistance to the places they already work: a pane inside Word, a summary attached to an email, a result written back to the matter record. A simple screen for review is acceptable if it saves more time than it costs.

06.6. Honesty

The last item is the hardest and the most important. Lawyers want the tool to say when it is unsure. A confident wrong answer is worse than no answer, because it invites trust it has not earned.

Practical ways to build this in:

• Return a confidence level with each result, and send low-confidence items to a person.
• Say "not found" when a clause is absent, with the sections searched.
• Show when the document is poorly scanned or incomplete.
• Track and publish error rates by clause type so users know what to double-check.

07.What this looks like when it goes wrong

Consider a plausible case. A team adopts a review tool that is quick and tidy. It marks clauses in red and amber, but it does not say why. Lawyers open a contract, see an amber flag on a termination clause and have to read the clause anyway to find out what is wrong. After a week, they stop looking at the flags.

Now compare a tool that says: "Termination for convenience is allowed for the supplier only. Playbook requires mutual rights. Suggested wording attached." The lawyer reads one sentence, checks the clause, and decides. The difference is not intelligence. It is whether the tool respects the lawyer's need to verify.

08.What this means for buyers

If you are choosing a tool, ask for a demonstration on your own documents, including difficult ones. Ask to see what the system does when it finds nothing, when the scan is bad and when two clauses conflict. Ask where the data is processed, who at the vendor can see it and what happens when you leave.

If you are building, write these six points into the specification before you write any code. Each one maps to a design choice: source tracking, an editing interface, an access model, a rules layer, integrations and confidence scoring. Retrofitting any of them later is far harder.

09.How to gather requirements from lawyers

Lawyers are busy and often unsure what AI can do, so open questions yield vague answers. Better methods work from real examples.

• Sit with a lawyer while they review a contract, and note where they slow down.
• Ask them to mark which parts of the work are routine and which need judgment.
• Show them a draft output and ask what they would change.
• Ask what would make them stop using it. The answers are often about trust, not features.

10.A quick test for any legal AI tool

• Can I see the source of every answer?
• Can I accept, edit or reject each suggestion?
• Do I know where my data goes and who can see it?
• Does it use my playbook?
• Does it work where I already work?
• Does it tell me when it is unsure?

If the answer to any of these is no, expect low adoption.

11.Common mistakes

• Demoing on clean documents only. Real files include scans, tracked changes and odd formatting. Test on the messy ones.
• Measuring speed alone. A faster review that misses a key clause is a loss. Measure misses as well.
• Ignoring the junior lawyers. They do much of the first-pass work and will tell you quickly if a tool slows them down.
• Leaving privacy until the end. Hosting and data terms can decide whether a project goes ahead. Settle them first.

12.What to do next

Pick one document type, write the playbook, and run a small pilot with the six points above as your scorecard. Ask the lawyers to mark every suggestion and tell you why they changed it. That feedback is worth more than any vendor demo.

A final thought for teams who are still undecided. Ask your lawyers which task they would most like never to do again. The answer is usually a repetitive reading job with a clear standard, and that is the best place to begin. Start there, let the six points above set the standard, and expand only when the lawyers themselves ask for more.

One last point. Lawyers differ by seniority. Partners care about risk and client confidence. Associates care about time and accuracy. Legal operations staff care about volume and cost. A good tool serves all three, and a good pilot hears from each of them.

Brandsmashers builds legal AI tools around these expectations: citations, lawyer control, privacy and the team's own standards. If you are weighing a pilot, we can help you scope it.