Technical Guide | Insurance Claims AI

    AI Cost per Claim at an Insurance Carrier: How to Calculate It

    AI cost per claim is the attributed AI cost for a defined claim population in a period, divided by the number of claims in a stated denominator for the same population and period. The figure is only comparable when the cost boundary, the denominator and the attribution method are written down. The numerator should itemize inference, tool and retrieval calls, human review, rework and exceptions, runtime policy enforcement and audit evidence retention. Attribution to a whole claim depends on the carrier's own claim identifiers and data joins.

    What belongs in the numerator

      Treat cost per claim as a measurement-design problem

      Carriers now use AI across claims intake, triage, document review, coverage analysis and fraud screening. Each of these tasks generates its own model calls, tool calls and human touchpoints, and the spend lands in different systems and budgets. A single per-claim number built from whichever data is easiest to reach will be incomplete, and it will not compare across claim types or lines of business.

      The working formula is simple: AI cost per claim equals attributed AI cost for a claim population and period, divided by the count of claims in the chosen denominator for that same population and period. The difficulty sits in three definitions: what counts as cost, what counts as a claim, and how cost is tied to a claim. The method in this guide is author guidance for measurement design. It is not a published standard, and it makes no claim about savings. Its purpose is a figure that a finance team, a claims leader and a risk function can all read the same way.

      Choosing the denominator

      Three denominators are common, and each answers a different question. Claims touched by AI measures cost where AI actually ran. It suits workflow-level analysis, but it excludes claims the AI never saw, so it cannot be read as a portfolio figure. Claims closed measures cost against completed work. It aligns with how many carriers report claims operations, but it lags, because a claim can accrue AI cost for months before closing and a reopened claim can accrue more after. Claims by segment, such as line of business, claim type or complexity band, keeps simple and complex claims from being averaged together.

      A practical approach is to report claims touched as the primary denominator for workflow analysis, claims closed for period reconciliation, and always break both out by segment. Whichever you choose, apply it consistently across lines, and state it beside every figure. Cost classification conventions elsewhere in insurance, such as the way health loss-ratio rules treat claims adjustment and cost containment expenses as non-claims costs, show why an explicit boundary matters. They are not an AI cost standard, and they do not tell you where AI cost should sit.

      Attribution limits when a claim spans many interactions

      One claim rarely maps to one model call. A single claim can trigger document review, a coverage analysis, a fraud screen, several retrieval calls and one or more human escalations, potentially across different models and teams. Usage data typically exists at the level of the individual call. Claim-level cost exists only if each of those records carries a claim identifier, or can be joined to one.

      That join is the carrier's own design choice. It depends on identifiers the carrier already controls, such as the claim number, the claimant or policy reference, and the workflow task ID, and on a decision about who owns the join across systems. Several limits follow. Calls made before a claim number exists, such as at intake, need a provisional key that is later reconciled. Shared calls, such as a batch job that serves many claims, need an allocation rule. Human review time is often recorded in a different system from model usage, so its link to a claim may be coarser. Where the join is weak, report the unattributed share explicitly rather than spreading it silently across claims.

      Trussed enforces policy at the level of individual interactions and tool calls, and does not provide transaction-level identity across tasks and agents. Rolling those records up to a claim relies on the carrier's identifiers.

      Where regulatory evidence enters the cost base

      For regulated claims workflows, evidence is a recurring cost, not a one-time documentation exercise. The NAIC AI Model Bulletin expects insurers authorized in a state to develop, implement and maintain a written AIS Program for the responsible use of AI systems that make or support decisions related to regulated insurance practices. The program is expected to address AI use across the insurance life cycle, including claim administration and payment and fraud detection. Because it covers systems that support decisions as well as those that make them, inventory and record-keeping should include both. The model document does not settle which states have adopted it, so applicability is a state-by-state question for each carrier.

      NYDFS Insurance Circular Letter No. 7, issued July 11, 2024, is titled Use of AI Systems in Insurance Underwriting. It defines AI systems by reference to underwriting or pricing for health, life, property or casualty. Do not assume its obligations extend to claims workflows, and segment your cost model by line and by use so that this distinction stays visible.

      Colorado changed course. As of October 2026, the Colorado Attorney General reports that Senate Bill 26-189, signed in May 2026, repeals and reenacts the earlier SB 24-205 provisions with new requirements for automated decision-making technology in consequential decisions. SB 24-205 obligations should not be used as the basis for current cost assumptions.

      Where a carrier enforces policy in the execution path, the enforcement itself and the evidence it produces become cost lines. Trussed enforces policy across models, agents, tools and MCP servers: allow, redact, block, rate limit, or escalate for human approval. It produces audit-ready evidence for interactions and tool calls, mapped to NAIC and NYDFS, and can be deployed in the customer's cloud with configurable retention and data residency. Retention settings drive storage cost, and escalations for human approval add reviewer time to the human-in-the-loop line.

      A minimal starting sequence

      Begin with one workflow and one line of business before generalizing. The aim is a figure whose boundaries you can defend, which matters more than breadth.

      • Write the cost boundary: list each numerator component and mark it included or excluded.
      • Choose the primary denominator and the segments, and apply them to every line.
      • Name the claim identifier carried in every model call, tool call, review and escalation record, and assign an owner for the join.
      • Set allocation keys for shared and fixed costs, and a reporting rule for unattributed spend.
      • Add the evidence and enforcement lines for each claim use within the scope of your state and line obligations.
      • Review the definitions on a fixed schedule and when regulations change, so periods stay comparable.

      Per-claim AI cost: the three design decisions

      Numerator

      Itemized cost components inside a stated boundary.

      Denominator

      Claims touched, claims closed or claims by segment.

      Attribution

      Claim identifiers carried across calls, tools and reviews.

      Evidence

      Regulatory records treated as a recurring cost line.

      Put enforcement and evidence on the cost map

      See how policy enforcement in the execution path produces audit-ready evidence for interactions and tool calls in regulated claims workflows.

      See How Evidence Is Produced
      Next step

      How does your AI governance program compare?

      See where your program has gaps in less than 2 minutes.