Claims Intake with Document Intelligence

Problem

A property and casualty insurer handles 400,000 claims a year, and 60% arrive as e-mails with PDF forms, invoices and photos. About 600 adjusters spend roughly 40% of their time on data entry. The regulator requires human oversight and explainability for automated decisions, under the EU AI Act. The company owns eight GPUs and will not send customer data to external AI services. Simple claims under 2,000 EUR should be settled automatically by business rules.

Approach

The binding constraints are human oversight, reproducibility, eight GPUs, and no data leaving the premises. Customer SLAs are 24 hours to acknowledge and three days to settle simple claims, so accuracy and traceability matter more than speed. The model does not decide. It recommends. Rules decide simple claims, and a named human decides everything else, including every adverse outcome. GPU work waits in a queue.

Architecture

• Intake: Apache Camel receives e-mail, portal, app and broker input. Originals go to object storage with Object Lock, and Kafka gets a claim.received event.
• Document pipeline: OCR with PaddleOCR or docTR. An open-weight language model on vLLM then extracts fields into a JSON schema, with a confidence score per field.
• Decision: Flowable runs the BPMN workflow. Drools decides simple claims. Fields below the threshold become review tasks for adjusters.
• Fraud and tracing: a graph in PostgreSQL with Apache AGE scores repeat repair shops and duplicate invoices. Langfuse traces every model call. MLflow holds model versions, and prompts live in Git.

Decisions and trade-offs

• Two-lane GPU queue. The kata estimates 8 to 9 GPU-hours of work a day against 192 GPU-hours of capacity. The problem is latency variance, not utilisation. So the target is minutes, not seconds, and there is no client timeout. If the GPUs stop, the queue grows, while intake receipts and adjuster screens keep working. The cost: this setup would not serve real-time chat.
• Audit row and outbox row in one transaction. Other katas write events straight to Kafka. Here the AI Act record and the workflow step must never drift apart, and a dual write to database and Kafka carries exactly that risk. Debezium publishes from the log. The cost is an Iceberg copy that lands seconds later, so PostgreSQL is the source of truth in that window.
• The model suggests; rules and people decide. Drools closes only simple claims under 2,000 EUR. A rejection or reduction needs a named human approval. The customer explanation comes from the fired rule and the adjuster note, never from raw model output. The cost is automation bias, so 10% of claims are a blind sample to measure it.
• Confidence per field, thresholds per field type. An IBAN and a free-text damage description do not share a threshold. A low-confidence field sends only that field to review, not the whole claim. Confidence comes from calibrated log-probs, because constrained output renormalises raw probabilities. The cost is keeping the calibration current.
• Prompts and rules versioned like code. They are tested against an evaluation set in CI on a nightly GPU, and new versions run in shadow before they count. The 95% accuracy target is measured weekly by sampling, not promised. The cost is the effort to maintain that set.
• Erasure by key destruction. Per-claim data keys are destroyed at the end of retention, and that counts as erasure under GDPR Article 17. Prompts and outputs in the audit record are stored encrypted too, so key destruction covers them. A litigation hold keeps the key. The cost is careful key management, which the data protection officer still has to review.

What I would revisit

• GPU type. Are the 8 GPUs 40 to 80 GB data centre cards or 24 GB workstation cards? Model size and tensor parallelism depend on it.
• What counts as a simple claim. I assumed 45% of claims. The real share sets the straight-through rate and the adjuster savings.
• AI Act role. The insurer is the provider of a high-risk system. Who owns the technical file and the conformity assessment, and is a notified body needed?
• Damage estimates from photos. Classification only, or an amount suggestion too? The vision model and its GPU share depend on it.

Outcome notes (design assumptions, not measurements)

This is a design exercise, not a running system. The output is a four-page diagram set, a one-page whiteboard version and a 16-page Turkish PDF. Field accuracy and the 45% share of simple claims are assumptions from the brief, not results.

Sources

• Architecture PDF (Turkish, 16 pages).
• draw.io diagrams (English labels): four-page set and a one-page 30-minute version.