AI Governance Platforms for Insurers: Mapping Tool Layers to NAIC, NYDFS and Colorado Requirements

Why one label covers five different jobs

Carriers and brokerages deploying AI agents that call tools and touch policyholder data face overlapping expectations from the NAIC AI Model Bulletin, NYDFS Circular Letter 7 and Colorado law. Vendors respond with products that all carry the phrase AI governance, yet they solve different problems. A model inventory and a runtime policy engine share almost no functionality.

The useful question is not which platform is best. It is which layer produces the evidence a given expectation requires, and whether that evidence is specific enough for the question a regulator is likely to ask. For agents, that question is often granular: what was this agent permitted to do in this interaction, and what did it do?

What each layer can and cannot demonstrate

The table summarizes the evidence each category typically produces. Individual products vary, so treat it as a starting frame for vendor questions rather than a statement about any specific product.

• Inventory and risk assessment: Shows which AI systems exist, who owns them and how they are rated. NIST describes an inventory as an organized database of artifacts relating to an AI system or model. It is recordkeeping and does not describe runtime behavior.
• Pre-deployment testing: Shows test results for bias, performance and robustness. It maps to the NYDFS expectation of discrimination testing before production, on a regular cadence and after material changes. It reflects behavior under test conditions, not each live interaction.
• Observability: Captures traces, outputs and metrics for monitoring and investigation. Review happens after execution. Its evidentiary value depends on what is captured and how long it is retained.
• GRC workflow: Documents the governance framework, policies, approvals, attestations and board reporting. It supports governance and oversight expectations but does not itself constrain what an agent does.
• Runtime enforcement: Applies policy to each interaction and tool call before it completes, and records the decision. It shows what was allowed, altered or stopped. It does not replace testing or governance documentation.

What the regimes ask of insurers

The NAIC AI Model Bulletin reminds insurers that decisions or actions made or supported by AI must comply with all applicable insurance laws and regulations. It sets expectations for how insurers govern AI use and describes the information a department may request in an investigation or examination. That framing makes producible documentation a design requirement, not an afterthought.

NYDFS Circular Letter 7, issued July 11, 2024 and focused on underwriting, says unfair or unlawful discrimination testing and analysis should occur before AI systems enter production, on a regular cadence afterward, and whenever material changes are made to the AI system or the external consumer data and information sources it uses. It also ties to 11 NYCRR § 90.2, under which an insurer should have a corporate governance framework appropriate to its nature, scale and complexity, with oversight of its use of these systems. The board or governing body is expected to oversee the framework and monitor risk appetite.

Colorado has changed. A Colorado Attorney General page states that SB 26-189, signed in May 2026, repeals and reenacts the SB 24-205 provisions with new requirements for automated decision-making technology in consequential decisions. As of October 2026, insurers should read earlier guidance on SB 24-205 as superseded and track SB 26-189 and the Attorney General's anti-discrimination rulemaking for current duties.

None of these texts prescribes where a control must sit. They ask for governance, testing and information about controls. Mapping a tool to a requirement is therefore a judgment about which evidence it can supply.

Where agents change the risk picture

An agent that reads policyholder records, calls internal tools and acts on the results behaves differently from a model that returns a score. In underwriting, claims and distribution workflows, the main risks are exposure of personal data in prompts or tool arguments, tool actions outside the agent's intended authority, and outcomes that could amount to unfair discrimination.

Testing addresses the third risk well and the first two only partially, because tool behavior in production depends on live inputs. Observability can reveal a problem after it occurs. Inventory and GRC tools establish who is accountable. Preventing an unauthorized tool call, or redacting personal data before it leaves a boundary, requires a control that acts while the interaction is in progress. That is the gap runtime enforcement is designed to fill.

Where runtime policy enforcement fits, and where Trussed does not

Trussed is a runtime control product. It enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval. Policy is enforced at runtime, not reviewed after the fact, at the scope of individual interactions and tool calls. That enforcement generates audit-ready evidence mapped to NAIC and NYDFS requirements, and it can be deployed self-managed in the customer's cloud with configurable retention and data residency.

Trussed is not an inventory, a testing or red-teaming product, an observability tool or a GRC platform, and it does not replace them. Inventory tells you what exists, testing tells you how a system behaved under evaluation, and GRC tooling holds the governance framework and board reporting. Trussed adds the record of what an agent was allowed to do and what it did in production. Customers span four regulated verticals, including insurance.

A practical sequence is to keep or select inventory, testing and GRC tooling for the expectations they address, then add runtime enforcement where agents touch policyholder data or invoke tools. Confirm the evidence it produces answers the questions your examiners are likely to ask.