Discover how AI in insurance transforms underwriting, claims, and fraud detection. Explore real case studies and a step-by-step implementation playbook.
October 19, 2026

AI adoption in insurance is broad. Governance maturity is not. In NAIC survey testimony, 92% of U.S. health insurers reported that they currently used, planned to use, or were exploring AI and machine learning, yet nearly one-third reportedly did not regularly test their models for bias or discrimination, according to NAIC testimony on AI and insurance.
That gap reframes the question a CIO should be asking. The issue is no longer where AI can automate work. It is which decisions an insurer can defend, monitor, and explain once a model enters production.
The useful distinction runs across three stages: adoption, deployment, and governance maturity. Exploring a use case is not running a model in a live workflow, and operating a model is not proof that its outcomes are tested or that customers can challenge them. The figures that follow map those differences by line of business, function, and the controls surrounding each decision.
AI adoption varies sharply by insurance line. In EIOPA's 2023 survey, 50% of responding European insurers used AI in non-life insurance, compared with 24% in life insurance; an additional 30% expected to adopt it in non-life and 39% in life within the following three years, according to EIOPA's digitalisation survey. In U.S. NAIC surveys, 88% of private-passenger auto insurers, 70% of homeowners insurers, 58% of life insurers, and 92% of health insurers said they currently used, planned to use, or were exploring AI/ML, based on NAIC's AI overview.
Treat those percentages as market signals, not readiness scores. They come from different surveys, markets, and definitions of adoption, and they fold explorers, pilot teams, and production operators into the same headline number. A CIO still has to determine whether a specific model is an experiment, a live workflow component, or a decision service with testing, monitoring, and challenge rights attached.

Start with the line of business. Health, auto, homeowners, and life differ in data sensitivity, decision frequency, loss severity, and the harm caused by a wrong output. Then locate the function: extracting fields from a submission carries different risk than ranking fraud alerts, recommending a price, or declining coverage. Finally, test governance maturity: who validates the model before release, who watches drift and adverse impact after release, who can override it, and what evidence survives an examination.
The thin part of most adoption stories sits in that third layer. Earlier insurance systems often handled narrower operational tasks with structured data, human review, and more explainable methods, which made control ownership easier to see. Current models can affect pricing, eligibility, claims handling, and customer communication at once, so the evidence a CIO needs extends beyond accuracy into bias testing, exception review, customer recourse, and vendor oversight.
That is also how to read vendor claims and case studies. Ask whether the reported result came from a controlled test, a limited deployment, or sustained production use, and whether the savings survived audit, appeal, and complaint handling. Applied's AI use-case library documents implementations across insurance and adjacent financial services, which teams can use as a comparison set while separating demonstrated outcomes from governance assertions.
Seventy percent of U.S. private-passenger auto insurers reported AI/ML use in claims operations in the NAIC's 2022–2023 survey, while reported use in loss prevention sat at 2%. That spread is the argument for a workflow map: adoption concentrates in particular stages of the value chain, and the stages where it concentrates share a common shape.
The chain runs from product design through distribution, underwriting, pricing, policy administration, claims, and fraud review, with customer service and back-office work cutting across all of it. Each stage hands AI a different job: extracting fields from a submission, ranking alerts, drafting a reply, recommending a risk tier.

The first distinction to make is between assistive AI and delegated AI. An assistive system ranks claims for review, extracts information from a submission, drafts a response, or recommends a risk tier. A delegated system makes or executes a consequential decision, such as denying a claim, setting a price, or changing eligibility. Validation, audit records, human escalation, and customer recourse matter more as a system moves toward delegated authority.
The claims concentration is no accident. Marketing and fraud detection also ranked among the most reported uses, according to the survey findings summarized by Eversheds Sutherland. These workflows generate recurring cases that can be scored, ranked, and checked against outcomes, and a human still confirms the disposition. That is an assistive pattern, and it is the easiest pattern to govern.
Underwriting and pricing sit differently. A score that informs an underwriter and a score that automatically changes an offer are separate operational commitments, because the second changes what a customer pays or whether they are covered at all. Teams evaluating external property signals for risk assessment can use property evidence with BatchData as a reference point for how supplementary data enters the workflow and how it should be validated before release.
The survey counts adoption, not control quality. It records which insurers use AI in a function; it does not record which of them test that function for adverse impact or document customer recourse. Those are separate measurements, and this survey captures only the first.
Practical rule: Classify a use case by what it can do to a customer. The technology label on the vendor slide is the wrong axis.
Across insurance functions, adoption figures measure reported use or intent, while performance benchmarks measure specific results in defined settings. The distinction matters: a high adoption rate does not establish that a model improves accuracy, reduces costs, or performs safely in production.
| Function | Representative outcome | Typical tooling pattern |
|---|---|---|
| Underwriting | U.S. life insurers' reported current, planned, or exploratory AI/ML adoption was 58%. | Risk classification and document extraction to assist underwriters, with human review for consequential decisions. |
| Claims | A published benchmark found 84% recall within the highest-scored 20% of claims reviewed in a health-insurance fraud-triage setting. | Ranking, document extraction, and case routing integrated into adjuster workflows. |
| Fraud detection | XGBoost reached 84% recall when investigators reviewed the 20% of claims with the highest scores, 4.2 times the positive-rate baseline. | Supervised scoring to prioritize investigations, with investigator confirmation. |
| Pricing | U.S. health insurers' reported current, planned, or exploratory AI/ML adoption was 92% across the surveyed line, not pricing specifically. | Model-assisted risk and rate analysis, with documented testing before customer-impacting use. |
| Customer service | U.S. auto insurers' reported current, planned, or exploratory AI/ML adoption was 88% across the line, not service specifically. | Agent assistance for information retrieval, summarization, and response drafting. |
| Operations | EIOPA found AI use more prevalent in non-life than life insurance, 50% versus 24% among responding European insurers. | Document intake, workflow routing, and administrative assistance, measured against a defined operational baseline. |
The fraud benchmark connects model performance to investigation capacity. In a published study using real health-insurance claims data, XGBoost achieved 84% recall among the 20% of claims with the highest fraud scores. The authors reported a 4.2-fold improvement over the positive-rate baseline in their health-insurance fraud-detection benchmark. That result supports prioritizing cases for review. Investigators still need to confirm suspected fraud before action.
For underwriting, the adoption figure does not measure decision accuracy or processing speed. A CIO should test whether a model reduces information-gathering effort and track underwriter overrides, evidence quality, and outcomes for complex cases.
Claims performance depends on the authority granted to a system. Document extraction and queueing are different from approving or denying a payment. For fraud detection, recall at a fixed review volume shows how well a model focuses limited investigator time. Confirmation rates matter alongside the number of alerts.
For pricing, compare model recommendations with existing rules and test whether differences produce unjustified customer impacts. In customer service, agent-assist tools can retrieve policy information or draft replies, but line-wide adoption figures do not establish their effectiveness. Operations also calls for task-level measurement: document handling and routing can be assessed against a baseline, while exception handling needs a named owner.
The case-study section below examines a specific quotation workflow from Icatu Seguros. Any reported result should be read in its operating context, including the baseline and whether the workflow was a pilot or in production.
A case study is useful when it identifies the insurer, workflow, tools, and measured result. Those details help CIOs distinguish a production deployment from a pilot and a local process improvement from an enterprise-wide gain.

Consider two different workflows. Icatu Seguros' broker-facing quotation and product-information case uses WhatsApp. Its reported quotation-time reduction should be assessed against the original process and the scope of deployment. Decision-makers should also establish how the assistant handles incomplete requests, whether it provides recommendations or binding quotes, and how staff correct errors.
Emirates Insurance's claims-processing deployment using Snowflake AI provides a different operational comparison. The reported processing reduction and hours automated need context: which steps run without human intervention, which decisions remain under staff control, and whether the result covers a defined workflow or a broader operation.
Applied presents these cases through the organization, situation, tools, and reported outcome. That structure supports comparison, but it does not establish that results will transfer to another insurer. Adoption evidence also says little about governance maturity. A deployment description may not show whether the insurer tested for bias, set boundaries for customer-facing decisions, or assessed the third-party provider's controls.
The video below walks through how insurers present AI outcomes and what questions to ask when assessing the claims.
Before treating a case study as investment evidence, ask four questions: who used the system, what data informed it, what governance applied, and how was the result measured? Then establish whether the outcome came from a pilot, a controlled rollout, or sustained production. Without comparable baselines and governance details, a reported efficiency gain is not enough to support a scale decision.
A sound AI program advances when evidence answers a decision question, not when a project has accumulated a large dashboard. The steering committee should agree on what would justify proceeding, pausing, or ending a pilot before the team selects a model.

Start with a specific workflow and an accountable owner. Define the current process, the decision the system will support, and the customer or employee who bears the consequence of an error. If teams can't agree on the decision or baseline, the problem isn't ready for model selection.
Check whether the data represents the cases the system will encounter in production. For claims, examine missing fields, inconsistent labels, and how investigations are recorded. For underwriting, check whether historical decisions reflect a stable process or a changing set of rules. Useful decision signals include data completeness, label quality, and whether the team can trace inputs back to their source.
Run the model in shadow mode or alongside existing decision-making. Compare its recommendations with the current workflow without allowing it to act on customers. For an adjuster-assistance pilot, track override rates and the reasons for overrides; for fraud triage, measure recall at a fixed investigation volume and verify outcomes after investigation.
Advance only when the model's errors are visible, explainable to the people using it, and manageable within the workflow.
A controlled rollout should define eligible cases, escalation routes, and who can pause the system. Compare cycle time against a suitable control group, but pair efficiency measures with customer outcomes and error review. A faster process isn't a successful deployment if it shifts the burden onto customers or creates unreviewed exceptions.
In production, monitor drift, changes in input quality, override patterns, and outcome differences across relevant groups. Where protected-class data isn't available or appropriate to use, compliance and data-science teams should agree on lawful proxy-based testing and document its limits. Set thresholds locally, based on the line of business and decision risk; no universal cut-off can substitute for an insurer's own validation.
Build-versus-buy decisions depend on the workflow, the insurer's technical capacity, and its ability to oversee the resulting system. According to the NAIC's 2022–2023 private-passenger auto insurer survey, cited earlier in this article, respondents reported 2,531 AI/ML models. Approximately 60% were developed internally, while 40% came from more than 70 third-party vendors. That split makes vendor oversight a routine operating responsibility.
| Evaluation criterion | Build internally | Buy or integrate a vendor |
|---|---|---|
| Data residency | The insurer has greater control over architecture and access, subject to internal capability. | Require documented data locations, access rules, and contractual safeguards. |
| Interpretability | Internal teams can tailor review and documentation to insurer requirements. | Test the specific model and decision; product descriptions alone do not establish interpretability. |
| Integration cost | The insurer owns engineering and ongoing maintenance. | Estimate integration effort, data mapping, and dependencies on core systems. |
| Vendor lock-in | The insurer has more control over code and deployment options. | Review portability, exit terms, and continued access to outputs and records. |
| Latency | Teams can tune performance to internal workflows and infrastructure. | Test response times under actual operating conditions. |
| Audit evidence | Internal teams maintain the evidence trail. | Contract for access to model documentation, performance evidence, and change records. |
Claims OCR, contact-center assistance, and fraud scoring may suit vendor products when specialized capabilities or faster deployment are priorities. Pricing, underwriting, and eligibility decisions may call for an internal build or a governed hybrid when the insurer needs direct control over model logic, data lineage, and validation. These are starting points, not rules; the decision should reflect the model's role and the authority it exercises.
A structured AI implementation consulting guide can help teams assign implementation responsibilities and assess integration needs. The insurer remains responsible for its scorecard, technical testing, legal review, and documented approval.
The NAIC adopted its Model Bulletin on the Use of Artificial Intelligence Systems by Insurers on December 4, 2023. Its scope covers product development and design, marketing, underwriting, rating and pricing, case management, claim administration and payment, and fraud detection, as set out in the NAIC adoption announcement. The bulletin is not a model law or regulation. It gives state regulators a shared framework for supervising AI-supported insurer decisions.
Adoption is ahead of governance maturity. NAIC survey data indicates broad current or planned AI use across health, auto, homeowners, and life insurance. Yet nearly one-third of surveyed health insurers reportedly did not regularly test models for bias or discrimination, as noted in the NAIC testimony cited in this article's introduction. That gap matters: deploying AI does not establish consistent, auditable controls over its effects.
Insurers should maintain a written AI Systems program proportionate to risk, with validation, monitoring, and internal controls for systems that affect consumers. That includes documenting model purpose and data lineage, testing for errors and unfair discrimination, monitoring for drift, retaining decision records, and ensuring vendor-produced scores can be examined. Existing insurance obligations apply whether an algorithm supports a decision or produces one.
Customer comfort varies with the action. Polling summarized in an NAIC journal article found comfort at 39% for AI tracking claim status, 22% for AI filing a claim on a customer's behalf, and 16% for AI cancelling or renewing a policy, according to the NAIC journal coverage of insurance AI and customer trust. Customers appear more comfortable with help accessing information than with automated actions that can affect claims or coverage.
Insurers should distinguish systems that assist customers from those that recommend or trigger decisions. For high-impact decisions, define when a human must review or escalate an outcome, and retain records that let compliance teams reconstruct how it was reached. The AI risk management framework discussion offers a point of comparison for tailoring controls to each insurance function and regulatory context.
Applied catalogs AI implementations by company, workflow, tools, and measured outcome, with examples organized across industries and business functions. Insurers can compare use cases with adjacent applications by creating an account or subscribing to access the library, tools, and outcome filters on Applied.