Contract review and clause extraction: what AI can and can't do

The first AI idea most firms have is to paste a contract into a chat window and ask what's wrong with it. The output reads well. It names a few issues, sounds confident, and gives a partner no way to tell whether the flagged problem came from reading clause 14.2 or from the model's sense of what a liability complaint usually looks like. That question, whether a flagged issue is judgment or surface pattern matching, is the one practitioners keep returning to in discussions of AI-native legal review, and it's the question a workflow has to answer structurally rather than by asking the model to try harder.

The version that works in production is narrower and duller. You ask the model to extract facts into a fixed schema, with a pointer back to the text each fact came from, and you hand the result to a lawyer as a starting worksheet.

Why extraction outperforms an open-ended review

"Review this contract" asks for three things at once: find the relevant text, decide what it means in context, and decide whether it's acceptable for this client on this deal. The model has some capability at the first, patchy capability at the second, and none at the third, because acceptability depends on commercial appetite, the relationship with the counterparty and what the firm agreed last time.

Extraction splits those apart. The model finds and quotes; your playbook of standard positions decides what counts as a deviation; the lawyer decides what to do about it. Each step can be checked. When a comparison against a standard position is wrong, you can see whether the extraction was wrong or the playbook rule was.

The checklist drives the loop, one query per item you care about. This matters more than it sounds, because the expensive failure in contract review is the clause that isn't there. A model summarising a contract will rarely tell you there's no assignment restriction, no GST gross-up, or no cap carve-out for a data breach. Ask per item and "not present in this document" becomes an answer the system produces, not a silence you have to notice.

The shape of the extraction output

Keep the record flat and make every field verifiable against a span of source text:

{
  "item": "limitation-of-liability",
  "found": true,
  "clause_ref": "14.2",
  "page": 18,
  "quote": "The Supplier's aggregate liability under or in connection with this Agreement shall not exceed the Charges paid in the twelve (12) months preceding the claim.",
  "summary": "Liability capped at fees paid in the 12 months before the claim.",
  "standard_position": "Cap at 125% of total contract value, uncapped for breach of confidentiality.",
  "deviation": true,
  "notes": "No carve-out located for confidentiality or IP indemnity."
}

Around that sit the boring fields a matter file needs anyway: parties and their ACNs, execution and commencement dates, term and renewal mechanics, termination triggers and notice periods, governing law, payment terms, and the obligations with dates attached that someone will need to diarise.

The quote field carries most of the weight. A summary with no quote can't be checked in under a minute, so it gets skimmed and trusted. A summary with a quote and a clause reference can be confirmed or rejected at a glance, and the lawyer's eye goes to the text rather than to the model's prose.

Verify the extraction with something other than the model that produced it

Asking an LLM to grade its own answer produces agreeable nonsense. The pattern that's emerged in engineering tooling is a separate verification pass: MaruCheck, published on Show HN this month, exists specifically to provide independent QA for AI-generated code rather than relying on the generating model to check itself. Clause extraction needs the same separation.

In our pipelines the verification step is mostly deterministic and cheap:

• String-match every quote back into the source document. A quote that doesn't appear verbatim is a fabrication and the record is dropped or re-run.
• Check clause_ref and page against the document structure parsed at ingestion, so a quote attributed to the wrong clause fails.
• Re-run the deviation comparison as a second call that sees only the quote and the standard position, with no access to the first model's conclusion.
• Flag documents where OCR confidence is low or the clause numbering doesn't parse, and route those to manual review instead of extracting from mush.

Ignore the model's self-reported confidence score. It's fluent, not calibrated, and it tends to be highest on the clauses that are drafted most conventionally, which are the ones you needed help with least.

The lawyer's markup stays the deliverable

The strongest argument in that practitioner discussion is about artefacts: the thing clients pay for is the redline, and the value only lands when the lawyer's pass is captured as edits. Build the workflow so the machine output is a worksheet sitting beside the document, and the returned markup is what goes out the door.

CodeRabbit's auto-generated review summaries show the production shape of this in software: a structured first-pass summary posted alongside the pull request, with the human reviewer's decision remaining authoritative. Contract review maps onto it cleanly. The summary lands in the matter in your DMS or practice management system, the lawyer accepts, edits or rejects each row, and the accepted rows flow into the redline and the obligations register.

Capture the accept and reject decisions. After a few hundred contracts you have a record of which checklist items the extraction handles reliably and which ones a senior lawyer overturns half the time. That's the evidence you need to decide where to spend engineering effort, and the only honest basis for telling partners how much of the first pass they can lean on.

What accuracy to expect

Nobody can give you a number that transfers. Published accuracy claims for clause extraction are measured on someone else's document set, usually clean, usually in US or English drafting conventions, and they say nothing about how a tool performs on your precedents, your counterparties' paper, and the scanned 2013 deed of variation that amends clause 14 without renumbering anything.

Measure it yourself before you commit. Take 30 to 50 contracts representative of the work, have a senior lawyer mark up what a correct extraction looks like for each checklist item, and score the pipeline against that set. Report recall and precision separately, because they cost different amounts: a false positive wastes fifteen seconds of a lawyer's time, while a missed indemnity carve-out can go out the door. Re-run the set whenever you change a model, a prompt or a document parser.

The failure modes are consistent. Defined terms that shift meaning across a suite of documents, obligations incorporated by reference from a schedule or a URL, conditional carve-outs ("except as provided in clause 9.3"), and anything in a table or a poorly scanned annexure are where extraction degrades. Long agreements also lose fidelity toward the end of a context window, which is a reason to chunk by clause and run per-item queries rather than posting the whole document with one broad instruction.

Confidentiality and cost

Contracts are dense with material facts, which is why they reward systematic analysis. The Intercept reconstructed the working relationship between the Pentagon and OpenAI, Google and Anthropic from more than 400 pages of contract paperwork obtained under FOI. The same property makes these documents the last thing you want sitting in a third party's training pipeline or retained logs.

Before any pilot, settle where the documents go: which region the inference runs in, what the provider's retention and training terms say, whether your client engagement terms and confidentiality undertakings permit disclosure to that processor, and who signs off on that decision inside the firm. Get privacy advice on cross-border disclosure rather than inferring it from a vendor's marketing page. Deployment options in Australian regions exist across the major cloud providers, and for firms with the strictest undertakings we've run smaller open-weight models on infrastructure the client controls, accepting lower extraction quality in exchange for the documents never leaving.

Running costs are modest. Per-document API spend for a commercial agreement is small against six minutes of a lawyer's time, and the tokens are a rounding error in the project. The real cost is the gold set, the playbook of standard positions written down properly for the first time, and the ongoing maintenance when models change underneath you. Budget for a pilot on one contract type, with one checklist and one practice group, before anyone talks about rolling it out across the firm.

This post is part of our Practical AI for Law Firms series, which covers the systems Australian firms can put into production now and the ones worth waiting on.

PicNet builds production AI systems for Australian organisations. Talk to us about what a first project could look like.

---

Originally published at picnet.com.au.