AI for Insurance Companies: Where to Start, What Blocks It

Avtar by Nazrina Sohal

AI for insurance companies has a sequencing problem, not an idea problem. Most insurers can list ten use cases. Far fewer can say which one their data and their regulator will let them run this year.

The first answer is usually in the claims inbox. Documents already arrive, adjusters already retype them, and the cost of the retyping is already measured. The harder answers sit in the policy administration system and in a written governance programme that most insurers haven't finished.

This article covers where AI pays off first in insurance and what usually blocks it. It also covers what to have ready for a regulator. It's for the COO, the head of claims or underwriting, and the CTO deciding where AI starts.

Key Takeaways

  • The best first AI project for an insurer runs on data it already holds, such as claim documents, not data it hopes to collect.
  • Claims intake and underwriting support cover most first insurance AI projects, and each needs different data and a different level of human sign-off.
  • Older policy administration systems usually set the timeline for insurance AI, because they hold the data and weren't built to be called by a model.
  • US insurance regulators expect a written AI programme covering governance, an inventory of AI systems and human oversight, so plan it from the start.
  • Any model that influences coverage or pricing decisions needs a human sign-off step designed in from the start, not added after launch.

What Does AI for Insurance Companies Cover?

AI for insurance companies means using machine learning and related models to make or support decisions in claims, underwriting, fraud and servicing, using the data an insurer already holds.

It sits inside the lifecycle, not beside it. A model that reads a claim document, scores a submission or flags a suspicious claim is doing a job a person did before. That's different from a chatbot on a website. And it's where most of the value sits, along with most of the regulatory attention.

AI in insurance covers four areas in practice, and each one runs on different data:

Use case Data it needs Where the output lands
Claims intake and triage Claim documents, forms and photos The claims system, as a pre-filled claim and a routing flag
Underwriting support Submission documents and past decisions The underwriter's workbench, as a summary with risk flags
Fraud detection Claim history with confirmed outcomes The investigator's queue, as a ranked referral
Customer servicing Policy and claim status data The portal or contact-centre screen

In every row, the output has to land in a system the team already uses. But a model that produces a score nobody sees changes nothing.

Insurance AI follows the same sequence as any AI transformation. Choose a use case the data can support, fix what it runs on, then measure the return.

Which AI Use Cases in Insurance Pay Off First?

Four use cases account for most first projects in insurance. They're claims intake and triage, underwriting support, fraud detection, and customer servicing.

Claims Intake and Triage

In our experience, claims intake is where insurers see a return soonest, because the documents already arrive and the retyping is already costed. It's the cleanest case for AI in insurance claims. It also suits AI in claims processing more broadly.

A model reads the claim form, photos and supporting documents, pre-fills the claim, and flags how complex it looks. A person confirms the fields and handles the exceptions. The work needs the claim documents and an interface to the claims system.

Two things block it. Documents vary: scans, photos and handwritten forms all arrive. And nobody has agreed an acceptable error rate. Settle what the model may pre-fill and what a person must confirm before anything is built. Then prove it by testing AI models on real claims, with the adjuster's agreement on what good looks like.

Many guides recommend fraud detection first, and it can be right where claims data is rich and confirmed outcomes are recorded. But where they aren't, intake is the safer start.

If claims arrive as documents and adjusters retype them, start here.

Underwriting Support

Underwriting support is the safest form of AI in insurance underwriting. It reads submissions, summarises them and flags risk factors for the underwriter. It needs submission documents and a history of past decisions. That's AI underwriting as support, not decision.

The constraint is sign-off, not accuracy. A model that influences a coverage or pricing decision needs a human in the loop, and in our experience, that sign-off path has to be designed in from the start. Adding it afterwards means reworking the workflow.

Start with summaries and data extraction, and leave the decision with the underwriter. Move toward scoring only once the sign-off path works.

Fraud Detection

Fraud detection needs claims with confirmed outcomes. Confirmed fraud is rarer than claims, so a model can only learn from a small labelled set. That caps what AI fraud detection in insurance can do early on.

Investigators also need a reason for each referral. A bare score they can't explain gets ignored. Rank referrals and show the factors behind each one, and keep the denial decision with a person.

Customer Servicing

Customer servicing assistants answer questions about policies and claim status. It's a low-risk start, but it depends on the policy and claims systems exposing live data. An assistant that can only read a document library can't tell a customer where their claim is.

If the policy system exposes status through an API, this can be quick. If it doesn't, the integration is the project.

What Usually Blocks AI in Insurance?

AI in insurance usually stalls on the policy system, the document data and the sign-off path, not on the model.

Policy administration systems are often older than the use case. They hold the data a model needs, and they weren't built to be called by one. In our experience, a policy administration system older than the use case sets the timeline. Where that's true, AI integration with legacy systems is the real project, and the model is the smaller part.

And if the policy system can't expose data through an API at all, wrapping or replacing it comes first. That's custom insurance software development, not AI work.

Document data is the second blocker. Claims and submissions arrive as PDFs, scans and emails. But a model can only read them once they've been extracted, checked and stored somewhere queryable.

The third is regulatory. About half of US states have adopted the NAIC's model bulletin on insurers' use of AI. It expects a written programme with governance, risk controls and human oversight. A use case that can't show that programme can't go live safely.

How Do Insurers Choose a First AI Use Case?

Choose the first use case from the data you already hold and the sign-off it needs. Don't start from the list of what's possible.

If you already have Start with The sign-off it needs
Claims arriving as documents that adjusters retype Claims intake and triage An adjuster confirms the pre-filled fields
Submissions arriving as documents and emails Underwriting support, meaning summaries and extraction The underwriter decides, and the model never does
Claims with confirmed fraud outcomes on record Fraud referral ranking An investigator reviews every referral
Policy and claim status exposed through an API A customer servicing assistant A person handles anything the assistant can't answer
Little of the above, and an old policy system Integration work first None yet, because nothing is live

If more than one row applies, pick the one with the lightest sign-off. But a use case a person confirms is quicker to launch than one that affects a coverage decision.

And pick it by the data you can reach this quarter, not the data you'd like to have next year. A first use case that waits on a data programme isn't a first use case.

Measure it against a number the insurer already tracks: claim cycle time, cost per claim, the share of claims handled without rework, or quote turnaround in underwriting. Take the baseline before launch. And count running costs from the first day, because model usage fees rise with volume.

What Does a Regulator Expect From an Insurer Using AI?

A US regulator expects a written AI programme. It needs governance, an inventory of AI systems, risk controls and oversight of third-party models.

The NAIC's model bulletin, adopted in December 2023, calls it an AIS Program. It covers AI used across the insurance lifecycle, from underwriting and pricing to claims and fraud detection. That includes systems the insurer bought as well as built. Regulators may ask to see the documentation during an examination, including an inventory and description of the AI systems in use.

In engineering terms, that means having these ready:

  • A register of every AI system in use, with its purpose and its owner.

  • A written governance framework: who approves a model, who monitors it, and who can switch it off.

  • Testing records that show how often the model is right and where it fails.

  • A human sign-off path for decisions that affect coverage, pricing or claim outcomes.

  • Oversight of third-party models and data, including what you're able to inspect.

  • A way to tell customers when AI is involved.

That list is our translation of the bulletin into engineering work, not a legal checklist. And rules differ by state, so check yours with counsel. This section applies to the US. Other markets have their own regimes.

Some insurers argue that governance slows delivery, and a heavy programme can. But in our experience, a short design-stage review with a human fallback costs days. The same review after launch costs weeks. Keep the evidence coming after launch too. AI observability is how an insurer sees a model's accuracy slip before a regulator or a customer does.

Where Do Generative and Agentic AI Fit in Insurance?

Generative and agentic AI sit on top of the same foundation: they help people work with documents and policy data, but they need the same data access, permissions and sign-off.

Generative AI in insurance is mostly about documents. It summarises a claim file for an adjuster, pulls the relevant clauses from a policy, and drafts a customer letter for a person to review. Outputs vary, and every request has a cost. Accuracy checks and running costs matter more here than they do for software that behaves the same way each time.

Agentic AI in insurance goes a step further. Instead of producing text, it takes actions: requesting a missing document, updating a claim record, scheduling an inspection. And that raises the stakes on permissions. A system that can change a claim record can change it wrongly.

Start both narrow. Give the system the smallest set of actions that does the job, and keep a person approving anything that moves money or changes coverage.

And both fall under the same written programme. A generative assistant and an agent belong in the inventory, with an owner, and under the same human oversight.

Let's Sum Up!

The insurers getting value from AI aren't the ones with the longest use-case list. They're the ones that picked one their data and their regulator could support.

And that's usually claims intake, built on documents the insurer already holds, with a person confirming the output. But the order matters less than the discipline. Choose by data and sign-off, fix the policy system early, and build governance alongside the first use case.

If you're deciding where AI starts at your insurer, Classic Informatics runs enterprise AI transformation services from assessment to production. We're here to help.

FAQS

Frequently Asked Questions