Minimum viable LLM governance for a mid-size insurer

What minimum viable means for a mid-size carrier

Mid-size insurers face the same expectations as larger carriers for LLM use in underwriting, claims, and customer and agent service, with fewer staff and less tooling. Two failure modes follow. One is a governance program so broad that it stalls adoption. The other is a set of policy documents and after-the-fact reviews that cannot show a regulator what an LLM was allowed to do and what it actually did.

A minimum viable baseline avoids both by being small and enforceable. NYDFS Circular Letter 7, adopted on July 11, 2024, expects a corporate governance framework appropriate to the nature, scale and complexity of the insurer. That supports a proportionate program for a mid-size carrier. It is not an exemption. The test is whether each control exists, has an owner, and can be shown to operate.

This guide separates three things. Some decisions are made once, on paper, and reviewed periodically. Some controls must act on every interaction and tool call as it happens. Some records must be kept so that both can be demonstrated later. Keeping those apart makes it clear which controls are essential now and which can wait.

Mapping regulatory expectations to baseline elements

The NAIC, NYDFS and Colorado materials overlap on governance frameworks and documentation, but they are not uniform. The table maps each expectation to a baseline element. Map each LLM use case to the jurisdictions that apply to it rather than assuming one standard.

• Written program: The NAIC AI Model Bulletin expects a written AIS Program covering governance, risk management controls and internal audit. NYDFS expects the insurer's use of AI systems to be formalized in written policies.
• Accountability and reporting: NYDFS assigns oversight to the board or governing body and day-to-day implementation to senior management. NAIC materials ask for the governance structure, board reporting and its frequency.
• Inventory and third parties: NAIC materials ask about the process for acquiring and relying on third-party AI systems and data. NYDFS expects documentation of AI systems relied upon, whether internal or third-party.
• Risk tiering: NYDFS ties the framework to complexity and materiality, and looks at risk across the life cycle, individually and in the aggregate. Tiers and a rolled-up inventory support both.
• Demonstrable oversight: NAIC materials say insurers must show oversight mechanisms are in place and functioning effectively. The NAIC page notes Departments may request information in an examination.
• Colorado SB 24-205: The bill includes a provision treating an insurer as in full compliance if it is subject to specified insurance-specific laws and commissioner rules. Confirm per use case which of those laws apply before building Colorado-specific controls.

What to decide on paper

Four decisions belong in documents, and they should be short enough to keep current.

Accountability comes first. Name a board or committee that oversees LLM risk, and a senior executive responsible for implementation. Reuse an existing risk or model governance structure where possible, since the NAIC draft allows an insurer to rely on existing structures. Set a board reporting cadence. A policy without named owners does not meet the expectation as described.

Next is the inventory. List every LLM use case, internal or vendor-supplied, including LLM features embedded in vendor software. Record the owner, the business function, the model and provider, the data it touches, and whether it makes or supports decisions in a regulated insurance practice. An assistive tool used by an adjuster or underwriter can still support a decision, so do not exclude it by default.

Then assign risk tiers. A simple three-level scheme based on materiality is enough: for example, internal productivity, customer-facing communication, and anything that supports underwriting, claims or pricing decisions. The tier determines review depth, testing, and which runtime policies apply.

Finally, set vendor oversight. For each third-party model or feature, record the contractual commitments, the data shared, and what you will accept as assurance. A vendor attestation describes the vendor's practices. It does not show what happened inside your own interactions.

Two supporting processes complete the paper layer. Document how you test for unfair or unlawful discrimination, in proportion to materiality. Establish how complaints about AI-related decisions are received, handled and recorded.

What to enforce at runtime

The regulatory materials describe outcomes, such as oversight that functions effectively. They do not prescribe specific technical controls. Runtime enforcement is a design choice, and it is the one that makes a written policy demonstrable. A rule that exists only in a document depends on every user and every vendor following it. A rule applied in the execution path is applied to each interaction.

Four actions cover most of the baseline. Allow what the use case and tier permit. Redact personal or sensitive data before it reaches a model or leaves a tool call. Block requests, tools or destinations the policy does not permit. Escalate for human approval when an action is consequential, such as a tool call that changes a claim record or sends a communication to a policyholder.

Access and data-handling controls sit inside these actions. Define which roles can use which LLM use cases, which data classes can be sent to which models, and which tools an agent may call. Apply stricter policy to higher tiers. Enforce at the level of the individual interaction and tool call, because that is the level at which an examiner can ask what happened.

Trussed is one way to do this. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate-for-approval actions. It can be self-managed in the customer's cloud, with configurable retention and data residency. Any approach should be judged on the same question: is the policy enforced at runtime, not reviewed after the fact?

What evidence to retain, and how to judge it

Evidence should show two things for a given interaction or tool call: what the policy permitted, and what occurred. For each, retain the use case and its tier, the policy version in force, the decision taken (allowed, redacted, blocked or escalated), who approved any escalation, and a timestamp. Keep the inventory, tier assignments, board reporting, testing documentation and complaint records alongside it, so each can be retrieved on request by a named owner.

Retention periods and record formats are not specified in the guidance, so set them according to your records obligations and your counsel's advice. Make sure the records are retrievable by use case, since examiners are likely to ask about specific functions rather than the whole program.

To evaluate any approach, ask four questions. Can you pick one interaction and show the policy that applied and the action taken? Does the record come from the enforcement point itself, or is it reconstructed later from application logs? Does the inventory include vendor-embedded LLM features? Can the records be rolled up across use cases to support aggregate risk reporting? If the answer to the first two is no, the program holds documentation but not evidence of operation.

Trussed generates audit-ready evidence from enforcement, mapped to NAIC and NYDFS expectations. The evidence is a product of the policy decision made in the path, so it does not depend on a separate reconstruction exercise.

Must have now versus later maturity

A mid-size insurer can sequence the work. The first column is the baseline needed to support an examination conversation. The second can follow as use expands.

• Now: accountability and written program: Named board and management owners, a short written program, a board reporting cadence. Later: formal internal audit coverage of the full program.
• Now: inventory and tiers: One register of internal and vendor LLM use cases with three risk tiers. Later: automated discovery of unsanctioned use and finer tier criteria.
• Now: vendor oversight: Recorded terms, data shared and assurance accepted for each third-party model. Later: scheduled vendor reassessment tied to tier.
• Now: runtime enforcement on higher tiers: Allow, redact, block and escalate for underwriting, claims and customer-facing uses. Later: extend to all low-tier uses.
• Now: retained evidence: Interaction and tool-call records tied to policy version, retrievable by use case. Later: aggregate dashboards and trend reporting.
• Now: testing and complaints: Documented discrimination-testing approach and a complaint intake and record process. Later: expanded testing cadence for higher-materiality uses.