Insurance underwriting: AI before the policy, before the claim

We covered insurance claims processing earlier in this series. This post is about the workflow that comes before — underwriting. The work of evaluating applications for insurance coverage, classifying risk, determining pricing, and deciding which policies the carrier will write at what terms.

Underwriting is where the carrier's business model actually lives. The quality of underwriting determines profitability over the long run. AI has been integrated into underwriting workflows fast in the past three years. The data is sensitive. The regulatory framework on AI bias and fairness in underwriting is intensifying. The local-SLM case combines cost, privacy, and regulatory considerations in a particularly clean way.

The work

Underwriting AI workloads include:

Application processing: reading inbound applications, extracting structured data, identifying missing information, classifying risk factors. Volume scales with the carrier's growth.

Risk classification: applying the carrier's risk classification framework to each application, generating preliminary risk scores, identifying applications that need additional information.

Pricing: applying the carrier's pricing models to risk-classified applications, generating rate quotes, drafting policy terms and conditions.

Medical underwriting (for health and life): reviewing medical records, assessing health conditions, generating underwriting decisions. The data is heavily regulated.

Commercial underwriting (for property and casualty commercial lines): analyzing business operations, reviewing loss histories, evaluating property characteristics, drafting risk improvement recommendations.

Reinsurance and treaty work: evaluating treaty submissions, modeling portfolio impacts, drafting treaty terms, producing the documentation that reinsurance markets expect.

Renewal underwriting: re-evaluating existing policies at renewal, adjusting risk classifications based on experience, drafting renewal terms.

The math

A representative midmarket insurance carrier processes a meaningful volume of underwriting work across its lines of business.

For a P&C carrier writing one to two billion in premium, the application volume is in the tens of thousands per month across personal and commercial lines. For a life and health carrier of similar size, the application volume is similar with longer per-application analysis cycles. For a specialty carrier focused on a specific risk category, the volume is smaller but the per-application complexity is higher.

Each application moves through multiple AI operations: data extraction, risk classification, pricing analysis, decision documentation, sometimes external data enrichment (loss history, credit data, property data). A reasonable token budget per application aggregate is twelve thousand input tokens and one thousand output tokens, at frontier pricing about $0.051 per application.

A midmarket carrier processing twenty thousand applications per month at $0.051 each is about $1,020 per month, or about $12,240 per year. Modest.

For larger carriers — major personal lines insurers, large commercial markets, global reinsurance markets — the numbers scale to the high six figures or seven figures per year as application volume and underwriting sophistication grow.

The cost case is real but not extreme. The regulatory and privacy cases are what drive the architectural conversation.

Why underwriting is a strong local-SLM workload

The standard properties are all present, with several that are unusually strong.

The work is narrow within the carrier. Each carrier has its specific products, risk appetite, pricing models, and underwriting philosophy. A model fine-tuned on the carrier's own underwriting corpus outperforms a general model on the carrier's specific work.

The work is repetitive. Applications follow predictable structures. Risk classifications follow predictable frameworks. Pricing decisions follow predictable logic. Specialization compounds.

The privacy story is real. Applications contain PII, financial information, medical information (for health and life), business information (for commercial). Sending all of it to a third-party cloud LLM creates privacy exposure that the carrier's compliance officer and the customer (if disclosed) both have opinions about.

The regulatory framework on AI bias and fairness in underwriting is intensifying. State insurance regulators in the US have been issuing model guidance on AI use in underwriting, with specific concerns about disparate impact, fairness, and explainability. The EU AI Act classifies AI use in insurance underwriting as high-risk. NAIC has model bulletins. The regulatory conversation is moving fast and the architectural choice matters.

The audit trail matters for underwriting decisions specifically. Adverse underwriting decisions (declines, rate-ups, exclusions) are subject to consumer rights frameworks, complaint processes, and potential litigation. The reasoning behind every adverse decision needs to be defensible. A local model with structured logs produces an audit trail that maps onto what regulators and consumer advocates expect.

The bias and fairness conversation favors local. Demonstrating that the model is fair, that the training data is appropriately representative, that the decision logic is auditable — all of these conversations are easier when the model is the carrier's own and the inference happens in the carrier's controlled environment.

What changes with local inference

An underwriting AI workflow on a local SLM looks like this.

A model is fine-tuned on the carrier's underwriting corpus — historical applications, risk classifications, pricing decisions, loss outcomes, regulatory reviews. The fine-tuning happens in a compliance-controlled environment with attention to bias and fairness considerations.

The model deploys on infrastructure the carrier controls. The deployment is documented, validated, and monitored against fairness metrics that the carrier's actuarial and compliance functions define.

Applications flow through the inference pipeline. Risk classifications, pricing recommendations, decision documentation — all produced locally. The audit trail accumulates inside the carrier's controlled environment.

The cost flips from per-application to fixed. Application volume can grow with the carrier's business activity.

The regulatory conversation gets easier. The carrier can demonstrate to regulators and to consumer advocates that the model is the carrier's own, that the training data is the carrier's own, that the audit trail is the carrier's own, and that the bias and fairness monitoring is the carrier's own responsibility.

What the regulator is watching

Insurance regulators are issuing increasingly detailed guidance on AI use in underwriting. The questions being asked map onto the cloud-vs-local distinction.

How is bias being monitored? Local deployment supports the carrier's own bias monitoring practices; cloud deployment depends on the vendor's practices.

How is fairness being measured? Local deployment uses the carrier's own data and frameworks; cloud deployment relies on what the vendor exposes.

How is the model being validated for the underwriting use case specifically? Local deployment supports carrier-controlled validation; cloud deployment depends on vendor validation that may or may not match the carrier's risk appetite.

How is consumer recourse being supported? Adverse underwriting decisions need to be explainable to consumers and to regulators. Local deployment makes the audit trail directly accessible; cloud deployment depends on what the vendor exposes.

For each of these questions, the carrier on local inference has structurally better answers. As regulatory expectations tighten, the gap widens.

Where the cloud LLM is still acceptable

A few cases.

For research and pricing analytics workflows operating on aggregated, non-applicant-identifying data.

For internal training and knowledge management content that doesn't touch underwriting decisions.

For specific cloud LLM services that have explicit regulatory authorization and have been validated for specific underwriting use cases.

For the bulk of underwriting work — application processing, risk classification, pricing, decision documentation, renewal — the local-SLM case is strong on cost, on privacy, on bias and fairness considerations, and on audit trail.

The pattern, in the underwriting workflow

Avery NXR is not an underwriting tool. It scaffolds Next.js applications. The architectural pattern repeats, with the bias/fairness regulatory dimension adding a unique element.

Insurance underwriting AI is a narrow, repetitive, volume-meaningful, privacy-sensitive, bias-and-fairness-regulated, audit-critical workload. Every dimension favors local inference. The emerging regulatory framework on AI fairness is the under-discussed argument that may end up being the strongest.

The insurance AI vendors that build on local infrastructure — with appropriate fine-tuning, bias-monitoring frameworks, fairness-evidence packages, and integration with policy administration systems — will own the institutional underwriting AI market. The cloud-LLM-default products will hold pockets but face increasing regulatory pressure.

The pattern continues. Underwriting is one of the workflows where the architectural shift is being driven primarily by the emerging regulatory framework on AI fairness, reinforced by cost, privacy, and audit considerations. Carriers that move first will be ahead of the regulatory curve in addition to being ahead on cost.