Field notes · Production AI
Optimise the reviewer, not the robot
A legal team was drowning in contract review. The build went to a vendor strong in ML but new to production, and the first attempt - a custom-trained model - was shelved after it lost the team’s confidence. We came in to architect the deployment, and then, repeatedly, to get it unstuck. The lesson that runs through it: a lawyer reviews everything regardless, so the win was never machine autonomy. It was making the human’s review effortless - and choosing the simpler architecture every time.
The bottleneck
The legal team managed more than a thousand enterprise agreements. Every new contract or renewal needed manual review to confirm the mandatory clauses were present and compliant. That took days per document, and it quietly delayed commercial deals. Finding a precedent in the existing library meant reading through files by hand. When the top-down AI mandate landed and threw up a list of candidate problems, this one was picked because it was visibly slowing a team down.
The role we held
The honest version matters here, because it isn’t the obvious one. The mandate to design and build went to a vendor team. We were brought in for the cloud and application-deployment architecture, and then stayed, because at each hard moment we were the ones who found the way through. We didn’t build the model. We made it possible to ship one, and we directed the calls that made it trustworthy.
The false start
The first project was different from what eventually shipped: redraft each contract into the in-house language. The vendor’s approach was to custom-train a small model (a T5-XL) on around a hundred example contracts. It couldn’t meet the bar. Our call, in early 2024, was to stop training a small model and reach for a far more capable one instead. But by the time that landed, the legal team’s confidence was spent, and the project was shelved in favour of a new, narrower proposal.
The hard call: optimise the reviewer
It’s tempting to frame legal AI as automation versus accountability. Here that was never a live tension. This was early 2024, the models weren’t that strong, and nobody wanted full automation. A lawyer was always going to review everything. So the real design question wasn’t “how autonomous can we make it?” It was “how effortless can we make the human’s review?”
When a human has to check everything anyway, machine autonomy is the wrong thing to optimise for. Optimise their review instead. Keep them in charge, and make being in charge effortless.
Capability over cleverness
The same pattern showed up again and again, and it’s the thread worth pulling. Each time the build got stuck on cleverness, the way out was to simplify and let a capable model carry the load. The bespoke T5-XL gave way to a strong foundation model that simply followed instructions. On the search side, a contributor with a traditional-NLP background had piled on pre-processing that added complexity and errors. The fix was to strip it back and trust the model to do the work.
The capable model is the layer that keeps getting better fastest. Betting on it, and against your own cleverness, is usually the right call.
Clause by clause
The review half turned out to decompose cleanly, which is part of why it worked. The requirement supplied a list of standard clauses, and the task was to check a draft agreement against them. So at any moment the problem reduced to one clause against one paragraph. Divide and conquer. Paired with a model that followed instructions faithfully, that narrow framing kept the review accurate and the output easy for a lawyer to scan: each suggested revision sat against the clause it addressed.
Two kinds of question
The chatbot half was where users first hit wrong answers. The cause was that two very different kinds of question were being handled the same way. “What is the breach-notification time for this vendor?” is a semantic question a model should answer from retrieved text. “How many agreements do we have?” or “do we have one for this vendor?” is a counting or metadata question, exactly where a model quietly guesses wrong. So we split the paths: exact questions go to deterministic tools that answer reliably, and semantic questions go to the model over retrieval.
Making it trustworthy
A minority of chatbot answers being wrong was the blocker that kept it from production. The fix wasn’t a cleverer prompt. It was a correctness regime, the discipline most teams skipped in 2024. We built a test set from the questions users actually asked, ran it automatically on every change, analysed the errors, and used a capable model as a judge to grade answers at scale. The misses closed, and stayed closed.
Confidentiality, handled
The documents were highly confidential, so the integration mattered as much as the model. Security was comfortable from the start; they knew our approach from earlier work. Users authenticated with their enterprise identity and were authorised by role through Cognito, approved by the legal lead. Documents stayed inside a designated SharePoint area the team already used and security had already blessed. Reads and writes happened only through a protected Lambda, one that nothing else could invoke, using a service principal. The Cognito integration proved tricky enough that the app team couldn’t complete it. Closing it was one of the pieces we took on directly.
What we'll stand behind
It reached production and it’s in use. By design, a lawyer reviews every result. The system’s job was never to decide, only to make that review fast. We’ll report that plainly, with no dressed-up numbers: the honest measure here is that it shipped, it’s used, and the human stayed in charge. It also shares its bones with the other builds, a common React frontend and container-based CI/CD shared with the other AWS system, so each new build started further along than the last.
Our role
Cloud and application-deployment architect, and technical director, for a vendor-built system. We owned the production architecture - containers, CI/CD, Cognito, the protected SharePoint integration - and directed the decisive calls: the move to a capable model, the deterministic tools, the correctness regime. The ML build itself sat with the vendor team.
A lesson, generalised
A pattern worth naming, gently: a build team can be strong in ML and still new to production. The distance between a notebook that demos and a system that runs is exactly where most AI projects stall. It isn’t a knock on anyone. It’s a different discipline. Someone has to own the deployment, the integration, the security, and the correctness regime, or the cleverest model never reaches a user. On this build, that was the seat we held.
The principles underneath
A handful of durable ideas carried the whole thing.
- →Capability over cleverness. Reach for a capable model and a simple flow before bespoke training and heavy pre-processing.
- →Optimise the human's review. When a person must check everything, the value is in making the check effortless, not in chasing autonomy.
- →Deterministic tools for exact questions. Counts and metadata come from code, not from a model's guess.
- →Trust the model, then prove it. Strip the scaffolding - then earn the trust back with tests and an LLM-as-judge loop.
- →Observability isn't optional. You can't fix what you can't see; log first, analyse, then improve.
- →Build from reusable parts. A shared frontend and shared CI/CD let each build start further along.