---
title: "AI Document Extraction for an Insurance Software Platform | Agility"
url: https://agilitytech.ai/case-studies/insurance-document-ai
description: "Case study: serverless AI that pulls 100 to 200 fields from 1,000 page insurance and legal contracts, with cross document Q&A and data kept in the customer's cloud."
publisher: Agility (agilitytech.ai)
---

Insurance · Document AI

# 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.

1,000

Pages per contract

Insurance and legal documents of 500 to 1,000 pages each

100 to 200

Fields per document

Structured data pulled out of each contract

Serverless

On AWS

Lambda, including container based Lambda, and S3

Single tenant

Data stays put

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

Python

AWS Lambda and S3

Amazon Bedrock

Retrieval augmented generation

Frontier and open weight models

## 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](https://agilitytech.ai/ai-consulting-insurance) · [All case studies](https://agilitytech.ai/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.

[Book a free 30 minute call](https://calendly.com/nihar-t-agilitytech/30min)[See case studies](https://agilitytech.ai/case-studies)
