NAIC AI Model Bulletin data governance means an insurer can trace every data element feeding an AI system back to its source, document why each input is suitable for its use, and run repeatable tests that catch when a model’s outputs vary by a protected characteristic or a proxy for one. The bulletin, adopted by the NAIC on December 4, 2023, names data governance as one of the AI Systems Program elements a market-conduct examiner expects to see evidence of, alongside governance, risk controls, and validation. This guide focuses specifically on that element: what data lineage documentation looks like in practice, how consumer data handling fits inside it, and what a defensible unfair-discrimination testing program actually tests for.
This is a companion to the broader NAIC AI Model Bulletin requirements explainer, which covers the bulletin’s full scope, state adoption, and the AI Systems Program overall. This guide assumes that AIS Program context and goes deep on the data governance piece specifically, the element most carriers underbuild.
Want to put this into practice? Use our AI system inventory generator.
Why data governance gets underbuilt
Governance gets a charter and a named owner. Validation gets a testing calendar. Data governance tends to get a sentence in a policy document, because it sits upstream of the model and no one owns the full data path the way a model owner owns the model. That is a problem: a model validated on data no one can trace is a model validated on an assumption.
An examiner will ask for three distinct things under this one heading: where the data came from (lineage), what the insurer is allowed to collect and do with it (consumer data handling), and whether using it produces unfair discrimination (testing). Treating these as one undifferentiated bucket is how carriers end up with a policy that reads well and an evidence file that does not back it up.
Data lineage: documenting where the data came from
Data lineage, in the bulletin’s language, is the record of a data element’s suitability and quality, traced from its original source through every transformation to the point an AI system consumes it. For an underwriting, rating, claims, or marketing AI system, that means being able to answer, for every input field, four questions: where did it originate, has it been transformed or derived, who is responsible for its accuracy, and is it still fit for the use the model puts it to.
A practical lineage documentation framework
Most carriers do not need a data-lineage platform to satisfy this expectation; they need a documented, repeatable record. This framework works for a compliance or data team building the record for the first time.
| Lineage element | What to document | Who typically owns it |
|---|---|---|
| Source | The system of record or external source (policy admin system, claims system, consumer report, third-party data broker, public record) for each input field | Data owner in the business unit that captures the data |
| Collection basis | What notice or authorization governs the collection, and whether the use in this AI system was contemplated when that notice was given | Privacy or compliance officer |
| Transformation | Every derivation, aggregation, or scoring step between the raw source and the value the model sees, including any third-party vendor model that produces a derived score | Data engineering or the vendor, documented by the AI system owner |
| Proxy risk | Whether the field, alone or combined with others, could function as a proxy for a protected characteristic (geography standing in for race, certain occupation codes standing in for age or disability status) | Compliance, informed by the testing results below |
| Freshness and suitability | How current the data is, and whether it remains suitable for the specific underwriting, rating, claims, or marketing use, not just the use it was originally collected for | Data owner, reviewed on the model’s revalidation cycle |
Build this table once per AI system, not once per company. A carrier running underwriting, claims triage, and marketing-personalization models needs three lineage records, because a field that is a legitimate rating factor in one model can be a proxy risk in another.
Where lineage breaks down in practice
The most common gap is third-party data: a consumer report, an external score, or a vendor-supplied enrichment field that arrives already transformed, with the vendor’s methodology undisclosed. The bulletin’s third-party oversight expectation does not let an insurer wave this off as the vendor’s problem; the insurer remains responsible for the output. The fix is contractual: require the vendor to disclose, at minimum, the data sources feeding its score and any proxy variables it uses, built into onboarding and periodic review rather than a one-time intake question. Our machine learning third-party risk guide applies the interagency third-party risk framework to exactly this kind of vendor, and the discipline carries over even though insurers answer to NAIC rather than the federal banking agencies.
Consumer data: what insurers can collect, use, and retain
The bulletin’s data governance element also covers the suitability and quality of the data itself, which in practice means confirming that consumer data entering an AI system was collected and is used consistently with the notice given to the consumer and the insurer’s own retention commitments. This is not a privacy-law explainer; GLBA’s privacy and safeguards obligations for nonpublic personal financial information apply to insurers independent of the bulletin, and state insurance privacy statutes layer on top. What the bulletin adds is a documentation duty: can the insurer show that the consumer data an AI system uses was within the scope of its original collection, and produce that trail if a regulator or consumer complaint asks.
Four consumer-data practices worth confirming before an AI system goes live:
- Purpose consistency. The data was collected for a stated purpose (underwriting, claims administration, fraud detection), and the AI use case stays inside that purpose rather than repurposing data collected for one function into a model built for another.
- Minimization. The AI system uses only the fields it needs for the model’s function, because every additional field is additional proxy and exposure if the model is later challenged.
- Retention alignment. Data feeding a model follows the same retention schedule as the source system, so it is not quietly retained past the point the source record would have been purged.
- Access logging. Who and what systems can read the consumer data feeding the model is logged, which matters for a breach investigation and for showing the data was not accessed outside its intended use.
Testing for unfair discrimination: what the bulletin actually asks for
The bulletin is specific that verification methods should detect errors, performance degradation, bias, and unfair discrimination, both before deployment and on an ongoing basis. That phrase means something more concrete than a general bias review.
The testing methods that hold up
A defensible unfair-discrimination testing program for an insurance AI system combines three checks, run together:
- Disparate impact analysis. Compare model outcomes (approval, pricing tier, claim decision) across groups defined by protected characteristics where state law permits the comparison, looking for statistically meaningful gaps not explained by legitimate risk factors. The testing discipline, not the underlying legal standard, is what transfers from lending; our AI fair lending model validation framework documents that methodology for a reader building the actual test.
- Proxy detection. Test whether any input field, or combination of fields, correlates strongly enough with a protected characteristic that it functions as a stand-in for that characteristic even without naming it. Geography, certain occupation or education variables, and some credit-adjacent fields are the usual suspects in insurance underwriting and rating models.
- Outcome stability over time. Rerun the disparate-impact and proxy analyses on a fixed schedule and after any material model, data, or vendor-score change, because a model that passed at deployment can drift as the population or vendor data behind it changes.
Insurance unfair discrimination is its own body of law
A precision point worth holding onto: insurance unfair discrimination statutes are a distinct legal regime from lending’s fair-lending framework under the Equal Credit Opportunity Act and Regulation B. Every state has its own unfair trade practices and unfair discrimination statutes governing how insurers classify and price risk, and those statutes, not ECOA, govern an insurer’s testing obligation. The bulletin does not create new liability here; it tells the insurer what evidence a regulator now expects to see the existing statutory standard was actually tested for, not assumed.
A compliance evidence checklist
Pull these together and a carrier has the data governance record a market-conduct examination will ask for:
- [ ] A lineage record for every AI system, documenting source, collection basis, transformation, proxy risk, and freshness for each input field
- [ ] Vendor contracts that require disclosure of data sources and proxy variables behind any third-party score feeding an AI system
- [ ] A documented purpose, minimization, and retention review for consumer data feeding each AI system
- [ ] Access logs showing who and what systems can read the consumer data in scope
- [ ] Pre-deployment disparate-impact, proxy-detection, and outcome-stability test results for each AI system, with thresholds and findings
- [ ] A recurring retest schedule tied to the model’s revalidation cycle and to any material data or vendor-score change
- [ ] Named ownership for the lineage record, the consumer-data review, and the testing program, so the evidence has an owner when an examiner asks who can speak to it
Questions buyers ask
Does the bulletin require a specific statistical test for unfair discrimination?
No. The bulletin describes an outcome, verification methods that detect errors, bias, and unfair discrimination, without mandating a specific technique, so an insurer can choose methods proportionate to the system’s potential for consumer harm. An examiner looks for evidence that a real, repeatable method was applied and documented, not a specific formula.
Is data lineage the same thing as a data inventory?
Related but not the same. A data inventory lists what AI systems exist and what data they use. Lineage goes one level deeper for each data element, tracing its source, transformations, and suitability. A carrier typically builds the inventory first, at the governance stage, then builds lineage records per system as the data governance element.
Our third-party vendor will not disclose its model’s variables. What do we do?
Push for disclosure at the level of data sources and proxy variables, not full methodology or trade secrets, which most reputable vendors provide under a standard due-diligence agreement. A vendor that will not disclose even that much leaves the insurer carrying the oversight expectation with no visibility into what it is overseeing, a vendor-selection risk worth escalating before the model goes live.
How often should we retest for unfair discrimination?
At minimum, on the same cycle as the model’s broader revalidation, and immediately after any material change to the model, its training data, or a vendor score it depends on. A model that passed at launch is not evidence it still passes after population drift or a silent vendor update.
Does this apply the same way to a small AI vendor tool as to a core underwriting model?
The bulletin’s expectations are proportionate to potential consumer harm, so documentation and testing depth scale down for a low-stakes tool like marketing copy and up for anything touching underwriting, rating, or claims. Every system still needs to be inventoried and assigned a data governance record; only the depth is proportionate.
What this guide is / What it is not
What it is: A practitioner explanation of the data governance element of the NAIC AI Model Bulletin’s AI Systems Program, focused on data lineage documentation, consumer data handling, and unfair-discrimination testing methods, with a framework and checklist a compliance or data team can use directly.
What it is not: It is not legal advice, and it is not a certification or a guarantee of any examination outcome. The bulletin binds only in states that have adopted it; confirm your own states’ status before treating this as applicable. DSE prepares organizations for audit and examination; we do not certify, and we do not guarantee passing an examination. The primary source is the NAIC’s Model Bulletin.
The Bottom Line
Data governance is where most NAIC AI Model Bulletin programs are weakest, because it sits upstream of the model and no single owner naturally claims the full data path. Treat it as three deliverables, not one: a lineage record that traces each input field to its source and flags proxy risk, a consumer-data review that confirms purpose, minimization, and retention, and a repeatable testing program that runs disparate-impact, proxy-detection, and stability checks rather than asserting fairness in a policy document. A carrier that can produce all three for its underwriting, rating, claims, and marketing AI systems has the evidence a market-conduct examination actually asks for.
Building the full AI Systems Program, governance, risk tiers, validation, data governance, and vendor oversight together, is what an AI governance for insurers engagement is built to deliver. If you want a structured way to check where your own program stands first, start with the AI Governance Checklist, or see how this fits inside a broader financial-services compliance posture if your AI systems span insurance and other regulated lines.
Key facts
- The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted December 4, 2023, names data governance as one of the core AI Systems Program elements, covering the suitability, quality, and lineage of the data an AI system uses, including the risk that an input proxies for a protected characteristic (NAIC, 2023).
- The bulletin directs insurers to test AI systems for unfair discrimination before deployment and on an ongoing basis, a testing duty distinct from the lending fair-lending regime under the Equal Credit Opportunity Act and Regulation B (DSE, 2026).