Why Insurance Is a Harder AI Target Than It Looks

Insurance companies sit on some of the richest data in any industry. Policy histories, loss runs, adjuster notes, medical records, weather overlays, court filings. On paper it is a perfect environment for AI agents. In practice, carriers are finding the gap between a promising demo and a production deployment is wider here than almost anywhere else.

The reasons are not mysterious. Insurance decisions carry financial and legal consequences that most enterprise software does not. State insurance commissioners regulate how decisions get made, not just what data gets used. The technology stack at most carriers is a layered archaeological dig: a core policy admin system from the 1990s, a claims platform built in the 2000s, a data warehouse that was modern in 2015, and a dozen integration layers holding it together with aging middleware. You cannot point an LLM at that and call it production.

That said, the carriers that have done the hard integration work are seeing real returns. The question for a CTO or Head of AI is not whether AI agents work in insurance. It is which workflows justify the investment, how to sequence them, and what deployment actually requires that the vendor pitch deck left out.

Three Workflows Where AI Agents Deliver

Claims Triage and First Notice of Loss

The first 24 to 48 hours of a claim are the most expensive to handle poorly. An adjuster reviewing a new loss has to collect facts, cross-reference policy coverage, flag potential fraud indicators, and decide whether to assign the file to a specialist or route it to a fast-track settlement path. That process is repetitive, data-intensive, and bottlenecked by adjuster availability.

AI agents have produced measurable results here. A well-built claims triage agent can ingest the FNOL data, pull the relevant policy, check coverage applicability, cross-reference the claimant against fraud databases, and surface a recommended routing decision with supporting evidence, all before a human adjuster touches the file. McKinsey estimates AI-enabled claims processes can reduce handling time by 30 to 40 percent on straightforward property claims, with the largest gains on intake and documentation.

The design decisions that matter most: the agent needs deterministic guardrails on coverage interpretation, because an agent that hallucinates a coverage determination creates liability exposure, not efficiency. Human review stays in the loop for coverage denials and any claim above a defined dollar threshold. The output is a recommendation with supporting evidence, not a decision. That framing matters both for regulatory defensibility and for adjuster trust.

Underwriting Intake and Preliminary Risk Assessment

Commercial lines underwriting starts with a submission: a broker sends over an application, supplemental questionnaires, loss runs, financial statements, and sometimes hundreds of pages of supporting documents. A junior underwriter's first job is to read all of it, extract the relevant data points, and populate an underwriting workbench. For a mid-market commercial account, it is not unusual for a carrier to spend four to six hours on intake before a senior underwriter has looked at the actual risk.

AI agents built for underwriting intake handle document extraction, data normalization, and preliminary risk scoring. The agent reads the submission, extracts structured data from unstructured documents, flags missing information, compares the risk profile against the carrier's appetite guidelines, and produces a prioritized queue for the underwriting team. On routine submissions that clearly fall within or outside appetite, this can cut intake time by 70 to 80 percent.

AI in insurance underwriting is not a new concept, but the shift from simple rule-based scoring to LLM-powered document understanding is real and recent. The challenge is that carrier appetite is proprietary, nuanced, and changes frequently. Any agent in this workflow needs to be trained on and regularly updated against the carrier's actual guidelines, not generic insurance knowledge. Off-the-shelf solutions struggle here because the intelligence has to be specific to how that carrier thinks about risk, not how some average insurer does.

Policy Administration and Endorsement Processing

Policy changes, endorsements, and cancellations are high-volume, low-complexity operations that consume a disproportionate share of policy operations headcount. A commercial lines policyholder adds a vehicle to a fleet. A homeowner adds a scheduled personal property item. A business changes its address. Each change requires pulling the policy, interpreting the request, calculating premium impact, generating the endorsement, and sending confirmation. For a carrier processing thousands of these a month, the labor cost compounds fast.

AI agents with access to the policy admin system, a rating engine, and document generation tools can handle straight-through processing for a large percentage of these requests. The agent interprets the endorsement request from email, portal, or phone transcript, validates it against policy terms, calculates the premium change, generates the endorsement document, and triggers issuance. Human review is reserved for exceptions: complex endorsements, requests that trigger underwriting judgment, or changes that affect coverage in ways the agent is not authorized to decide.

Straight-through processing rates of 60 to 75 percent on endorsement workflows are achievable with a well-scoped agent. The remaining 25 to 40 percent that requires human judgment still flows through, but the agent has done the data prep, so handling time is lower even on exceptions.

What Makes Insurance Deployments Hard

Regulatory Exposure Is Specific and Consequential

When you deploy an AI agent in insurance, you are often deploying into a regulated decision process. State insurance commissioners have started scrutinizing AI-driven decisions in underwriting and claims under existing unfair discrimination statutes, even before any new AI-specific regulations pass. The NAIC's 2023 model bulletin on AI systems calls on carriers to ensure AI systems are accurate, reliable, and non-discriminatory, and that humans remain accountable for decisions.

What this means practically: any agent that touches coverage, pricing, or claims disposition needs a documented audit trail. You need to be able to show a regulator what the agent considered, what it recommended, and who made the final call. Several state commissioners have started requesting this documentation in market conduct examinations. Building audit logging as an afterthought, after the agent is in production, is significantly harder and more expensive than building it in from the start.

Unlike banking, where you are dealing primarily with federal regulators like the OCC or CFPB, insurance regulation is state-by-state. A carrier operating across multiple states needs to track which state's rules govern each transaction and ensure the agent behaves accordingly. That state-specific compliance logic has to be built into the system architecture, not added later.

The Data Layer Problem

Most insurance AI projects hit a wall not because the AI is bad but because the data feeding it is fragmented, inconsistently formatted, and held in systems not designed to expose data programmatically. A claims agent needs to read from the claims system, the policy system, the fraud database, and possibly the customer communication history. If those systems expose clean APIs, the integration is tractable. If they do not, which is the case at most carriers of a certain vintage, you are building a data extraction and normalization layer before you can build the agent.

Teams that have gone through this describe it as the most time-consuming part of the project by a wide margin. The agent itself is often the easier problem. Getting clean, reliable, real-time data flowing from legacy systems into the agent's context is what takes months and requires people who understand both the AI architecture and the specific system internals. This is consistently underestimated in initial project scoping.

Adjuster and Underwriter Adoption

Insurance professionals, particularly experienced adjusters and underwriters, are skeptical of systems that give them an answer without showing their work. This is not irrational. A 30-year adjuster who has seen AI projects come and go has earned their skepticism. The teams that have achieved strong adoption designed agents that show their reasoning explicitly: here are the coverage provisions that apply, here is how the loss facts map to each one, here is what comparable claims in this territory have settled for, here is the recommended path and why.

That design pattern serves a dual purpose. It builds trust with professionals faster, and it generates the documentation trail that regulators want to see. The output is not just a recommendation. It is a documented analytical process that a human reviews and approves. This is architecturally different from an AI that simply outputs an answer, and it is the version that actually gets adopted.

Build vs. Buy in Insurance AI

The insurance AI vendor market has gotten crowded fast. There are now point solutions for claims, underwriting, policy ops, and customer service, each promising rapid deployment and pre-trained models. Some are genuinely good products for certain carriers. The limitations, though, are predictable.

Packaged solutions work well when the workflow is standard and the data infrastructure is reasonably modern. They struggle when the carrier has proprietary appetite guidelines, legacy integration requirements, or workflows that diverge from what the vendor assumed when building the product. They also come with data sharing arrangements that security and privacy teams scrutinize carefully: where does the policyholder data go, who can train on it, what are the retention terms after you leave.

Custom-built agents take longer to deploy but can be shaped around the carrier's actual workflows, integrated with their specific systems, and kept entirely within their data environment. The right choice depends on how standard your workflows are and how much competitive advantage lives in proprietary processes you do not want encoded into a shared vendor model.

A few questions worth pressing any vendor on: Does the model get trained on your data or pooled across customers? Can the agent's decision logic be audited by your compliance team, or is it a black box? How does the vendor handle state-specific regulatory changes? What is the total cost after the implementation fee, including ongoing model maintenance and retraining when your appetite guidelines change?

Where to Start

The carriers seeing the most traction are not attempting comprehensive AI transformations. They picked one workflow, defined success metrics before writing a line of code, and built the data pipeline first. Claims triage is often the best entry point because the workflow is bounded, the success metrics are clear (time-to-first-contact, routing accuracy, adjuster hours per file), and the regulatory exposure is manageable with proper human-in-the-loop design.

Once that first workflow is running and the data infrastructure exists, the second and third use cases move faster. The integration work does not start from scratch. Trust with business stakeholders is already built. The compliance framework is documented. McKinsey's Insurance 2030 analysis consistently finds that phased, workflow-specific deployments outperform big-bang transformation programs on both ROI and time to value.

The companies hitting their timelines in insurance are the ones who treated the data layer and governance architecture as the real project, not a prerequisite to it. The agent is the visible output. What makes it work in production is everything built underneath it.

If you are working through where to start or evaluating whether a custom build makes more sense than a packaged solution for your specific environment, the Genta team is glad to compare notes. We build and deploy production agentic systems for regulated industries and can usually identify where a project plan is going to run into trouble before it does.