Private AI for Insurance Claims Handling

A single bodily injury auto claim can arrive as a first notice of loss, a police report, two repair estimates, forty photos, a recorded statement transcript and a stack of hospital bills. Under the NAIC Insurance Data Security Model Law, almost every page of that file is "nonpublic information": a name combined with a driver's license number qualifies, and so does any information from a health care provider or the consumer about a health condition, the care given or payment for it, with only age and gender carved out. That is the reason AI for insurance claims is a good fit for a model on the carrier's or TPA's own server. The work is mostly reading and sorting, and the material is exactly what a claims organization should not be pasting into a public chatbot.

This article covers four jobs (intake, document classification, file summaries and missing-document checks) and the rules that shape them. It is general information, not legal advice; state law and the department of insurance decide what applies to a given licensee.

The rules that frame claims AI

Only one of these rules was written with AI in mind.

State data security laws based on NAIC Model 668

The Insurance Data Security Model Law asks each licensee to run a written information security program based on a risk assessment, to exercise due diligence in selecting third-party service providers, and to require those providers to protect the nonpublic information they can access. A third-party service provider is a non-licensee that contracts to maintain, process or store nonpublic information, or is given access to it, through services to the licensee: a fair description of a cloud AI vendor receiving claim documents. The model also requires records of cybersecurity events to be kept for at least five years. Many states have enacted a version, with differences in deadlines and exemptions; the NAIC keeps an adoption map, and the home state's statute is what governs. The model's small-licensee exemption and its 72-hour commissioner notice are covered in the article on AI for advisers and insurance offices, so they are not repeated here.

The NAIC model bulletin on AI systems

In December 2023 the NAIC adopted a model bulletin on insurers' use of AI systems. It names claim administration and payment and fraud detection among the areas an insurer's written AI program should cover, and it says decisions made with AI must not be "inaccurate, arbitrary, capricious, or unfairly discriminatory." It also ties AI use to existing unfair claims settlement laws: actions must not violate them "regardless of the methods the Insurer used." For tools bought from a vendor, the bulletin expects due diligence and, where available, contract terms for audit rights and cooperation with regulators. The NAIC adoption map dated October 8, 2026 lists 27 states plus the District of Columbia and Puerto Rico as having adopted it, and California, Colorado, New York and Texas as having their own insurance-specific guidance.

Unfair claims practices still apply

The NAIC Unfair Claims Settlement Practices Model Act lists conduct such as "refusing to pay claims without conducting a reasonable investigation" and failing to acknowledge claim communications with reasonable promptness. A model that misfiles a doctor's letter, or a summary that drops the page where liability became clear, can feed exactly that kind of failure. That is the practical case for keeping the adjuster as the decision maker and the model as a drafter.

Where HIPAA does and does not reach

Health plans are HIPAA covered entities. Property and casualty claims mostly are not: the HIPAA definition of a health plan excludes the excepted benefits listed in 42 U.S.C. 300gg-91(c)(1), which include liability insurance, workers' compensation and automobile medical payment insurance. Medical records in an auto or workers' comp file are still health information under the state data security law. For a health insurer, the HIPAA side is covered in what a BAA does and does not cover. Model 668 treats a licensee that keeps a HIPAA security program, and certifies compliance, as meeting its program requirement.

Job one: intake and document classification

Claims arrive by email, portal upload, fax and mail scanned in bulk. The first useful job is putting each document into the right bucket and attaching it to the right claim.

A workable label set is small and tied to what adjusters already call things. For an auto line it might be:

Label	Typical fields worth extracting
First notice of loss	policy number, date of loss, location, vehicles
Police report	report number, agency, citations issued
Repair estimate	shop name, total, labor hours, supplement or original
Medical bill	provider, dates of service, billed amount
Medical record	provider, date, treating clinician
Correspondence	sender, claim reference, request made
Photo	vehicle or scene, no extraction
Other	route to a person

Scanned pages first need text, which is the job of local OCR and document extraction. The language model then reads the first page or two of each document and returns a label, a confidence and the extracted reference numbers as structured JSON. Code, not the model, matches the policy or claim number against the claims system. When the number does not match an open claim, the document goes to a queue for a person instead of being attached to the closest guess.

The arithmetic is easy to check. Take an illustrative office that receives 60 new or updated claims a day with an average of 12 documents each: 60 x 12 = 720 classification calls. If each call takes about 3 seconds on the office's GPU, that is 720 x 3 = 2,160 seconds, or 36 minutes of machine time per day. Run as an overnight batch, one server usually covers it, but measure the real per-call time first.

Job two: summarizing a claim file

An adjuster picking up a reassigned claim wants to know what happened, what is documented and what is still open.

Suppose a file has 140 pages and averages about 500 tokens per page after OCR: 140 x 500 = 70,000 tokens. A model running with a 32,000-token context cannot read that in one pass. The usual approach is two stages:

1. Summarize each document on its own, with its label, date and page range.
2. Build the file summary from those document summaries, in date order, never from the raw pages.

Each statement in the final summary should point to the document and page it came from, for example "Claimant reported neck pain at the ER on the date of loss (medical record, ER visit, page 3)." A reviewer can then click through instead of trusting the sentence. Requiring quotes, and checking that the quoted text actually exists in the source, is the main defense against invented facts, as described in reducing hallucinations in document Q&A.

The summary should not estimate claim value or recommend coverage. Those are decisions under the unfair claims settlement rules, and a machine sentence such as "liability appears to rest with the insured" is easy to repeat and hard to defend. Keep it to facts and sources.

Job three: spotting missing documents

This is the least glamorous job and often the most useful. Each line of business has a list of documents a file usually needs before it can move forward. An auto physical damage claim might need a first notice, photos, an estimate and, if the vehicle is a total loss, a title and lienholder information. A bodily injury claim adds medical records, bills and a signed authorization.

The split between model and code matters here:

• The model does what it is good at: reading a document and deciding it is a repair estimate, or that a letter is a supplement request.
• Code compares the classified documents against the checklist for that claim type and produces the list of what is absent.

A model asked "what is missing?" will produce a plausible list, sometimes naming things present on page 87. A checklist lookup is repeatable and auditable. The output is a draft request letter or a task in the claims system, which the adjuster sends or discards.

Keeping the data in-house in practice

Running the model locally removes one third-party service provider from the risk assessment, but the information security program still has to cover the AI server itself. Concretely:

• Access control: the model server sees whatever the claims staff can see, so it should sit behind the same authentication, and a summary should only be shown to someone allowed to open the file.
• Retention: prompts, extracted text and summaries are copies of nonpublic information. Set a retention period and a disposal procedure for them, since the model law asks for secure disposal of nonpublic information in any format.
• Logging: record which model version produced which label or summary, and who accepted or changed it. If an examiner asks why a document sat unclassified for nine days, that log answers it.
• Testing: before go-live, run the classifier on a few hundred already-labeled documents from closed files and count the errors per label. Medical records mislabeled as correspondence matter more than photos mislabeled as "other".

A sensible first step is the missing-document check on one line of business: it needs only classification, it produces a list an adjuster can verify in a minute, and its error rate is easy to measure.

Frequently asked questions

Can a local model detect claims fraud?

It can flag patterns for a special investigations unit to look at, such as the same phone number or repair shop across unrelated claims, but that is closer to analytics than to language work. Any fraud flag that affects how a claim is handled falls under the AI program the NAIC bulletin describes, including testing for unfair discrimination, so it needs more governance than document sorting.

Does a third-party administrator have the same obligations as the insurer?

A TPA is often itself licensed or registered under state insurance law, which would make it a licensee under the data security model, and it is also the insurer's service provider. Each side should check its own state's statute and the contract between them, including who keeps logs and who handles breach notice.

What hardware does claims document work need?

Classification and short extraction run well on a mid-size model on one current workstation GPU, because each call reads only a page or two. File summaries need a larger context window and more memory, but they run less often and can be queued. Test throughput with real documents before buying.

Should photos go through the model too?

Vision models can describe damage or read a VIN plate, but damage appraisal from photos is a specialized task with its own accuracy questions. For intake, labeling a photo as a photo and attaching it to the claim is usually enough.