NAIC AI model bulletin: what insurance software vendors must give carriers

What does the NAIC AI model bulletin ask of insurers?#

The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers asks insurers to govern their use of AI so that decisions affecting consumers comply with existing insurance laws, including rules on unfair trade practices and unfair discrimination. It is a model: it takes effect in a state when that state's insurance regulator issues it, sometimes with changes.

The core expectation is a written program for AI systems, with governance, risk management and internal controls proportionate to how the insurer uses AI. The bulletin also expects insurers to manage AI systems and data they acquire from third parties, which is where software vendors come in.

Many states have adopted the bulletin in some form, and adoption continues. Rather than relying on a count from any summary, check the insurance department publications for each state where your carrier customers are domiciled or write business.

Why the bulletin reaches vendors through carrier contracts#

The bulletin reaches vendors indirectly because insurers remain responsible for decisions made with third-party tools. A carrier that uses your claims triage model, underwriting rules engine or fraud score cannot tell a regulator it does not know how the tool works; it needs documentation from you, and the contractual right to get more if a regulator asks.

That turns into three kinds of requests: due diligence questionnaires during procurement and renewal, new contract clauses on audit and cooperation, and ongoing reporting when your models change. Vendors that prepare one standard package can answer each carrier from it instead of starting over for every questionnaire.

Documents carriers commonly request#

Carrier requests vary, but the same documents come up again and again. Prepare them once, keep them versioned and share them under NDA.

Training data provenance: the hardest request#

Training data provenance is the hardest request because many insurance software models learned from records supplied by several carriers under contracts that never mentioned AI. A carrier asking where your training data came from is also asking whether competitors' data shaped decisions about its policyholders, and whether its own data trained a model others use.

A provenance register answers that question source by source. The Data & Trust Alliance Data Provenance Standards offer a useful vocabulary: their metadata falls into Source, Provenance and Use groups, and the Use group includes elements such as consent documentation location, license to use, intended data use and privacy-enhancing technologies applied. You can borrow the structure without adopting the standard formally.

• 1For each model: the datasets used, their date ranges and the carrier or other source of each.
• 2The contract clause or consent that permitted the training use.
• 3De-identification applied before training, and who performed it.
• 4Whether any dataset has been withdrawn, and whether the model was retrained afterward.
• 5Third-party or foundation models in the pipeline and their terms on training data.

Contract clauses to expect and how to negotiate them#

Carrier contract clauses tied to the bulletin usually cover audit rights, cooperation with regulators, notice of model changes and limits on data use. Refusing them outright tends to end a procurement; negotiating their scope is normal and expected.

Where to start if a questionnaire is already open#

If a carrier questionnaire is already open, start with the documents that unblock the most questions rather than the longest ones. An honest, partial answer with a dated plan for the rest is easier to defend later than an overstated one.

• 1Write the AI system inventory first, because every other answer refers back to it.
• 2Draft the provenance register for the model this carrier actually uses, not every model you run.
• 3Collect existing test results before commissioning new testing.
• 4Mark answers that depend on counsel's review so the carrier does not treat them as final.
• 5File the questionnaire, your answers and supporting documents together as the start of your standard package.

Illustrative: a claims triage vendor answers a carrier questionnaire#

Illustrative: a fictional vendor sells claims intake and triage software to regional property and casualty carriers. A new carrier customer sends a third-party AI questionnaire asking for a model inventory, training data provenance and testing results, plus a contract addendum with audit and regulator cooperation rights.

Building the provenance register reveals that the triage model was trained on claim notes from several carriers under an old services agreement that allowed the vendor to improve its services. Counsel advises that the clause is too thin to rely on when a carrier asks pointed questions. The vendor retrains the model on records from carriers that sign an explicit training consent, documents the change and narrows the audit clause to documentary review under NDA.

The carrier accepts the package, and the vendor reuses it, updated, for the next questionnaire.

How SourceX approaches carrier-sourced records#

The SourceX Evidence Packet has the same shape as a carrier's provenance request: provenance, licensing rights, permitted use, the privacy record and release authorization. When an insurance software vendor considers licensing records, SourceX applies that structure from the first step.

In the SourceX five-step transaction, the Rights step separates carrier-owned and policyholder data from the vendor's own records, such as support conversations, engineering issues and product decisions. Carrier data generally stays out unless the carrier has approved the use, and Preparation removes policyholder and claimant details from everything that remains.