LLM Governance RFP for Insurance Carriers

Why most LLM governance RFPs cannot be compared

Many carrier RFPs for LLM governance tooling are written around policy documents, model inventories and pre-deployment reviews. Those are necessary, but they describe intent. They do not say what must be enforced while an interaction is happening, or what record must exist afterward. Vendors from different categories then answer the same questionnaire with different products in mind, and procurement, risk, security and compliance cannot score the responses consistently.

The regulatory context points toward operation, not only documentation. The NAIC AI Model Bulletin, adopted in December 2023, reminds insurers that decisions or actions made or supported by AI must comply with all applicable insurance laws and regulations. It also advises insurers of the type of information a state insurance department may request in an investigation or examination. NYDFS Insurance Circular Letter No. 7 (July 11, 2024) states that insurers remain responsible for understanding tools developed or deployed by third-party vendors for underwriting and pricing. Colorado SB 24-205 lists disclosure duties for high-risk systems, including disclosure to the attorney general within 90 days of discovering that algorithmic discrimination has occurred. NIST AI RMF 1.0 adds that risk management should be continuous and performed throughout the AI system lifecycle. Regulatory status is stated as of October 2026.

Taken together, an RFP should ask whether the vendor can show what the AI was permitted to do and what it did. Vendor attestation alone does not meet that test, because the carrier keeps responsibility for vendor-provided AI.

Define scope before you write requirements

Start by listing what the requirement covers. For LLM use, that usually means models, agents, the tools those agents call, MCP servers, and coding assistants used by engineering teams. Name each in the RFP. A vendor that covers chat prompts but not tool calls or coding assistants is answering a narrower question, and the scoring should show that.

Then tie scope to insurance functions: underwriting, rating and pricing, claims administration and payment, and fraud detection. Ask vendors to state which of these they support and at what unit of control. Be explicit about the unit. Enforcement on individual interactions and tool calls is a different requirement from governance of a business transaction spanning several agents. If you need the second, write it as a separate requirement and score it separately.

Finally, require third-party documentation that supports your own compliance assessment: purpose, data sources, methodology, validation, monitoring approach and change history. Given NYDFS expectations on vendor oversight, this documentation is part of how you demonstrate understanding of the tool, so request it as a deliverable rather than a courtesy.

Separate runtime control from adjacent categories

Responses become comparable once each requirement is tagged by the category that can satisfy it. The categories below overlap in marketing language but answer different questions. A vendor can legitimately be strong in one and absent in another. The RFP should let it say so.

• Runtime policy enforcement: Sits in the execution path and acts on each interaction or tool call. Ask what it can allow, redact, block, rate limit or escalate, and what record each decision produces.
• Observability: Shows what happened, typically after the fact. Ask whether it can change an outcome before a response or tool call completes.
• Pre-deployment testing: Evaluates a model or application before release. Ask what continues to operate once traffic is live.
• Gateway or proxy: Routes and brokers traffic. Ask whether policy decisions are enforced per interaction and whether decision records are retained.
• GRC workflow: Manages policies, inventories, reviews and attestations. Ask whether any control acts on live AI activity or only tracks it.

Specify audit evidence as artifacts, format and exportability

Regulators and internal auditors need to see what the AI was allowed to do and what it did. The RFP should ask for the records that answer both halves. NAIC working group discussion frames the difference as documentary governance, which is policy, versus operational governance, which answers with evidence. Build the evidence section on that distinction.

Specify completeness, not just existence. Ask whether a record is produced for every enforced interaction or only a sample, and whether records show policy version, action, timestamp, requesting identity and the tool or model involved. Specify format and exportability in contract terms: machine-readable export, delivery to the carrier's own storage, and the ability to produce records for a defined examination request without vendor involvement. Ask vendors to map their evidence to the NAIC AI Model Bulletin, NYDFS Circular Letter 7 and, where applicable to your role, Colorado SB 24-205. Request a sample export and a mapping document with the response, and have internal audit review them before shortlisting.

For Colorado notification clauses, the carrier's role as developer or deployer affects what the contract needs to say, so settle that with counsel before drafting.

• Sample evidence export for a scripted proof-of-concept session
• Record schema listing every field captured per enforced action
• Mapping of evidence to NAIC, NYDFS and Colorado expectations
• Description of how records are protected against alteration
• Procedure for producing records for an examination request
• Documentation of purpose, data sources, methodology, validation, monitoring and change history

Set deployment, residency and retention as carrier decisions

None of the regulatory texts above prescribe a hosting model, a residency location or a retention period for this evidence. These are carrier choices, driven by your security architecture, data classification and records policy. State them as requirements and let vendors respond against them, rather than accepting whatever their default offers.

On deployment, ask whether the solution can run self-managed in your cloud account, what data leaves your boundary, and which components are vendor-hosted. On residency, ask where prompts, responses and evidence records are stored and processed, and whether location is configurable. On retention, require configurable periods by record type, with legal hold support and deletion procedures you can verify. Tradeoffs are real: self-managed deployment increases your operational responsibility, while vendor-hosted options reduce it but widen the third-party footprint. The RFP should surface that tradeoff in the response and the pricing structure, not leave it for contract negotiation.

One boundary check is useful. Ask which party holds the evidence at the end of the contract, and in what form it is returned.

Score runtime control separately, and place Trussed accurately

Use a weighted model with two scoring tracks. The first track covers runtime control: in-path enforcement, coverage across models, agents, tools, MCP servers and coding assistants, action completeness, and proof-of-concept results. The second covers evidence: completeness, format, export, mapping and retention. Score adjacent capabilities such as observability, testing and workflow in a separate, lower-weighted section so a strong dashboard cannot offset missing enforcement. Require a proof-of-concept artifact for every point awarded above a baseline, and give no credit for assertions.

Trussed fits the runtime track and the evidence track. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalate for human approval on individual interactions and tool calls. It generates audit-ready evidence mapped to NAIC, NYDFS, HIPAA, EU AI Act and NIST, supports self-managed deployment in the customer cloud, and offers configurable retention and data residency. It is not a GRC, observability or pre-deployment testing product, and an RFP should score it accordingly. Your requirements should be written so any vendor can be measured against them the same way.