What Insurtech Vendors Must Prove to Carriers Under the NAIC AI Bulletin

What the bulletin asks of carriers about third-party AI

The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers was adopted on December 4, 2023. It reminds insurers that decisions or actions affecting consumers, whether made or supported by AI systems, must comply with all applicable insurance laws and regulations. That holds when the AI system or its data comes from a vendor.

Section 4.0 says each carrier's AIS Program should address how it acquires, uses or relies on third-party data to develop AI systems, and AI systems developed by a third party. Three further provisions matter to vendors. Section 4.1 covers due diligence: the methods the carrier uses to assess the third party and its data or AI systems, so that decisions that could lead to adverse consumer outcomes meet the legal standards imposed on the carrier itself. Section 4.2 refers to contract terms with third parties where appropriate and available, including a term requiring cooperation with the carrier on regulatory inquiries and investigations related to its use of the vendor's product or services. Section 4.3 covers audits and/or other activities to confirm the third party's compliance with contractual and, where applicable, regulatory requirements.

If an examination involves data, predictive models or AI systems developed in whole or in part by third parties, the carrier should expect the Department to ask for more information. That includes the due diligence performed on third parties, contracts with third-party AI, model or data vendors, and audits or confirmation processes performed on third-party compliance.

Two cautions apply. The NAIC states that the bulletin does not prescribe specific practices or specific documentation requirements, so the checklist in this guide describes expected practice and is not a mandate. And as of October 2026, state adoption varies in form, so each state's own bulletin or regulation should be checked. This guide is educational and is not legal advice.

Vendor evidence matrix

The matrix works backward from each third-party hook to the proof an examiner could ask a carrier to produce. The vendor's job is to make that proof available to the carrier.

• Due diligence (4.1): Vendor must demonstrate: how its data and AI system were assessed for the carrier's use case. Acceptable evidence: data source, provenance, lineage and quality records, bias analysis, and validation and testing results. Common gap: a generic questionnaire answer not tied to the carrier's use.
• Contract terms (4.2): Vendor must demonstrate: willingness to accept terms where appropriate and available. Acceptable evidence: executed terms on data security, data sourcing, confidentiality and disclosures. Common gap: terms that restate policy but create no evidence obligation.
• Regulatory cooperation (4.2): Vendor must demonstrate: it can support the carrier in an inquiry or investigation. Acceptable evidence: a contractual cooperation duty and a defined process for producing records. Common gap: no named owner or turnaround for regulator requests.
• Audits and confirmation (4.3): Vendor must demonstrate: the carrier can confirm compliance with contract and regulatory requirements. Acceptable evidence: audit or confirmation records, with access to the underlying data. Common gap: audit language that allows only a summary report.
• Validation, testing and drift: Vendor must demonstrate: ongoing oversight, not a one-time test. Acceptable evidence: validation and testing documentation, model drift evaluation, and the techniques, measurements and thresholds used. Common gap: pre-launch results with no monitoring history.
• Production behavior (interpretation): An examiner asking what a system did implies records tied to the carrier's AI inventory entry. The bulletin does not prescribe this. Acceptable evidence: time-stamped records of permitted actions and actual interactions. Common gap: no record beyond application logs.

Asserted documentation versus verifiable evidence

Most vendor submissions today are assertions: policies, security questionnaires, model cards and attestations. These are legitimate and the bulletin's documentation categories include them. But they describe intended behavior. They do not show that a control operated on a given day for a given carrier.

A useful test is to ask who or what produced the record. A policy document is produced by the vendor's staff. A record that shows a request was allowed, redacted or blocked under a named rule was produced by a control operating at the time. The second kind can be sampled by a carrier, checked against the contract, and handed to a Department. The first kind usually has to be taken on trust.

The bulletin's references to monitoring, oversight and auditing leave room for both, and carriers will still need both. The difference is weight. When a Department asks what a vendor's AI was permitted to do and what it actually did, a written policy answers the first half only. Carrier procurement and vendor-risk teams can reduce renewal friction by asking for each claim to be paired with the record that would prove it.

Where runtime enforcement fits

One way to meet the evidence burden is to enforce policy in the execution path of the AI system and keep the records that enforcement generates. This is editorial interpretation. The bulletin does not specify runtime enforcement or log formats, and it does not require any particular architecture.

The design logic is straightforward. If every model call and tool call passes through a policy layer, the layer can allow, redact or block the interaction, rate limit it, or escalate it for human approval. Each decision is recorded as it happens. The vendor can then show the carrier the rules that applied and the record of what occurred, instead of reconstructing behavior after the fact. Scope matters: this evidences individual interactions and tool calls, and it does not by itself cover model lineage or dataset provenance, which a carrier would still ask the vendor to document separately.

Trussed provides this kind of enforcement for regulated enterprises. It enforces policy at runtime, not after review, and generates continuous audit-ready evidence mapped to the NAIC bulletin and other regimes. It can be self-managed in the customer's cloud, with configurable retention and data residency. It has run in continuous production in a regulated enterprise for more than 18 months, with customers in insurance, pharma, healthcare and education. A vendor, or a carrier running vendor AI, can evaluate this approach alongside others against the matrix above.