AI Contract Review on Your Own Server

A vendor sends a 22-page master services agreement. The company's standard position caps liability at 12 months of fees, and the vendor's draft caps it at $50,000. With fees of $8,000 a month, the standard cap would be 12 x 8,000 = $96,000, so the draft gives away almost half. Spotting that by hand means reading the whole agreement against a checklist. AI contract review on premise does the same reading on a server the company controls: a local model splits the contract into clauses, compares each one to the company's own playbook, and flags the gaps for a lawyer, without the draft ever leaving the building.

This article covers how that review pipeline works. The confidentiality and ethics questions for law firms, and the other workflows a firm can run, sit in private AI for law firms.

The playbook is the real product

A model with no playbook can only say whether a clause looks unusual compared with contracts in general. That is rarely the question. The question is whether the clause matches what this company accepts. So the first deliverable of any contract review project is a written playbook, one row per clause type, in a structure a program can read.

Clause type	Standard position	Acceptable fallback	Escalate if
Limitation of liability	Cap at 12 months of fees, mutual	Cap at 6 months of fees	Cap below 6 months, or one-sided
Governing law	Company's home state	Any US state	Non-US law
Auto-renewal	None, or 60 days' notice or less to cancel	61 to 90 days' notice	Notice over 90 days
Indemnity	Mutual, third-party IP claims	Vendor-only for IP	Uncapped indemnity by the company
Termination for convenience	Either party, 30 days	90 days	Not available to the company

Three things make a playbook usable by software. Each position is stated as something checkable (a number, a list of allowed values, a yes or no), not as "reasonable". Each row says who may approve a fallback. And each row names the questions a reviewer would ask, which become the fields the model extracts.

Writing this table is legal work, and it often surfaces two lawyers applying different standards, which is worth knowing either way.

Clause extraction: turning a contract into rows

The pipeline does not hand the model a whole contract and ask what is wrong. It works in two steps: find the clauses, then read each one with a narrow question.

Splitting and labeling

Most contracts have numbered sections, so a parser can split on headings and numbering before any model is involved. The model then labels each section with one or more clause types from the playbook. A single section titled "Miscellaneous" can hold governing law, assignment and notices, so labels are per paragraph, not per heading.

A public reference point for which clause types exist is CUAD, the Contract Understanding Atticus Dataset, which the Atticus Project describes as 510 commercial contracts with more than 13,000 labels across 41 clause types, released under CC BY 4.0 (CUAD). Its categories are a useful checklist when drafting a playbook, and the labeled contracts can serve as a first test set before the company's own contracts are used.

Extracting fields, not opinions

For each labeled clause, the model fills a small schema. For the liability clause above, that might be: cap type (fixed amount, multiple of fees, none), amount, fee period, whether it is mutual, and the list of carve-outs. Getting a local model to return that shape every time is a separate engineering problem, covered in getting reliable JSON out of a local LLM.

The comparison itself then happens in ordinary code. The model reports "fixed amount, $50,000, mutual"; the program reads monthly fees from the order form, computes 12 x $8,000 = $96,000 and 6 x $8,000 = $48,000, and concludes that $50,000 is below standard but above the fallback floor. Models are unreliable at arithmetic and at applying thresholds consistently across hundreds of clauses. Code is not.

Missing clauses are findings too

An extraction step only sees what is present. If the playbook expects a data protection clause and none was labeled, that absence must be reported as a deviation. A review that lists only problems in existing text will pass a contract that simply leaves out the protection the company needed.

Flagging deviations

Each playbook row ends in one of four states:

• Matches standard: no action, but still listed so the reviewer sees it was checked.
• Within fallback: acceptable if the named approver agrees.
• Outside fallback: escalate.
• Not found: the clause is missing, or the model could not locate it.

The last state deserves care. "Not found" must never be silently converted to "matches standard". A reviewer who sees 25 green rows assumes 25 clauses were read.

Defined terms cause the most quiet errors. A liability cap of "the Fees paid in the Measurement Period" means nothing until the definitions section says what the Measurement Period is. The extraction step should pull the relevant definitions alongside each clause, and the output should show them. A contract of 30 pages at roughly 500 words a page is about 30 x 500 = 15,000 words, and more than 15,000 tokens, since English text usually needs more tokens than words. That is more than many local setups accept by default: Ollama, for example, documents a 4k context default on GPUs with less than 24 GiB of VRAM (Ollama context length). Processing clause by clause, with only the needed definitions attached, keeps each prompt small; the trade-offs are laid out in why long documents break local LLMs.

Why the model must quote the clause it relies on

Every finding should carry the exact text the model based it on: the section number and the verbatim sentence. This is the single most useful rule in contract review, for three reasons.

First, the quote can be checked by code. If the quoted sentence does not appear character for character in the contract text, the finding is rejected or retried before a human sees it. That check, and its limits, are explained in reducing hallucinations in document Q&A.

Second, the quote exposes misreadings that a summary hides. Suppose the model reports "liability capped at $50,000, mutual". The quoted sentence reads: "Except for Supplier's obligations under Section 11, each party's aggregate liability shall not exceed $50,000." The carve-out for Section 11 is right there, and a reviewer who reads it will check what Section 11 covers. A paraphrase would have dropped it.

Third, the quote makes review fast. A lawyer who can jump from the finding to the highlighted sentence checks a flag in seconds. A bare "liability cap is below standard" sends the lawyer searching through 22 pages.

A quote that exists is not proof that it supports the finding. The model can quote the right sentence and still misjudge it, for example by treating "fees paid in the prior 12 months" as equal to "12 months of fees" when the contract is only three months old. That is why the reviewer reads the quote, not only the verdict.

Redlines as suggestions, never edits

Once a deviation is found, the useful next step is a proposed change: replace "$50,000" with "the fees paid or payable in the 12 months preceding the claim". The model can draft that from the playbook's standard language. What it must not do is change the contract.

In a Word document, a suggestion can be written as a tracked change. In the underlying WordprocessingML, an insertion is a w:ins element and a deletion a w:del element, each carrying w:id, w:author and w:date attributes (Microsoft Open XML reference). Writing changes with an author such as "AI review" lets the lawyer accept or reject each one with the normal Word controls, and makes it obvious later which edits a person made. A comment anchored to the clause, containing the finding and the quote, works even when the proposed wording is not ready.

Three rules keep this safe:

1. The original file is never overwritten. Suggestions go into a copy.
2. Nothing goes to the counterparty without a lawyer accepting each change. A tracked change from "AI review" in a sent draft tells the other side exactly how the company reviews contracts.
3. Before sending, a script checks the document for leftover comments and unaccepted AI changes.

Testing it before anyone relies on it

The measure that matters is how many real deviations the system misses. Build a test set from contracts the company already negotiated, where a lawyer's markup shows what was wrong.

Take 40 past contracts checked against a 25-row playbook. That is 40 x 25 = 1,000 clause checks. Suppose lawyers had found 80 real deviations among them, and the system flags 68 of those plus 50 false alarms. It caught 68 / 80 = 85% of deviations, and 68 / (68 + 50) = 58% of its flags were real. The false alarms cost reviewer time; the 12 misses are the risk. Look at what the misses have in common before tuning anything: often they cluster in one clause type, a definition the extractor never pulled, or a scanned exhibit with no text layer.

Repeat the test whenever the model, the prompts or the playbook changes. A playbook edit that tightens one threshold can change dozens of results at once.

A sensible first deployment is narrow: one contract type, such as inbound NDAs or vendor agreements, where the playbook is short and volume is high. If the tool's flags on that type agree with lawyers on the test set and every finding carries a verified quote, extend it to the next contract type; if not, fix the playbook and extraction before adding scope.

Frequently asked questions

Can the system review a contract that was scanned on paper?

Only after optical character recognition turns the scan into text. OCR errors such as a misread digit in a dollar amount flow straight into the extracted fields, so scanned contracts deserve a lower trust level and a reviewer check of every numeric finding.

Does the model need to be fine-tuned on the company's contracts?

Usually not at the start. The playbook, the extraction schema and the quote check do most of the work with a general instruction-following model. Fine-tuning becomes worth considering only after testing shows a consistent failure on one clause type that better prompts do not fix.

Who owns the playbook once the system is live?

A named lawyer or contracts manager, with changes recorded and dated like any other policy. When a position changes, the test set should be rerun, because an old threshold left in one row will quietly approve terms the company no longer accepts.