Insurance Claims Automation: GPU Planning for Document AI at Scale
Overview
Insurance claims processing is one of the few enterprise AI workloads where the volume arithmetic is genuinely large and genuinely predictable. Every claim arrives as a bundle of documents — forms, invoices, prescriptions, discharge summaries, repair estimates, photographs — most of them scanned, many handwritten, frequently in Indian languages and mixed scripts. The 2026 change is that vision-language models read these end-to-end rather than through a brittle OCR-plus-rules pipeline. That changes both accuracy and the sizing method: the unit of capacity is pages per hour, not queries per second.
Key takeaways
- Size in pages, not claims — a health claim bundle can run to dozens of pages and dominates the compute.
- Vision-language models replaced OCR pipelines — layout, tables and handwriting are handled in one pass.
- Indian scripts and handwriting are the hard part, and generic benchmarks overstate accuracy on them.
- Confidence tiering controls cost — a small model handles clean documents, a large one handles the difficult remainder.
- Batch, do not stream — claims processing tolerates minutes of latency, so throughput optimisation dominates.
Why the pipeline changed
The traditional stack was optical character recognition, then layout heuristics, then template matching, then rules to extract fields. It worked when documents were standardised and broke whenever a hospital changed its discharge summary format or a garage wrote an estimate by hand. Maintenance cost grew with every new document type, and accuracy on the long tail was poor.
Vision-language models change this by reading the page as an image and producing structured output directly, using layout, tables and surrounding context together. The practical benefit is generalisation: a model that has learned to read invoices reads an unfamiliar invoice format reasonably well without a new template. The practical cost is compute — a VLM pass over a page is far more expensive than OCR, which is precisely why sizing needs care.
From claim volume to GPU capacity
Work in four steps. First, count pages: claims per day multiplied by average pages per claim. Motor claims might average five to ten pages plus photographs; health claims frequently run to thirty or more. Second, apply the peak factor — claims arrive unevenly, with month-end and post-event spikes, so a factor of two to three over the daily average is prudent.
Third, measure pages per second per GPU for your chosen model at your chosen resolution. Resolution is a first-order cost driver: a VLM processing a page at high resolution generates many more image tokens than at low resolution, and doubling the effective resolution can more than double the compute. Fourth, divide and add redundancy. The discipline is the same as any inference sizing exercise — see the GPU server sizing checklist for AI inference — but with pages as the unit.
A confidence-tiered pipeline
| Stage | Function | Share of pages | Compute profile |
|---|---|---|---|
| Classification and triage | Identify document type, quality, language | 100 percent | Small vision model, cheap |
| Standard extraction | Structured fields from clean documents | 60-75 percent | Compact VLM, moderate resolution |
| Difficult extraction | Handwriting, poor scans, unusual layouts | 20-35 percent | Large VLM, high resolution |
| Reasoning and adjudication | Policy matching, exclusions, consistency | Per claim, not per page | Text LLM, long context |
| Human review | Low-confidence or high-value cases | 5-15 percent | None; queue and interface |
The economics of this structure are the whole point. Running every page through the largest model at maximum resolution is straightforward to build and several times more expensive than necessary. A calibrated confidence threshold at the standard-extraction stage, routing only uncertain pages upward, typically cuts GPU requirement substantially while improving accuracy on the hard cases that actually needed the bigger model.
The Indian document problem
Model performance on Indian claims documents is materially worse than on the English business documents that dominate public benchmarks. The reasons are concrete: Devanagari, Tamil, Bengali and other scripts are under-represented in training data; medical handwriting is difficult in any language; scans from clinic-grade equipment are low quality; and documents frequently mix scripts within a single page, with an English form annotated in a regional language.
Two responses matter. Build an evaluation set from your own claims, stratified by language, document type and scan quality, and measure field-level accuracy on it before committing to a model — published benchmark numbers will overstate what you will see. And plan for domain adaptation: a modest fine-tune on a few thousand representative pages typically outperforms a much larger general model on this data, which is both cheaper to serve and easier to govern. The adaptation approach is covered in fine-tuning GPU server sizing.
Latency, batching and the shape of the hardware
Claims processing is a batch workload wearing a real-time costume. A customer expects a decision in hours or days, not milliseconds, which means the system can batch aggressively — large batches, high resolution, full GPU utilisation — rather than optimising for interactive latency. That is a significantly cheaper operating point than a chat workload at the same token volume.
The exception is the growing set of instant-settlement propositions for small motor and health claims, where a decision is promised in minutes. Those deserve a separate, smaller, latency-optimised path rather than compromising the batch design for the whole estate. Splitting the two is almost always cheaper than building one system that does both adequately.
Regulatory shape
Claims documents contain health data, financial data and identity documents — among the most sensitive categories under DPDP, with penalties up to Rs 250 crore and full enforcement expected in 2027. IRDAI’s own record-keeping and grievance obligations add a requirement that a decision be explainable and its evidence retrievable years later.
Three design consequences follow. The extraction outputs and the model’s confidence scores are part of the claim record and must be retained with it, not discarded after processing. An adverse decision — a rejection or partial settlement — needs a reconstructable rationale, which argues for keeping the deterministic policy-matching logic outside the model even where extraction is model-driven. And the whole pipeline, including the document store and any derived index, sits in-country under the insurer’s control. The placement logic is worked through in where BFSI AI compute must sit.
Frequently asked questions
How do I size GPUs for claims processing?
Count pages, not claims. Multiply claims per day by average pages per claim, apply a peak factor of two to three, then divide by measured pages per second per GPU at your chosen model and resolution. Resolution is a first-order cost driver.
Why replace an OCR pipeline with a vision-language model?
Because VLMs generalise across document formats without templates, handling layout, tables and handwriting in a single pass. The traditional OCR-plus-rules stack required new templates for every format change and performed poorly on the long tail.
Do public benchmarks predict accuracy on Indian claims documents?
No. Indian scripts, mixed-script pages, medical handwriting and low-quality clinic scans are under-represented in public benchmarks. Build an evaluation set from your own claims stratified by language, document type and scan quality, and measure field-level accuracy on it.
How can I reduce the GPU cost of document AI?
Tier by confidence. Classify cheaply, extract most pages with a compact model at moderate resolution, and route only uncertain pages to a large model at high resolution. This typically cuts GPU requirement substantially while improving accuracy where it matters.
What must be retained for regulatory purposes?
Extraction outputs and confidence scores as part of the claim record, plus a reconstructable rationale for any adverse decision. Keeping deterministic policy matching outside the model makes that rationale defensible, and the whole pipeline should remain in-country under the insurer’s control.
Ready to deploy?
Talk to an RDP architect about power, cooling and lead time.