AI Cost per Policy Issued or Renewed: How Insurers Define and Attribute It

Define the metric before you compute it

Cost per policy issued is total attributable AI cost over a reporting period divided by the number of policies that reached a defined outcome in that period. The renewal version uses the same structure with a different denominator. Blending new business and renewal into one figure hides the fact that the workflows, human review patterns and tool usage usually differ.

Treat this as a measurement-design problem, not a savings claim. A figure is only useful if two lines of business, or two workflows, can be compared on the same terms. That requires four decisions written down and held constant: which cost components are in scope, what counts as a policy, where the workflow starts and ends, and how a usage record is tied to a policy. Changing any one of them changes the number without changing the underlying cost.

Choose the numerator: direct cost and allocated cost

A practical numerator has five components: model inference, retrieval, tool and API calls, human review, and exception handling or rework. Inference, retrieval and tool calls are metered per request, so they can be recorded directly at the interaction level. Human review and rework are usually measured in time, which must be converted using a stated rate before it can be added to metered spend.

Shared costs, such as platform operation or model evaluation, do not belong to any single policy. Decide whether they are allocated across policies or reported separately. We recommend reporting two figures: a directly metered cost per policy and a fully loaded cost per policy. The gap between them shows how much of the number depends on allocation rather than measurement.

Rework deserves its own line. A retried tool call, a failed extraction that a person corrects, or a policy sent back to intake all consume cost without changing the denominator. Excluding them makes straight-through workflows look cheaper than they are.

Choose the denominator: what counts as a policy

The denominator is where most distortion enters. Each choice below is defensible, but only if it is stated and applied consistently across the lines of business being compared.

• New business issued: Counts policies that completed issuance. Keeps renewal cost out of the figure.
• Renewals processed: Counts renewal transactions separately, since renewal evaluation often follows a different path than new business intake.
• Bound versus quoted: A quoted count includes cost spent on submissions that never bind. Bound counts understate the effort behind each policy. Report both or state which is used.
• Straight-through versus human-assisted: Segment the count so human review cost is visible and the straight-through rate can be read alongside the cost.
• Line of business: Report per line, with the policy definition for each, before producing a blended carrier-wide figure.

Attribution methods and where they break down

Attribution links each usage record to a policy transaction. The cleanest approach is direct keying: the carrier's workflow or policy administration system passes its own policy or submission identifier into each AI interaction, and every interaction and tool-call record carries it. Where that is not possible, teams fall back on time-window correlation, matching records to a transaction by user, session and timing. The weakest approach is proportional allocation, where a step's total cost is spread evenly across the policies it touched.

All three degrade when a workflow spans multiple tasks, agents or systems. One retrieval result may serve several steps. A background agent may act on a batch of submissions. Retries and fallbacks create records that map to a step but not clearly to a policy. In these cases attribution requires approximation, and the honest response is to report it as such: state what share of cost was keyed directly and what share was allocated, and document the allocation rule.

The usage records themselves are interaction-level and tool-call-level. Assembling them into a per-policy view across tasks and agents is a join the carrier performs using its own transaction identifiers. It should not be assumed that the join is exact.

Regulatory context and the evidence the metric depends on

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. Its text refers to the measurements, standards or thresholds an insurer adopts in developing, validating and overseeing models and AI Systems. NYDFS Insurance Circular Letter No. 7, issued July 11, 2024, sets out the Department's expectations for how authorized insurers develop and manage their use of ECDIS, AIS and other predictive models in underwriting and pricing policies and annuity contracts. Whether it reaches a given issuance or renewal workflow depends on how AI is used in that workflow.

Colorado has changed. As of October 2026, the provisions of SB 24-205 have been repealed and reenacted by SB 26-189, signed in May 2026, with new requirements for automated decision-making technology in consequential decisions. Summaries of the earlier bill should not be treated as current law, and data capture and retention design should be set against the current Colorado duties.

None of these regimes asks for a cost-per-policy figure. Their focus is governance and oversight of AI in regulated decisions. The practical consequence is that cost data touching those decisions should sit within the written program's documentation, and cost reporting should be kept separate from decision-evidence reporting.

Trussed enforces policy in the execution path on individual interactions and tool calls (allow, redact, block, rate limit, escalate for human approval) and produces audit-ready evidence mapped to NAIC and NYDFS expectations. That evidence records what each interaction was permitted to do and did, and it can serve as a defensible input to the metric. It is not a substitute for the carrier's policy-level join. Deployment is self-managed in the customer cloud, with configurable retention and data residency.