Build vs. Buy (legal AI) was never a technology question

Every few weeks I have a version of the same conversation. A general counsel or head of legal ops tells me their CEO or CFO has asked, “What’s our AI plan?” And almost every time, somewhere in that conversation, the question is framed as a build vs. buy decision. 

I understand why. It’s the framing every other function has used for every software decision for the last twenty years. Do we build our own CRM or buy Salesforce? Build our own ticketing system or buy Zendesk? Legal has watched the rest of the business make that call for years, so when AI shows up, reaching for the same instinct feels natural. 

But I don’t think it’s the right question, and I’ve come to believe that starting there is what gets teams stuck. 

Build vs. buy sounds like a technology decision. It isn’t. In my experience, it’s really a legal operations maturity question. It’s about how seriously a legal team is treating itself as a function, with its own workflows, data, and operating model. Get that maturity piece right, and the right legal AI strategy tends to follow on its own. 

Why building it yourself rarely works 

Start with “build.” I’ve sat across the table from legal teams who’ve genuinely considered building their own AI tooling in-house. It’s an admirable instinct, and I understand the appeal of owning something end-to-end. But building AI is rarely a project. It’s a commitment. Models evolve, infrastructure changes, expectations shift, and the work never really finishes. For the handful of legal teams with the resources and appetite to operate like a software company, that can make sense. For most, the challenge isn’t building something once. It’s maintaining it forever. 

There’s a second, quieter problem with building it yourself. Expertise is valuable, but it can also create blind spots. The people who know a process best are often the ones most invested in how it works today. When legal teams build their own tooling, there’s a risk they simply automate existing workflows rather than rethinking them. One thing I’ve learned over the years is that innovation often comes from questioning assumptions that insiders barely notice anymore. 

The three versions of “buy” 

So, most teams land on “buy.” Fair enough. But this is where I think the real confusion starts, because “buy” isn’t one option. When I listen to these conversations, I think people are lumping together three very different things and treating them as interchangeable is where many decisions go wrong.  

First, there’s horizontal AI: tools like ChatGPT, Microsoft Copilot and Claude. These are incredibly powerful and, increasingly, can be connected to organisational content and knowledge. They are often the fastest way to help a lawyer draft, analyse, research or find information. But they aren’t built around the way legal teams operate. They don’t inherently understand your matter structures, intake processes, approval workflows, precedent management, panel relationships or legal risk frameworks. They provide intelligence, but not necessarily legal operational context. 

Then there’s AI connected to a single point solution, often through something like MCP. A contract repository, document store or specialist application can expose its content to an AI model and provide a much richer understanding of that specific dataset. That’s a meaningful step forward. But the AI’s view of the world is still constrained by what exists within that particular system. It can tell you what’s in the contract. It may even identify patterns across contracts. What it typically lacks is the broader context surrounding how legal work is being performed across the organisation. 

Horizontal AI can help lawyers draft, analyse and find information more quickly. AI connected to a single application can add context from that particular system. But the bigger opportunity lies in AI that understands how legal work connects across the function, rather than what happens within any one tool. 

That’s because legal knowledge isn’t just stored in documents. It’s embedded in decisions, matters, approvals, negotiations, outside counsel relationships, risk assessments and years of institutional experience. The more knowledge, history and operational understanding an AI can access, the more useful it becomes. 

The real breakthrough isn’t that a system contains AI, it’s that AI becomes more useful as it gains context. So, where does that context come from? 

Not from the model itself, but from the way the legal function operates. The more connected the work, the richer the context available to both lawyers and AI. 

It’s a legal operations strategy, not an AI strategy 

In practice, the harder task isn’t connecting AI to legal work, it’s connecting legal work to itself, and that’s where a connected legal operating system comes in. When intake, matters, contracts, spend and knowledge all sit together, AI can reason across the full picture rather than a single slice of it. 

At LawVu we call that a LegalOS, and I’ll use that term throughout the rest of this series.

The real question underneath build vs. buy 

One lesson I’ve learned from working with legal teams is that the presenting problem is rarely the real problem. What they’re asking is often just a symptom of something deeper, and AI is no different. 

Build vs. buy is the surface question. 

What it’s really asking is how serious you are about building legal operations as a genuine function. The organisations getting the most value from AI aren’t necessarily the ones with the most advanced technology. They’re the ones who have invested in creating the structure, processes, and connected data that make AI useful in the first place. 

Over the next few weeks, I want to walk through what that looks like in practice, starting with the AI most teams already have running in the background: the general-purpose assistant in a browser tab, quietly doing more and less than most people realise. 

This is the first of six articles on what it takes to get a legal team ready for AI.