Five things we learned putting AI on insurance claims intake

Claims-intake automation is a useful example of how Cortex Document AI behaves in production. If you're scoping a document workflow, these are five principles worth applying.

1. How sure the AI is is the product

Cortex Document AI gives you a per-field confidence score for free. Most teams treat it as a debug field. Treat it as the routing key.

A practical design bands every field into three lanes:

• Auto-post (>0.92 and master-data validated): straight through to the policy admin system. No human in the loop.
• Adjuster-confirm (0.75–0.92 or one validation miss): claim record is created, but the disputed fields are highlighted on the adjuster screen with the cited source page pre-loaded.
• Human-review queue (<0.75 or two validation misses): a Streamlit-on-Snowflake reviewer triages before the record lands.

The straight-through rate isn't a model number. It's a policy number — you set the thresholds against the cost of a bad auto-post in your domain. In FNOL, a wrong loss date is expensive, a wrong reported amount is recoverable, and a wrong cause-of-loss code is somewhere in between. Three different thresholds, set with the claims ops lead in the room.

2. Checking answers against records you already trust beats tinkering with the AI

Prompt tuning may improve extraction accuracy, but validation against authoritative records is often more valuable. Two extra characters of OCR noise stop being only a model problem when a policy number can be checked against a real policy record. The same pattern applies to vendor IDs, effective dates, and geographic codes.

If you have authoritative reference data sitting in Snowflake — and you almost always do — your Cortex Document AI accuracy ceiling is way higher than the model alone implies. Build the validators before you tune the prompts.

3. Human review has to feed the model, or it's just data entry

A review interface should save corrections as labeled examples for future prompt and evaluation cycles, scoped by document class. Re-evaluate on a held-out set, promote changes only when they improve field-level accuracy without regressions, and keep a simple changelog so operations teams can see what shifted and why.

4. Drift monitoring is a day-one requirement, not a v2

Document corpora drift. Brokers change their email templates. A new managing general agent comes online with a different ACORD variant. A vendor updates their estimate PDF and the line items move two columns to the right. None of these are model failures — they're upstream changes that a model that was right yesterday is right to be confused by today.

Four dashboards should be in place before production traffic:

• Field-level accuracy against the rolling holdout, by document class.
• Confidence distribution by field and document class, week-over-week. A drifting source shows up here before it shows up in accuracy.
• Validation-failure rate by field. A spike in policy-number validation failures usually means the OCR layer is degrading on a specific source.
• Volume by document class. Catches new variants entering the mix before they hurt aggregate accuracy.

5. Cortex isn't always the right call

Cortex is a strong fit when documents and operational data already sit in the same Snowflake governance perimeter, existing masking and row-access policies can carry through to extraction outputs, and the team wants to avoid operating a second platform. Those conditions are not universal.

When we'd point you at a packaged IDP product instead:

• Your document mix is dominated by a class the IDP vendor has a pre-trained model for (high-volume invoices, US tax forms, standard shipping docs) and the accuracy out of the box beats what you'd reach with prompts in a quarter.
• You don't have Snowflake yet, or your operational data lives somewhere the IDP integrates more cleanly with.
• Your volume is genuinely low and the per-page pricing of a packaged product undercuts the engineering investment.

When we'd point you at Databricks instead:

• The pipeline is going to fan out into heavy unstructured ML — vision models on the photo supplements, audio extraction off recorded statements, fine-tuned classifiers on a domain-specific corpus. That's Mosaic AI's home turf, and forcing it into Cortex creates friction.

The document automation deep-dive describes the broader pattern, and the Snowflake Cortex page covers related capabilities such as Cortex Search, Cortex Analyst, and in-warehouse LLM functions.

The bigger point

Cortex Document AI is not magic, and it's not a packaged product. It's a set of primitives — extraction, confidence, citations — that you compose into a pipeline with validators, a review UI, drift monitoring, and a feedback loop. The teams that succeed treat it that way. The teams that wait for it to "just work" end up with a 50% straight-through rate and a backlog they're pretending isn't growing.

If you're deciding whether Cortex fits a document workflow, the readiness assessment is a fast way to evaluate the gap. Once the extraction layer works and retrieval is next, continue with the Cortex Search lessons post.