# AI Governance Documents to Prepare for a Market Conduct Exam
> The insurance AI exam documentation to have ready for a market conduct exam: an insurer-built readiness file of eight evidence categories, and how to record a gap.
- Source: https://insureaiwire.com/market-conduct-exam-ai-docs-ready/
- Publication: InsureAI Wire
- Author: Simon Li
- Updated: 2026-08-04
---
A [market conduct exam](/glossary/market-conduct-exam/) notice does not arrive with a syllabus. It arrives with a date, a scope, and a list of document requests that may or may not use the word AI. The [NAIC AI Model Bulletin](/naic-model-bulletin/) still places an insurer's AI use inside the market conduct machinery the regulator already runs. It says the department may ask for the AIS Program, model documentation, and vendor files [^1]. The Evaluation Tool then shows the shape those questions take on paper [^3].
Market conduct examinations are the state's standing mechanism for inspecting how an insurer actually treats consumers, run by the departments under the NAIC's [Market Regulation Handbook](/glossary/market-regulation-handbook/) [^2]. If the process itself is new to you, [what a market conduct exam is and how it runs](/market-conduct-examinations/) covers the triggers, the sampling, and the timeline; this piece assumes it and goes straight to the AI files. AI did not get its own proceeding. It got folded into that one. So the useful question is narrow: name the eight files, name who in the building can produce each, and name what happens on the ones nobody can. For the wider governance program these documents sit inside, see our [AI governance in insurance guide](/ai-governance-in-insurance/).
## The exam sequence
A market conduct exam follows a recognizable sequence, but no national timetable governs the phases below. This is an InsureAI Wire planning model. The department's notice, scope, and instructions control the actual dates and deliverables.
**Table [row-headers]:** Planning sequence, owners, and deliverables for an AI-focused market conduct examination
| Phase | Planning cue | Key action | Owner | Deliverable |
|---|---|---|---|---|
| Exam notice received | Immediately | Log receipt, acknowledge to regulator, open exam file | Compliance officer | Acknowledgment letter + internal exam file |
| Kickoff call | After initial review | Confirm scope, document requests, timeline, contacts | Compliance + legal | Kickoff minutes + confirmed document list |
| Document collection | After scope is confirmed | Pull AIS Program, inventories, validation records, vendor contracts | Compliance + IT + actuarial | Document index with Bates numbers |
| Internal review | Before submission | Gap check against the request and applicable authorities | Compliance + legal | Gap list with owners and remediation dates |
| Submission | By the department's deadline | Deliver documents, log transmittal, confirm receipt | Compliance officer | Transmittal letter + delivery confirmation |
| On-site or interview | If requested | Prepare witnesses, run mock interviews, document Q&A | Compliance + business leads | Interview prep memo + Q&A log |
| Findings response | After findings issue | Draft response and corrective action plan if needed | Legal + compliance + CRO | Response letter + CAP |
The worksheet below mirrors this table with editable columns for your own deadlines and owners.
FIG. 1: A PLANNING SEQUENCE, NOT A REGULATORY TIMETABLE
## An eight-part readiness file
We organize AI exam readiness into eight evidence categories: the written AIS Program and its adoption record, the AI system inventory, high-risk system documentation, data records, vendor contracts and due diligence, consumer notices and complaint records, governance minutes, and incident or override records. This is a preparation framework assembled from the Model Bulletin and Evaluation Tool. It is not a uniform request list, and an examiner may ask for fewer, more, or different materials.
Items 3 and 4 line up with the Evaluation Tool's Exhibits C and D, the closest published list of what a regulator may ask about a model. Item 2 is the register needed to answer Exhibit A's counts [^3]. The remaining categories come from the Model Bulletin's program requirements, including its call for inventories and descriptions of the models themselves [^1]. Every one of them is something a person can hold in hand and read a date off.
**Table [row-headers]:** Eight documentation items and the signs that each is examination-ready
| # | Documentation item | What the examiner sees | What counts as solid | Gap sign |
|---|---|---|---|---|
| 1 | AIS Program document | A written AI Systems Program with adoption date, review frequency, and board approval | Dated minutes showing board or committee adoption; annual review entries | Undated document, or one with no review history |
| 2 | AI inventory (feeds Exhibit A) | A list of every AI system, with operational area, owner, vendor flag, and last validation date. Exhibit A itself asks only for counts by operational area: but you cannot produce the counts without the list | Each entry has a named owner and a validation date inside your stated revalidation interval | Systems listed without owners, or validation dates with no interval to measure them against |
| 3 | High-risk system documentation (Exhibit C) | Per model: name and version, type, implementation date, built or bought and by which vendor, risk classification, known risks and limitations, whether it automates or only supports, how it was validated and is monitored, last test date, and any regulatory action taken over it | Dated validation reports, bias and unfair-discrimination test results, a last-testing date that is not years old | Validation reports with no dates, or bias testing that says "N/A" |
| 4 | Data records (Exhibit D) | Not a free-text lineage narrative: a fixed list of data-element categories: age, gender, ethnicity/race, geocoding, geo-demographics, education, income, criminal convictions, facial analysis and the rest: where you mark which ones feed your models and whether each came from inside the company or from a named third party | A defensible answer for every category you checked, and a data dictionary behind it | Data sources listed as "various internal systems" with no further detail |
| 5 | Vendor contracts and due diligence | Contracts with audit rights, model documentation clauses, monitoring provisions | Signed contracts with specific AI audit clauses; due-diligence files with dates | Contracts signed before AI was added, with no amendment covering AI |
| 6 | Consumer notice and complaint log | Records of AI-related consumer disclosures and any complaints or appeals | Notice templates, mailing or portal logs, complaint register with AI flag | No AI-specific complaint category, or complaints handled in general queue only |
| 7 | Governance meeting minutes | Minutes from AI governance committee or risk committee meetings | Dated minutes with AI agenda items, attendance, and action items | Minutes with no AI items, or attendance that does not include the model owner |
| 8 | Incident and override log | Records of AI incidents, near-misses, and human overrides | Dated entries with root-cause analysis and remediation | Empty log, or entries that say "no issues found" without detail |
Rows 2 and 3 are the two that get pulled first, and each is a whole exercise on its own: row 2 rests on the inventory built in our [Exhibit A inventory playbook](/ai-inventory-by-line-of-business/), and the validation and drift records behind row 3 in the [AI model monitoring playbook](/ai-model-monitoring-insurance/).
They also need a number you have to supply yourself. Row 2 turns on a revalidation interval and row 3 on how often bias testing repeats, and neither the Model Bulletin nor the Evaluation Tool sets one. Annual is a common working assumption for models that shape pricing or claims, but it is an example, not an authority. The interval is yours to set and defend, and the defensible version is written down in the AIS Program with a reason attached rather than inferred from whenever the last report happens to be dated.
The gap sign column is where most first passes stop being comfortable. That is the column doing the work. An examiner tests whether the program operates; the useful thing to be able to show is that you already know which parts do not, and since when.
## The gap record: what to do when you cannot produce it
Every carrier has gaps. The expensive version is discovering them in the same week the examiner does. The gap record is a worksheet for naming one first, in a form that reads as management rather than apology.
The two rows below are illustrative, not a real company's data.
**Table [row-headers]:** Illustrative examination-gap log with interim controls, owners, and due dates
| Gap # | Exam request or finding | What we could not produce | Why | Interim control | Owner | Due date |
|---|---|---|---|---|---|---|
| G-01 | Produce validation records for the claims triage model | No validation performed since 2025 rebuild | Model rebuilt by vendor without a re-validation clause in the contract | Manual review of all triage decisions until validation completed | Chief Actuary | 2026-Q3 |
| G-02 | Show proxy-discrimination screening for geo score | No proxy screen documented | Geo score added in 2024, before proxy screening was part of the standard intake | Run the disparate-impact test now; document methodology and results | Model Risk | 2026-Q4 |
The pattern is the same for every gap: name it, explain why it exists, assign an interim control, name the owner, and set a due date. The interim control is the load-bearing column. "We are aware of the issue and are working on it" describes a feeling about the gap; "all triage decisions are manually reviewed until validation is completed" describes what happens to a policyholder in the meantime, which is the thing an examiner can test.
Both illustrative gaps above are vendor-shaped, which is the common case. The contract that governs whether you can get validation records out of a vendor at all is usually signed years before anyone asks, and our [AI vendor risk assessment checklist](/ai-vendor-risk-assessment/) covers the clauses that decide it. For the data-lineage side of row G-02, the [NAIC Exhibit D data documentation playbook](/naic-ai-exhibit-d-checklist/) works through what naming a data source actually requires.
## What the NAIC Evaluation Tool means for exam prep
The Evaluation Tool, at Version 4.0 and running as a pilot in twelve states through September 2026, is a structured request for information about an insurer's AI systems [^3][^4]. Nothing in it is exam procedure. Its own pages still carry a DRAFT header, its exhibits are labelled optional and supplemental, and it tells regulators to cut them down to the inquiry at hand. It is still the most detailed published account of the questions a regulator has decided are worth asking. That makes it the closest available proxy for exam scope, and its four exhibits fit the eight items above:
- **[Exhibit A](/glossary/exhibit-a/)** sits on top of item 2. It does not ask for the inventory itself; it asks you to count it: how many AI systems run in each operational area, how many touch consumers directly, how many carry material financial impact, how many went live in the past twelve months.
- **Exhibit B** lands on items 1 and 7, and asks whether the program is written, adopted, and reviewed rather than what it says.
- **[Exhibit C](/glossary/exhibit-c/)** lands on item 3, model by model: what it is, when it went in, who built it, how it is classified for risk, how it was validated, when it was last tested, and whether anyone has ever taken action against you over it.
- **[Exhibit D](/glossary/exhibit-d/)** lands on item 4, but not as a lineage essay. It hands you a checklist of data-element categories and asks which ones your models use and where each came from. Look at which categories it names: race, geocoding, geo-demographics, education, income, criminal convictions. Nobody puts those on a form for no reason.
We take the exhibits apart one at a time in [How to Read the NAIC AI Evaluation Tool's Exhibits A-D](/naic-ai-evaluation-tool/); the point here is narrower. Filling the tool in is an internal exercise, and you can leave a cell blank and come back to it. An exam has a transmittal date, a record, and a findings letter at the end. That difference is why the gap record above exists, and why it is worth writing before anyone is waiting on it.
## Run a 30-minute production test
If you have not received an exam notice, run the documentation checklist against your own files. Pick one item and try to produce it in 30 minutes. If you cannot, that is a gap. Write it down with an owner and a due date. Do this for all eight items. The result is your gap record, ready before the letter arrives.
If the notice has already arrived, read the dates in it first, then handle the two administrative deliverables: the acknowledgment letter and the internal exam file, then the kickoff minutes. Run the same 30-minute test anyway, on the items your confirmed scope actually reaches. Finding the hole during collection week costs you a gap record. Finding it during the interview costs you the answer.
A caution about the list itself: your exam's scope is set by the department, not by this article. An exam can arrive pointed entirely at claims handling and never open the inventory, or it can start with the AIS Program and stay there for six weeks. Eight items is what the Bulletin and the Evaluation Tool make reachable. What actually gets reached is the examiner's call.
[^1]: NAIC Model Bulletin, "Use of Artificial Intelligence Systems by Insurers," adopted December 4, 2023: https://content.naic.org/sites/default/files/inline-files/2023-12-4%20Model%20Bulletin_Adopted_0.pdf
[^2]: NAIC, "Market Conduct Regulation," last updated May 15, 2025: https://content.naic.org/insurance-topics/market-conduct-regulation
[^3]: NAIC, "AI Systems Evaluation Tool 4.0," 2026: https://content.naic.org/sites/default/files/inline-files/AI%20Systems%20Evaluation%20Tool%204.0%20%28Clean%29.pdf
[^4]: NAIC, "AI Systems Evaluation Tool Pilot: Pilot Project Background": https://content.naic.org/sites/default/files/call_materials/Pilot%20Project%20Summary.pdf