Contract analysis & clause extraction

Companies hold thousands of contracts in shared drives, e-mail and CLM tools, but the key facts (renewal dates, notice periods, liability caps, change-of-control or data-protection clauses) are locked in prose. AI turns each contract into a structured record with clause-level evidence, checks it against internal standards and makes the whole portfolio searchable. The AI finds and flags; lawyers and contract owners decide. Review of a single new contract in negotiation (redlining, drafting) is covered by DOC-010; this use case is about reading, extracting and comparing.

Problem & value

• Today: contract data is keyed into spreadsheets or CLM fields by hand, or simply not captured. Missed termination windows cause unwanted automatic renewals; audits, M&A and regulatory changes (e.g. new data-processing or supply-chain obligations) trigger expensive manual file reviews.
• AI value: template-free extraction of metadata and clauses from any layout and language, evidence links to the source passage, portfolio-wide questions ("which supplier contracts allow unilateral price changes?"), and deviation detection against a playbook.
• Evidence base: the CUAD benchmark (510 commercial contracts, 13,000+ expert labels, 41 clause categories) shows this is a well-defined extraction task, and its authors found early transformer models had "substantial room for improvement" [1][2]. Vendors publish efficiency claims (e.g. Luminance states a 75 % reduction in repetitive contract review work), but these are self-reported and the measurement method is not stated [4] — pilot on your own contracts.

Variants

• SMB: NDA and supplier-contract triage; renewal and notice-period reminders from a folder of PDFs.
• Enterprise legal / procurement: portfolio-wide extraction into a CLM, playbook compliance, obligation management, regulatory remediation campaigns (re-papering after law changes).
• Sales / finance: revenue-contract abstraction (payment terms, price escalators, termination rights) for revenue recognition and renewal forecasting.
• Real estate: lease abstraction (rent, indexation, options, break dates).
• Public sector: framework agreements and grant contracts; tender documents are DOC-015.
• Insurance & broker variant — policy checking and wording comparison: an insurance policy is a contract. Extract coverage, sums insured, deductibles, exclusions, waiting periods and obligations (Obliegenheiten) from quotes, binders, issued policies and general terms (AVB), then compare quote vs. issued policy (did the policy match what was offered?), old vs. new wording on renewal, or competing offers side by side (Bedingungsvergleich). Brokers and insurers use this to support the advice and documentation duties of § 6 VVG and the IDD demands-and-needs analysis [8]. The comparison is evidence for a human advisor, not an automated recommendation.
• Private use: checking a rental, gym, telecom or insurance contract for cancellation periods and renewal traps; do not rely on it as legal advice.

How it works

1. intake (CLM, DMS, e-mail, shared drive, scan)
2. document parsing (OCR, layout, headings, numbered clauses, tables, annexes)
3. classification (contract type, language, version / amendment chain)
4. segmentation into clauses with section tree
5. extraction (metadata + clause finder, schema-constrained JSON, with page + quote evidence)
6. comparison (playbook / template / second document; semantic diff on clause level)
7. validation (dates and amounts consistent, citation really in source, confidence)
8. human review (legal / contract owner confirms flagged and low-confidence items)
9. CLM / ERP / calendar update, portfolio index for search and Q&A (RAG)

• Parsing is the foundation: scanned signature pages, amendments overriding earlier clauses, cross-references ("as defined in Annex 2") and tables are the usual failure points; keep the clause tree so references can be resolved.
• Extraction: a long-context LLM or reasoning model reads the whole contract (or retrieved sections) and returns a schema with a verbatim evidence quote per field. Verbatim quotes are checked programmatically against the parsed text to catch hallucinations.
• Playbook check: each rule ("liability cap ≥ 12 months of fees", "governing law: Germany") is evaluated against the extracted clause and returns compliant / deviation / not found, plus a suggested fallback clause for DOC-010.
• Human-in-the-loop: reviewer sees the source passage next to each extracted value; legal assessment and any decision to sign, terminate or renegotiate stay with people.

Data preparation

Contracts typically live in shared drives, e-mail attachments, the DMS, a CLM tool or paper folders in the legal or purchasing department. Typical gaps: scanned PDFs without text, several versions of the same contract, amendments stored apart from the main agreement, inconsistent file names, no list of which contracts exist at all, and restricted access rights (HR or customer contracts).

Preparation steps: (1) inventory the sources and agree on a scope, e.g. all active supplier and customer contracts (PREP-001, PREP-005); (2) OCR old scans (PREP-006, tools such as OCRmyPDF or Paperless-ngx); (3) collect main contract, annexes and amendments into one folder per contract and mark the final signed version (PREP-009, PREP-010); (4) define the metadata fields to extract and the playbook of standard positions (PREP-019, PREP-016); (5) build a small test set of 20 to 30 contracts with verified answers (PREP-018); (6) check who may see which contracts (PREP-023). Related: DOC-014, DOC-018.

Rough share: 30 to 40 percent of the total effort in the first project, mostly collecting, de-duplicating and scanning. The model setup itself is comparatively quick.

Implementation paths

Which path for whom

• SMB: Path A, because mature contract-intelligence tools with EU or Swiss hosting exist at moderate prices and contract analysis is a standard process.
• Enterprise: Path B, because the extraction should feed the existing CLM, ERP and playbooks, and volume makes seat-based pricing expensive.
• Developer: Path C, because open-source document parsing plus an open-weight model gives full control and a reusable pipeline.
• Public: Path C on sovereign EU or German cloud, because procurement rules and confidentiality of contracts favour self-controlled hosting.

Path A — Buy (recommended for most SMBs)

• Contract-intelligence / AI legal platforms: Luminance (UK, Cambridge-founded; ISO 27001, SOC 2 Type II) [4]; Legartis (Switzerland; data hosted in Switzerland/Europe, GDPR, ISO 27001, playbook-based review and portfolio insights, European languages) [5]; Kira (Litera), Harvey, other contract-review tools; Noxtua and Libra (German legal-AI offerings, data-sovereignty focus).
• CLM suites with AI extraction: Icertis, Ironclad, DocuSign IAM / Lexion, Workday (Evisort), ContractPodAi, Sirion, Agiloft; in the DACH area also Contractbook-style SMB tools and the contract modules of SAP Ariba and Coupa. Check EU data residency, subprocessors and whether customer data is used to train models.
• Insurance variant: policy-checking and comparison tools from insurtech vendors and broker pools; verify against the exact AVB wording your market uses.
• Choose A when: standard contract types, a legal team that wants a ready UI, no strict on-prem requirement. Test with 50–100 of your own contracts, including bad scans.

Path B — Build on cloud APIs

• Parsing: Azure AI Document Intelligence (prebuilt contract model extracts parties, jurisdictions, contract ID, title; English only; layout model for other languages) [3]; Mistral OCR / Document AI (EU provider, annotations with structured output) [6]; Google Document AI, AWS Textract (Frankfurt region).
• Extraction & reasoning: frontier LLMs with structured outputs and long context (Claude, Gemini, GPT, Mistral Large) via EU regions (e.g. Azure OpenAI EU data zone, Vertex AI EU, Bedrock Frankfurt, Mistral La Plateforme). Prompt = clause definition + schema + "quote the exact sentence".
• Search layer: embeddings plus hybrid search (OpenSearch, pgvector, Qdrant) and a reranker for portfolio Q&A; workflow with n8n / Power Automate; push results into CLM, SharePoint or DATEV.
• Choose B when: you need custom fields, German-law clause libraries or integration with internal systems and may send data to a contracted EU cloud region.

Path C — Self-host (open source)

• Parsing: Docling (MIT licence, PDF/DOCX/scans, tables, runs local or air-gapped, MCP server, LangChain/LlamaIndex integrations) [7]; alternatives PaddleOCR, MinerU, Marker.
• Models: open-weight LLMs in the 30–120B class (e.g. Qwen3, Mistral, gpt-oss, Llama families) served via vLLM with constrained JSON decoding; multilingual embeddings such as BGE-M3 and an open reranker; Qdrant / pgvector / OpenSearch.
• Hardware: HW3 (one 48–141 GB GPU) runs a ~70–120B-class model for confidential contracts; HW2 is enough for a quantised ~30B model with retrieval over clause sections but is weaker on long, cross-referenced agreements. Ops effort: a part-time ML/DevOps engineer.
• Choose C when: M&A, board, employment or defence-supplier contracts must not leave the premises, or volume makes API costs dominant.

Path D — Custom training

Rarely the first step. Fine-tuning a clause classifier (BERT-class encoder) or a small LLM pays off for very high volumes, rare languages or highly specialised contract types (e.g. reinsurance treaties, energy PPAs). Public data: CUAD (CC BY 4.0) and LegalBench tasks [1][9] for evaluation and warm-start; real value comes from several hundred of your own annotated contracts, which reviewer corrections generate as a by-product.

State of the art (2026)

• LLM-first extraction replaced rule/ML templates: long-context models read an entire contract and return clause-level JSON with evidence; classic clause-finder training (hundreds of examples per clause) is now optional. Reasoning models are used for the judgement step (does this indemnity deviate from the playbook?).
• Benchmarks: CUAD (41 clause types) and LegalBench (162 tasks from 40 contributors, many contract-based such as CUAD, ContractNLI, MAUD) remain the public references [1][9]; they are English and US-centric, so German- or French-law accuracy must be measured on your own gold set.
• Playbook-driven agents: vendors now market "legal agents" that run multi-step tasks under customer playbooks and escalate outside-standard cases to the decision owner [5].
• Limits and failure modes: missed clauses hidden in annexes or general terms; amendment chains (which version prevails?); cross-reference errors; negations and exceptions ("except where…"); invented quotes; date arithmetic (notice periods, business days); poor scans and handwritten changes. "Clause not found" is the most dangerous output — recall must be tested explicitly. Law-specific validity (e.g. whether a clause is void under §§ 305 ff. BGB standard-terms law [10]) is a legal assessment, not an extraction task, and should not be auto-concluded.

Shared resources & combinations

• Same stack (ocr-docparse + llm + embeddings + vector-db): DOC-014 (PDF parsing for RAG), DOC-011 (due diligence uses this extraction at data-room scale), DOC-015 (tender requirements), DOC-016 (compliance checking against rules), DOC-008 (mailroom classification routes contracts in), DOC-018 (anonymisation before sharing or model use).
• Direct neighbour: DOC-010 consumes the deviation findings and proposes fallback wording and redlines; AGENT-004-style workflow agents handle reminders and approvals.
• Hardware: one HW3 inference server can serve DOC-009/010/011/014/015 together; the parsing, embedding and vector index are reusable building blocks.
• Data pipeline: a single contract repository with clause tree, extracted metadata and evidence quotes feeds search, renewal alerts, spend analysis and risk dashboards.

Effort, cost & KPIs

• Path A: days to weeks for a pilot; SaaS licences typically per user or per contract volume.
• Path B: 1–3 months for a production pipeline with CLM integration and a gold set; cost drivers are pages processed, model choice and review time.
• Path C: 2–4 months plus GPU server and operations; justified by confidentiality.
• Path D: additional 2–3 months and annotation effort.
• KPIs: field-level precision and recall per clause type (recall first), share of contracts with complete metadata, reviewer correction rate, review time per contract, missed-deadline incidents, percentage of portfolio searchable, time to answer an audit or M&A query.

People & change

Involve management for scope and budget, the legal or purchasing lead as process owner, and the daily users (legal, purchasing, sales operations) from the first workshop, because they define the playbook. IT handles access to repositories and accounts; the data owners of the contract folders must release the sources. The DPO joins early: contracts contain names and signatures of natural persons, so check the legal basis, sign an AVV (Art. 28 GDPR) with every provider and run a DPIA if employee or consumer contracts are included.

Works council: depends. Pure document analysis does not monitor staff, but tools that log individual user prompts or review speed can fall under §87(1) no. 6 BetrVG (objective suitability suffices, per BAG); §90(1) no. 3 requires timely information when work processes are planned with AI. Where a council exists, inform it before the pilot.

AI literacy: support staff with a short training on verifying citations and on what must not be uploaded (Art. 4 AI Act). Start with a pilot group of 3 to 5 contract reviewers and a defined contract type. Typical concerns are job loss and liability; address them by stating that AI prepares and humans decide, and by keeping the page-level source link for every extracted value. See GUIDE-004, GUIDE-005, GUIDE-008.

Risks, regulation & compliance

• EU AI Act: typically minimal risk — private-sector contract analysis is not listed in Annex III (closest is item 8, justice/ADR use by or for judicial authorities, which would be high-risk) [11]. Art. 4 AI-literacy duty applies to users. Chatbot-style interfaces need disclosure under Art. 50. If contract data feeds decisions about employees (e.g. employment contract or performance clauses used for management decisions) or credit, the classification must be re-checked.
• GDPR: contracts contain personal data (signatories, employees, sole traders, insured persons; in insurance potentially health data, Art. 9). Needs a data-processing agreement, EU hosting, retention rules and data minimisation; consider DOC-018 redaction before use of external APIs.
• Professional law: in Germany, legally binding advice to third parties is reserved to lawyers (RDG); internal tooling and tools for lawyers are unproblematic, consumer-facing "legal advice" products need legal review. Confidentiality (§ 203 StGB, § 43e BRAO) applies to law-firm use of external services.
• Insurance: advice and documentation duties (§ 6 VVG, IDD) remain with the human advisor [8].
• Risks & mitigations: hallucinated clauses (quote verification, evidence links), missed clauses (recall testing, second-pass checks), over-reliance (mandatory review for high-value or high-risk contracts), prompt injection in contract text (treat document content as data, no tool permissions during extraction), vendor training on your data (contractual exclusion).

Getting started

1. Pick one contract type (e.g. supplier contracts or NDAs) and define 10–15 fields and clauses that matter, with a definition for each.
2. Build a gold set of 50–100 contracts annotated by a lawyer, including scans, amendments and German/English mixes.
3. Run two Path-A tools and one Path-B prototype on the gold set; compare recall, precision and evidence quality, not demo impressions.
4. Add a review screen with source highlighting, a playbook, and renewal / notice-period alerts.
5. Roll out to the next contract type; track correction rate and missed deadlines monthly.

Sources

1. Atticus Project — CUAD (510 contracts, 13,000+ labels, 41 clause categories, CC BY 4.0) — https://www.atticusprojectai.org/cuad
2. Hendrycks et al. — CUAD: An Expert-Annotated NLP Dataset for Legal Contract Review (NeurIPS 2021) — https://arxiv.org/abs/2103.06268
3. Microsoft — Azure AI Document Intelligence contract model — https://learn.microsoft.com/azure/ai-services/document-intelligence/prebuilt/contract
4. Luminance — product and claims page — https://www.luminance.com/
5. Legartis — legal AI workspace (hosting, features) — https://www.legartis.ai/
6. Mistral AI — Document AI / OCR documentation — https://docs.mistral.ai/capabilities/document_ai/
7. Docling project — https://github.com/docling-project/docling
8. § 6 VVG, Beratung des Versicherungsnehmers — https://www.gesetze-im-internet.de/vvg_2008/__6.html
9. LegalBench (Stanford Hazy Research) — https://hazyresearch.stanford.edu/legalbench/
10. § 305 BGB, Einbeziehung Allgemeiner Geschäftsbedingungen — https://www.gesetze-im-internet.de/bgb/__305.html
11. AI Act Annex III (high-risk systems list) — https://artificialintelligenceact.eu/annex/3/
12. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj