Budgeting for AI in Underwriting Workflows

Where underwriting AI budgets usually fall short

Most underwriting AI budgets start with what is easiest to quote: model licensing, data integration, and engineering time. Those lines are necessary. They do not answer the question a regulator or examiner will ask, which is what the AI was permitted to do and what it actually did.

Underwriting is a consequential use. The NAIC reports AI in underwriting across property and casualty (renewal evaluations and inspections) and life (shorter issuance times, approval and denial decisions, and risk class assignment). The NAIC also states that insurers using AI remain responsible for complying with insurance laws and consumer protection rules, and that regulators may require insurers to explain how AI is used in underwriting.

When enforcement and evidence are funded late, the usual result is a retrofit. Teams add controls and record-keeping to a workflow that is already live, which means rework, delayed rollouts, and gaps in the history of what the system did before the controls existed. Budgeting for these items at the start is a sequencing decision, not an extra layer of spend.

What the regulatory expectations mean for a budget

The NAIC Model Bulletin expects insurers 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 should address the life cycle, including underwriting. The NAIC also describes the bulletin as telling insurers what information a Department may request during an investigation or examination. Adoption varies by state, so confirm which version applies to each jurisdiction where you write business.

NYDFS Insurance Circular Letter No. 7, issued July 11, 2024, covers AI systems and external consumer data and information sources used in underwriting and pricing. It expects a governance and risk management framework. It also says an insurer should not use such a system for underwriting or pricing unless it can establish that the data source or model does not use and is not based in any way on a protected class under Insurance Law Article 26. Its definition reaches systems used in whole or in part to supplement or act as a proxy for traditional underwriting, so decision-support AI can be in scope, not only fully automated decisions.

Colorado SB 24-205 contains an insurer provision under which an insurer subject to specified insurance laws and commissioner rules is treated as in full compliance with the act. As of October 2026, risk teams should have counsel confirm which regime governs each product line rather than assume an exemption.

None of these texts prescribes a technical design. The budget implications below are practitioner inferences from the expectations: explain AI use, produce documentation on request, and manage risk across the life cycle.

Mapping budget categories to regulatory drivers

Each category below ties to an expectation that an insurer will have to answer for. Use the table to confirm that every driver has a funded owner before the pilot starts.

• Written AIS Program: Driver: NAIC Model Bulletin. Fund policy, ownership, and underwriting scope as an explicit line, not a side task of the build.
• Protected-class evidence: Driver: NYDFS Circular Letter 7. Fund the analysis and records that establish data sources and models are not based on protected classes.
• Runtime policy enforcement: Driver: governance and risk management expectations. Fund enforcement on model and tool interactions in the execution path.
• Human-approval escalation: Driver: consequential decisions. Fund routing, reviewer capacity, and recorded outcomes for actions that need a person.
• Audit-ready evidence: Driver: examination and information requests. Fund generation, storage, and retrieval of records of what the AI was allowed to do and did.
• Retention, residency, deployment: Driver: ability to produce records on request. Fund scoping and verification of where evidence lives and for how long.

Runtime enforcement and human approval as line items

Runtime policy enforcement means rules are applied to model and tool interactions while the workflow runs, not reviewed after the fact. In an underwriting context, that includes which models a workflow may call, which tools and data an agent may reach, what data must be redacted before it leaves the carrier boundary, and which actions must stop for review. The basic outcomes are allow, redact, block, and escalate.

Budget for this in three parts: policy design, enforcement in the path, and ongoing policy change. Policy design requires underwriting, compliance, and security to agree on what each workflow may do. Enforcement requires placing a control in the execution path of each model and tool interaction. Change cost is easy to overlook. When a model, data source, or third-party tool changes, the policy and the validation behind it need to be revisited, so plan a recurring allowance.

Human-approval escalation needs its own funding because it has an operational cost beyond software. Someone must receive the escalated action, have the context to decide, and record the outcome. Size reviewer capacity against expected escalation volume, and tier controls by decision consequence. An agent that influences risk class assignment warrants tighter controls than one that formats an endorsement.

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, with allow, redact, block, rate limit, and escalate for human approval. Its scope is individual interactions and tool calls, which is the level at which many underwriting controls are applied.

Audit evidence, retention, residency, and deployment model

Evidence is the output of enforcement, not a separate reporting project. If each allow, redact, block, and escalation decision is recorded when it happens, the carrier can show what a system was permitted to do and what it did. If evidence is assembled later from application records, gaps are likely, and each examination request becomes a manual effort.

Budget for evidence in four parts: generation, storage, retrieval, and mapping to the frameworks examiners use. Storage deserves attention because volume grows with workflow count and interaction rate. Retrieval matters as much as storage, since a record that cannot be produced in usable form on request does little for the insurer.

Retention periods and data residency should be set by legal and compliance and then verified technically. Both feed the cost of the evidence store, and both depend on state and product obligations that vary by carrier.

Deployment model changes who carries operational effort. Running controls in your own cloud keeps evidence inside your boundary and gives you direct control over retention and residency, but your infrastructure team owns capacity, upgrades, and availability. A vendor-hosted model shifts that effort but raises scoping questions about where evidence is held. Treat these as carrier-specific scoping questions, not fixed numbers.

Trussed generates continuous audit-ready evidence from enforcement, mapped to NAIC and NYDFS, among other frameworks. It supports self-managed deployment in the customer cloud with configurable retention and data residency.

Sequencing funding across pilot, production, and scale

The sequence below is a framework, not a spending split. The principle is that controls and evidence precede each expansion in scope, so each phase starts with the records and enforcement the previous phase proved out.

• Pilot: Fund AIS Program scope for the use case, a limited set of model and tool policies, one human-approval path, and evidence capture from the first interaction.
• Production: Fund enforcement across all live workflows, reviewer capacity, protected-class analysis, retention and residency settings, and examination-ready retrieval.
• Scale: Fund policy change management, re-validation when models or data sources change, third-party dependency coverage, and control tiering by decision consequence.