Contract review, drafting & redlining assistant

Contract work is repetitive: read a counterparty draft, compare it with your standards, mark up deviations, propose fallback wording, and write a summary for the business. AI assistants embedded in Microsoft Word now do the first pass against a codified playbook and produce tracked changes that the lawyer accepts, edits or rejects. The benefit is faster first-pass review and more consistent positions; the responsibility for the legal outcome stays with a qualified human.

Problem & value

• Today: legal teams, procurement and sales ops receive NDAs, supplier agreements, DPAs and SaaS terms in Word/PDF and review them manually against an internal playbook (or from memory). Business teams wait days; lawyers spend their time on low-risk standard deviations; positions drift between reviewers.
• AI value: triage by risk (standard NDA vs. unusual liability regime), consistent application of playbook positions, first-draft markup, plain-language summaries for non-lawyers, and reuse of precedent from the firm's or company's own contract base.
• Evidence (treat vendor figures as marketing): the independent Vals Legal AI Report (Feb 2025) found AI tools beat a lawyer baseline on document Q&A and summarisation, but lawyers clearly outperformed all tested tools on redlining (lawyer baseline 79.7 %, Vincent AI 53.6 %, Harvey Assistant 65.0 % in the table) [1]. Spellbook advertises 75 % time saved on contract work, a self-reported figure [2]. Redlining quality is the key thing to test on your own contracts.

Variants

• In-house legal / legal ops: playbook-driven review of inbound paper, intake portal for business users, CLM integration.
• Law firms: drafting from firm precedents, due-diligence style tabular review (see DOC-011), client-specific playbooks.
• SMB without legal department: NDA, supplier and customer-terms checks with a "traffic light" summary; escalation to external counsel for anything above a value threshold.
• Procurement / sales: review of supplier terms or customer paper at quote stage (see DOC-015 for tender documents).
• Public sector: review of IT/supplier contracts against EVB-IT / UVgO-style standard terms and procurement rules.
• Private use: tenancy, employment or consumer contracts - explain and flag clauses only; no individual legal advice.
• Not covered here: bulk extraction across a contract portfolio (DOC-009) and large-scale data-room review (DOC-011).

How it works

1. contract intake (Word/PDF/email/portal)
2. parsing (DOCX structure kept; OCR for scans)
3. clause segmentation & classification
4. playbook retrieval (positions, fallbacks, approved clause library, precedents via RAG)
5. LLM review per clause: deviation vs. playbook, risk rating, rationale, cited text span
6. redline generation (tracked changes + comments in DOCX) / drafting from templates
7. lawyer review in Word (accept/reject/edit)
8. negotiation memo
9. sign-off in CLM / e-signature

• Playbook as data: clause-level positions (preferred, acceptable fallback, red line, escalation owner) are the most valuable asset; vendors such as Spellbook and Luminance expose them as "playbooks" [2][4].
• Redline engine: the model proposes edits; software converts them into real OOXML tracked changes so the other side and the reviewer see a normal Word redline. Minimal edits (change only the necessary words) are essential - rewriting whole clauses annoys counterparties.
• Grounding: each finding must cite the clause text and the playbook rule; drafted wording is taken from the approved clause library where possible rather than generated freely.
• Human-in-the-loop: a qualified person approves every outgoing redline; high-risk clauses (liability caps, indemnity, IP, data protection, governing law) have mandatory escalation.

Data preparation

The assistant needs three kinds of data: the contract drafts themselves (Word, PDF, scans, often in e-mail), the negotiation playbook with fallback positions (often only in lawyers' heads, old memos or slide decks), and a clause library with executed precedents (DMS, file shares, CLM). Typical gaps: no written playbook, several outdated template versions, precedents without a marker of which one was good, scans without text, and mixed languages.

Preparation steps: (1) write down the playbook as a structured list: clause, preferred position, fallback, red line, escalation (PREP-016, PREP-014); (2) select a small set of approved templates and clean precedents and mark outdated ones (PREP-013, PREP-017); (3) tag the clause library by clause type, contract type and language (PREP-010, PREP-019); (4) OCR scans of historic contracts only where they will be used as precedents (PREP-006); (5) collect a company glossary of defined terms (PREP-015); (6) build a test set of past negotiations with the final outcome (PREP-018). Related: DOC-009, DOC-014.

Rough share: 30 percent of effort, of which the playbook workshop is the most valuable and often the hardest part.

Implementation paths

Which path for whom

• SMB: Path A, because Word-integrated review and drafting assistants with playbooks are mature products and the process is standard.
• Enterprise: Path B, because playbooks, clause libraries and the CLM should be integrated and the legal function is strategic with high seat counts.
• Developer: Path B, because cloud reasoning models via API plus a playbook layer are the fastest way to build a custom assistant.
• Public: Path C on sovereign EU cloud, because contract drafts are confidential and procurement rules favour controlled hosting.
• Private: Path A, because a general chat assistant with a clear checklist is enough to understand a rental or consumer contract (no legal advice).

Path A - Buy (recommended for most SMBs)

• Legal AI platforms: Harvey (US; EU/US/AU regions listed, SOC 2 Type II, ISO 27001/42001) [5], Legora (Sweden; Word and Outlook add-ins, tabular review, agent; ISO 27001, SOC 2, ISO 42001 claimed) [EU] [3], Luminance (UK; negotiation with precedent and playbooks, ISO 27001, SOC 2 Type II) [4], Spellbook (Canada/US; review, draft, compare, playbooks inside Word and Google Docs, zero data retention claimed) [2]. Also Thomson Reuters CoCounsel, and CLM suites (Ironclad, Icertis, Agiloft, Evisort/Workday) with embedded AI.
• German/EU-oriented options: check Legora, Noxtua (Xayn/Beck, EU-hosted legal LLM) and local legal-tech vendors for German-law content and on-prem/EU hosting - verify current offers before buying.
• Microsoft 365 Copilot in Word works for summaries and drafting but has no playbook discipline by default; use only with clear prompts and review.
• Choose A when: you need Word-native workflow, vendor-maintained quality, and have no strict on-prem requirement. Check: data residency, no-training clause, subprocessor list (which LLM provider), audit logs, German-law support, price per seat.

Path B - Build on cloud APIs

• Models: a frontier reasoning model (Claude, GPT, Gemini) or Mistral models (EU provider, [EU]) via EU-region endpoints (Azure OpenAI EU Data Zone, AWS Bedrock Frankfurt/Paris, Vertex AI EU, Mistral La Plateforme). Use structured output for findings (clause, rule ID, severity, quote, suggested text).
• Pipeline: DOCX parsing with python-docx/OOXML, vector index over playbook and clause library (embedding + reranker), orchestration in n8n or a small service, Word add-in (Office.js) for in-document comments and tracked changes.
• Choose B when: you have special playbook logic, want your own clause library and CLM integration, or need to embed review in a product. Expect to build evaluation sets yourself.

Path C - Self-host (open source)

• Models: open-weight LLMs such as Mistral Large 3 / Mistral Small 4 (Apache 2.0, [EU]) [6], Qwen, Llama or gpt-oss-class models served with vLLM; Docling or PaddleOCR for scans; BGE/Qwen3 embeddings with Qdrant or pgvector.
• Fit: law firms with confidentiality duties, defence/public sector, or corporate legal departments that cannot send drafts to US clouds. Long contracts need long-context models (128k+) or clause-wise chunking.
• Hardware: HW3 (one 48-141 GB GPU) for ~30-120B models; HW2 is enough for 8-30B models with clause-wise processing, at lower redline quality. Ops effort: moderate; no maintained Word UI - you build or integrate one.

Path D - Custom training

Rarely worthwhile. Fine-tuning on a firm's own negotiated contracts can improve style and playbook adherence and cut cost with a smaller model, but needs thousands of clean, labelled (clause, position, edit) examples and strict confidentiality handling. Open datasets such as CUAD (510 contracts, 41 clause types, CC BY 4.0) help for clause classification, but are US commercial contracts and not German law [7]. Start with prompting + RAG; train only after evaluation shows a gap.

State of the art (2026)

• Playbook-driven agents inside Word are the standard product pattern: review, compare against standard, draft, ask questions, multi-document workflows [2][3][4].
• Strengths: clause identification, summarisation, Q&A over a contract, first drafts from templates, comparing against a standard, translation of clauses.
• Weaknesses: redlining quality (minimal, legally precise edits), cross-reference and defined-term consistency across long agreements, jurisdiction-specific law (German AGB-law under §§ 305 ff. BGB), and quantitative logic (caps, payment schedules). The only independent comparison with a lawyer baseline showed redlining as the weakest task [1]; newer model generations have improved reasoning, but public independent redlining benchmarks for 2026 are scarce - run your own evaluation.
• Failure modes: hallucinated clause references or case law, missed non-standard clauses buried in annexes, silent changes in untouched text, over-confident "low risk" ratings, prompt injection hidden in counterparty documents (white text instructions).
• Evaluation practice: build a gold set of 30-50 past contracts with accepted redlines; measure recall of playbook deviations, precision, and acceptance rate of suggested edits.

Shared resources & combinations

• Same stack (llm-reasoning + embedding-text + vector-db + ocr-docparse): DOC-009 contract analysis & clause extraction (portfolio view; the clause library and extraction schemas are shared), DOC-011 due diligence, DOC-015 tender analysis, DOC-021 eDiscovery, KNOW-006 legal research and KNOW-002 RAG assistant (same index and reranker), DOC-014 for robust PDF parsing, DOC-018 anonymisation before sending contracts to external models, LANG-009 for translation of foreign-language contracts.
• Workflow: AGENT-002 workflow automation for intake, approval and signature routing; AGENT-018 for continuous compliance checks against obligations extracted from signed contracts.
• Hardware: a single HW3 server with one open LLM serves DOC-009/010/011/015 and KNOW-006 together; vector database and embedding service are common.

Effort, cost & KPIs

• Path A: days to weeks to pilot; per-seat subscription (enterprise legal AI is usually priced on request); most effort goes into encoding the playbook.
• Path B: 2-4 months for a production Word add-in with evaluation; API cost per contract is small relative to lawyer time, but evaluation and maintenance dominate.
• Path C: 3-6 months; GPU server plus engineering; no vendor UI.
• KPIs: review turnaround time, share of contracts closed without escalation, playbook adherence, acceptance rate of AI redlines, number of negotiation rounds, missed-issue rate in quarterly audit samples, lawyer hours per contract.

People & change

Involve the head of legal (or the managing director in an SMB) as process owner, the lawyers and business users who negotiate daily, IT for the Word add-in and accounts, IT security for data flows to the provider, and the DPO. The playbook workshop is the key moment: the people who negotiate must own the positions, not the vendor. Legal and compliance review contract terms with the vendor (AVV, no training on customer data, exit; see GUIDE-010).

Works council: depends. If the tool logs individual users' prompts, accepted or rejected suggestions, or review times, it is objectively suited to monitor performance and §87(1) no. 6 BetrVG applies; §90(1) no. 3 requires early information about AI-supported work processes. Public bodies involve the Personalrat. A DPIA is advisable when contracts with personal data (employment contracts) are processed.

AI literacy: support staff with training on hallucinated clauses, verifying redlines and confidentiality rules (Art. 4 AI Act). Start with a pilot of 3 to 5 reviewers on one contract type, e.g. NDAs. Typical concerns are liability and deskilling; address them by keeping lawyers accountable, requiring review of every redline, and keeping an audit trail of suggestions versus accepted changes. See GUIDE-008, GUIDE-009, GUIDE-005.

Risks, regulation & compliance

• EU AI Act: typically minimal risk - contract review for businesses is not an Annex III use; Art. 4 AI literacy applies. Caution: AI that assists judicial authorities in applying law to facts is Annex III (point 8) high-risk [8]; employment-contract screening used for decisions about workers or credit/insurance contract assessment of individuals could touch Annex III, so check the specific context. Art. 6(3) exemptions apply to narrow procedural or preparatory tasks, but not where natural persons are profiled [8].
• Legal services law: in Germany, a tool that gives individual legal assessments to consumers or third parties may amount to a Rechtsdienstleistung under § 2 RDG, which only licensed providers may perform [9]. In-house use and use by lawyers is fine; consumer-facing products need legal review.
• Professional secrecy: lawyers are bound by § 43a BRAO / § 203 StGB; use providers under confidentiality obligations (§ 43e BRAO) with EU hosting or self-hosting.
• GDPR: contracts contain personal data (signatories, employees, sole traders); DPA with vendor, no training on customer data, transfer assessment for US providers, anonymise where possible (DOC-018).
• Liability and quality: the user remains responsible; document review steps; keep an audit log; do not auto-send redlines to counterparties; guard against hidden prompt injection in documents.

Getting started

1. Pick one narrow contract type (e.g. inbound NDAs) and write the playbook with preferred, fallback and red-line positions.
2. Collect 30-50 past contracts with final negotiated versions as an evaluation set.
3. Trial 2-3 Path A tools (or a Path B prototype) in Word on the evaluation set; score deviation recall and redline acceptance by a lawyer.
4. Clarify confidentiality, hosting and subprocessor questions with legal and the data protection officer before using real counterparty drafts.
5. Roll out with mandatory human sign-off and track KPIs; extend to further contract types only after the first reaches stable acceptance rates.

Sources

1. Vals AI - Legal AI Report (VLAIR), Feb 2025 - https://www.vals.ai/vlair
2. Spellbook - product page (review, draft, playbooks, security claims) - https://spellbook.com/
3. Legora - product page - https://www.legora.com
4. Luminance - product page (negotiation, security) - https://www.luminance.com
5. Harvey - product page (security, certifications, regions) - https://www.harvey.ai
6. Mistral AI - models overview (open-weight models and licences) - https://docs.mistral.ai/getting-started/models/models_overview/
7. The Atticus Project - CUAD dataset - https://www.atticusprojectai.org/cuad
8. AI Act Service Desk / artificialintelligenceact.eu - Article 6 high-risk classification - https://artificialintelligenceact.eu/article/6/
9. Gesetze im Internet - § 2 RDG (Rechtsdienstleistungsgesetz) - https://www.gesetze-im-internet.de/rdg/__2.html