AI Model Card Template for Insurers: NAIC Bulletin Fields
An AI model card template for insurers should hold one record per AI system, with each field mapped to an element of the NAIC Model Bulletin's AIS Program expectations: governance, risk management and controls, third-party oversight, and inventory and documentation. Classify each field as declarative (an attestation a person maintains) or evidence-backed (populated from records generated when the system runs). The bulletin does not provide a model card format, so this mapping is recommended practice, not a mandate.
What the bulletin expects and what it leaves open
The NAIC Model Bulletin expects authorized insurers to develop, implement and maintain a written program, the AIS Program, for the responsible use of AI Systems that make or support decisions related to regulated insurance practices. The text also advises insurers of the information and documentation a department may request during an investigation or examination. Its section on management and oversight of predictive models lists inventories and descriptions of those models and detailed documentation of their development and use.
Industry commentary describes the program as including a governance framework and documentation of risk management and internal controls. NAIC working group materials also refer to the process for acquiring, using or relying on third-party AI Systems and data.
None of this amounts to a model card schema. Compliance teams therefore have to derive fields from the documentation items the bulletin names. Adoption of the bulletin varies by state, so confirm the status and any variations in each jurisdiction where you write business. Because section numbering differs across adopting states, the mapping in this guide is to bulletin elements, not section numbers. Label it as your own interpretation. The model card is one artifact inside the AIS Program and does not replace the program.
Declarative fields and evidence-backed fields
A declarative field records a fact someone knows and maintains: who owns the system, what it is for, where it came from. These are attestations. They are necessary, and they can be completed in a single review.
An evidence-backed field makes a claim about behavior over time, such as which policy applied or what happened when a request was out of bounds. A person typing that claim into a form proves only that someone wrote it down. The examination risk is the gap between a described control and a record showing the control operated. A model card full of intended controls with no runtime records leaves that gap open.
For each evidence-backed field, state the system of record it is populated from and the date range it covers. That lets an examiner see that the field is current and where to verify it. Fields tied to testing, such as an annual output and drift test description, generally stay manually attested unless a test pipeline produces records.
A field-by-field template
Keep one record per AI system so the bulletin's inventory and description expectations can be met by listing records. Add a column that maps each field to the bulletin element it supports. The groups below are recommended practice.
- Identity, owner and review cadence (declarative): System name, named accountable owner, business unit, review date and cadence. Supports AIS Program governance and the inventory of systems.
- Purpose, intended use and decision context (declarative): What the system does, which regulated insurance practice it makes or supports decisions in, and uses that are out of scope. Supports description and documentation of use.
- Origin, vendor and data dependencies (declarative): Internal or vendor-supplied, vendor name, contract terms covering the bulletin's third-party expectations, and external data sources relied upon. Supports third-party oversight.
- Applicable requirements (declarative): Jurisdictions, the bulletin as adopted in each state, NYDFS Circular Letter 7 where New York business is involved, and other regimes. NIST AI RMF GOVERN 1.1 supports recording these requirements.
- Testing and drift (attested, record-linked where possible): Last testing date, result summary, and a description of testing of outputs, including drift. Supports risk management and controls.
- Controls operated at runtime (evidence-backed): Policy applied, actions taken (allow, redact, block, rate limit, escalate), human escalation outcomes, and data handling, each with system of record and date range. Supports risk management, internal controls and documentation of use.
Keeping evidence-backed fields current
Evidence-backed fields stay current only if the records are produced as the system operates. When policy is enforced in the execution path, each interaction or tool call can yield a record: the policy that applied, the action taken (allow, redact, block, rate limit, or escalate for human approval), the outcome of any escalation, and what data was redacted. The model card field then summarizes those records for a stated period and points to where they are kept.
This changes the exam question. Instead of asking a team to reconstruct what a system did, a compliance lead can produce, for a given system and date range, the controls applied and the actions taken, including human escalations.
There are tradeoffs. Records cover only what passes through the enforcement point, so the field should state its scope. A record of actions does not replace testing, validation or fairness review, which remain separate controls. Retention periods and data residency should be set so the records still exist when an examiner asks.
State and regime adjustments
NYDFS Insurance Circular Letter No. 7, issued July 11, 2024, expects insurers to maintain comprehensive documentation for their use of AI systems, including external consumer data and information sources, whether developed internally or supplied by third parties, and to make it available on request. It lists a description of testing conducted at least annually to assess model outputs, including drift. The final letter also adds a clause drawn from the NAIC bulletin on terms insurers should incorporate into third-party vendor contracts where appropriate. For New York business, add fields showing the documentation covers external data sources used by each system and can be produced on request.
Colorado has changed. As of October 2026, the Colorado Attorney General 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. Any field built on SB 24-205 duties needs review against the new law. Track Colorado in its own jurisdiction field so changes do not disturb the rest of the template.
Where runtime enforcement evidence fits
The declarative half of this template is a documentation exercise any compliance team can run. The evidence-backed half depends on records that exist only if controls act while the AI runs.
Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions that include allow, redact, block, rate limit and escalate for human approval. That enforcement produces audit-ready evidence mapped to NAIC and NYDFS requirements, which can serve as the system of record for the evidence-backed fields above. Enforcement applies to individual interactions and tool calls. It does not populate fields on model lineage or dataset provenance, so those remain outside this template.
Model card field classes
Declarative
Owner, purpose, intended use, origin, third-party dependencies, applicable requirements.
Attested with records where available
Testing and drift results, reviewed on a set cadence.
Evidence-backed
Policy applied, actions taken, human escalations, data handling, with date range and system of record.
Back model card fields with enforcement evidence
See how policy enforced in the execution path produces audit-ready evidence for the fields an examiner is likely to ask about.
See How Evidence Is Produced