The problem with legal tech tools
Giel De Prins
Dec 9, 2025
Executive summary
Legal tech was supposed to simplify legal work. The pitch sounded direct enough: upload documents, run analyses, and let technology take care of the repetitive parts. But in practice, many teams discover something very different. The tools don’t actually come with the legal expertise built in. They require you to write detailed instructions for every risk you want to identify, test those instructions again and again, and constantly refine them as new deals and document types come in. What was sold as automation becomes a parallel engineering effort.
The article looks at why this keeps happening across the industry. Not because the platforms are weak, but because they are designed to serve every legal practice at once. That breadth forces them to stay generic. They provide the infrastructure, while firms must supply all the reasoning logic themselves. In the context of due diligence, where the work is sequential, accuracy is non-negotiable, and contract language can directly affect deal value, that gap becomes impossible to ignore.
There are tools that handle this differently, but the point of this piece is not to compare products. It is to explain the structural tension at the heart of most legal tech promises today. When automation depends on the user building automation before it can work, adoption slows, maintenance grows, and the expected efficiency rarely appears.
This article outlines that tension clearly and asks a simple question: what should legal tech deliver, and who should be responsible for making it reliable enough?
Article
You spent €100K on a legal tech tool everyone is buzzing about. Eight months in, your associates are still figuring out how to use it, the results are inconsistent, and you discover you first need to build your entire legal processes on top of it.
The pitch was simple. AI would make your legal processes faster and more reliable. You'd upload documents, get an analysis, and watch efficiency soar. That's not what happened. Instead, you discovered there's a whole engineering project nobody mentioned. You thought you were buying legal automation. What you actually got was AI infrastructure requiring months of configuration before it works.
Even after months, most firms still don’t see the gains they expected. Others are getting far better results, but not because they cracked the generic platforms. They moved to tools where the legal expertise is built in from day one.
The hidden engineering problem nobody warned you about
You get powerful technology. What you don't get is the legal logic built in. Every risk check, every analysis, every instruction needs to come from you. While creating these instructions requires legal knowledge, it is a separate discipline that combines legal expertise with AI engineering, a field most lawyers have never encountered.
Take something that sounds straightforward: checking management agreements for problematic non-compete clauses. You can't just ask "are there problematic non-compete clauses?" The system needs detailed instructions, something like:
“Deal context” (things like: official name target company, type transaction, estimated value, …)
** Deal context (name and structure of the target(s), type transaction, estimated deal range, industry)***
** Rules about how to reason about risk materiality *Identify any non-compete clause and assess its validity under Belgian law: confirm protection of a legitimate business interest (confidential information, clients, know-how), direct competitive activities only, proportionate duration and territory aligned with the company’s actual market, clarity on restricted services and customer targets, no disproportionate limitation on the manager’s ability to work or earn income, no restriction that exceeds what is necessary for fair competition, and a reasonable and enforceable penalty. Conclude valid, partially valid, or invalid with a short justification.
That is just one check for one document type. You need comparable instructions for every risk you want to identify, across every contract category and for every jurisdiction you operate in.
What makes this even harder is that each legal check must be tested on hundreds of contracts to uncover edge cases and misinterpretations. Then you refine the instructions and test again. This cycle repeats until you reach a certain accuracy level.
While you're certainly good at law, this is about understanding how large language models like ChatGPT and Claude interpret instructions, what makes them hallucinate, what causes inconsistencies. Most lawyers don't have this knowledge. Not because you're not smart enough, but because you studied law, not AI engineering.
Another layer that is often missed is that you don't naturally know what these systems can and cannot do. The technology isn't transparent about its limitations. It will attempt any task you give it, even when it lacks the right information. Instead of admitting uncertainty, it generates something that looks plausible but is a hallucination.
The economic reality? You spend weeks or months just getting your instruction sets to work. Every new document type forces you to rebuild large parts of the logic. Every deal starts with configuration overhead. The efficiency gains you expected are absorbed by the maintenance burden.
Why general-purpose platforms can't and will not fix this
The major legal AI platforms support everything: contract drafting, legal research, compliance work, litigation support, M&A. That is not a technical achievement. It is a business strategy. Broader coverage means broader revenue. One platform for all legal work means a stronger investor story.
But that strategy forces them to stay horizontal. And that creates two structural problems.
First, the economics don’t support depth: ****Companies like Harvey and Legora have plenty of capital. The limitation isn’t ability. It’s incentive. Automation of legal due diligence requires embedded expertise: 100+ checks per contract type, jurisdiction-specific rules, constant updates as laws and deal practice evolve. That work takes a lot of resources to build and even more to maintain.
And the payoff is limited. Improving M&A workflows does not expand their market. It narrows it. They prioritize features that every legal team will use. They deliver powerful infrastructure and expect your team to build the expertise on top.
They will not embed specific workflows. It doesn’t fit their model.
Second, the interface must remain generic: Due diligence is not a single task. It is a sequenced workflow: deal context, categorization, risk analysis, reporting. Each step depends on the one before it. The UI needs to be designed around that flow for the work to be fast and reliable.
A horizontal platform has one interface for every practice group. Litigation. Regulatory. Corporate. M&A. They can’t redesign the product around one workflow without making the rest worse. They can’t maintain dozens of specialized workflows without turning the product into a maze.
So they stay broad. They let you configure the workflows yourself. Which means you design everything. You test everything. You maintain everything.
You get the engine, but you still have to build the vehicle.
What’s needed for due diligence?
Due diligence isn't a single task. It's a multi-step process that needs to work as an integrated sequence. Here's what that process actually looks like:
Document intake
Deal context (Information request list, name company and subsidiaries, …)
Structuring and sorting the data room
GAP analysis
Document analysis
Q&A with target
Reporting
Notice something? You can't just run step 5 (the analysis) in isolation and call it done. Each step feeds into the next. Document intake from data room providers is not always possible without having connections with them. The deal context determines how documents are analyzed. Document categorization determines which risks the platform needs to check for…
The accuracy requirements are also completely different from other legal work. While 80% accuracy might be acceptable in legal research where you're validating everything anyway and the work is exploratory, due diligence demands far more. Missing a change-of-control clause in one of the most important customers contracts in a €200M deal isn't a minor oversight.
It's the kind of miss that could kill deals or create post-closing disasters. You're not just looking for interesting information. You're looking for deal-breaking risks, valuation impacts, and post-closing operational constraints. Your reputation and your company’s investment depend on not missing the critical issues.
Built-in legal expertise: The questions generic systems can't answer without you building the legal expertise in: Which change-of-control clauses are actually material? Which indemnity carve-outs impact deal value? When does a non-compete become unenforceable post-closing? How does assignment language create operational constraints after acquisition?
This is knowledge built together with dozens of lawyers who have done hundreds of transactions. It's jurisdiction-specific, deal-type-specific, and industry-specific. It can't be discovered through trial and error on your live deals. You need this expertise built into your tools before you start using AI tools for legal due diligence.
What exactly is the built-in legal expertise we’re talking about?
So, instead of you implementing the expertise by writing thousands of instructions and the platform automating execution, the software vendor brings the legal expertise and the automation, you bring the deal specifics. How does that actually work and why is it necessary?
It starts with specialists like you who've spent careers doing M&A. Employment lawyers for employment agreements. IP counsel for licensing and patents. Commercial specialists for customer and supplier contracts. They document how and what they would review in a specific document type.
The real value comes from capturing the detailed logic these specialists use to assess contracts. Then AI engineers are necessary to translate that knowledge into instructions that guide the large language model in the most accurate and efficient way. Not the surface-level "look for non-competes," but the full detailed version that captures the actual legal reasoning and knows what edge cases to watch for.
This is where legal expertise meets AI engineering. The engineers know what language models can and cannot reliably do. They know how to prevent hallucination. They understand how to structure instructions so the system performs tasks it can handle reliably and transparently declines tasks where it lacks the right information.
Testing, testing and testing
Each check is tested on hundreds of real contracts, where false positives (issues that aren't actually problems), false negatives (real issues the system missed), and accuracy rates are measured. Then the instructions are refined, so you test again, and adjust again.
This process repeats itself until performance consistently hits 95%+ accuracy. This takes weeks per document type. Sometimes months. It's expensive and slow. Which is one of the reasons why most vendors don't do it. And why it creates a lasting competitive advantage for those who do.
The result is embedded checks that are ready for you to use immediately. Most document types like customer contracts, employment contracts, lease agreements, etc. contain +100 legal checks. Each designed to catch a specific risk that could affect the deal structure, valuation, or post-closing execution.
Outcome
That way the user experience is much more streamlined and simplified: you upload your documents or connect directly to your data room. You provide the deal context (transaction value, target entity, corporate structure, jurisdictions). The system automatically categorizes everything by document type. It runs the relevant embedded checks on each document and delivers structured risk analysis across all your contracts.
You skip the instruction writing. You skip the testing phase. You skip the maintenance between deals. The expertise is already built in. You get to focus on what you're actually good at: interpreting the findings, assessing materiality for your specific deal, and advising your client.
More about the due diligence checks
About 80% of legal checks during a due diligence are jurisdiction-agnostic. They're structural questions: Is there a termination clause? What's the notice period? Does the contract include change-of-control provisions? These don't depend on local law. You need to find and analyze them regardless of where your target operates.
The remaining 20% are jurisdiction-specific. Here you need to know local enforceability standards, statutory requirements, what courts typically uphold. With narrow focus on just M&A, you can build both layers completely. The universal checks work everywhere. The jurisdiction-specific logic gets added systematically, market by market.
With horizontal platforms, this depth breaks down fast. The same employment agreement is reviewed differently in an M&A deal than in a standalone HR audit. A lease in a real estate transaction requires different checks than the very same lease in a corporate restructuring. Environmental representations matter one way for a share purchase, another for a site acquisition. Every context introduces its own priorities, thresholds and conclusions. To maintain these layers of logic across all legal scenarios is unmanageable.
Adaptability
Before you ask: "But what about our firm's specific standards?" While embedded expertise serves as your foundation, you can add your own layer and adapt the parameters over time. For example, PE funds can build industry-specific playbooks. If you're doing healthcare deals repeatedly, you embed the healthcare-specific risks you care about.
Law firms can adapt the materiality thresholds. Your standard for what constitutes a material change-of-control clauses becomes embedded in your configuration. Corporate M&A teams layer in group-specific requirements. Your parent company's restrictions, your standard warranty expectations, your operational red flags.
The system becomes more valuable as you use it. Classic software retention model. But it works from day one without any of this. The customization is additive, not required. You get immediate value, then you make it better for your specific needs over time.
And most important of all you do the adaptations within a guided framework, you don’t start from a blank page.
Non-legal teams
With built-in legal logic, non-lawyers can safely take on parts of the review. Investment analysts can run first-pass checks. Corporate development can prepare structured summaries. Finance teams can pull key commercial terms. The rules are already embedded, so they interpret results instead of building the analysis themselves.
The output can be tuned for non-legal users. Concepts like change of control, assignment, or indemnity can be explained in plain language and tied to the context of the deal. They don’t need the underlying legal reasoning. The system handles that. This lets more people contribute to due diligence without increasing risk.
Making the Right Choice for Your Team
How do you decide which approach your M&A practice actually needs? If you have internal teams that combine legal and technical expertise, if you have people who can design reliable prompts, test it systematically, and maintain it across your deals, then general platforms might work fine for you.
You can build exactly what you need on top of their infrastructure. You own total flexibility. You control every aspect of how your analysis works. The tradeoff is ongoing maintenance burden and the need to keep those specialized resources on your staff. That's a significant investment, but for some firms it makes strategic sense.
For the vast majority of M&A practices, building and maintaining your own configurations doesn't make sense. You'll spend months getting your first version working. You'll need to maintain it as your deals vary. Your "AI advantage" becomes an "AI project" that needs dedicated resources you didn't plan to hire.
Better to use systems where this work was already done, tested on thousands of contracts, and maintained by teams whose full job is keeping it current. You get to focus on your deals, not on maintaining your tools.
If you're in corporate development, investment analysis, or finance, general platforms aren't safe for you to use without extensive legal oversight. The risk of missing something critical or misinterpreting findings is too high when the legal guardrails aren't built in.
You need systems where the legal expertise is embedded, so you can safely contribute to the process without creating downstream problems for your legal team. You bring your financial analysis skills, your industry knowledge, your transaction experience. The system brings the legal expertise.
Time to value
Time to value differs dramatically between approaches. Embedded expertise platforms work immediately, letting you test on real documents today, while build-your-own platforms require months of configuration before meaningful testing becomes possible. You can know within days whether embedded expertise tools work for your deals.
Ongoing maintenance follow a similar pattern. With embedded expertise, the vendor maintains and improves checks. You benefit from their continuous testing and refinement. With build-your-own approaches, you need continuous internal resources just to keep your configurations working as your deals evolve.
Consistency also varies significantly. Embedded expertise means the same checks run the same way every time across your entire team. Build-your-own results vary depending on who configured the system and when, creating risk that different associates are effectively running different analyses.
Team training also differs dramatically. With embedded expertise, you provide deal context and the system handles analysis logic. Your training focuses on interpreting results and understanding findings. With build-your-own, you're training people on how to design and maintain prompts. That's a completely different skill set.
Questions for Vendor Evaluation
When you're comparing legal AI platforms, these questions reveal which model you're actually buying. Are your legal checks already built into the platform, or do we design them ourselves? How do you ensure the same risk gets flagged consistently across hundreds of our documents?
Can non-legal team members use this safely for preliminary work? When the system is wrong, who owns the accuracy? Is that our responsibility to fix through better configuration, or yours to fix in the product?
How many real contracts did you validate each check against? Can we run a meaningful trial on actual documents immediately, or do we need to configure the system first? The answers tell you immediately whether you're buying infrastructure or expertise.
The choice ahead
The legal AI market is splitting into two distinct approaches. The first includes firms with specialized technical resources who build on general platforms, maintain sophisticated configurations, and own that complexity as part of their competitive advantage. The second comprises firms that want due diligence solutions that work immediately, where the expertise is embedded and accuracy is the vendor's responsibility.
Both are valid. Neither is wrong. But for 98% of M&A practices, the choice is clear. Due diligence is too complex for ad-hoc configuration. The accuracy bar is too high for "best effort" results. The real question isn't which tool has better AI. It's simpler: Do you want to build your due diligence system, or do you want to buy one that already works? The firms winning with AI aren't the ones with the most sophisticated configurations. They're the ones who realized they didn't need to build configurations at all.