Insurance Regulators on External Data for AI: The NAIC Bulletin and State Rules on Third-Party Data

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

What the NAIC bulletin asks of insurers that acquire third-party data

The bulletin treats data you buy as part of your AIS program, so the insurer stays accountable for it even when a vendor collected or prepared it [1]. It is principles-based guidance, not a model law, and it reaches licensed insurers only in states whose departments adopt it [2]. NAIC's own adoption map, reflecting status as of May 1, 2026, is the reference for which jurisdictions have done so; check it rather than relying on older law-firm tallies [3].

The bulletin text describes several elements that touch acquired data directly [1]:

• A written AIS program with governance, risk management and internal controls proportionate to the consumer impact of each use (claims, underwriting, pricing, fraud, marketing).
• Third-party AI systems and data: a process for due diligence and assessment of vendors, plus contract terms that, where appropriate, give the insurer audit rights and require the vendor to cooperate with regulatory inquiries and investigations.
• Data practices: attention to data currency, lineage, quality, integrity, bias analysis and suitability for the intended use.
• Regulatory examinations: departments may request documentation of the program, the data and models used, and the controls applied, including for third-party components.

The bulletin also ties AI use back to existing statutes such as unfair trade practices, unfair claims settlement practices and rating laws [1]. A claims model trained on purchased adjuster notes is therefore still judged against claim-handling standards; the NAIC Unfair Property/Casualty Claims Settlement Practices Model Regulation, for example, requires claim files detailed enough to reconstruct pertinent events [5]. If your training data cannot be traced to its claim files and dates, that gap shows up in an exam.

How New York and Colorado go further on external consumer data

New York and Colorado move from principles to specific expectations about external consumer data and information sources (ECDIS), and both put responsibility on the insurer rather than the vendor [4]. Treat them as the strictest current baseline when you design a multistate data intake process.

New York DFS Insurance Circular Letter No. 7 (July 11, 2024) addresses AI systems and ECDIS used in underwriting and pricing [4]. As described in the circular, insurers should be able to show that ECDIS do not use protected-class information or proxies for it and do not produce unfairly discriminatory outcomes, should document that assessment, and remain responsible for data and models supplied by third parties. Read the full letter for its testing and governance sections before relying on a summary.

Colorado SB21-169 and Regulation 10-1-1 take a binding-rule approach: insurers that use ECDIS, and algorithms or predictive models built on them, must maintain a board-overseen governance and risk management framework. The regulation began with life insurers and has since been amended to reach additional lines, and insurers that do not use ECDIS file an attestation instead. Confirm the current text, covered lines and filing dates directly with the Colorado Division of Insurance before relying on them, because they have changed since adoption.

Colorado's general automated decision-making law is separate. SB26-189, signed May 14, 2026, replaced the consumer protections of SB 24-205, with core obligations starting January 1, 2027 [6]. Our overview of US state AI laws that reach training data covers that track.

Which kinds of acquired data trigger which expectations

Scope depends on what the data is and what the model decides, not on whether a vendor sold it [1][4]. A rough mapping as of October 2026:

Confirm each classification with counsel; definitions of ECDIS and "insurance practice" differ between the instruments [4].

Vendor diligence and contract terms for data suppliers

The bulletin's third-party expectations translate into concrete diligence questions and contract clauses you should get before the data touches a model [1]. The same logic is familiar from bank model risk management; see model risk management for third-party training data for the parallel.

Ask every data supplier for:

1. Provenance: which system the records came from (for example a claims platform such as Guidewire ClaimCenter or Duck Creek Claims, a document management system, a ticketing tool), the date range and the extraction method.
2. Rights: who owns the records, what consents or notices covered the original collection, and whether the supplier can license the data for model training and evaluation.
3. Personal data handling: which fields were removed or replaced, the method used, and how a sample was checked. Health information in claims (bodily injury, disability, workers' compensation medical notes) needs HIPAA de-identification by Safe Harbor or Expert Determination where HIPAA applies [7]; see what a HIPAA-compliant label must mean.
4. Protected-class exposure: whether any field is, or plausibly proxies for, race, religion, national origin or other protected classes, which is the core concern in New York [4] and in Colorado's ECDIS rules.
5. Change notice: how the supplier tells you about schema changes, backfills or corrections.

Contract terms to negotiate, drawn from the bulletin's language [1]:

• An audit or information right covering data collection and preparation.
• A duty to cooperate with regulatory inquiries and examinations about your use of the data.
• Documentation delivery obligations, so the evidence exists in your files and not only in the vendor's.
• Defined permitted uses, records, term and delivery method in the license.

Whether a regulator can inspect the licensed data itself is a separate question covered in regulator access to licensed training datasets.

The evidence pack an examiner will expect for acquired data

The answer to most exam requests is a per-dataset file that links source, rights, preparation and testing to each model that used the data [1][4]. Build it at intake, because reconstructing it after deployment is where programs fail. The broader structure is in our guide to AI training data audit readiness.

Illustrative example: invented to show structure; it does not describe an available dataset.

Illustrative example: invented to show structure; it does not describe an available dataset.

dataset_id: EXT-CLM-2026-014
supplier_type: US third-party claims administrator
source_systems: [claims_platform_notes, adjuster_field_reports, estimate_line_items]
date_range: 2021-01-01/2025-12-31
lines_of_business: [homeowners, commercial_property]
intended_use: claims_triage_model
ecdis_determination: "not consumer-level external data; operational claim records"
personal_data_method: "names, phones, emails, policy and claim numbers replaced with tokens; free-text NER pass plus manual sample review"
hipaa: not_applicable_property_only
protected_class_review: "ZIP-level geography retained at 3 digits; proxy analysis scheduled before training"
license_ref: LIC-2026-031
audit_and_cooperation_clauses: true
linked_models: [triage-v3.2]

Common failure modes in insurer data intake

Most findings come from gaps between procurement, data science and compliance rather than from the data itself [1]. Watch for these:

• Lineage stops at the vendor. You know the supplier but not the source system or extraction dates, so you cannot show currency or reconstruct claim events [1][5].
• Free-text leakage. Structured fields are scrubbed while adjuster notes still carry names, VINs, addresses or medical details; see indirect identifiers in business text.
• Proxy variables in operational data. Fine-grained geography, language of correspondence or provider names can act as protected-class proxies [4].
• Contract silence. No audit or cooperation clause, so the vendor can decline to answer an examiner's question about its data [1].
• Label drift. Claim outcomes used as labels reflect past adjusting practices; if those practices were inconsistent, the model learns them. Our page on insurance claims AI evaluation covers how to treat adjudication outcomes as test labels.

Where operational claims and underwriting data come from

Much of the training data insurers want for claims triage, underwriting assist and agent training sits in other businesses' operational records: TPA claim notes, FNOL transcripts, adjuster field reports and estimates, inspection reports and underwriting files. SourceX sources operational datasets from US companies on request and manages the commercial process, including licensing agreements and ongoing purchases; nothing is held in stock and a request does not guarantee a match. Each dataset is rights-reviewed for ownership and consents and delivered under a license defining records, uses, term and delivery, with diligence materials on source, rights, preparation and allowed use prepared per dataset. Those materials map onto the evidence pack above; you can describe the data you need on the buyers page.

Related pages: insurance buyers, compliance checks for insurance carriers and TPAs licensing data, insurance claims workflow datasets, underwriting files, and the compliance hub for data buyers.

Sourcing insurance data that fits an AIS program

SourceX looks for US businesses that hold the operational data you describe, assesses data and licensing permissions, and agrees pricing and allowed uses in a license; nothing is contracted until a supplier agrees and every release is approved by the supplying company. Personal details are removed or replaced before delivery, the method is recorded and a sample is checked, and health records require HIPAA de-identification. Start a request at https://sourcex.si/buyers.