NAIC AI Model Bulletin vs. FCRA: How the Two Regimes Apply to External Data and AI-Driven Underwriting

Two regimes with different legal natures

The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers was adopted on December 4, 2023. It is principles-based guidance, not a statute. It reminds insurers that decisions or actions affecting consumers, when made or supported by advanced analytical and computational technologies including AI systems, must comply with all applicable insurance laws and regulations. It also sets out regulator expectations for how insurers govern the development, acquisition and use of certain AI technologies. Insurers are expected to maintain a written program for the responsible use of AI, and the bulletin encourages verification and testing to identify errors, bias and the potential for unfair discrimination in predictive models and other AI systems.

The bulletin is a model. Each state department issues its own version, so operative dates and wording depend on the state. As of October 2026, a separate NAIC working group is developing a third-party data and models regulatory framework, described as in development. It is meant to streamline how regulators gather the information they need to evaluate third-party data and models used by insurers.

FCRA is a statute. FTC guidance states that insurers who use consumer reports to underwrite policies or screen high-risk applicants must comply. The law protects the privacy of consumer report information and is designed to help ensure that information supplied by consumer reporting agencies is as accurate as possible. The bulletin tells you how to govern the system. FCRA tells you what you owe a consumer when a consumer report shaped the outcome.

Side-by-side comparison

The table summarizes how the two regimes differ on the dimensions compliance teams most often need to map.

• Legal nature: NAIC bulletin: supervisory guidance, issued by each state department in its own version. FCRA: federal statute.
• What triggers it: NAIC bulletin: decisions or actions impacting consumers made or supported by AI systems. FCRA: a decision based partly or completely on information in a consumer report.
• Core obligations: NAIC bulletin: a written AI program, governance of AI development, acquisition and use, and verification and testing. FCRA: adverse action notices, consent before obtaining medical information, and the consumer's dispute and free report rights.
• Third-party data: NAIC bulletin: oversight of third-party data and models is an active NAIC work area, with a framework in development. FCRA: attaches to information furnished by consumer reporting agencies and its accuracy.
• Consumer-facing duty: NAIC bulletin: no notice mechanism of its own. FCRA: notice of adverse action, such as denial, a rate increase or policy termination, including the right to dispute CRA-furnished information and to request a free CRA report within 60 days.
• Evidence expectation: NAIC bulletin: documented program, testing and governance a regulator can examine. FCRA: proof that notices and consent requirements were met. Many insurers keep copies of written notices for two years.

Mapping common underwriting scenarios

Start with the data input, then follow it to the decision. Four scenarios cover most cases.

If an underwriting model uses information from a consumer report and the outcome is a denial, rate increase or termination, FCRA Section 615(a) notice duties apply. The bulletin also applies, because the decision is made or supported by an AI system and the insurer must show a governed program around it.

If a model uses external data that is not subject to FCRA, FCRA notice duties do not attach to that input. The bulletin still applies. A June 3, 2024 draft from the NAIC Accelerated Underwriting Working Group distinguishes FCRA data from non-FCRA data. It says an insurer should be able to give the consumer the reasons for an adverse underwriting decision and all the information the decision was based on, whether or not the data is subject to FCRA. That draft is not a final requirement, but it signals where regulator expectations are heading.

If the workflow involves medical information, FCRA Section 604(g) requires the consumer's consent before the insurer obtains it. Consent may be oral, electronic or written.

If a decision draws on both kinds of data, treat the FCRA input as the trigger for notice duties and the full set of inputs as the scope of the explanation. The same draft notes that FCRA data can be extensive and that accessing it may expose non-usable credit attributes, which is a reason to control what reaches the model.

What can be enforced at runtime and what cannot

The regimes do not specify technical enforcement, so the following is an architectural reading, not a regulatory requirement. Some obligations can be applied to individual AI interactions and tool calls in the execution path. Others are program-level or legal processes that no runtime control replaces.

In the execution path, a team can apply policy to each interaction or tool call. A policy can allow a data input, redact attributes the model should not see, or block a call to a source that has not been cleared for underwriting use. It can also route a call to human approval, for example when a request would pull medical information or when an output could lead to an adverse decision. These controls depend on a classification of each input as FCRA or non-FCRA, which has to be defined and maintained by the insurer.

Program-level obligations sit outside the execution path. They include the written AI program, verification and testing for errors and bias, and tracking each state's version of the bulletin. They also include the documented decision on when FCRA adverse action and dispute duties are triggered, the delivery of notices, handling of consumer disputes, and the retention of notice copies. A runtime control can support these processes with evidence. It does not perform them.

The tradeoff is scope. Runtime enforcement is precise for individual interactions and tool calls, but it does not decide legal questions or substitute for governance of the wider program.

Where Trussed fits

Trussed is runtime control and evidence infrastructure for consequential AI in regulated enterprises. It enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, and escalate for human approval. The scope is individual interactions and tool calls. Enforcement is applied at runtime, not reviewed after the fact.

That enforcement generates continuous audit-ready evidence, mapped to NAIC among other frameworks. For an insurance compliance team, this gives regulator-facing proof of what an AI interaction was permitted to do and what happened. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Trussed does not make an insurer FCRA compliant. Permissible purpose, notice content, dispute handling and the written AI program remain legal and program-level responsibilities. Runtime enforcement and its evidence support those processes for the portion of the data path that runs through AI interactions and tool calls.