AI in insurance: how to automate underwriting and claims safely

AI creates the most dependable value in insurance where the work is document-heavy and rule-bound: submission intake, claims triage, document and photo extraction, and fraud screening. Start with assistive automation that keeps underwriters and adjusters in the loop, measure cycle time, touch rate and extraction accuracy against a pre-automation baseline, and open straight-through processing only for low-complexity segments after a shadow-mode period. Any model that assesses or prices risk for individuals is a regulated decision system from day one, so explainability, fairness testing and GDPR Article 22 safeguards belong in the design rather than in a later phase.

Where AI creates value in the insurance value chain

Most insurance cost sits in reading documents, re-keying data, routing cases and checking facts, not in the final judgment, and that is where current AI techniques are strongest. The table lists metric types rather than percentages, because the right number depends on your lines of business, legacy systems and baseline.

Capture a pre-automation baseline for the same metric on the same population before the first model goes live; without it, "outcome" becomes an opinion.

Underwriting automation: intake, scoring, triage and straight-through processing

Underwriting automation works best as a pipeline of narrow, testable steps, each with its own accuracy target, human fallback and log.

Document intake. Commercial submissions arrive as ACORD forms, loss runs, statements of values, financials and broker emails; life and health applications add medical records. A classifier sorts pages by type, an extraction model maps them to a fixed schema with a confidence score and a provenance reference, and low-confidence fields go to a human whose correction becomes training data.

{
  "field": "total_insured_value",
  "value": 4250000,
  "currency": "USD",
  "confidence": 0.93,
  "source": { "document_id": "sov-2026-0412.pdf", "page": 3, "bbox": [112, 640, 388, 662] },
  "status": "auto_accepted"
}

Risk scoring. Keep the language model out of the price. LLMs read and structure documents; the score comes from a tabular model (gradient-boosted trees or a GLM) trained on your own loss experience, with monotonic constraints where the actuarial relationship is known, which keeps pricing auditable.

Triage and straight-through processing. Deterministic rules run first (appetite, exclusions, sanctions, limits), ML scoring second. Cases inside appetite with low predicted complexity can be quoted or bound without a touch; everything else reaches an underwriter with a pre-filled summary and the referral reasons.

Explainability. Every automated decision and referral needs reason codes that an underwriter, an auditor and, where required, the applicant can read; SHAP-style attribution serves tabular models, and for LLM extraction the explanation is the provenance link to the source page. Design straight-through processing as a narrow lane with hard boundaries and sampled audits, not as a default that humans override.

Claims automation: FNOL to settlement with a human in the loop

Claims is where policyholders judge the insurer, so automation must improve speed without producing unexplained denials. Automate fact collection, score risk continuously, and keep the settlement decision with a person until data proves a narrow lane is safe.

• FNOL intake. A chat or voice agent captures loss facts into a structured record, checks coverage against the policy in force at the loss date, and sets expectations for next steps.
• Document and photo extraction. Repair estimates, invoices, police reports and medical bills use the same confidence-and-provenance approach as underwriting. Computer vision can estimate damage severity from photos, but as a decision aid with an uncertainty range, not a final number.
• Fraud and anomaly detection. Score each claim at FNOL and at every material update, combining supervised models trained on confirmed outcomes, anomaly detection for unlabeled patterns, and graph analytics linking claimants, providers, repair shops and phone numbers across claims. Investigator feedback must flow back into training or referral precision decays.
• Settlement recommendation. Retrieve similar closed claims, check limits and deductibles, and propose a settlement range with the reasoning shown. Auto-payment fits only low-value, low-risk claims inside pre-agreed limits, with a random sample audited by a senior adjuster.
• Human review. Set authority thresholds by claim type and value, store the model's recommendation and the adjuster's decision as separate fields, and make disagreement easy; disagreements are your best drift signal.

Open an auto-settlement lane only for a specific claim segment with months of shadow-mode evidence behind it.

Policy servicing agents: chat and voice with RAG over policy documents

Service teams most often ask for an assistant that answers "am I covered for X?" and "what is my deductible?" without a person reading the policy. Retrieval-augmented generation (RAG) is the right technique because the answer must come from this customer's wording, schedule and endorsements, not from the model's general knowledge; fine-tuning does not solve this, as explained in RAG vs fine-tuning: a decision guide.

Retrieval must be scoped to the exact document version in force for the authenticated customer, every answer must cite the clause it relies on, and the agent must decline when the retrieved text does not support an answer. Coverage statements with legal weight are labeled as informational and handed to a human on dispute. Voice adds latency and privacy load, since speech-to-text, the model and text-to-speech all sit in the response path and the audio is personal data. Serve the model where the policy documents live, scope retrieval to one customer and one document version, and measure containment and escalation rate rather than "conversations handled".

Data and integration requirements

Insurance AI projects fail on integration more often than on models. The systems of record are typically a policy administration system (Guidewire PolicyCenter, Duck Creek, Sapiens, Majesco or an in-house mainframe application), a claims system, a document platform (OpenText, IBM FileNet, SharePoint or a scanned-image archive), a CRM and a warehouse such as Snowflake, plus third-party feeds for motor vehicle records, property data, telematics and fraud databases.

Before the first pilot, confirm:

1. Read access to policy and claims systems through APIs or events, not screen scraping.
2. A document store with stable identifiers, so extracted fields can point back to page and region.
3. Labeled historical outcomes: bound versus declined, paid versus denied, confirmed fraud versus cleared.
4. A data dictionary shared by underwriting, claims and actuarial teams.
5. A PII inventory, retention rules and a way to pseudonymize training data.
6. A tool layer agents can call; MCP servers over SAP, Salesforce, Microsoft 365 and Snowflake standardize this, as described in What is MCP, and how do you build an MCP server?.

Where files contain health data or residency rules are strict, the language model is deployed privately on NVIDIA GPUs with vLLM or NVIDIA NIM rather than sent to a public API; this is the default Nanobase AI recommends for claims files. Budget as much engineering time for connectors, identifiers and labels as for the models themselves.

Model governance and regulation

EU AI Act. Regulation (EU) 2024/1689 lists "risk assessment and pricing in relation to natural persons in the case of life and health insurance" as high-risk in Annex III, which requires risk management, data governance, technical documentation, logging, human oversight, accuracy testing and a conformity assessment before deployment. Property, casualty and commercial pricing are not named, but transparency obligations still apply and national supervisors may add expectations. As of 2026, verify the Annex III application dates on EUR-Lex, because the Commission proposed timeline changes in late 2025.

GDPR. Article 22 gives individuals the right not to be subject to a decision based solely on automated processing with legal or similarly significant effects, which covers a declined application or a denied claim. Health data is a special category under Article 9, and Article 35 expects a data protection impact assessment for large-scale profiling. Fully automated adverse decisions therefore need a lawful basis, human review on request and an explanation the individual can understand; the text is on EUR-Lex.

Fairness. Models reconstruct protected characteristics from postcode, occupation or purchase history even when those fields are excluded. Test for disparate impact by segment before and after deployment and document permitted features per jurisdiction: gender has been barred as an EU rating factor since the Test-Achats ruling, and in the United States the NAIC model bulletin on insurers' use of AI, Colorado's SB 21-169 and the New York DFS 2024 circular letter all expect documented testing.

Explainability and monitoring. Keep a model inventory with owners, intended use, data lineage and validation results; produce reason codes for every automated decision; monitor input drift, output drift and override rate. A deployment checklist is in EU AI Act, GDPR and KVKK compliant LLM deployment checklist. Document every model that touches an individual's price, acceptance or claim as if a supervisor will read the file, because one eventually will.

Implementation roadmap: from pilot to production

1. Pick one process with volume and a clear owner. Commercial submission intake or auto physical damage claims are common first choices because the outcome metric is unambiguous.
2. Baseline the current process. Measure cycle time, touch rate, keying accuracy and rework rate on a representative sample.
3. Prepare data and integration. Secure system access, document identifiers, labeled outcomes and a PII plan before model work starts.
4. Build in assist mode. The model pre-fills, summarizes and recommends; humans decide; everything is logged.
5. Run in shadow mode. Compare model outputs with actual decisions by case type and fix the segments that disagree.
6. Open a narrow straight-through lane. Take the segment with the strongest evidence, set hard boundaries, and audit a random sample weekly.
7. Complete governance artifacts. Model card, validation report, fairness results, DPIA where required and the human-oversight procedure, reviewed by risk, legal and actuarial functions.
8. Scale by adding lanes, not by removing controls. Each new segment repeats steps 5 to 7 with its own evidence.

The build takes a few months; shadow mode and governance take most of the calendar time, and rushing them turns a good pilot into a bad production system. Expect to spend more time proving a model is safe in a segment than building it.

Pitfalls to avoid

• Letting the LLM price the risk. Numerical judgments vary between runs and cannot be audited as a rating model.
• Measuring accuracy on documents, not on decisions. A wrong insured value is a wrong premium; a wrong date of loss is a wrong coverage decision.
• Automating first, governing later. Retrofitting reason codes, logging and fairness tests onto a live system usually means a production pause.
• Skipping shadow mode. Agreement on a test set says little about the live mix of brokers, regions and seasons.
• Ignoring the feedback loop. Fraud and triage models decay when investigator and underwriter decisions are not fed back.
• Sending health or claims data to a public API without a data-flow review. Residency, retention and sub-processor terms must match your obligations.
• Building the chatbot before the document plumbing. Without reliable retrieval over the right policy version, the agent gives confident, wrong answers.

Most failed insurance AI programs did not fail on the model; they failed on baselines, integration and governance.

Frequently asked questions

What is straight-through processing in insurance underwriting?

Straight-through processing (STP) means a submission is quoted, and sometimes bound, with zero underwriter touches. It combines deterministic rules for appetite and exclusions, a risk score from a tabular model, and a triage layer that passes only low-complexity cases. STP share is the proportion of cases completed without a human touch, grown one audited segment at a time.

Can a large language model price insurance risk?

Not in a way an auditor or regulator will accept. LLMs read documents, extract fields and summarize well, but their numerical judgments vary between runs and cannot be reconstructed as a rating formula. Use the LLM to structure the submission and a gradient-boosted model or GLM, trained on your own loss experience, to produce the score and the reason codes.

Is AI-based insurance underwriting high-risk under the EU AI Act?

Partly. Annex III of Regulation (EU) 2024/1689 names AI used for risk assessment and pricing of natural persons in life and health insurance as high-risk, triggering risk management, data governance, logging, human oversight and conformity assessment obligations. Other lines are not named, but transparency duties still apply. As of 2026, check the current application dates, since the Commission proposed timeline changes in late 2025.

How does AI detect insurance fraud?

Three techniques are combined: supervised models score claims on patterns learned from confirmed fraud, anomaly detection flags claims that look unlike the normal population without needing labels, and graph analytics connect claimants, providers, repair shops and contact details across claims to reveal organized rings. Scores are produced at first notice and at each update, and investigator decisions are fed back so referral precision does not decay.

How accurate does document extraction need to be before automating?

Accuracy is set per field by its downstream effect, not by one global target. Fields that drive premium or coverage, such as insured value, date of loss or policy number, need near-perfect accuracy or a human check, while descriptive fields tolerate errors. Each field gets a confidence threshold tuned on a labeled sample of your own documents, and values below it go to review.

Does GDPR allow fully automated claims decisions?

Only within limits. Article 22 restricts decisions based solely on automated processing with legal or similarly significant effects, and a denied claim qualifies. Such decisions need a lawful basis such as contract necessity or explicit consent, plus the right to human intervention, to express a point of view and to contest the decision. Automated approval of low-value claims is far easier to justify than automated denial.

How Nanobase AI can help

Nanobase AI builds insurance AI end to end: document intake and extraction with confidence scoring and provenance, underwriting triage and claims automation with human-in-the-loop workflows, fraud and anomaly models, and RAG-based policy servicing agents grounded in your own policy documents. We deploy language models privately on NVIDIA GPU infrastructure (vLLM, TensorRT-LLM, NVIDIA NIM), integrate with policy administration, claims and document systems through APIs and MCP servers, and deliver the governance artifacts, from model cards and fairness testing to EU AI Act and GDPR documentation, that supervisors expect. Nanobase AI is headquartered in Silicon Valley and is a member of the NVIDIA Inception Program. See our solutions for a reference pipeline you can run on your own sample documents.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.