What Was Built: The AI Contract Review Architecture
The AI contract review MVP architecture consists of four processing stages. The first is document ingestion and normalisation: the system accepts PDF, DOCX, and sometimes image-scanned contracts, applies OCR where needed using a service such as AWS Textract or Google Document AI, and produces a structured text representation with paragraph-level segmentation. The second stage is clause extraction and classification: a fine-tuned or few-shot prompted LLM identifies and extracts named clause types such as limitation of liability, indemnification, intellectual property assignment, termination rights, governing law, and payment terms, labelling each extracted passage by clause type and assigning a confidence score. The third stage is risk analysis: the extracted clauses are evaluated against a configurable playbook of standard positions defined by the law firm or in-house legal team. Deviations from standard positions are scored and flagged by severity, generating a structured report that highlights the clauses requiring lawyer attention. The fourth stage is the review interface: a purpose-built document viewer presents the contract with inline clause highlighting, the risk flags surfaced in a structured sidebar, and a lawyer-in-the-loop annotation layer that allows the reviewing solicitor to accept, dismiss, or escalate each flag and add notes that feed back into the playbook.
Why This Architecture Works in Legal Practice
The playbook-based risk analysis design is the architectural decision that makes AI contract review genuinely useful rather than merely impressive in a demo. Generic LLM contract analysis produces clause summaries and generic risk observations that a junior lawyer could produce from a template. A playbook-based system compares every extracted clause against the specific standard positions that the law firm or legal team has defined, meaning the risk flags are relevant to their actual deal parameters rather than to an abstract notion of contract risk. This is also what allows the tool to improve over time. Every solicitor acceptance or dismissal of a flag is a labelled training signal that refines the playbook and improves the model's sensitivity calibration for that clause type. The lawyer-in-the-loop design is important for a different reason: it correctly positions the tool as an AI-assisted review platform rather than an autonomous legal advisor, which is the boundary that SRA regulations and the Legal Services Act 2007 draw between a legal technology tool and a reserved legal activity.
Tech Stack Used
The production AI contract review MVP stack includes Python with FastAPI for the document processing backend, AWS Textract or Google Document AI for OCR on scanned documents, LangChain for the clause extraction and risk analysis orchestration layer using Claude or GPT-4o as the primary LLM, PostgreSQL for storing contracts, extracted clauses, risk flags, and reviewer annotations, AWS S3 or equivalent object storage for encrypted document storage, a Next.js frontend with a custom PDF viewer built on react-pdf or PDF.js for the review interface, and a configurable playbook management interface built in Next.js that allows the legal team to define and update standard positions without engineering involvement. For law firm deployments, the entire stack is deployed within a private cloud environment or on-premises to satisfy client confidentiality requirements, with no document data transiting to shared LLM provider infrastructure. For in-house legal teams at enterprise companies, a private Azure OpenAI or AWS Bedrock deployment handles the LLM inference layer within the company's existing cloud boundary.
Regulatory and Professional Conduct Considerations
The most important regulatory consideration for AI contract review in the UK is the boundary between legal technology and the provision of legal services. The Solicitors Regulation Authority's guidance on technology and innovation confirms that AI tools that assist solicitors in their work do not themselves need to be regulated, but the solicitor using the tool retains professional responsibility for the legal advice provided. The system design must therefore make the lawyer-in-the-loop element structurally visible: the tool produces flags and analysis, the solicitor produces the legal advice. GDPR applies to any contract that contains personal data of identified individuals, which includes most employment contracts, consumer agreements, and any contract naming natural persons as parties. Document storage must use encryption at rest and in transit, retention periods must be defined, and processing agreements with any cloud LLM providers must be in place. The use of client contract documents to train or fine-tune models requires explicit client consent and is typically prohibited by law firm professional conduct obligations.
What to Replicate from This Pattern
The configurable playbook design is the practice most worth replicating. Building the risk analysis layer against a fixed set of clause risk rules produces a tool that works for the demo but does not adapt to the specific deal parameters of different practice areas or industry verticals. Making the playbook configurable by the legal team without code changes creates a tool that becomes more valuable as the team customises it to their work. The annotation feedback loop is the second most valuable practice: every lawyer interaction with a flag is a training signal that, when systematically captured and periodically used to update the system's sensitivity thresholds, produces continuous improvement in flag relevance without requiring new training data collection campaigns.
What to Avoid
The most common mistake is attempting to build an AI system that summarises the entire contract in one LLM call. Long contracts, frequently running to 80-150 pages, exceed the effective context window of most LLM deployments when combined with a detailed system prompt and playbook. The chunking and clause extraction stage exists precisely to avoid this: by extracting individual clause texts before sending them to the LLM for risk analysis, the relevant context is always within the model's effective attention range. The second mistake is designing the interface around the AI's output rather than around the lawyer's workflow. Solicitors working under time pressure need to navigate from the risk summary to the specific contract clause in one click, see the exact wording, compare it to the playbook standard position, and record their decision. Interfaces that require switching between a separate summary view and the underlying document add friction that makes the tool feel slower than manual review.