NAIC AI Bulletin and Subrogation and Recovery AI: Scope, Controls and Evidence

What the bulletin says, and what it leaves open

The NAIC adopted the Model Bulletin on the Use of Artificial Intelligence Systems by Insurers on December 4, 2023. It expects insurers to maintain a written program, the AIS Program, for the responsible use of AI Systems that make, or support decisions related to regulated insurance practices. The adopted text says the program should address governance, risk management controls and internal audit functions.

The draft text defines an AI System as a machine-based system that, for a given set of objectives, generates outputs such as predictions, recommendations, content or other output influencing decisions. Recovery scoring, file prioritization, liability assessment and demand drafting each produce outputs of that kind. The definition is therefore unlikely to be the deciding factor. The deciding question is whether the output makes or supports a decision related to a regulated insurance practice.

The bulletin says the AIS Program should cover the insurance life cycle, including areas such as product development and design, marketing, use, underwriting, rating and pricing, case management, claim administration and payment, and fraud detection. Subrogation and recovery are not named in that list. Claims coverage rests on the claim administration and payment language, so applying it to recovery is an inference. It should be recorded as one.

The bulletin also defines an adverse consumer outcome as a decision by an insurer that is subject to insurance regulatory standards enforced by the Department that adversely impacts the consumer in a manner that violates those standards. Recovery AI often affects consumers indirectly, for example through an insured's deductible or through communications with third parties. That indirect effect is the part of the analysis most likely to need legal judgment.

Scoping by function, not by the label subrogation

The bulletin's scope language follows decisions made or supported by AI Systems. A function-level review is therefore more reliable than a product-level or department-level one. The table gives a starting presumption for each function. These are the author's inferences, and each carrier should confirm them against its own workflows and its legal analysis.

• Recovery opportunity identification: Often uncertain. If flagging a file changes how the claim is handled or paid, treat it as supporting a claim decision. If it only creates a back-office referral, document why it is out of scope.
• Liability assessment: Likely in scope. The output supports a determination about fault that can bear on claim administration and on the insured's position.
• File prioritization: Uncertain. Scope depends on whether prioritization affects handling timelines or outcomes for consumers.
• Demand drafting: Likely in scope when drafts reach third parties or consumers. Record where human review sits before anything is sent.
• Recovery potential scoring: Uncertain to likely. A score that drives reserve, settlement or pursuit decisions supports a decision. A score used only for reporting may not.

Which expectations apply if a function is in scope

An in-scope recovery function belongs inside the AIS Program, with its governance, risk management controls and internal audit coverage documented like any other claims AI. The bulletin describes a risk-based approach. Controls and processes should reflect and be commensurate with the insurer's own assessment of the degree and nature of risk to consumers, including the nature of the decisions being made, informed or supported by the AI System. That puts the burden on the carrier. A control set for liability assessment should trace back to a written risk assessment for that function, and a lower-risk function can carry lighter controls if the reasoning is documented.

The adopted text also references documentation of techniques, measurements, thresholds and similar controls. A carrier should be able to show what limits were set for each recovery function and how they were applied.

Vendor-supplied and embedded AI belongs in the same inventory. Many recovery workflows use third-party tools, and a vendor model that scores files or drafts demands should be recorded in the AIS Program with its scope determination, the usage records the carrier can obtain, and a named internal owner. Because the carrier's own governance applies regardless of who built the model, the control and evidence plan should not depend only on vendor assurances.

Over-scoping and under-scoping both carry risk. Leaving in-scope recovery AI outside the program is a gap. Applying controls that do not match how the system actually runs produces documentation that cannot be evidenced.

State adoption changes the analysis

The model bulletin becomes enforceable only through state action, and states issue their own versions. As of August 2025, 24 states had adopted the model. Alaska was first, on February 1, 2024, and Wisconsin was the most recent at that time, on March 18, 2025. The NAIC implementation map reflects state action or pending action and makes no determination about whether a state's action is consistent with the model.

Two practical consequences follow. First, status changes, so the adoption position as of October 2026 should be confirmed for each state where the carrier is licensed. Second, a state bulletin may differ from the model in wording, scope or emphasis. The scoping memo should cite the specific state text for each licensed state. Where a state has not adopted a bulletin, the model remains a reference point but is not binding on its own.

The scoping memo should also keep what the bulletin states separate from what is inferred and from what a state department has interpreted. A conclusion that recovery scoring is in scope should be labeled as the carrier's judgment, with the reasoning attached.

Runtime controls and the evidence they produce

Policy documents describe intent. An examiner will also want to see what the system was permitted to do and what it did. For recovery AI that means controls that act where the AI runs, and records generated by those controls.

Four enforcement outcomes cover most recovery cases. Allow routine requests within policy. Redact personal or claim-sensitive data before it reaches a model or leaves the carrier. Block actions outside policy, such as a tool call to an unapproved system. Escalate for human approval where a draft demand or a liability conclusion is about to leave the carrier. Each outcome produces a record. Together the records show the permitted behavior, the actual behavior and who approved exceptions. This mapping to the bulletin's documentation and control expectations is an inference, since the bulletin does not prescribe runtime techniques.

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 outcomes. Enforcement runs at runtime, not as a review after the fact, and generates audit-ready evidence mapped to NAIC and other frameworks. The scope is individual interactions and tool calls. Reconstructing a full recovery file from those records depends on the carrier's own file identifiers and case systems. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.