Here are the answers.
The ten themes that came up frequently before our AI webinars held over the last six months.
Before each of our AI in legal delivery webinars this year, we asked registrants one question: what do you want us to make sure we cover?
83 professionals responded. We grouped what came back into themes, and ten of them account for 94% of everything asked. We've also written about what that ranking inspired us to build - Is Your Legal team Optimised for AI - The Assessment. Below we answer the questions, for those who missed hearing them live and others who may be asking the very same ones now.
Some of these have short answers and some don't. We've tried to give a clear take on how we think either way, including where the honest answer is "nobody knows yet."
1. Where do we actually start? (17 questions)
The most-asked question by far, and it was articulated in a number of different forms: what's the low-hanging fruit, what are the first three things to try, what do you wish you'd known, and how do we tell the hype from the things that actually work?
The instinct is to go shopping, book the demos, check G2, compare features, pick a platform. It feels like progress, but a tool with no specific tasks to do just sits there, and "we bought AI" is not the same as "AI is helping” - just ask Uber’s CFO.
We would start at the other end. Look at where your team's time actually goes, and find one task that's high-volume, low-complexity and painful. The afternoon that disappears into first-pass reviews. The same three clauses explained for the hundredth time or the NDA that shouldn't take twenty minutes but does.
Rather than looking for the most impressive use case, look for the most winnable one. A good first use case usually has four things in common:
First-pass review against a playbook, summarising a long agreement, a first draft of a standard document, triaging what lands in the team's inbox. The specifics matter less than the shape: small, frequent, checkable, useful.
Then prove it on real work - your actual contracts, not a polished demo - and compare it fairly to how the job gets done now. Where is it clearly faster? Where does it wobble? AI is confident even when it's wrong, so someone has to check the output against reality until you know its limits.
On telling hype from substance: ask anyone selling you something, what it does badly. A straight answer is a good sign. "Nothing, really" means you're talking to marketing.
Our Guide, Optimising Legal teams for AI walks you through this, step by step.
2. How do we get the team on board - especially the sceptics? (15 questions)
This was the second-biggest theme, and the questions were unusually well put. One person asked how you build genuine adoption confidence in a small, senior legal team where tools have to earn trust quickly - not through a formal change programme, but through demonstrated reliability on real, regulated work. Another asked how you keep momentum when the results are mixed.
Every team has a senior lawyer who's watched tools come and go and isn't about to trust this one on your say-so. That scepticism is useful because it uses the same instinct that catches the bad clause on page forty.
We recommend you don't try to win with a policy or a rollout plan. Rather, win with evidence. Hand your sceptic the exact thing they'll judge most harshly and let them watch it work on real files. Reliability on their terms does more than any enthusiasm from above.
Then make the wins visible. When someone gets an afternoon back, communicate that - in the team meeting, Slack channel, wherever people are watching. Time is the greatest gift and commands attention meaning adoption sticks when the next person can see it already worked for the last one.
On mixed results, which is where most rollouts stall: mixed results aren't a failure signal, they're an information signal. They usually mean the use case is too broad. A tool that's brilliant on NDAs and unreliable on bespoke commercial terms hasn't failed - it's showed you its limits, just like a human might. Narrow the job to the side of the line where it works, bank that, and come back to the rest later.
The teams that lose momentum are the ones that keep asking the tool to do the thing it's bad at, and treat every miss as a verdict on the whole idea.
Being straight about the misses earns more trust than only raving about the hits. A team that says "here's what it's good at, and here's where you still need a human" is far more persuasive than one that oversells.
3. Automation or AI — which do we actually need? (9 questions)
People asked this as a genuine either/or: contract automation versus AI, how to balance the two, and where the basics of template preparation fit in. It's a fair question, and the answer is that they do different jobs.
Document automation is deterministic. Same inputs, same output, every time. You build the logic once and it runs. It's for producing your own document at volume - the standard agreement, the order form, the schedule that gets rebuilt forty times a month with six things changed.
AI is probabilistic. It reads, summarises, compares and drafts, and it will give you a slightly different answer each time. It's for dealing with documents you didn't write, and for work where judgement matters more than repetition.
The dividing line is roughly: are you producing a document, or reacting to someone else's?
Your document going out is an automation problem. Their document coming in is an AI problem.
Most teams need both, and many are trying to solve the first with the second - which is expensive and unreliable, because you've bought a judgement engine to do a repetition job.
One more thing worth knowing: automation usually pays back faster, and it's much less frightening to the business. If you need an early win that nobody argues about, it's often the better first move.
The basics of great template preparation
Several people asked about this specifically. Before you automate anything, we recommend doing three things:
If that sounds like work, it is. It's also the same groundwork AI needs, do it once and both routes open up.
4. How do we redesign the way the team works? (7 questions)
These questions were about structure, not tools: managing AI's arrival alongside a traditional team shape; building a legal operating model that scales with growth; building ops from scratch; getting the right balance between human and machine; and what skills keep a commercial lawyer useful.
The starting point is that AI changes the shape of the work before it changes the shape of the team. The first draft, the first-pass review and the first summary take far less effort. What still takes real effort is deciding what matters, holding the commercial line, and being accountable for the answer.
So the balance question mostly answers itself: machines take the first pass, humans take the last one, and the skill that matters is knowing which is which.
On team structure, the shape changes before the headcount does. As AI absorbs the volume work, the traditional pyramid loses its base: you need fewer hands for throughput and more heads for judgement. The catch is that the base was also the training ground. Juniors built judgement by working through volume, and if you remove that, you have to find another way to build the judgement.
We think there is value in letting junior teams keep doing bespoke, high-volume work, using AI to sharpen quality as they go, while we push the simpler workflows into AI. They still learn the traditional way - just across a smaller share of the work . The bigger problem of where judgement comes from is still unsolved, and anyone who tells you otherwise is selling something.
If you're building legal ops from scratch, the order that works is: understand your demand, standardise what's repeatable, measure it, then automate the standardised bits. Skipping to the last step is the most common and most expensive mistake we see.
On skills, for what it's worth: the commercial lawyers who look most future-proof to us are the ones who can define a problem precisely, judge an answer they didn't produce, and explain a risk to someone who isn't a lawyer. None of these are new, they were simply buried under the hours drafting used to take.
5. Which tool should we buy - and should we build instead? (6 questions)
This landed fifth, which surprised us. It's the question everyone assumes is first.
We're not going to name a winner, and not out of diplomacy. The honest reason is that any specific answer we give has a shelf life of about six months at most.
A more logical approach is to take a step back and examine the order of operations.
Decide the task before you start demos. A tool evaluated against a real, named task takes an afternoon to assess. Be specific, it’s worth the investment upfront because "AI for legal" will not get you to something that works and produces the results you want and management expects.
Then use what you're already paying for. Several people asked specifically about getting more out of Copilot rather than buying something expensive, and it's a good instinct. Whatever's already inside your Microsoft agreement likely gives you a free pilot with no procurement cycle, security review, consultancy service fees or internal politics. If it turns out to be enough, you've saved budget for something more important. If it isn't, you now have a specific, evidenced reason why, which is a far stronger business case than a demo.
On committing when the pace of change is this fast - this was the sharpest question in the set, we thought - the trick is to stop treating it as a technology problem. It's a procurement problem. Don't buy a five-year answer to a six-month question. Short terms, break clauses, your data exportable in a usable format, and no workflow so deeply wired into one vendor that leaving means starting again. Buy the ability to change your mind.
On build versus buy: Building your own AI tool will give you more certainty and control over costs, but it comes at an upfront investment cost which most teams don't have the budget for. Buy the general capability, build the bit that's specific to you. Nobody else can build your playbook, your templates or your risk positions, and that's where the value actually sits. Building your own model is not the right answer for most legal teams, and increasingly isn't the answer for anyone.
6. Who owns the output, and what about IP? (6 questions)
A cluster of related worries: IP ownership and licensing positions for AI output, how to be sure you're not inadvertently plagiarising, how AI affects director duties, and whether you should be monitoring how employees use it.
Taking them in turn.
Ownership. Two separate questions hide in here. First, what your vendor's terms say about your inputs and outputs, who can use them, whether your data trains their model, what happens to it when you leave. That one you can answer today by reading the contract, and it's worth doing before anything else. Second, whether AI output attracts copyright at all. That's genuinely unsettled, and the direction of travel in most jurisdictions is that purely machine-generated material struggles to qualify, because copyright generally wants a human author. If ownership of the output matters commercially, deal with it in the contract rather than relying on the default position.
Plagiarism. The risk is real but small for contract drafting, where the language is largely conventional anyway. It's higher for anything you'll publish and assert originality over. The practical control is the same as it's always been: if you'd be embarrassed to find it was someone else's, check it.
Director duties. You can't delegate a duty to a tool. Whatever accountability sat with a person before still sits with them, and "the AI said so" isn't a defence any more than "the trainee drafted it" was. What changes is the evidence trail - so record what the tool was used for, and who checked it.
Monitoring. Most teams asking about this are solving the wrong problem. Yes, using unapproved tools is a compliance failing, but treating it as a discipline problem misreads the cause. People do it because they have work to get done and no sanctioned way to get help with it. Cracking down just pushes that use out of sight, which is the opposite of what you want for risk and oversight. To resolve this, you have to address the underlying cause: give people an approved tool, set out plainly what they can and can't use it for, and reinforce it often enough that no one can claim they didn't know the policy. You'll get far better visibility from usage data on a tool you've sanctioned than from trying to police the ones you haven't.
7. Can we trust the output? (5 questions)
This theme produced one of the best articulated questions of all 83, to quote the substance of it: LLMs are non-deterministic, so how do you get stability in contract review, instead of different hits and misses every time the model analyses the identical contract?
The short answer is that you can't eliminate that but you can shrink it a lot.
The variation isn't a bug, these models generate by sampling from probabilities, so two runs on the same document genuinely can differ. What reduces it:
There is also one thing worth doing once: run the same contract through five times and compare. Where the answers agree, you can rely on it. Where they diverge, you can't, that gives you a reliability map for your own documents that is worth more than any vendor benchmark.
The most useful thing to know about where it's weak: these models are much better at finding what's there than noticing what isn't. "Quote the indemnity" is a fair question. "Is anything missing?" is not - absence is genuinely hard for them, and that's exactly the question lawyers most want to ask.
A useful mental model
Treat it as a fast junior who has read everything and remembers nothing, has no judgement about consequences, and might not tell you they're unsure.
8. How do we prioritise when everything is urgent? (5 questions)
Notice this one is barely about AI and it came up anyway, five times, including a very precise version: how do you handle the stakeholder who skips the process and then declares an emergency, while the people who followed it get pushed down the queue - especially when it's the same department every time?
We'll answer it, because it's a contracting problem.
When everything is urgent, nothing is prioritised, and the queue gets set by whoever shouts loudest. The fix isn't better triage judgement - it's removing the judgement from the moment of pressure.
If sales is bypassing the legal process to close a deal, that's almost always a speed problem because people don't route around a process that's fast. Make the compliant route the quickest one - pre-approved fallbacks, a self-serve NDA, clear thresholds for what doesn't need review, and most of the bypassing stops.
Where AI can genuinely help here is at intake: triaging what arrives, flagging the standard from the unusual, and answering the questions that never needed a lawyer. That shortens the queue rather than reordering it.
9. How do we prompt well? (4 questions)
Ninth out of ten, which we found telling. Prompting gets a disproportionate amount of the noise and comparatively little of the actual concern.
Three specific asks came up: useful legal prompts, structuring prompts to minimise rework, and - a good practical one - how to get a prompt that works for everyone when Copilot has already adapted itself to each user.
The single biggest gain is: give it your material. A mediocre prompt with your playbook attached beats a beautifully engineered prompt with nothing. Most rework comes from the model guessing at context you had but did not share.
After that, the patterns that help include:
On persona and elaborate prompt engineering: modest gains, much smaller than the internet suggests. Context and source material do most of the work.
On team consistency - the Copilot problem. The answer is to avoid treating prompts as something people carry in their heads. Keep them in a shared library, versioned, with a short note on what each one is for and where it fails. Treat a good prompt like a precedent: someone owns it, it gets improved, and everyone uses the current version. That's also the only realistic way to keep quality steady when the underlying tool keeps changing underneath you.
10. What about data security? (4 questions)
The last theme, and the one that will likely halt more pilots than any other: the risk of staff putting data, including personal data, into tools where it shouldn't go, and how to implement anything without data leaving the secure environment.
The practical picture:
Know which tier you're on. Consumer and enterprise versions of the same product often have very different terms on retention, on whether your inputs train the model, and on where data physically sits. The gap between "we use ChatGPT" and "we use ChatGPT Enterprise" is the whole answer to this question.
The risk isn't the sanctioned tool. It often stems from the free one someone's using at 6pm because the sanctioned one wasn't available or wasn't good enough. Which loops back to the monitoring answer above: provision generously, say plainly what can go in, and make the approved route the easy one.
Write the "what can go in" list in plain English and make it short enough that people remember it.
Lastly, one that legal teams are better placed than anyone to spot, but often miss in their own house: you may not have permission to put the counterparty's document into a third-party tool at all. The confidentiality clause in the contract you're reviewing may say so in terms. It's worth checking what your own NDAs commit you to before you paste anything into anything.
What we didn't cover
A handful of questions didn't fit any theme, and a few deserve their own article – how AI affects junior lawyers' development, and what any of this means for the rule of law, to name two we're still chewing on.
If yours didn't get answered here, tell us. It'll go in the next one.
Where to go next
If you're towards the beginning of your AI journey - our guide covers the five foundations to Optimise your Legal Team for AI. It's free and ungated. Read the guide
If you'd rather know where you stand first, our two-minute assessment shows which foundations are solid and which need work before you go further. Take the assessment
You might be wondering what your next steps should be. Let us guide you with three easy options:
We use cookies to monitor the performance of our website and to improve user experience. By continuing to browse our site, you agree to our use of cookies.
.png)
