How to develop practical AI workflows for lawyers

Written with Raymond Sun, a technology lawyer and founder of LegalQuants. There's a gap in AI training for lawyers. Firms tend to push two types of training. One is on security, confidentiality and risk. The other is the vendor demo of what the tool can process — reads X documents at once, processes Y in seconds. Where a lot of lawyers struggle is that missing middle: actually building out repeatable workflows with practical use cases, rather than one-off prompts or tasks.

So this guide isn't about how AI is going to take all our jobs. It focuses on two things: how we translate our expertise, client knowledge and judgment — the things AI tools need to actually be useful — and how we apply AI in a way that builds on the skills you've already developed in legal practice, instead of learning a whole new process. The idea is that this process can be applied with any AI tool you're allowed to use, and for any practice group.

A quick note on confidentiality and privilege. You've probably heard this from the "risk-centred" AI training sessions, but there are two main ways we maintain confidentiality and privilege when using AI. First, at the architecture level — the organisation's decision on which tool to use, the user terms, whether the tool is built with guardrails to keep inputs private, and the contract with the provider. Second, at the prompting level — if you're not 100% sure about the architecture, anonymise your prompts and keep client-specific information off the platform.

How AI actually works (a quick overview)

Let's start with a very quick recap of how AI works, so you have an idea of what it does well and what it's actually lacking. Once we have that, each step in the process makes more sense.

Without getting too technical: it predicts what a helpful, accurate answer looks like based on patterns in an enormous body of training material. On the inputs side, it's heavily reliant on how we prompt it and the information it receives. On the outputs side, there's still room for iteration, our know-how, and tailoring it to our clients' preferences. Here's the mechanism, and what it means for the way you prompt:

Where this is heading. A quick "where are we?" in the AI shift. Right now nearly all of us are working generatively: you prompt, it produces. The next phase we're moving towards is agentic: it plans, takes sequential steps, and completes multi-step tasks with less intervention — this is when you start feeding it entire workflows and it takes a more autonomous role.

The three-stage process

There are heaps of prompting frameworks and acronyms being sold to lawyers right now. But we don't need another acronym. What we want to do is build on our existing delegation skills — giving instructions, reviewing and amending the work product, and verifying the output. That's three stages:

1. Briefing — instruct it like a junior.
2. Scoping — let it question you first.
3. Refining and standardising — fix it, then save the reusable part.

The human stays in the loop throughout, and the standardised workflow feeds the next matter. To show the elements before applying them to legal work, I'll use a worked example so you see how each part works.

Step 1 — Briefing

Instruct it the way you'd instruct a junior. For lawyers with good delegation skills, this will look familiar. A good brief has five elements, plus the documents you're relying on:

1. Role. Who it is, and what expertise to draw on. The role narrows what it treats as relevant.
2. Purpose and context. Who the client is and what they're trying to achieve.
3. Task. The specific piece of work and the form of the deliverable.
4. Key facts. What isn't public, and what to focus on. Key facts and documents stop it filling gaps.
5. Constraints. Format, length, tone, house style, and where to flag rather than guess. Constraints are the guardrails.

Plus the documents you referred to — your house style, a precedent, your issues checklist. This is why we did the mechanics first. And these elements apply to every prompt you write, not just the first one.

So what does this look like with an example? (A non-legal one first, so the mechanics are clear.)

Specific is good, but too specific starves it of material. I've referenced professional athletes, but within the broader category of high-net-worth individuals.

On the task: include the precedent, checklist or matrix that should be followed — the same as giving a junior something to work from instead of a blank page.

Here we're asking it to consider two specific options rather than every possible variant.

Note the recommendation section is left for us to populate. The tool does the legwork, but we still apply our judgment.

I like to restate what I'm attaching, to make sure I haven't missed anything. It's optional, but useful. And the closer sets up the next stage.

A quick point on the deliverable. What we sometimes see is lawyers not going into enough detail on exactly what they want the output to look like. "Review this contract" is not a deliverable. "An issues table with a clause reference, the issue, the risk to our client, a suggested position, and a source reference" is. Going back to those delegation skills we already have: we need to either spell it out clearly, or provide examples and precedents to use as reference.

Step 2 — Scoping

People assume scoping means a longer prompt. It doesn't — it's the tool asking you questions before it produces anything. Like when we delegate to somebody, we want to give them an opportunity to clarify anything that doesn't make sense, or to check they're giving us exactly what we're asking for. Maybe there are constraints that don't make sense, or they might ask if there's a precedent they should use. That's where we add a question at the end of the initial prompt:

So we might get questions like these:

• The meeting notes mention Giannis wants flexibility. Should that be weighed in the risks and benefits, or only in the earnings comparison?
• For the post-tax comparison, which state of residency should I assume for 2027–28, and do you want that assumption stated on the record?
• Should the comparison assume he plays out every year of each contract, or should I also show an early-exit or serious-injury scenario?
• You've said not to recommend a path. Should I still flag which option carries more risk, or keep the risk section neutral?

By answering these questions, we get a first draft that's much closer to what we're hoping for.

Step 3 — Refining and standardising

Refining

We let the AI do its thing and produce a first draft. We take a look, and there are some things we want to change. That's refining. The point is to give specific, directive feedback — the way you'd give it to a junior — and to take an iterative approach:

With a contract-review example, you might amend the first few rows of a table yourself, then ask it to analyse how you changed them and apply that across the rest. You stay in the loop; it does the legwork.

Standardising

We aren't building workflows if we use AI task by task. Lawyers sometimes get into a habit of retyping instructions, guardrails and preferences every time, because they've never separated the reusable part of a chat from the disposable part. It helps to think of everything you feed the tool as two buckets:

• Standing context — reusable. Role · house style · client risk appetite and known preferences · output format · verification requirements.
• Matter context — disposable. This contract · these parties · these facts · this deadline.

Remember how AI works — "it doesn't remember you between sessions". You're building the memory it doesn't have, and creating a way to reapply it quickly across different chats. It might be your personal preferences (Australian English instead of American English), how to approach a particular task, a particular client's preferences, or anything else you reuse from time to time. And the answers you gave at the scoping stage are a specification: capture them and they go into the brief up front next time, which is how scoping gets shorter with every run.

The good thing is we can get AI to help build the workflow as well. Here's an example prompt you can use:

Every correction you made at the scoping stage was you teaching it a preference it had no way of knowing. If you don't capture those, you retrain it from scratch every time. And apply Step 2 again here — get it to ask you any questions when preparing this prompt.

Keeping a human in the loop

I'll keep this part quick — you've probably had the full risk lectures already, so let's focus on what it actually looks like in practice. Again, this builds on the delegation skills you already have: approach it as if you're working with a junior or paralegal for the first time, and have given them work that might be outside their skills.

The non-negotiables:

• You're responsible for the output. It doesn't sign the advice.
• It assists your judgment. It doesn't replace it.
• Verify citations and provisions.
• Well-reasoned and confident is not the same as correct.
• Know your firm's policy before client material goes near a tool.

In addition to hallucinations and over-reliance on training data, which we've already covered, the risks that actually catch lawyers out are:

• Misapplication — right framework, wrong facts.
• Loss of nuance — misses the commercial or strategic context.
• Confidentiality — client material into an unapproved tool.

So what does verification actually look like?

1. Ask for the citations. Have the platform expressly set out every citation it relied on.
2. Check them against the source. Open the clause, the case, the section, and read it.
3. Follow the reasoning. Read its reasoning. If it can't explain step by step, that's a red flag.
4. Confirm it used your documents. "Which part of the document did you rely on for this?"

Some AI platforms have built in the ability to verify outputs — cross-references to the relevant parts of the document, and so on. If they don't, we should build it into the standing instructions. Like with any work we're reviewing, we should look at the primary source and also read around it for context. With a contract review, for example, I'd be reading clause X — but there might be surrounding or cross-linked clauses that change how that clause works. Designing the deliverable so it's easy to check is why every table in the next section has a Source column.

The workflows in practice

Now we're onto the application — what this looks like when we apply the three-step process to an actual legal task. Both worked examples are construction: a subcontract, then the dispute that comes out of it. Same process, applied to a transaction and to litigation. But again, the focus is on the process, so it can be applied with any tool in any practice group.

Workflow 1 — contract review

The scenario (fictitious): our client, Harbour Steel Fabrication Pty Ltd, is the subcontractor under a structural steel subcontract with ABC Corp, the head contractor, for a commercial development in Sydney. Subcontract sum $4.2m, on ABC Corp's standard form, lightly amended. The partner wants an initial review before tomorrow's client call.

Start with what not to do — the lazy prompt:

What comes back is generic: "Payment provisions may be unfavourable and should be reviewed carefully. The contract permits termination in certain circumstances. Consider whether liability is adequately limited. Extension-of-time provisions should be reviewed. Recommendation: obtain legal advice on the above." No clause numbers. No quotes. No risk grading. Nothing about New South Wales, nothing about our client's cash position. Nothing I could put in front of a partner. It isn't wrong, but it's generic and not really usable — and note that at the end it advised me to get legal advice.

Here's the line that sets up everything after: everything that follows is the same contract and the same tool. The only thing that changes is the instruction.

Calling out the attached example review is the same move as giving a junior a precedent instead of a blank page.

Scoping — and my answers. Some questions that might come back from the scoping step:

First output — the issues table.

Refining. The second version produces a much better draft than the first — purely driven by how we prompted and scoped the task. Then we move on to refinement, with a specific comment like this:

So from the first prompt we've got a summary of what's in the contract that may be a risk. Then you might see that what the review doesn't address is what's missing from the contract compared to what would be standard. So you iterate with an additional prompt:

Turning it into a workflow (standardising). Run the extraction prompt at the end of the same conversation, tailored to contract review. What comes back is the reusable artefact — and about 80% of it is standing context, which is why the second review of this type takes ten minutes instead of an hour.

Workflow 2 — litigation: chronology, then arguments and rebuttals

Let's do something for litigation now, using the same project. Harbour Steel claims an extension of time for late access to Zone B; ABC Corp rejects it as submitted too late. Say we're given six documents.

Briefing — role, purpose and context, task and deliverable, key facts, constraints, and ask me any questions:

Two instructions in there are doing a lot of work. "Date uncertain rather than guessing" is what stops it inventing a date to complete the table. And "work through each document in turn, then stop" sequences the task so it doesn't summarise the whole bundle in one pass and lose the detail.

Some of the questions that might come back: do internal communications count as evidenced events, or only communications between the parties? Document 5 is undated — exclude it, or include it as "date uncertain" with a note? Where a document refers to an earlier event not otherwise evidenced, record it as an event or only as a reference?

The chronology. The output might look something like this:

We might refine it by adding hyperlinked sources, or highlighting the key documents — all of that can be done with further prompts or a list of comments. Again, the key is to make those comments specific, so the AI doesn't fill in the blanks by drawing on information or training you don't want it to. The flagged inconsistency is the most valuable row in the table: when the crane actually arrived may decide the claim.

Then: argue the other side. Another way to build on that initial output is to start testing the legal analysis. For example, you can test the other side's case:

Telling us what the bundle doesn't prove is the most lawyerly thing in the whole demonstration — and it happens because the instruction said "say so rather than arguing it".

Three more quick workflows

Some other quick workflows you can build with the same three-step method:

Drafting. Never start from a blank page. Give it your precedent and house style as constraints. Ask for the assumptions list alongside the draft:

Clarifications. For unclear instructions, ask for its best interpretation, the assumptions that interpretation depends on, and the questions you should ask before starting. You then send the questions.

Admin. All the value is in the deliverable spec. Agenda: time allocations, one line per item. Taxi pack: what I need to know in the ten minutes before I walk in. Follow-up: Action | Owner | Deadline, only where an action was agreed.

Where else this process works

These are some other examples lawyers are using AI for quite effectively. You can take the same approach — prompting, scoping and refining — to each of these, or to the tasks specific to your clients and practice area:

• Transactions — due diligence red-flag reports; checking a draft against your precedent for deviations; conditions precedent trackers; closing checklists and transaction bibles.
• Disputes — triaging a large bundle before you read it; summarising an expert report; comparing versions of a pleading or contract; preparing questions to ask a witness.
• Practice and clients — getting up to speed on a new industry; turning advice into a client-friendly summary; checking against internal policies (NDAs, amendments to engagement letters).

The same closing move applies throughout: stay in the loop as the human, then get AI to build the reusable workflow, so you're not typing the same information and instructions again.

Five things you can do this week

Finally, what can we do to start implementing AI more effectively beyond this three-step process?

1. Save a general instructions file. Your standard role, context, guardrails and style. Paste it at the start of every session.
2. Save task-specific prompt templates. The sequence that reliably works, stored where the team can use it.
3. Keep an inputs and outputs folder. What went in, what came out — for quality control and professional responsibility.
4. Keep a prompt log. What worked, what didn't, what you changed. Invaluable on handover.
5. Build incrementally. Start on low-stakes admin. Move to substantive work as your feel for it develops.

Pick the task you did most often last month — not the hardest one. Have a think about, or map out, how you'd approach it and teach somebody else to do it. Run the three stages once, and save the standing context at the end. And if you remember one thing, make it the scoping question: letting the tool interrogate you before it drafts.

About Raymond Sun

Big thanks to Raymond Sun for co-writing this guide. Raymond is a founder of LegalQuants — a global network of lawyers who build their own tech to practise and transform law. He is a technology lawyer and long-time lawyer-builder with deep experience at the intersection of law, technology and systems design.