The NAIC's Third-Party Data and Models (H) Working Group spent its March 23, 2026 session sketching the contours of a framework that, if adopted later this year, will reshape how every property and casualty carrier procures AI. The working group is drafting a registration regime rather than a licensure regime, with disclosure obligations attached and a clear note that insurer accountability does not transfer to the registered vendor.
The distinction matters. Licensure would let regulators approve or deny a vendor's right to operate in a state. Registration only requires the vendor to file information with regulators and update it on a defined cadence. The registry creates visibility. It does not create a safe harbor. An insurer that uses a registered model is still answerable for the model's behavior in pricing, underwriting, claims, utilization review, marketing, and fraud detection. Carriers that read the bulletin and concluded the vendor would carry the regulatory weight read it wrong.
The working group's public-facing materials frame the goal narrowly: regulators want a way to look at the same model across multiple carriers and ask consistent questions about it. Today, when a New York examiner and a Colorado examiner separately review the same third-party underwriting model, they receive different documentation packages, scoped differently, with different vendor cooperation levels. The registry is a coordination layer for examiners. It is also, by design, an accountability layer for insurers, because the registered information becomes the regulator's baseline expectation for what every insurer using that vendor should already know.
What Triggers Registration
The framework as drafted applies to vendors whose data or models contribute to "consumer-facing decisions" in regulated lines. The working group is still defining the term, but the Carlton Fields summary of the spring session identified the categories the group is converging on: pricing, underwriting, claims handling (including coverage decisions and reserve estimation), utilization review, marketing and lead scoring, and fraud detection. Models used purely for back-office functions (HR, IT operations, internal analytics with no consumer impact) sit outside the scope.
Two scoping questions remain unresolved and are worth tracking. First, the threshold for "contribution" to a decision. A model that fully automates a decision is clearly in scope. A model that surfaces a recommendation an underwriter overrides 80% of the time presents a harder question, and the working group has not committed to a threshold. Second, the treatment of foundation models repurposed for insurance use. A general-purpose LLM accessed via API to summarize claim files arguably falls under the framework if the summarization influences claim decisions, even if the vendor never marketed the model as an insurance product. Vendors of large multi-purpose models are paying close attention.
What registration will require, based on the working group's current draft, is meaningful: a description of the model and its intended use, training data sources and date ranges, documented testing methodology including bias testing where applicable, known limitations, change-management practices, and a contact for regulator inquiries. Vendors that have been treating governance documentation as confidential IP are about to discover that the registration filing is the new floor.
Why the Bulletin Does Not Solve This for Insurers
The 2023 NAIC Model Bulletin on Use of Artificial Intelligence Systems by Insurers already places the diligence obligation on the carrier. Bulletin Section 4 makes clear that an insurer's AI systems program must address third-party data and models with the same rigor as internally developed systems. The registry does not change that allocation. It adds a regulator-side data layer on top of it.
Insurers that participated in the NAIC AI Systems Evaluation Tool pilot have already seen what examiners ask for when a third-party model is in use. The questions are not "is the vendor registered." The questions are: what governance program does your organization apply to this vendor; how did you validate the model before deployment; what monitoring do you perform post-deployment; what is your remediation pathway if the model produces biased or inaccurate outcomes; what contractual rights do you have to the vendor's testing artifacts.
A registered vendor that produces a confidential filing to the NAIC central registry does not satisfy any of those questions. The carrier must produce its own evidence that it understood, evaluated, and continues to monitor the model. The Alston & Bird readout of the spring meeting flagged this point explicitly: state insurance departments have signaled they will treat the registry as a prerequisite, not a substitute, for the carrier's own diligence file.
What to Demand From Vendors Before the Framework Lands
The realistic adoption timeline puts the framework's first state implementations in late 2026 or early 2027. That window is when carriers should be renegotiating vendor relationships, because waiting until vendors are required to disclose creates a much weaker negotiating position than asking now.
The vendor evaluation file every carrier should be assembling has six components. First, a model card that documents architecture, training data sources and date ranges, intended use, known limitations, and version history. Second, the vendor's bias testing methodology and results, segmented by the protected classes that apply in the carrier's operating states. Third, sub-processor disclosure listing every entity that handles training data, hosts the model, or contributes to inference. Fourth, the vendor's incident-response and notification commitments when the model produces flagged outputs or experiences a security event. Fifth, a written commitment to share, on request and within a defined SLA, monitoring metrics and drift indicators the vendor itself collects. Sixth, exit and continuity provisions that survive vendor acquisition or insolvency.
The first three of these are documentation a regulator will eventually expect to see in the registry filing anyway. Asking for them now positions the carrier to validate the vendor's own answer against what the carrier observed during evaluation. A vendor whose registry filing later disagrees with the model card it provided you is a vendor with a governance problem you need to know about before an examiner finds it.
For carriers that have not yet built this discipline into procurement, Swept AI's evaluation infrastructure provides the scaffolding: documented model evaluation against carrier-specific test cases, bias testing that mirrors the methodology examiners apply, and an evidence file that travels from procurement through deployment into ongoing supervision.
Building a File That Survives Both the Registry and State Exams
The harder problem is that vendor evaluation is not a one-time event. The registry will require vendors to update filings on a defined cadence, but the carrier's supervision file needs to update continuously. State market conduct exams in Colorado, Connecticut, New York, and the bulletin-adopting states routinely look back two to three years. A file built only at procurement is a file that will be stale by the time it is examined.
Three practices separate the carriers that will pass these exams from the carriers that will not. The first is tying the vendor evaluation file to a model inventory entry that records every production model in use, the business purpose, the responsible owner, the deployment date, and the supervisory cadence. An examiner who asks "show me everything that touches underwriting decisions" needs an answer in hours, not weeks. The inventory is the index; the vendor file is the underlying document.
The second is building contract terms that match what the registry will eventually require. If your contract does not give you audit rights, drift-notification SLAs, sub-processor disclosure, and the right to receive bias testing results on request, your vendor evaluation file will be incomplete by definition. The registry creates regulator-side visibility into what vendors document. The contract creates carrier-side rights to access that documentation continuously.
The third is treating the vendor file as an evidence pipeline, not a folder. Every monitoring report the vendor sends, every incident notification, every annual recertification belongs in a queryable system that timestamps the artifact and links it to the relevant model inventory entry. Carriers that store these in shared drives or email threads discover at exam time that they cannot reconstruct what they knew, when they knew it, or what they did about it.
The Registry Does Not Reduce the Work. It Raises the Floor.
The temptation in reading the working group's materials is to assume that a vendor registry shifts work from carriers to vendors. The opposite is more accurate. The registry sets a regulator-validated baseline of what every carrier using a registered vendor should already know. It does not file your model inventory. It does not produce your bias testing artifacts. It does not generate your audit trail. It creates an external reference point against which examiners will measure your diligence.
The carriers that will benefit from the framework are the ones whose vendor files already exceed what the registry will require. They will treat the registry filing as confirmation of what they have independently validated. The carriers who will struggle are the ones who treated vendor governance as the vendor's problem and now discover that the regulator-validated baseline is a starting point, not an endpoint.
The framework will likely be exposed for public comment in the third quarter and considered for adoption at the November Fall Meeting. Carriers that begin the vendor evaluation work now will have a complete file by the time the framework lands. Carriers that wait will find themselves rebuilding diligence on a model that has been in production for years, under examiner pressure, with vendors who have leverage they did not have six months ago.
