AI contract analysis promises to extract clauses and surface risk across contracts at scale, and it delivers, until the one indemnification clause it silently misses costs a client real money. Contract review is a brutal product to evaluate from the outside: a demo showing 95% clause-detection accuracy looks impressive, and it is, but the 5% is where the liability lives, and it's rarely evenly distributed across clause types. Hiring the right team here means hiring people who think about that 5% obsessively, not people who optimize the headline accuracy number.
The metric trap: why 95% accuracy isn't the number that matters
AI contract analysis extracts clauses and surfaces risk across contracts at scale, and the impact is real, flagging risk that would otherwise take a lawyer hours to find manually. But a single aggregate accuracy number hides exactly the information that matters most: which clause types the model is weak on. A model that's 99% accurate on standard confidentiality clauses and 70% accurate on unusual indemnification language will report a great overall number while missing the clauses most likely to cost a client real money, because unusual, high-stakes clauses are exactly the ones a busy in-house team most needs flagged. Hire engineers who ask 'accurate on what, specifically' before they ask 'how do we get to 95%.'
The evaluation approach that actually catches the failure mode
The evaluation sets that catch this problem are deliberately weighted toward rare, unusual, and high-stakes clause language, not just a random sample of typical contracts, because a random sample under-represents exactly the clauses where a miss is expensive. Engineers who've done this well build test sets from real edge cases, unusual indemnification terms, non-standard liability caps, oddly worded termination clauses, sourced from actual contracts the tool will realistically encounter, not synthetic examples. This is slower and less glamorous than chasing an aggregate score, and it's the difference between a tool that's actually trustworthy and one that just looks trustworthy in a sales demo.
- Build the evaluation set from real, varied contracts, weighted toward unusual and high-stakes clause language.
- Track accuracy per clause type, not just overall, and treat the weakest clause type as the team's actual scorecard.
- Re-run the weighted eval on every model or prompt change, a change that improves the average can quietly regress the rare cases.
- Have a domain-literate reviewer (in-house or contracted) validate the hard cases in the eval set, not just the engineering team.
A confidence signal, not a single pass/fail
A contract review tool that returns one verdict per document, 'reviewed, risk flagged' or not, hides exactly the nuance a lawyer needs to trust it. The engineers worth hiring design for a per-clause confidence signal: which extractions the model is highly confident about, which are borderline, and which it genuinely isn't sure it caught correctly. That signal is what lets a review process route human attention efficiently, full trust on the high-confidence extractions, mandatory human review on the low-confidence ones, rather than either reviewing everything (defeats the purpose) or nothing (defeats the safety case).
| Confidence tier | Review approach | Why |
|---|---|---|
| High-confidence, common clause types | Spot-check on a sampling basis | Model has demonstrated reliability here across a large evaluation history |
| Low-confidence or rare clause types | Mandatory human review before any output is finalized | This is exactly where the liability concentrates |
| Novel clause language not seen before | Flag explicitly as unscored, force human review | The model has no track record to be confident about |
The team shape that gets this right
Contract review is a precision problem, not a coverage problem, and the team that gets it right is usually small and obsessive about evaluation rather than large and focused on adding features. One senior engineer who owns retrieval and extraction quality, working closely with someone (in-house counsel, a contracted legal reviewer, or a domain-literate product person) who can validate hard cases, outperforms a bigger team without that evaluation discipline. When interviewing, ask candidates to describe the last time they found their own system's blind spot, not the last time they improved an aggregate metric; the answer tells you whether they think about precision the way this product actually requires.
Setting the actual launch bar
The launch decision for a contract review tool shouldn't be 'the accuracy number crossed X%.' It should be 'the weakest clause-type accuracy crossed an acceptable bar, and every clause below that bar is either fixed or explicitly routed to mandatory human review.' That reframe is uncomfortable, because it means launching with known gaps clearly labeled rather than an implied blanket guarantee, but it's the only version of the launch decision that's honest about what the tool can actually promise a legal team relying on it.