How to Explain AI Spend Variance to the Board

Variance explanation is an evidence problem

Most finance teams can state the gap between budgeted and actual AI spend. Fewer can say what caused it. Model provider invoices, cloud platform bills, and vendor charges are aggregates. They rarely record which interaction, agent, or tool call generated the usage, or whether that usage was sanctioned.

The board's question is therefore two questions. First, why did spend move? Second, was the activity behind it inside approved limits? A budgeting exercise answers the first only in aggregate and cannot answer the second. Treating variance as an evidence problem means every explained dollar should map to a record that someone else can inspect later.

For an insurer the second question carries regulatory weight. NAIC states that state insurance regulators oversee insurers' use of AI and may require explanations of how AI tools are used in underwriting, pricing, marketing, or claims decisions. Spend that can be mapped to those business functions is easier to defend than a single consolidated figure.

Decompose variance into five drivers

A consistent driver taxonomy keeps variance classification repeatable from one period to the next. The five drivers below cover most budget-to-actual movement, and each needs its own attributable records. The taxonomy is a working framework to agree with technology and risk before the next budget cycle, not a standard.

The distinction that matters most to the board is between sanctioned growth and out-of-policy activity. Higher volume in an approved use case is a planning miss. Usage outside the approved-use-case register is a control question. Reported as one number, the two look identical.

• Usage volume: More interactions in approved use cases. Attribute with request counts by application and business function.
• Model mix: Traffic shifting between models with different unit prices. Attribute with model identifiers on each interaction.
• New use cases: Applications that were not in the budget baseline. Attribute by comparing usage to the approved-use-case register.
• Agent and tool-call activity: Spend generated by agents invoking tools and downstream calls. Attribute with agent and tool identifiers on each tool call.
• Out-of-policy or unapproved usage: Activity outside approved boundaries. Attribute with policy-decision records and the register of approved boundaries.

What finance needs from technology and risk

Finance cannot build this attribution alone. Two recurring extracts do most of the work. Technology provides a usage extract that ties volume to application, agent, tool, and model. Risk provides a policy-decision extract showing counts of allow, redact, block, rate limit, and escalation outcomes against the policies that produced them.

The extracts need a stable join key to billing data, such as model, application, or team identifiers, so that records reconcile to provider and cloud invoices each period. Any remainder that cannot be attributed should be reported as its own line rather than netted into an aggregate. A disclosed unattributed share is more credible to an audit committee than a variance explained to the last dollar by assumption.

Finance should also own, or co-own, the approved-use-case and approved-boundary register. It is the baseline against which sanctioned and unsanctioned usage are separated, and without it the out-of-policy driver cannot be measured.

Structure the board narrative around limits and evidence

A board-ready variance narrative follows a fixed order: budget, actual, and variance by driver; then the policy decisions that bounded usage; then a pointer to the retained evidence behind each figure. Keep the narrative to the drivers that moved. Each driver statement should name the records that support it.

NYDFS Insurance Circular Letter No. 7, dated July 11, 2024, says an insurer's board, its committees, or senior management through delegated authority should review and approve AI-related policies and procedures at least annually. It also notes that internal audit under 11 NYCRR § 89.16 may assess whether reporting to the board is sufficient to evaluate whether management is operating within the insurer's risk appetite and limits for model risk. NAIC approved its AI Model Bulletin on June 11, 2024. Colorado SB 24-205, titled Consumer Protections for Artificial Intelligence, is also on many insurers' regulatory lists.

These texts address AI use and board oversight. Applying them to spend variance is a management practice, not a stated requirement. Positioning variance reporting alongside the annual policy review, and agreeing with internal audit which evidence is reproducible, keeps the finance narrative consistent with how oversight is already structured.

Where runtime enforcement evidence fits

Evidence generated after the fact has to be reconstructed from logs, tickets, and recollection. Evidence generated by an enforcement point in the execution path is recorded when the decision is made. That distinction matters to finance because a policy decision attached to an interaction or tool call is what separates an allowed, in-boundary request from a blocked, rate-limited, or escalated one.

For reconciliation, each enforcement record should carry at least the policy applied, the decision taken (allow, redact, block, rate limit, or escalate for human approval), a timestamp, and the interaction or tool-call context. With those fields, finance can count usage by decision, compare it to approved boundaries, and show the board what was permitted and what was stopped. The field set is a design recommendation for finance requirements, not a regulatory prescription.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites, and coding assistants, with decisions enforced at runtime, not reviewed after the fact. Its scope is individual interactions and tool calls. It generates continuous audit-ready evidence from enforcement, mapped to NAIC, NYDFS, and NIST, among other frameworks. It does not provide transaction-level governance, model lineage, or end-to-end tracing of agentic workflows, so those questions need other sources.