What an AI Governance Framework Actually Looks Like for an Insurer

Lay the NIST AI Risk Management Framework’s four-function diagram next to the NAIC Model Bulletin, and the word “governance” changes size. In NIST’s framework, governance is one of four functions, “designed to be a cross-cutting function to inform and be infused throughout the other three functions.”¹ In the bulletin, “a governance framework for the oversight of AI Systems” is one component of a written AIS Program, listed after the general guidelines and ahead of risk management, internal controls, and third-party systems.² Read against the bulletin, an AI governance framework in the generic sense a diagram uses corresponds to the whole AIS Program, and the bulletin’s governance section is one part of it. That is our reading of the two texts, and the mapping below rests on it.

For a state-regulated insurer, the difference decides which box on the diagram answers which request. Section 4 of the bulletin begins one sentence with “Regardless of the existence or scope of a written AIS Program,” and says insurers should expect the resulting inquiries to include “the Insurer’s governance framework, risk management, and internal controls.”² The first item on its documentation list is “The written AIS Program.” None of the requests is phrased as Govern, Map, Measure, or Manage. What follows maps the generic framework onto what an insurer’s file actually holds: the parts of the AIS Program, the Section 4 request list, and the four exhibits of the NAIC’s draft evaluation tool. The regulatory map around those documents belongs to the AI governance in insurance hub.

Where NIST and ISO enter the bulletin

The bridge between the voluntary frameworks and an insurer’s regulatory file is a single guideline. Guideline 1.5 says the AIS Program “may be independent of or part of the Insurer’s existing Enterprise Risk Management (ERM) program.” The next sentence says it “may adopt, incorporate, or rely upon, in whole or in part, a framework or standards developed by an official third-party standard organization, such as the National Institute of Standards and Technology (NIST) Artificial Intelligence Risk Management Framework, Version 1.0.”² NIST’s is the only outside framework the bulletin names.

On our reading, the wording makes reliance optional (“may”) and divisible (“in whole or in part”), and it runs one way: the program adopts or relies on the framework, so a department still receives the insurer’s own program. Section 4 asks for it, including “Information and documentation relating to or evidencing the adoption of the AIS Program.”²

Neither outside framework is an insurance requirement. NIST says its AI RMF “is intended for voluntary use,”³ and the framework document says it is intended to be “voluntary, rights-preserving, non-sector-specific, and use-case agnostic.”¹ The bulletin does not mention ISO/IEC 42001 at all. ISO’s catalogue records that standard as published on December 18, 2023,⁴ two weeks after the NAIC adopted the bulletin. The “such as” in guideline 1.5 leaves the list open, and the bulletin recognizes that insurers may demonstrate compliance “through alternative means,”² so the text does not rule out an ISO-based program. Where a state has issued the bulletin, the bulletin is the regulatory expectation, and the state tracker records which states have issued it and in what form.

The bulletin also gives the governance part of an AI framework a second insurance reader. Its legislative-authority list carries a placeholder for the state law corresponding to the Corporate Governance Annual Disclosure Model Act (#305).² It says that law and its companion regulation “apply to elements of the Insurer’s corporate governance framework that address the Insurer’s use of AI Systems to support actions and decisions that impact consumers.”² For an insurer that files that disclosure, the governance row has a place in the filing too.

NIST AI RMF vs ISO 42001 for an insurer

For an insurer, NIST AI RMF vs ISO 42001 is mostly a choice of shape, because the bulletin expects a written program and leaves the choice of outside framework to the insurer. NIST’s AI RMF is a free, voluntary catalogue of outcomes in four functions, GOVERN, MAP, MEASURE, and MANAGE, each broken into categories and subcategories whose actions “do not constitute a checklist, nor are they necessarily an ordered set of steps.”¹ ISO/IEC 42001 is a paid international standard for a management system. ISO’s page says it “specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS),” and describes implementing it as putting policies and procedures in place “using the Plan-Do-Check-Act methodology.”⁴

As we read them, NIST supplies a vocabulary of outcomes that can be laid against what the bulletin asks a program to address, and ISO supplies the machinery around a program. A crosswalk listed on NIST’s AI Resource Center quotes clause titles such as “Determining the scope of the AI management system,” “Leadership and commitment,” “Internal audit programme,” and “Nonconformity and corrective action.”⁵ Those titles line up, in our reading, with the bulletin’s guideline that the AIS Program “should address governance, risk management controls, and internal audit functions.”² NIST’s listing names Microsoft as the crosswalk’s provider, and the document maps RMF subcategories to the ISO/IEC FDIS 42001 text, the final draft before publication, rather than to the published edition.⁵⁶ The listing adds that inclusion “does not imply NIST endorsement of the resource the AI RMF is mapped to, nor does it imply that either resource comprehensively covers the contents of the other.”⁶ This article describes ISO/IEC 42001 only from ISO’s public page and the titles and labels quoted in that crosswalk; the standard’s text is sold by ISO and is not quoted here.

Neither framework, as its publisher describes it, supplies an insurance definition of harm. NIST states that the AI RMF “does not prescribe risk tolerance” and notes that “Some sectors or industries may have established definitions of harm or established documentation, reporting, and disclosure requirements.”¹ ISO’s page describes ISO/IEC 42001 as applicable across all industries and says that “Rather than looking at the details of specific AI applications, it provides a practical way of managing AI-related risks and opportunities across an organization.”⁴ For a state-regulated insurer, the bulletin supplies the definition and a list of what a department may request. It defines an Adverse Consumer Outcome as an insurer’s decision, subject to regulatory standards that the Department enforces, whose adverse impact on the consumer violates those standards, and it scales controls to the “Degree of Potential Harm to Consumers.”² In the mapping below, that definition occupies the slot NIST reserves for organizational risk tolerance, MAP 1.5.

The AI governance framework, cell by cell

The table follows nine groups of NIST AI RMF outcomes into the bulletin’s program guidelines (Section 3), its request list (Section 4), and the draft evaluation tool.¹²⁷ Row labels come from NIST, cell contents from the NAIC documents, and the pairings are InsureAI Wire’s analysis; neither NIST nor the NAIC publishes this crosswalk. Exhibit references are to version 4.0 of the tool, and every page of that version is marked DRAFT.

The inventory row shows that a framework element and an evaluation exhibit are different objects: the inventory is the bulletin’s guideline 3.3(a), while Exhibit A asks for counts and use cases by operational area.²⁷ The consumer row shows a gap running the other way. Guideline 1.9 makes notice to impacted consumers part of the program, and the tool asks about complaints and consumer awareness, yet none of the numbered items in Section 4 names consumer notices.²⁷ Section 4 does say inquiries include “the considerations identified in Section 3,”² so the question can still be asked, and a framework copied from the numbered items alone would have no row for it.

A program built on ISO/IEC 42001 would face the same rows, because they come from the NAIC documents; only the reference labels in the first column would change. Which function prepares and signs the evidence in each cell is a separate question, taken up in the AI governance roles guide.

Exhibits A to D read the framework back

The NAIC’s evaluation tool describes itself as “Optional Supplemental Exhibits for State Regulators” and says it is “designed to supplement” the market conduct, financial analysis, and financial examination procedures regulators already use to review AI Systems.⁷ What an insurer builds is the framework each exhibit reads from.

When Exhibit A asks for its counts, it treats models “that augment or automate decision making related to consumers” as having direct consumer impact.⁷ The counting criterion comes with the tool. What the insurer needs in order to answer Exhibit A is a model-by-model record that applies that criterion, and the counts are read off that record. Exhibit B’s checklist asks the company to “Reference the processes and procedures of the Company AI Governance Framework.”⁷ Before its questions, Exhibit B’s narrative form states that they “are not intended to be interpreted as creating new requirements for AI Systems Governance Risk Assessments.”⁷ The tool, in other words, calls what it is reading a governance framework and asks where it is written down. Exhibit C covers high-risk systems, and “AI System risk criteria are set by the insurance company.”⁷ Exhibit D asks which data elements went into developing AI models and whether each came from an internal source or a named third party.⁷

On our reading, the four exhibits are the framework’s evidence surface rather than a second system to build. The decisions under their questions are the ones in the table, and when those decisions are already on paper, answering an exhibit is a matter of retrieval. The tool also expects to be used selectively. It suggests that regulators “may wish to first use Exhibit A and based on the information provided, determine if further inquiry is necessary.”⁷

The newer draft points the same way. In the version 5.0 exposure draft, which has not been adopted, Exhibit B is retitled “AIS Program (Two Options: Narrative or Checklist).”⁸ Exhibit A in that draft adds a request for the model inventory itself, and a company that already keeps one may suggest submitting it in place of completing Exhibit A.⁸ The evaluation tool explainer tracks where that draft stands.

This article stops at what the framework looks like. How to implement it so that it can answer Exhibit B, element by element and with a self-audit worksheet, is the subject of the Exhibit B implementation guide.

The third-party cell reaches every layer

The bulletin returns to third parties in six separate places. They are the definition of “Third Party,” the fifth proportionality factor in Section 3, guideline 1.8, the three considerations under guideline 4.0, item 1.2 of the Section 4 request list, and the separate third-party AI request list, items 2.1 to 2.4, at the end of Section 4.² The fifth factor is “the extent and scope of the insurer’s use or reliance on data, Predictive Models, and AI Systems from third parties.” Guideline 1.8 covers AI Systems “whether developed by the Insurer or a third-party vendor.”

NIST builds the same row from its side. GOVERN 6 reads “Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues,” and MAP 4 and MANAGE 3 carry third-party risk into mapping and management.¹ The framework’s position is that “all parties and AI actors should manage risk in the AI systems they develop, deploy, or use as standalone or integrated components.”¹ In the crosswalk on NIST’s resource center, both GOVERN 6 subcategories map to FDIS items labeled “Allocating responsibilities” (B.10.2) and “Suppliers” (B.10.3).⁵ NIST’s Generative AI Profile adds a risk it calls “Value Chain and Component Integration,” which includes “improper supplier vetting across the AI lifecycle.”⁹

In the tool, the row surfaces in Exhibit B’s vendor and service-provider questions, Exhibit C’s item on third-party development, and Exhibit D’s vendor column.⁷ A framework that treats vendors only as a procurement matter can still supply those names. The harder part is the record behind them. The Section 4 third-party list asks for due diligence “conducted on third parties and their data, models, or AI Systems” (2.1), vendor contracts and their terms on “data sourcing” (2.2), and documentation of “validation, testing, and auditing” (2.4).² Guideline 4.0 frames the insurer’s third-party process in hedged terms, wording that the AI vendor risk assessment reads closely before building its vendor questions.

An AI governance framework example for one claims model

What follows is illustrative. The insurer, the model, and the vendor are invented to show how one system occupies the rows of the table, and nothing here describes a real company or an actual regulatory request.

A regional property insurer licenses a vendor model that reads photographs submitted with homeowners claims and suggests a damage estimate and a fast-track flag. An adjuster sees both and makes the decision.

The model enters the insurer’s framework as an inventory entry recording what it does, the vendor, and the claims operation it supports, which is GOVERN 1.6 in NIST’s terms and guideline 3.3(a) in the bulletin’s. Because it suggests an answer to an adjuster who is deciding a consumer’s claim, it augments that decision, and the tool’s Exhibit A instructions count augmenting models as having direct consumer impact.⁷ In Exhibit A the model is one unit in the Claims/Adjudication row’s counts.

Its risk tier comes from the insurer’s own criteria, which weigh, among other things, three of the bulletin’s five factors: the decision concerns a claim, a person makes the final call, and the model comes from a third party. Suppose those criteria put it in the high tier. If a regulator then sends Exhibit C, its thirteen items in version 4.0 reach this model, including whether it was developed internally or by a third party, with the vendor’s name (item 4). They also cover its AI type, here “augment” (item 7), and how it was validated before deployment and is monitored now (item 8).⁷ If the vendor trained the model on its own image library, the “Image/video Analysis” row of Exhibit D names that vendor as the third-party source. Exhibit B’s vendor question depends on which form is used: the checklist asks where the insurer’s standard for procuring AI vendors is written (item 3l), the narrative how vendor-supplied systems are validated and tested (item 3b).⁷

The version the bulletin names is being revised

Guideline 1.5 does not cite the AI RMF in general. It cites “Version 1.0.”² NIST’s page now says that “The AI RMF 1.0 is being revised as part of the White House AI Action Plan,”³ and the framework document said that “a review with formal input from the AI community is expected to take place no later than 2028.”¹ NIST’s page does not say what the revision will change or when it will be published. The NAIC side is also unsettled: version 4.0 of the evaluation tool is an optional draft, version 5.0 has been circulated for comment without adoption, and adoption of the bulletin itself varies by state.

Those moving parts favor one structural choice. It is our recommendation; the bulletin does not address how a framework map is organized. Key the framework map to the bulletin’s section numbers, the vocabulary in which a department’s requests are written, and carry the tool’s exhibit items, NIST subcategories, and any ISO/IEC 42001 clauses as reference columns beside them. When the revised RMF is published or the tool moves to a new version, those columns are what get updated, and the rows an examiner reads stay where they were.