Sample assessment · Specialty insurance
Atlas Specialty Insurance — Multimodal AI Readiness & Architecture
Illustrative sample. Atlas Specialty is a fictional commercial-property insurer (~$400M GWP); figures are representative, not client data. This excerpt shows the shape and depth of the real deliverable.
Executive summary
Every Atlas claim is already a multimodal document: adjuster photos, ACORD forms, contractor estimates, and email threads. Cycle time averages 11.4 days, and roughly a third of that is humans re-keying and hunting through files. The data needed to fix this is already in the claims system — unlabeled, unindexed, and untouched by the current AI initiative (a policy-language chatbot).
Recommendation: clean the intake, then compound. Document extraction is the wedge — it pays back immediately and produces the structured data every later phase (photo triage, claims copilot) depends on. Fraud detection is the shiny object to explicitly not chase this year.
1 · Use-case & value map
| Use case | Data | Est. value | Verdict |
|---|---|---|---|
| FNOL document intake extraction | PDFs, ACORD forms, emails | 2.1 days off cycle time | Do first |
| Damage-photo triage & severity scoring | Adjuster & policyholder photos | 31% of claims fast-tracked | Phase 2 |
| Multimodal claims copilot (RAG) | Full claim file: docs + photos + notes | Adjuster leverage | Phase 3 |
| Cross-modal fraud detection | Photos vs. estimates vs. history | Unproven | Defer |
- FNOL document intake extraction: Adjusters retype the same fields three times today. Hosted document AI plus a review UI removes the worst of it in six weeks.
- Damage-photo triage & severity scoring: Vision-language models score severity well enough to route, not to settle. Human-in-the-loop by design; needs the golden claims set first.
- Multimodal claims copilot (RAG): High value but it inherits every data-quality problem upstream. Sequence after intake extraction cleans the inputs.
- Cross-modal fraud detection: Promising research direction, but Atlas lacks labeled fraud outcomes at the volume needed. Revisit with 18 months of structured claim data.
2 · Reference architecture
- Intake pipeline: FNOL documents → hosted document AI (inside existing cloud tenancy) → adjuster review UI for low-confidence fields → claims system of record. Confidence thresholds tuned per claim type.
- Photo triage: policyholder and adjuster photos → vision-language scoring → route to fast-track or full adjustment. Model recommends; adjusters decide. Every decision logged for the eval loop.
- Eval & audit backbone: 300-claim golden set, per-claim-type accuracy dashboards, and a full audit trail of every model read and suggestion — built once, reused by every phase, and written for regulator questions.
3 · Production & reliability gaps
- PII and carrier compliance. Claim files are dense with PII. Architecture keeps all inference inside the existing cloud tenancy; no training on customer data; full audit log of every model read.
- No golden claims set. No labeled ground truth for extraction accuracy or severity. Weeks 1–2 build a 300-claim golden set with the two most senior adjusters.
- Latency budget undefined. Intake extraction can run in batch (minutes are fine); the copilot cannot (seconds). Two different serving paths, costed separately.
- Shadow-IT model use. Adjusters already paste claim text into public chatbots. The program includes a sanctioned, logged alternative — the fastest way to end the practice.
4 · Roadmap
- Weeks 1–6Golden claims set + FNOL intake extraction in production for two claim types (buy: hosted document AI; build: review UI and audit logging).
- Weeks 7–14Damage-photo triage pilot on fast-track candidates, human-in-the-loop, measured against the golden set.
- Quarter 3+Claims copilot over the now-clean claim files; expand extraction to all claim types.