A one-page framework for scoping a legal AI use case

Most legal AI projects that fail were doomed before anyone chose a vendor or wrote a prompt. They failed at the scoping stage, usually because there wasn’t one. Someone saw a demo, someone else had budget, and “let’s use AI for due diligence” became a project without anyone writing down what, exactly, would be different on a Tuesday afternoon if it worked. I’ve scoped a lot of these, from both sides of the table, and I’ve ended up with a rule: if you can’t fit the use case on one page, you don’t understand it well enough to build it. Here’s what goes on the page.

The task, in one sentence

Start with a single sentence describing the task at the level of real work. Not “contract review” or “knowledge management”, which are categories, not tasks. Something like: “A junior associate in the real-estate team extracts break clauses, rent review dates and alienation provisions from each lease in a portfolio and records them in a report for the client.”

That sentence has to name who does the work, what document or input they start from and what they produce at the end. If you can’t write it, the project isn’t ready, and no amount of technology will fix that. Most of the vague, stalled initiatives I’ve seen would have been saved, or sensibly killed, by forcing someone to write this sentence at the start.

Volume, and who feels it

Next, the numbers that tell you whether the task matters. How often does it happen? How long does it take each time? Who does it, and what would they be doing instead? A task that takes a day but happens twice a year is a very different proposition from one that takes forty minutes and happens forty times a week.

Then ask who actually feels the pain. Sometimes it’s the associate doing the work. Sometimes it’s the client waiting for it, or the partner writing off time on a fixed fee. The person who feels the pain is the person who will champion the tool, and if you can’t name them, you have a solution looking for a sponsor.

Where the judgement sits

This is the box that separates good scoping from bad. Break the task into its steps and mark each one as either mechanical or judgement. Finding the break clause is largely mechanical. Deciding whether its conditions create a real risk for this client, given everything else on the file, is judgement.

The use case should automate the mechanical steps and support the judgement steps, not the other way round. It should also say explicitly where the human sits: who reviews the output, at which point, and what they’re checking. If the scope quietly assumes the tool will make the judgement calls, either the scope is wrong or you’re building something your firm’s risk team will rightly refuse to approve.

What happens when it’s wrong

Every AI tool will sometimes be wrong, so the page needs an honest answer to three questions. What does an error look like in this task? How would the reviewer spot it? And what does it cost if they don’t?

A misread date in a lease report that a client relies on is serious. A slightly clumsy summary in an internal note is not. The cost of error determines how much verification the workflow needs, which in turn determines how much time the tool can genuinely save. Plenty of use cases look compelling until you write this box honestly and realise the checking will take nearly as long as the original work.

Where the inputs live

Then the unglamorous part, which kills more projects than anything else. Where do the documents actually live? What state are they in? Are they searchable PDFs or scans of photocopies? Are they in the document management system, in email attachments or in a data room the firm doesn’t control? Who has to approve the tool getting access to them?

You’d be surprised how often a sound use case founders here. The model can handle the task. The documents can’t get to the model, or arrive in a state that makes the output unreliable. Write down the real path from source document to tool, and if it involves someone manually downloading and renaming files, count that as part of the cost.

What success looks like in month three

Finally, define success before you start, in terms you can actually measure. Not “improved efficiency” but something like: “Associates in the team use the tool on most new lease reports, and time to first draft falls noticeably against our current baseline.” That means you need the baseline now, before anything changes.

Just as important, write down the kill criteria. What result at the three-month mark would tell you to stop? Firms are very good at starting projects and very bad at ending them, and agreeing in advance what failure looks like is the only reliable way to avoid a pilot that drifts on for a year because nobody wants to call it.

That’s the whole page: the task, the volume, the judgement line, the failure mode, the inputs and the test of success. It’s not sophisticated, and that’s the point. The discipline isn’t in the template. It’s in refusing to start until every box has an honest answer in it. Most bad legal AI projects could have been spotted on a single sheet of paper, and most good ones look obvious once someone has bothered to write them down.