AI Document Extraction for Long Insurance Contracts
An insurance software platform needed to pull structured data out of contracts that run to 1,000 pages, answer questions across documents, and keep every customer's data inside that customer's own cloud.
Insurance and legal documents of 500 to 1,000 pages each
Structured data pulled out of each contract
Lambda, including container based Lambda, and S3
Customer data never leaves the customer’s own cloud
The short answer: we built serverless pipelines on AWS that pull 100 to 200 structured fields from insurance and legal contracts of 500 to 1,000 pages, a retrieval layer for cross document questions and clause matching, and a routing layer that sends each task to the right model, all inside the customer's own cloud tenancy.
Project Overview
Industry
Insurance software (InsurTech)
Client type
Software vendor serving insurers and legal teams
Engagement
2026, ongoing
Team
Embedded AI and ML engineers
Technology Stack
The Challenge
General purpose LLM APIs were too slow and too costly at this document size
The platform reviews very large insurance and legal documents, pulls structured fields out of each one and answers questions across a set of documents for warranty and indemnity style review. Sending whole contracts to general purpose LLM APIs was too slow and too expensive per document to scale, and enterprise customers required that their data never leave their own cloud tenancy.
What We Delivered
A model agnostic document AI backbone
We built the extraction and retrieval pipelines the product runs on, and a routing layer that decides which model handles each task. The same backbone serves the existing document ingestion product and a new enterprise assistant, and a domain specific model can be dropped in later without changing anything that calls it.
Extraction and retrieval
- Structured field extraction over very long documents, fully serverless
- Cross document question answering and clause matching against a curated guideline corpus
- Latency work on document comparison and PDF generation, in progress
Architecture and governance
- Model agnostic routing with a reasoning route and a fast clause signalling route
- Data preparation for training a domain specific model
- Logged, auditable model calls with single tenant isolation
Challenges & Solutions
Documents too long for one prompt
Problem
Contracts of 500 to 1,000 pages do not fit a single model call, and the fields that matter are scattered across hundreds of pages.
Solution
Serverless pipelines split each document, run targeted extraction for 100 to 200 fields and assemble a structured record, scaling up and down with the load.
Impact
Structured data from the longest contracts without manual reading
Answers that must cite the right clause
Problem
Reviewers ask questions that span several documents and need answers tied back to specific clauses and internal guidelines.
Solution
A retrieval layer indexes the documents and a curated guideline corpus, so answers and clause matches come from the right passages.
Impact
Cross document Q&A and clause matching for review teams
Locked to one model
Problem
Hard wiring every task to one general purpose model made cost and speed hard to control and blocked a move to a domain model.
Solution
A routing layer sends each task to a suitable model, a reasoning route or a fast clause signalling route, behind one interface.
Impact
New models can be swapped in without rebuilding the product
Customer data cannot leave its tenancy
Problem
Enterprise customers review confidential legal and transaction documents and will not allow data to move between tenancies.
Solution
Everything runs inside each customer’s own cloud tenancy with single tenant isolation and logged, auditable model calls.
Impact
Meets data residency and confidentiality requirements
Related: AI consulting for insurance · All case studies
Frequently Asked Questions
How do you extract structured data from a 1,000 page contract with AI?
You do not send the whole contract to one model. The document is split, each field is extracted from the passages most likely to hold it, and the results are assembled and checked into one structured record. Running this serverless lets it scale with the number of documents.
What is a model agnostic routing layer?
It is a single interface that decides which model handles each task, for example a stronger reasoning model for complex questions and a faster one for spotting clauses. Callers never talk to a specific model, so a new or in house model can be added without changing them.
How do you keep customer documents inside their own cloud?
The pipelines run inside each customer’s own cloud tenancy with single tenant isolation, so documents never move across tenancies. Every model call is logged so it can be audited later.
Why not just use a general purpose LLM API for document review?
At hundreds of pages per document, general purpose APIs become slow and expensive per document, and many enterprise customers will not let data leave their tenancy. A routed, retrieval based design keeps cost and speed under control and keeps data in place.
Can a domain specific model replace general LLMs later?
Yes, if the architecture allows it. Because tasks go through the routing layer, a domain specific model can take over individual tasks once it is ready, without rewriting the product around it.
Drowning in long documents?
Tell us what you need pulled out of your contracts or policies. We will show you how an extraction and retrieval pipeline would work on your own documents.