Can Underwriters Use AI to Analyze Loss Runs and Schedules of Value?

The short answer

Insurance has already spent real money solving half of this problem. A category of well-funded platforms, Kolena, Bevaya, Decisions, SortSpoke, and others, now automate the extraction and normalization of loss runs and schedules of value: turning carrier PDFs, scans, and inconsistent Excel formats into one clean, structured spreadsheet. That part of the workflow is genuinely solved.

What isn't solved is the next step. Once the spreadsheet is clean, an underwriter still has to analyze it, and today that means building a pivot table by hand. That step involves reading and manipulating real claimant names, policy numbers, addresses, and financial reserves, and no tool has been built specifically for the question an underwriter actually wants to ask at that point, in plain English, without the data leaving their control.

What underwriters actually do with a loss run

A loss run is a claims-history spreadsheet: premium, paid losses, reserves, recoveries, and total incurred, per claim, often spanning multiple carriers and multiple years. Getting one clean is already a documented bottleneck. Industry sources put manual processing of a single multi-coverage submission at 90 to 120 minutes of pure data entry before any actual underwriting analysis begins, and underwriters report spending roughly 40% of their time on data processing rather than judgment.

Once the loss run is extracted and standardized, insurance's own training material describes the next step plainly. A well-known actuarial consulting firm publishes a guide titled, in essence, filters, pivot tables, and formulas for loss runs, walking underwriters through the manual process: highlight the claim data, insert a pivot table, drag the incurred-loss field into the values area, group by policy period. That is the accepted, current method for answering a basic question like "what's our total incurred by year."

From there, experienced underwriters look for a specific set of signals: frequency spikes, especially in recent years. Large open reserves relative to paid amounts. Severity trends, claim costs rising even as frequency holds steady. Subrogation patterns that might indicate third-party liability. Reserve accuracy, how close final paid amounts land to original estimates. Each of these is found by filtering, sorting, and eyeballing a spreadsheet that, for a complex commercial account, may span years of claims across multiple lines.

Schedules of value carry the same pattern

A commercial property Schedule of Value (SOV) is a different document with the same underlying problem. A 300-location SOV can run 40 columns wide, construction type, occupancy, year built, replacement cost value, protection class, across multiple tabs, often arriving in a different format from every broker and carrier that touches it.

The extraction vendors in this space describe the same before-and-after: what used to take a day or more to normalize now returns a structured, discrepancy-flagged spreadsheet in minutes. Again, that is extraction. The underwriting judgment that follows, which locations look inconsistent, where does replacement cost value not match construction type and age, which properties deserve a second look, is still work a person does by scanning rows and building comparisons manually.

Where a chat interface is a real improvement, and where it isn't

It's worth being precise here rather than claiming AI transforms every part of this job, because underwriters are, correctly, skeptical of that claim.

Genuinely faster and better: "Summarize this loss run by policy period, showing frequency and total incurred for each year" is the exact task the manual pivot-table tutorial walks through step by step. Asked as a sentence, it returns in seconds instead of five manual steps, and it doesn't depend on remembering which menu the date-grouping option lives in.

Genuinely better, not just faster: "Which locations in this SOV have replacement cost values that look inconsistent with their construction type and year built" is outlier detection across hundreds of rows. A systematic pass catches inconsistencies a manual scan can miss, not because the underwriter isn't skilled, but because 300 rows is a lot to hold in view at once.

Real, not a gimmick: questions that require connecting a pattern across many rows, subrogation clustering, reserve-versus-paid divergence, are the kind of reasoning language models do well and static spreadsheet formulas do poorly.

Not a meaningful upgrade: basic sums and counts that a two-click pivot table already handles instantly for an experienced user. The honest value there is removing the need to build the pivot table at all, more useful for someone less spreadsheet-fluent or working an unfamiliar carrier format, less dramatic for a power user.

Not something we're claiming, and shouldn't be: final risk pricing and underwriting judgment. That decision stays with the underwriter. The tools described in this piece, including ours, are built to answer the analytical question faster, not to make the call.

Why this hasn't been solved with a general-purpose AI tool

The obvious question is why an underwriter wouldn't just paste the cleaned loss run into ChatGPT once it's extracted. Two reasons this doesn't happen, or shouldn't.

First, the data itself is sensitive and often identifiable: named insureds, specific claim details, financial reserves, addresses tied to real properties. Under the NAIC's model bulletin on the use of AI by insurers, adopted in more than 20 states by mid-2026, carriers are expected to maintain documented governance over how AI systems use data, not simply attest that a policy exists. Pasting a client's loss run into a consumer AI tool is difficult to reconcile with that expectation, whatever the vendor's retention policy says.

Second, and this is the part that's easy to miss: even a fully compliant enterprise AI tier doesn't resolve this. ChatGPT Enterprise, Claude Enterprise, and similar tiers offer real protections, no training on your data, strong retention controls, SOC 2 certification, but every one of those protections governs what happens to the data before and after the model reads it. During the actual analysis, the model still receives the claimant names, the addresses, the reserve figures, in full, to answer the question. For data governed by carrier confidentiality obligations and increasing regulatory scrutiny of AI data handling, that's a meaningful gap between a strong policy and a structural guarantee. (Why that gap matters for insurability itself, and why exposure is the one AI risk that can actually be bounded, is the subject of The Two Perils of AI Risk.)

What a structurally different approach looks like

Instead of trusting a vendor's policy about what happens to a loss run after it's submitted, an alternative is to keep the underlying values out of the model's reach entirely. Data is encrypted before it leaves the underwriter's environment, using keys the underwriter's organization holds. The AI model receives the question and the structure of the spreadsheet, the columns, the shape of the data, not the claimant names, addresses, or dollar figures themselves. Computation happens on encrypted data. The result, the pivot table, the outlier list, the trend summary, returns and is decrypted only on the underwriter's side. (This is the architecture we define in What Is Confidential AI.)

The practical effect: the same "summarize this by policy period" or "which locations look inconsistent" question gets answered in seconds, without the loss run or SOV ever existing in readable form outside the underwriter's own control.

Nera Systems builds confidential AI infrastructure for regulated industries, including insurance. The platform lets underwriting teams ask questions of loss runs, schedules of value, and other sensitive spreadsheets using Claude, Gemini, or ChatGPT, without the underlying data ever being exposed. Learn more or try it on your own data.