Build vs Buy: Legal AI for In-House Teams (2026)

A general counsel I spoke with last quarter had a slide deck ready before our call even started. Her department was four lawyers covering a Series C SaaS company, and eight weeks earlier they had decided to build their own legal AI: retrieval over a contract corpus of a few thousand executed agreements, an LLM on top, an internal copilot in Teams.

The slide showed the projected cost as one number, the OpenAI bill, and it was small. What the slide did not show was the eval set nobody had built, the retrieval quality nobody had measured, and the engineer who had been "borrowed" from the platform team and was about to be un-borrowed.

The failure mode that surfaced in their pilot was the quiet kind: the bot kept answering renewal-term questions from the wrong contract, because near-identical MSAs retrieved as look-alikes and no test caught it. That gap is the entire build vs buy legal AI question, and most teams answer it on the cost line that is easiest to see, not the costs that actually decide the outcome.

This post is for in-house counsel, fractional GCs, CLOs, and lean two-to-ten-person legal teams weighing whether to build an internal legal AI stack or buy a workbench. It is not a hit piece on building.

There are real cases where you should build. But the decision is usually made on a fantasy version of the cost, so the first job is to make it real.

Build vs buy legal AI, in one paragraph

Buy when you are a in-house team without dedicated engineering, your data can sit in a vendor's cloud under zero-data-retention terms, and your query volume is in the hundreds per month, not the hundreds of thousands. Build only when you have proprietary data you genuinely will not upload, a hard data-residency mandate, and a platform team that can own an evaluation set for years. The cost that decides it is never the model API. It is retrieval quality, hallucination verification, the eval set, security review, and the engineer who maintains all of it next quarter. Most lean legal teams should buy and keep the option to build narrowly later.

TL;DR

• The build vs buy legal AI decision is rarely lost on the model bill. It is lost on the parts nobody budgets: an evaluation set, retrieval quality, hallucination verification, security review, and the engineer who has to maintain all of it next quarter.
• A working legal RAG pipeline runs roughly $40k to $120k in engineering time before the first production query, plus ongoing infra and a named owner. The LLM API is the cheap part.
• DIY quietly fails in legal in four predictable places: retrieval (the model answers from the wrong document), verification (it cites something that does not say what it claims), maintenance (quality drifts and nobody notices without an eval set), and adoption (lawyers stop using a tool they cannot trust).
• Building makes sense in a narrow band: large engineering-heavy orgs with proprietary data they will not upload, hard data-residency mandates, or a need to own the model layer. For most lean legal teams, none of those apply.
• 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before. The killer is rarely the initial build, it is the maintenance nobody staffed, which is exactly the burden a build takes on and a buy hands to the vendor.

Part of our in-house counsel guide series.

The cost you can see vs the cost that decides

Open any internal build proposal and the headline number is the model API. It is genuinely small. A team of ten lawyers running real volume against a frontier model lands somewhere between fifty and a couple hundred dollars per user per month in tokens, which is in the same range as what a finished workbench charges per seat (see our legal AI seat cost buyer's guide for what published prices actually buy).

That number is true and it is also a trap, because it is the one cost that scales gracefully and the one cost you would have paid either way.

The costs that decide the project are the ones a lawyer-led team is least equipped to estimate. The arithmetic on building a legal retrieval pipeline is unforgiving: roughly $40k to $120k in engineering time before your first production query, then ongoing infrastructure once it is live.

That range is not one line item, it is seven that all hide behind the word "build": document ingestion and parsing, chunking strategy tuned for legal structure, the vector database and its hosting, an auth and security review, building and labeling an evaluation set, logging and monitoring so you can see drift, and the maintenance hours that never end.

We walked through that math in detail in our legal API vs RAG pipeline cost comparison, and the conclusion held up under scrutiny: the crossover where DIY beats a hosted approach sits at hundreds of thousands of queries a month, not thousands. A ten-lawyer team does not generate hundreds of thousands of queries a month. It generates hundreds.

Then there is the cost that does not appear on any slide: the person. A build is not a project, it is a tenancy. Someone owns the retrieval pipeline, the eval set, the prompt regressions, the model swaps when a better one ships, and the 4:47 p.m. Friday outage.

In a 5,000-person company with a platform team, that person exists. In a lean legal department, that person is the same engineer the GC negotiated for over Slack, and the day that engineer gets pulled back to the revenue roadmap is the day quality starts drifting with nobody watching.

The market has already run this experiment at scale. S&P Global Market Intelligence found that 42% of organizations abandoned most of their AI initiatives in 2025, up from 17% the prior year, and that the average organization scrapped 46% of its AI proofs-of-concept before they reached production.

Cost, data privacy, and security were the top obstacles cited. The pattern is not that AI does not work. It is that the version teams build for the demo is not the version that survives the second quarter.

A worked TCO comparison, year one

Here is the same ten-lawyer department costed both ways. The build column is a practitioner estimate of fully loaded engineering time at roughly $150k to $200k per loaded engineer-year, not a vendor quote; treat it as a range, not a number to put in a board deck. The buy column uses Vaquill AI's published self-serve seat.

The buy total is a real published price. The build total is an estimate, and the honest part of the estimate is the last row: even if every dollar figure came in low, you still owe a person whose job is to keep it correct.

Build vs buy legal AI at a glance

Start free trialBook a demo

Where DIY quietly fails for legal

Generic build-vs-buy advice does not transfer cleanly to legal, because legal has a verification problem that most internal tools do not. A customer-support bot that is 90% right is a good bot.

A legal research bot that is 90% right is a bot that just told an associate the wrong holding 10% of the time, and the associate does not know which 10%. Here is where DIY breaks down in practice, in roughly the order it bites.

Retrieval is the real problem, not generation. The first instinct on a build is to obsess over the model. The model is rarely the bottleneck. The bottleneck is whether the right document came back before the model ever saw the prompt.

Lawyers ask narrow, jurisdiction-specific, time-sensitive questions, and naive chunking shreds exactly the context that makes a legal answer correct. A clause split across two chunks, a statute section severed from its cross-reference, a definitions section retrieved without the operative provision: the model then writes a fluent, confident, wrong answer over the wrong evidence. You cannot prompt your way out of bad retrieval.

Verification is harder than it looks and lawyers will not skip it. The Stanford RegLab and HAI study that landed in 2024 and was later peer-reviewed in the Journal of Empirical Legal Studies tested the AI-assisted research tools built by the two largest legal-research vendors on the planet, companies with hundreds of engineers and decades of proprietary data.

Across more than 200 open-ended legal questions, it found Lexis+ AI produced incorrect information more than 17% of the time and Westlaw's AI-Assisted Research hallucinated more than 34% of the time. Read those numbers again, because they are the most important in this entire decision.

If LexisNexis and Thomson Reuters, with all of their resources, ship legal AI that fabricates between roughly a sixth and a third of the time on hard questions, the realistic question for a two-person build is not "will ours hallucinate" but "will we even know when it does."

Catching it requires span-level verification, matching each generated claim back to retrieved evidence and flagging anything unsupported. That is a research-grade engineering problem, not a weekend feature.

Maintenance is invisible until it isn't. Quality does not fail loudly. It drifts. A model update changes behavior, a new contract type confuses the retriever, a prompt that worked in March quietly degrades by June.

The only way to catch a 5% accuracy regression is an evaluation set, a gold standard of real questions with known-good answers that you re-run on every change. Almost no internal legal build has one on day one, and the public legal RAG benchmarks that exist, like LegalBench-RAG, are useful for research but are not your contracts, your playbooks, or your jurisdictions.

Without your own eval set, you are flying a legal tool with the instruments covered.

Adoption dies on the first wrong answer. Lawyers are professional skeptics by training. Hand a litigator a tool that confidently miscites a case once, and it is dead to them, no matter how good it is the other 99 times. A build that is technically impressive but unverified does not get more cautious adoption, it gets none.

The buy side of the market has spent real money on the boring trust scaffolding: displaying the source passage next to the answer, anchoring every citation to a retrievable document, abstaining when the answer is not in the corpus, claim-by-claim support checks, audit logs, and redline provenance so you can see where a change came from.

Vendors built that because they learned the hard way that adoption is a trust problem before it is a capability problem.

Build vs buy legal AI: the narrow case for building

None of this means buying always wins. It means building wins in a smaller band than most teams assume, and the band has nothing to do with whether your GC is technical and everything to do with three structural conditions.

You have proprietary knowledge you genuinely will not upload. Not "would prefer not to," but a hard no: unredacted Series C side letters, prior negotiation outcomes that reveal your walk-away positions, the playbook that encodes years of dearly-bought leverage.

If your honest answer to "would you put that into a third-party system" is no, and the data is the whole point of the tool, you have a real reason to build. This is the strongest case, and it is rarer than people claim, because most vendors now offer zero-data-retention terms that solve the version of this worry that is actually about training data rather than custody.

Data residency is a procurement gate, not a preference. Regulated industries with hard residency mandates, healthcare under HIPAA, fintech, defense, anything multinational tripping German or Singaporean rules, sometimes cannot buy the tool they want because the data cannot legally sit where the vendor hosts it. When residency is a legal constraint rather than a comfort issue, build math changes.

You are large and engineering-heavy enough to own the layer. Building is for the org that already has a platform team, an MLOps function, and the headcount to keep an eval set alive for years. If you have six engineers you can dedicate and twelve months, you may be able to ship a credible internal system for a narrow workflow.

If that is your situation, our walkthrough on building an internal legal copilot covers what that narrow build actually involves. Reaching genuine parity with a mature workbench across drafting, review, redlining, matter management, and compliance is a much larger ask. The honest version of that sentence is the warning inside it: six engineers, twelve months, for one slice. A lean legal team has neither the engineers nor the slice to spare. That is not a knock on in-house teams, it is just what the resource line says.

Notice what is not on this list. "Our needs are too specific to buy" rarely survives contact with a modern workbench, because the specificity lives in your playbooks and matter folders, which a good tool ingests, not in the software.

"It will be cheaper" is the slide that started this post, true only at query volumes a small department will never hit. For a fuller frame on the buy side, our in-house legal software guide for 2026 walks through the questions that separate vendors.

Three questions; any "no" means buy. Only all three "yes" justify building.

A decision rule you can use in one meeting

Strip away the architecture diagrams and the decision collapses to a short sequence. Run it in order and stop at the first yes that forces your hand.

1. Is the core value proprietary data you will not put in any third-party system, even under zero-data-retention terms? If yes, you are in build territory. If no, keep going.
2. Does a legal or regulatory mandate prevent the data from sitting where vendors host it? If yes, build or find a vendor who meets the residency requirement. If no, keep going.
3. Do you have dedicated engineering you can commit for a year and keep committed, including someone whose job is the eval set? If no, you do not have the team to build, full stop. Buy.
4. Will your real query volume cross hundreds of thousands of queries a month? If no, the cost argument for building does not exist. Buy.

Most in-house teams hit "no" by step three. That is not a failure. It is the correct read of what a five-person department should spend its scarce attention on, which is legal work, not running a retrieval pipeline.

The teams that get burned are the ones that skip this sequence, build the demo, ship it on optimism, and discover the eval set and the maintenance owner in month four, right when the abandonment statistics catch up to them.

If step three or four sends you to the buy side, the work is not over, it just changes shape. The buy decision is only as good as the questions you ask, and the ones that matter are not the ones in the demo.

Ask how the vendor measures its own accuracy and whether it will show you the eval methodology. Ask for zero-data-retention terms in writing, not a verbal assurance. Ask how source verification works, whether you can click from any claim to the underlying document.

Ask about export rights so you are not locked in. Ask for SOC 2 status, matter-level permissions so one team's documents do not bleed into another's, and real Microsoft Word track-changes support, because a redline that does not land in Word is one your counterparties cannot use. A vendor that answers those crisply has paid the trust tax. One that deflects has not.

There is a sane middle path the binary framing hides. Buy the workbench for the 90% of work that is standard contract review, drafting, redlining in real Word track changes, multi-step legal AI workflows, matter management, and compliance, where a vendor has already paid the verification and trust tax.

Build narrowly, later, only if real usage data shows a genuinely proprietary workflow the market cannot serve, and only if you have the engineer to own it. Launching on a tool you can adopt this week beats shipping a build you cannot trust next quarter, and it keeps the option to build open instead of spending the team's credibility on a first attempt that miscites a case and loses the room.

FAQ

Is it cheaper to build your own legal AI in the long run? Almost never for a in-house team. The model API is cheap, but the engineering to build the retrieval pipeline, the eval set, the security review, and the named maintenance owner are not. The crossover where DIY beats a hosted workbench sits at hundreds of thousands of queries a month, and a ten-lawyer department generates hundreds. Buying wins on total cost of ownership until you are genuinely large and high-volume.

When does it actually make sense to build legal AI in-house? Three conditions, and you usually need all three: proprietary data you will not upload to any third party even under zero-data-retention terms, a hard data-residency mandate that prevents the data from sitting where vendors host it, and a dedicated engineering team that can own an evaluation set for years. If any one is missing, buying is the rational call.

Can you just fine-tune ChatGPT or a generic LLM for legal work? You can, but generation is not the hard part. Retrieval is. A generic LLM still answers from whatever document your pipeline hands it, so naive chunking that severs a clause or a cross-reference produces a fluent, wrong answer no amount of fine-tuning fixes. Generic consumer tools also fail the confidentiality and privilege gate that legal work requires.

How accurate is legal AI, and will a build hallucinate? The Stanford RegLab and HAI study (2024, later peer-reviewed in the Journal of Empirical Legal Studies) found Lexis+ AI produced incorrect information more than 17% of the time and Westlaw's AI-Assisted Research hallucinated more than 34% of the time on hard questions. Those are the two largest legal-research vendors with hundreds of engineers. A two-person build will not beat them, and without your own eval set you will not even know when it is wrong.

What is the middle path between build and buy? Buy the workbench for the standard 90% (contract review, drafting, redlining, matter management) where a vendor has already paid the verification and trust tax, then build narrowly later only if real usage data exposes a genuinely proprietary workflow the market cannot serve and you have the engineer to own it. This keeps the option to build open without betting the team's credibility on a first attempt.

What should you ask a legal AI vendor before buying? Ask how they measure their own accuracy and whether they will show the eval methodology, for zero-data-retention terms in writing, how click-through source verification works, export rights so you are not locked in, SOC 2 status, matter-level permissions, and real Microsoft Word track-changes support. A vendor that answers crisply has paid the trust tax; one that deflects has not.

Why did so many AI projects get abandoned? S&P Global Market Intelligence (October 2025) found 42% of organizations abandoned most of their AI initiatives in 2025, up from 17% the prior year, with cost, data privacy, and security as the top obstacles. The failure is rarely the initial build. It is the maintenance nobody staffed, which is exactly the burden a build keeps and a buy hands to the vendor.

The bottom line

Building your own legal AI is a real choice with a real, narrow set of conditions where it is the right one: proprietary data you will not upload, residency mandates, and the engineering org to own the thing for years.

Outside that band, the honest math favors buying, not because building is bad but because the costs that decide the outcome, retrieval quality, verification, maintenance, and a named owner, are exactly the costs a lean legal team is least equipped to carry.

The 42% abandonment rate is not a story about AI failing. It is a story about teams underwriting the visible cost and getting surprised by the invisible one.

If you want to skip the build entirely and put a verified in-house workbench in front of your team this week, start a 7-day trial of Vaquill AI, self-serve, no procurement gauntlet. See how it fits a lean legal department on our in-house counsel solution page.

Arshita Anand

Co-Founder & CEO · Attorney

Arshita leads product and strategy at Vaquill, building the legal AI suite that solo, small-firm, and in-house US lawyers use to run a matter end to end.