Local AI Contract Review: Private Setup Guide

Published on April 11, 2026 -- 16 min read

Short answer: a local contract review system is three pieces — a document converter that turns PDFs and Word files into clean text, a RAG index holding your own approved templates, and an Ollama-served model large enough to reason about nested legal conditions. It extracts terms, flags deviations from your standard positions, and diffs versions, entirely on hardware you control. It does not give legal advice, and the section on what it cannot do is the most important one on this page.

The reason to build it locally rather than paste into a chat window is simple: a contract is the single most concentrated confidential document your business produces. Pricing, strategy, personnel, exposure — all in one file.

---

Why keep contracts off cloud AI? {#why-no-cloud}

Consider what a typical commercial contract contains:

• Financial terms — pricing, payment schedules, penalties
• Trade secrets — proprietary processes mentioned in scope-of-work sections
• Personnel data — names, titles, compensation in employment agreements
• Strategic information — M&A targets, expansion plans, partnership terms
• Competitive intelligence — exclusivity arrangements, non-compete scopes

When you paste this into a cloud AI:

1. The text travels over the internet to a data center you have never audited
2. It is processed on shared GPU infrastructure alongside other customers' data
3. The provider's retention policy determines how long your contract text lives on their servers
4. Staff at the AI company may review flagged conversations for safety or quality

Even with enterprise agreements that promise no training on your data, the operational reality is that your text exists on someone else's hardware, subject to their security practices, their employees' access controls, and their government's jurisdiction.

Local AI can remove much of this exposure. The contract text goes from your document management system to your GPU and back, assuming the workflow has no telemetry, external storage, or remote vendor access enabled.

For a broader analysis of local AI data sovereignty, see why lawyers are choosing local AI.

---

What does the system look like? {#system-architecture}

The contract review stack has four components:

+----------------------------+
|  Contract Documents        |
|  (PDF, Word, plaintext)    |
+----------+-----------------+
           |
           v
+----------+-----------------+
|  Document Processor        |
|  (pdf2text, pandoc)        |
+----------+-----------------+
           |
           v
+----------+-----------------+
|  RAG Pipeline              |
|  (AnythingLLM or custom)   |
|  Template contracts as     |
|  reference embeddings      |
+----------+-----------------+
           |
           v
+----------+-----------------+
|  Ollama (LLM inference)    |
|  70B for analysis          |
|  14B for quick extraction  |
+----------------------------+

How much hardware does this need?

Start from the arithmetic rather than from a shopping list. Quantised weights scale almost linearly with parameter count, and at Q4_K_M the working rule is:

VRAM for weights (GB) ~= 0.6 x parameters in billions

So a 70B model at Q4_K_M is roughly 42 GB of weights, before any context. That single number decides your build:

Why "70B with CPU offload on one 24 GB card" is slower than people expect. Generation is memory-bandwidth bound: every token requires reading every weight. If part of the model sits in system RAM, that part is read at DDR speed, not GPU speed. The ceiling is:

seconds per token >= (GB on GPU / GPU bandwidth) + (GB in RAM / RAM bandwidth)

Put real vendor numbers in. NVIDIA's published specification for the RTX 4090 is 1008 GB/s of memory bandwidth; a dual-channel DDR5-5600 desktop works out to about 90 GB/s (5600 MT/s x 8 bytes x 2 channels). With ~22 GB of a 42 GB model on the card and ~20 GB in system RAM:

(22 / 1008) + (20 / 90) = 0.022 + 0.222 = 0.244 s per token
-> arithmetic ceiling ~4 tokens/second

That is an upper bound and real output lands below it. The practical conclusion: a partially offloaded 70B is a "start it and go do something else" tool, not an interactive one. If you want interactive review, either buy enough VRAM to hold the model or run a 14B and accept the quality difference described below.

---

Setting up the pipeline {#setting-up-pipeline}

Step 1: install Ollama and pull models

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull the analysis model (70B for best quality)
ollama pull llama3.3:70b-instruct-q4_K_M

# Pull a fast model for simple extraction tasks
ollama pull qwen2.5:14b-instruct-q6_K

Step 2: document conversion

Contracts arrive as PDFs and Word docs. Convert them to clean text:

# Install conversion tools
sudo apt install poppler-utils pandoc -y

# PDF to text (preserves layout better than alternatives)
pdftotext -layout contract.pdf contract.txt

# Word to text
pandoc contract.docx -t plain -o contract.txt

# Batch convert a directory of contracts
for f in contracts/*.pdf; do
    pdftotext -layout "$f" "${f%.pdf}.txt"
done

Step 3: build the reference library with RAG

Your approved contract templates are the gold standard. Embed them so the AI can compare incoming contracts against your positions:

# Using AnythingLLM (simplest approach)
docker run -d \
  --name anythingllm \
  -p 3001:3001 \
  -v /data/anythingllm:/app/server/storage \
  -e LLM_PROVIDER=ollama \
  -e OLLAMA_BASE_PATH=http://host.docker.internal:11434 \
  -e EMBEDDING_MODEL_PREF=nomic-embed-text \
  mintplexlabs/anythingllm

Upload your template contracts, clause libraries, and negotiation playbooks into AnythingLLM. It will chunk and embed them automatically.

For the full RAG pipeline setup, see the RAG local setup guide and the AnythingLLM setup guide.

---

How do you prompt for clause extraction? {#clause-extraction}

The difference between useful and useless AI contract review is entirely in the prompts. Generic "summarize this contract" prompts produce generic summaries. Structured extraction prompts produce actionable output.

Master extraction prompt

You are a contract analysis assistant. Extract the following information from
the provided contract text. For each item, quote the exact contract language,
then provide a plain-English summary. If an item is not present in the contract,
state "NOT FOUND" — do not guess or infer.

EXTRACT:
1. PARTIES: Full legal names, roles (buyer/seller/licensor/etc.)
2. TERM: Start date, end date, renewal provisions, auto-renewal clauses
3. TERMINATION: Termination for cause triggers, termination for convenience
   notice period, post-termination obligations
4. PAYMENT: Total value, payment schedule, late payment penalties, price
   escalation clauses
5. LIABILITY: Cap on liability (amount and basis), carve-outs from cap,
   exclusion of consequential damages
6. INDEMNIFICATION: Who indemnifies whom, scope, limitations, defense
   obligations
7. IP OWNERSHIP: Work product ownership, background IP, license grants,
   license restrictions
8. CONFIDENTIALITY: Definition of confidential info, exclusions, duration,
   return/destruction obligations
9. NON-COMPETE/NON-SOLICIT: Scope, duration, geographic restrictions
10. GOVERNING LAW: Jurisdiction, dispute resolution mechanism, venue

CONTRACT TEXT:
[paste contract here]

Two instructions in that prompt are doing most of the work. "Quote the exact contract language" forces every claim to be traceable to a span in the source, so a hallucinated term is immediately visible as a quote that does not appear in the document — you can literally Ctrl-F it. "State NOT FOUND — do not guess or infer" gives the model a licensed way to say nothing, which is the difference between a missing indemnity being reported as missing and being quietly invented.

Keep both. Verification is the entire value of this step; an unverifiable summary of a contract is worse than no summary, because someone will act on it.

---

How do you get it to flag risk, not just summarise? {#risk-flagging}

After extraction, the second pass identifies issues. This is where the RAG pipeline earns its keep — the model compares the incoming contract against your templates.

Risk assessment prompt

You are a contract risk analyst. Compare the following contract clauses against
our standard position (provided as context). For each deviation, assign a risk
level and explain the business impact.

RISK LEVELS:
- CRITICAL: Clause exposes the company to significant financial or legal risk.
  Requires immediate legal review before signing.
- HIGH: Clause deviates substantially from our standard position. Negotiation
  recommended.
- MEDIUM: Clause differs from our preference but is commercially reasonable.
  Consider negotiating if relationship allows.
- LOW: Minor deviation from standard. Acceptable as-is in most circumstances.

For each flagged item, provide:
1. Clause reference (section number and title)
2. Their language (exact quote)
3. Our standard position (from reference templates)
4. Risk level
5. Business impact (1-2 sentences)
6. Suggested counter-language (optional)

CONTRACT CLAUSES:
[paste extracted clauses]

Where model size actually changes the answer

The useful distinction is not a detection percentage — it is the kind of question each size class can answer at all. Detection tasks split cleanly into three tiers:

The pattern is that presence detection is nearly free and interaction between clauses is expensive. A contract is not a list of independent paragraphs; the damage usually lives in how a limitation in section 9 interacts with an indemnity in section 12. That is the work a bigger model does better, and it is also the work you should be checking most carefully, because it is where a confident wrong answer is most plausible.

Whatever size you run, verify against the quoted language. That discipline matters more than the parameter count.

---

How do you diff two contract versions? {#redlining-workflow}

Contract negotiation means multiple versions. Track what changed between drafts:

Version comparison prompt

Compare these two contract versions and identify every change. For each change:
1. Section and clause number
2. Original language (Version A)
3. Modified language (Version B)
4. Impact assessment: Does this change favor Party A, Party B, or is it neutral?
5. Recommendation: Accept, Reject, or Counter

VERSION A (our last draft):
[paste version A]

VERSION B (their markup):
[paste version B]

Automating the diff

For large contracts, manually pasting two versions is impractical. Script the comparison:

#!/bin/bash
# compare-contracts.sh — generates a structured diff for AI analysis

VERSION_A="$1"
VERSION_B="$2"

# Generate word-level diff
wdiff "${VERSION_A}" "${VERSION_B}" > /tmp/contract_diff.txt

# Feed to Ollama with the comparison prompt
cat << 'PROMPT' > /tmp/compare_prompt.txt
You are a contract redlining assistant. The following is a word-level diff
between two contract versions. Words in [-deleted-] brackets were removed.
Words in {+added+} brackets were added.

For each change, provide:
1. Section reference
2. What was removed
3. What was added
4. Whether this change favors the drafter or the recipient
5. Risk assessment (Critical/High/Medium/Low)

DIFF OUTPUT:
PROMPT

cat /tmp/contract_diff.txt >> /tmp/compare_prompt.txt

ollama run llama3.3:70b-instruct-q4_K_M < /tmp/compare_prompt.txt

# Clean up
rm /tmp/contract_diff.txt /tmp/compare_prompt.txt

---

Which models suit legal text? {#model-recommendations}

Legal text has characteristics that punish small models: precise terminology, nested conditional structures, cross-references between distant sections, and deliberate ambiguity a model must recognise rather than resolve.

The table below sizes each candidate with the same formula used above — weights (GB) ≈ 0.6 × parameters in billions at Q4_K_M — so you can see immediately what your card can hold. Context and KV cache add on top; a 32K-token contract prompt is not free.

Two corrections worth internalising, because both circulate widely and both are wrong: Llama 3.3 shipped as a 70B model only — the 8B in that family is Llama 3.1 — and Mistral Large 2 is a 123B model, so it does not fit in 48 GB at Q4_K_M no matter how the marketing reads. Run the formula before you buy a card. Our VRAM calculator does the same arithmetic across quantisation levels; the llama.cpp README documents what each quantisation actually costs per weight.

A custom Modelfile for legal analysis

Create a Modelfile tuned for contract work:

FROM llama3.3:70b-instruct-q4_K_M
PARAMETER temperature 0.1
PARAMETER top_p 0.9
PARAMETER num_predict 4096
PARAMETER num_ctx 32768

SYSTEM """You are a senior contract analyst with 15 years of experience in
commercial law. You analyze contracts with precision, always quoting exact
language from the source document. You never fabricate contract terms. When
you are uncertain about an interpretation, you flag the ambiguity rather
than guessing. You understand that contracts are adversarial documents where
word choice is deliberate."""

# Build and use the custom model
ollama create contract-analyst -f Modelfile
ollama run contract-analyst

Temperature at 0.1 is deliberate. Contract analysis needs consistency, not creativity. You want the same contract analyzed twice to produce the same output both times.

---

Worked example: reviewing a mutual NDA {#nda-review-example}

Here is a complete workflow for a mutual NDA — the contract type that crosses every business's desk most often.

The incoming NDA

A potential partner sends a mutual NDA. Before your legal team spends time on it, run it through the system:

# Convert the NDA
pdftotext -layout incoming-nda.pdf incoming-nda.txt

# Run extraction with the contract analyst model
ollama run contract-analyst << 'EOF'
Extract and analyze this NDA. For each standard NDA element, quote the exact
language and flag any deviations from standard mutual NDA terms:

1. Definition of Confidential Information — is it appropriately scoped?
2. Exclusions — are the standard exclusions present (public knowledge, prior
   possession, independent development, legally compelled disclosure)?
3. Duration — how long does the obligation last? Is it reasonable for the
   industry?
4. Permitted use — is use restricted to evaluating the business relationship?
5. Return/destruction — what happens to materials after termination?
6. Residuals clause — does it exist? (Major red flag if so)
7. Non-solicitation — does the NDA sneak in non-solicit provisions?
8. Governing law — whose jurisdiction?
9. Injunctive relief — is there a mutual acknowledgment?
10. Assignment — can either party assign rights?

FLAG anything unusual or one-sided.

NDA TEXT:
[paste NDA content]
EOF

The four things to look for in a "mutual" NDA

These are the recurring structural problems worth building into your prompt as named checks, because a model will find them reliably once you name them and will often skate past them if you do not:

That is the pattern-matching layer, and it is the part a machine does tirelessly and at 3am. What it explicitly does not do is tell you whether a residuals clause is acceptable in this deal, with this counterparty, at this stage — that judgement is the reason a lawyer reads the output.

---

Where should the files live? {#document-management}

Keep everything local. No Google Drive, no Dropbox, no SharePoint Online for contract storage.

Local file system structure

/data/contracts/
  ├── templates/          # Your approved templates (embedded in RAG)
  │   ├── nda-mutual.docx
  │   ├── nda-unilateral.docx
  │   ├── msa-standard.docx
  │   └── sow-template.docx
  ├── active/             # Contracts under negotiation
  │   ├── acme-corp-msa/
  │   │   ├── v1-their-draft.pdf
  │   │   ├── v1-extracted.txt
  │   │   ├── v1-analysis.json
  │   │   ├── v2-our-markup.docx
  │   │   └── v2-analysis.json
  │   └── ...
  ├── executed/           # Signed contracts
  └── archive/            # Expired or terminated

Automated analysis on file drop

Use inotifywait to automatically trigger analysis when new contracts are added:

#!/bin/bash
# watch-contracts.sh — auto-analyze new contract files

WATCH_DIR="/data/contracts/active"
ANALYSIS_MODEL="contract-analyst"

inotifywait -m -e create -e moved_to --format '%w%f' "${WATCH_DIR}" | while read filepath; do
    if [[ "${filepath}" =~ \.(pdf|docx|txt)$ ]]; then
        echo "[$(date)] New contract detected: ${filepath}"

        # Convert to text
        case "${filepath}" in
            *.pdf)  pdftotext -layout "${filepath}" "${filepath%.pdf}.txt" ;;
            *.docx) pandoc "${filepath}" -t plain -o "${filepath%.docx}.txt" ;;
        esac

        txtfile="${filepath%.*}.txt"

        # Run analysis
        ollama run "${ANALYSIS_MODEL}" < "${txtfile}" > "${filepath%.*}-analysis.txt"

        echo "[$(date)] Analysis complete: ${filepath%.*}-analysis.txt"
    fi
done

The same local-first storage discipline shows up in other document-heavy trades. Property transactions run on purchase agreements, disclosures and closing packets, and brokerages that index those files locally end up with the same folder-and-RAG structure described here — see local AI for real estate for that variation.

---

What can this system not do? {#limitations}

Be honest about what this system cannot do:

AI handles well:

• Extracting structured terms from unstructured text
• Identifying deviations from your standard positions
• Flagging missing clauses or protections
• Comparing versions and tracking changes
• Generating first-draft markup suggestions

AI handles poorly:

• Judging whether a deviation is acceptable given the business relationship
• Understanding negotiation dynamics and leverage
• Interpreting jurisdiction-specific enforceability
• Assessing reputational risk of contract terms
• Making sign/reject recommendations

The workflow should always be: AI extracts and flags, human reviews and decides. The AI's job is to reduce a 30-page contract to a 2-page summary of issues requiring attention. The lawyer's job is to decide what to do about those issues.

For more on how legal teams are adopting local AI, see the local AI for lawyers guide.

---

Frequently asked questions {#faq}

Can AI replace lawyers for contract review?

No, and the framing is the problem. A model can find non-standard clauses, flag missing protections and extract key terms far faster than a person reads. It cannot weigh those findings against your business relationship, your leverage, or the enforceability of a term in a given jurisdiction. Treat it as a first-pass filter that lets a lawyer skip the boilerplate and spend their attention on the handful of clauses that actually matter.

Why should contracts never go through cloud AI?

Contracts concentrate trade secrets, financial terms, acquisition details, personnel information and competitive intelligence into one file. Uploading one moves that text onto infrastructure you have not audited, subject to a retention policy you did not write and staff access controls you cannot inspect. Even where a vendor promises no training on your data, the exposure is operational rather than contractual. Local processing removes the transfer entirely.

What model size do I need?

Use the formula from the hardware section: at Q4_K_M, weights ≈ 0.6 GB per billion parameters. A 14B model (~8.4 GB) fits a 12 GB card and handles clause extraction and standard NDAs. A 70B (~42 GB) needs a 48 GB card or two 24 GB cards to stay resident, and it earns that cost specifically on questions about how clauses interact, not on finding clauses.

How accurate is local AI compared to cloud services for contract analysis?

Nobody should give you a number for this without publishing the corpus, the rubric and the reviewer — and there is no accepted public benchmark for contract-review quality the way there is for text-to-SQL or speech recognition. What is structurally true: the largest hosted frontier models remain stronger at nuanced legal reasoning than anything you can run on a single workstation, and that gap narrows as open-weight models grow. Whether the remaining gap outweighs putting an M&A agreement on someone else's servers is a risk decision, not a benchmark result.

How long does a 30-page contract take to review?

Compute it rather than guess. Time is prompt processing plus generation:

total ~= (input tokens / prompt-processing rate)
       + (output tokens / generation rate)

A 30-page contract is roughly 15,000-25,000 tokens in, and a structured analysis is perhaps 1,500-3,000 tokens out. Measure both rates on your own machine with ollama run <model> --verbose, then substitute. The offload arithmetic in the hardware section is why a partially offloaded 70B lands in the "go and do something else" range while a resident 14B feels near-interactive.

Can I build a RAG index from my company's template contracts?

Yes, and it is the step that turns generic output into useful output. Embed your approved templates, standard clause library and negotiation playbook so the model can say specifically how an incoming clause differs from your position, rather than describing what the clause says in the abstract. The RAG local setup guide covers the implementation.

Which contract types work best?

Documents with conventional structure: NDAs, MSAs, SaaS agreements, vendor contracts, employment agreements. Structure is what lets a model know a section is missing. Complex M&A documents, regulatory filings and multi-jurisdictional agreements still benefit from extraction, but the ratio of human oversight to machine output should rise sharply with the stakes.

---

Conclusion

A private contract review system takes an afternoon to set up and pays back on every contract afterwards — not by replacing judgement, but by reducing a 30-page document to a short list of things worth arguing about.

The requirement that makes it worth building is that none of it runs on someone else's servers. Your contracts contain your pricing, your strategies and your vulnerabilities. Sending them to a hosted service trades a short-term convenience for a permanent loss of control over where that text lives.

Run the models locally. Keep the documents local. Let the machine do the pattern matching. Let the lawyers do the thinking.

---

For the foundation of this setup, start with the RAG local setup guide. Already running Ollama? The AnythingLLM setup guide gets you a web-based document interface in minutes.