# How to Build an AI Inventory by Line of Business for NAIC Exhibit A

> Map your insurance AI systems by line of business for NAIC Exhibit A. Use this template to capture underwriting, pricing, claims, fraud, and customer service AI.

- Source: https://insureaiwire.com/ai-inventory-by-line-of-business/
- Publication: InsureAI Wire
- Author: Simon Li
- Updated: 2026-07-30

---
When a market conduct examiner sends [Exhibit A](/glossary/exhibit-a/), the request looks simple enough: count the AI systems the company uses, sorted by operational area. But no single person knows the whole picture. Underwriting owns its models, claims has its triage tools, marketing licenses a lead-scoring platform, and customer service rolled out a chatbot. IT may have a list of servers, but that is not the inventory Exhibit A wants.

The real task is a business-line map of where AI influences insurance decisions. It is the base every other exhibit stands on, because you cannot show governance over systems you have not identified, detail high-risk models you never flagged, or trace data lineage you never recorded. The work starts with an honest list.

## What Exhibit A is asking for

Exhibit A is first in the NAIC AI Systems Evaluation Tool because it is the foundation. Regulators use it to decide whether a company's AI use is so limited or low-risk that further inquiry is unnecessary, or whether the examiner should proceed to Exhibits B through D. The question is not how advanced the models are; it is where AI influences decisions in the company [^1]. For a map of how the four exhibits connect, see the [NAIC AI Evaluation Tool](/naic-ai-evaluation-tool/) breakdown.

The tool defines an AI system broadly, as a machine-based system that can generate predictions, recommendations, content, or other outputs that influence decisions, operating with varying levels of autonomy from supportive to augmented to automated [^1]. That definition is intentionally wide. It catches the vendor feature embedded in a claims workflow, the underwriting model built by a third-party data provider, and the internal tool the data science team forgot to mention. If it influences an insurance decision with some degree of autonomy, it belongs in the inventory.

Exhibit A asks for a quantitative count by operational area, and every column is a number rather than a yes or no. The carrier reports how many systems sit in each area, how many fall under each of the other three counting columns, and what the use cases are [^1]. Those numbers are what a regulator reads before deciding whether to go on to governance in [Exhibit B](/glossary/exhibit-b/), high-risk models in [Exhibit C](/glossary/exhibit-c/), or data types in [Exhibit D](/glossary/exhibit-d/) [^1]. Worth being precise about what changes hands: the exhibit asks only for counts. The inventory stays with you, unsubmitted, and it is what makes each count defensible when an examiner picks one and asks how you got it.

## Why organize by line of business, not by model

The natural instinct is to sort by model name, vendor, or technology stack. Regulators organize the request around the operational area and decision. The same vendor platform can serve both low-risk marketing scoring and high-risk underwriting. Two internal models built on the same codebase can sit in different risk buckets if one ranks work queues and the other recommends claim denials.

Organizing by business line also solves the ownership problem. The NAIC Model Bulletin looks for a written AI Systems Program, and it suggests the governance framework consider committees drawn from "appropriate disciplines and units within the Insurer, such as business units, product specialists, actuarial, data science and analytics, underwriting, claims, compliance, and legal" [^2]. That program is the governance layer behind the inventory; for a practical breakdown of what it requires, see [AI governance in insurance](/ai-governance-in-insurance/). When the inventory is owned by business lines, the people who can answer follow-up questions are already attached to each entry. When it is owned by IT, the examiner's follow-up questions about consumer impact get routed through three departments before anyone can answer.

Assign each operational area a business owner and a compliance contact before filling in the systems. The owner knows what the system does. The compliance contact knows whether it has been tested, documented, and reviewed.

## The 15 operational areas and how to group them

Exhibit A lists 15 operational areas, all in scope and grouped here into five familiar clusters to make the inventory manageable.[^1]

**Table [row-headers]:** Exhibit A operational areas grouped into five ownership clusters

| Cluster | Operational Areas | Typical Owner |
|---|---|---|
| Customer acquisition | Marketing; premium quotes and discounts | Marketing or distribution lead |
| Underwriting and pricing | Underwriting and eligibility; ratemaking and rate classification | Chief underwriter or chief actuary |
| Claims and service | Claims and adjudication; customer service; fraud, waste, and abuse | Claims operations lead |
| Health utilization | Utilization management and prior authorization | Health plan operations lead |
| Back office and support | Investment and capital management; legal and compliance; [producer](/glossary/producer/) services; reserves and valuations; catastrophe triage; reinsurance; other insurance practices | COO, CFO, or GC depending on area |

This clustering is our practical routing method. The tool itself still presents 15 operational areas, while the internal worksheet lets business owners fill out their sections without becoming experts on the whole company.

Three areas deserve extra attention because they are often undercounted. Producer services includes AI tools used to route leads, score agents, or recommend which producers handle which accounts. Catastrophe triage includes models that rank claims after a hurricane or wildfire. Reinsurance includes treaty pricing models and ceding decisions. Their use can be substantial even when the documentation is thin. The business-line risk map in [AI use cases in insurance by business line](/ai-by-business-line/) helps expose those gaps.

## What to collect for each system

A usable inventory needs more than a count. For each AI system, the business owner should be able to answer a short set of questions. Four of them are Exhibit A's own columns: operational area, direct consumer impact, material financial impact, and the use case. The system name, autonomy level, implementation date, vendor flag, and last validation date are what Exhibit C asks model by model, and the owner and decision-context fields are ours rather than the tool's [^1]. Collecting them in one pass means the later exhibits do not send you back to the same business owners.

- **Operational area.** Which of the 15 categories does it fall under?
- **System name and version.** What is the system called internally? If it is a vendor platform, what module or feature is being used?
- **Function.** What output does it produce: a score, a recommendation, a classification, a triage decision, or generated content?
- **Decision context.** Does it influence a consumer-facing decision, an internal workflow, or both?
- **Direct consumer impact.** Does the output affect coverage, eligibility, pricing, claim payment, or communication to a consumer? This field often moves a system into the high-risk column.
- **Material financial impact.** Does the system affect reserves, pricing, reinsurance, or capital allocation? If so, it matters even if it does not touch the consumer directly.
- **Autonomy level.** Is it supportive, augmented, or automated? A system that recommends but requires human action differs from one that executes without review.
- **Implementation date.** Was it deployed in the last 12 months? Newer systems often lack testing and monitoring records.
- **Owner and data steward.** Who is accountable for the model, and who can explain where its data comes from?
- **Vendor or third-party flag.** Was the system developed internally or acquired from a vendor? If vendor, who has contractual audit rights?
- **Last validation or review date.** When was the model last tested for accuracy, drift, or [unfair discrimination](/glossary/unfair-discrimination/)?

Most fields can be answered in a single sentence. The hard part is finding the person who knows the answer.

### The worksheet, with one row filled in

Here is the full field set as a worksheet, completed for one hypothetical system at a regional P&C carrier.

<div><a class="download-cta" href="/downloads/exhibit-a-ai-inventory-worksheet.xlsx" download><span class="dl-label">Download the Exhibit A inventory worksheet</span><span class="dl-ext">XLSX</span></a></div>

The download has the eleven fields as columns, the example row pre-filled, and a reference tab listing the fifteen operational areas by cluster. Prefer plain text? Open the **Ask AI** menu at the top of this article and choose **Copy for AI** to grab the page as Markdown.

**Table [row-headers]:** Example AI inventory record with the eleven fields needed for one system

| Field | Example entry |
|---|---|
| Operational area | Claims and adjudication |
| System name and version | ClaimSort triage module v4.2 (vendor platform feature) |
| Function | Scores incoming property claims 0-100 and routes the top decile to senior adjusters |
| Decision context | Internal workflow, with indirect consumer effect through settlement speed |
| Direct consumer impact | Yes: routing affects time-to-payment; low-score claims wait longer |
| Material financial impact | Yes: routing errors concentrate reserve risk in the fast lane |
| Autonomy level | Augmented: recommends routing, adjuster can reassign, override rate 4% |
| Implementation date | 2026-03 (inside the last 12 months, flag for examiner follow-up) |
| Owner and data steward | Claims operations lead (owner); vendor data team via contract clause 7 (steward) |
| Vendor or third-party flag | Vendor. Audit rights: annual model documentation review, contract §12 |
| Last validation or review date | 2026-05-14, quarterly drift review, next due 2026-08 |

Two things to notice about the filled row. The autonomy answer includes the override rate, because "augmented" without an override rate is exactly the kind of label an examiner probes. And both flag fields point to a specific contract clause, which is the difference between an answer and a promise to look it up later.

## The four questions that drive risk

Exhibit A asks four questions that shape the rest of the exam: how many AI system models are in use, how many have direct consumer impact, how many have material financial impact, and how many went in over the past twelve months.[^1] Treat them as risk gates.

**Does the system directly affect consumers?** If yes, the system is likely high-risk. Coverage, pricing, eligibility, claims settlement, and [prior authorization](/glossary/prior-authorization/) all fall here. The tool does not leave this to judgment. Models that augment or automate consumer decision making count as having direct consumer impact, and augmentation is defined as suggesting an answer or advising the human who decides [^1].

**Does the system have material financial impact?** This captures systems that do not touch consumers directly but matter to the company's financial condition. Catastrophe triage, reinsurance pricing, and reserve models are examples. They may not trigger consumer-protection scrutiny, but they can trigger financial-condition scrutiny.

**Was it implemented in the last 12 months?** Newer systems are more likely to lack documentation, validation records, and drift monitoring. The examiner will look for pre-deployment test evidence alongside the implementation record.

**What is the specific use case?** This is where vague labels hurt. "Fraud detection" is not enough. "Flags property claims for special investigation" is better. "Flags property claims in certain ZIP codes for special investigation" is better still, because the ZIP code is itself a data element. Geocoding and geo-demographics are two of the 25 categories Exhibit D will make you trace back to a named source [^1].

## Where carriers usually go wrong

The most common failure is an incomplete picture of what the company runs.

**Shadow AI.** Business lines adopt tools without telling compliance. A marketing team licenses an AI copywriting platform. A claims manager starts using an AI assistant to summarize notes. These tools influence work and sometimes decisions, but they never appear on an IT inventory. Ask business owners which software uses automation or predictions to help them decide, including products that nobody calls a model.

**Vendor-operated systems.** A carrier may use a vendor platform that includes AI features it does not fully understand. Build-or-buy makes no difference here. The bulletin's program is supposed to cover systems used in regulated insurance practices no matter who wrote them, and the diligence on a vendor is the insurer's own job [^2]. If the vendor cannot explain how a feature works, that gap is the carrier's problem in the exam.

**Model versus system.** A model is a statistical artifact. A system is what operates in production. Exhibit A asks about systems. A carrier with three underwriting models but one production platform should list the platform once and note the models it contains. A carrier with one model used in three different workflows should list three systems, because the consumer impact and risk profile differ by use.

## Reconcile one business line first

Perfect software is optional. What a good Exhibit A inventory cannot do without is a clear process and owners who cannot pass the question to someone else.

First, schedule a 30-minute session with each business-line leader. Give them the 15 operational areas and ask them to name every system that produces predictions, recommendations, classifications, or automated outputs. Do not ask for models. Ask for systems that influence decisions.

Second, route each identified system through the eleven fields above. For systems where the owner cannot answer, mark the gap and assign a due date. An incomplete inventory with visible gaps is far more useful than an inventory that looks complete but is missing whole categories.

Third, flag third-party systems and systems implemented in the last 12 months. These will be the examiner's first follow-up targets. Make sure someone has the vendor contracts and can locate the audit rights clause.

Finally, accept that the first version will be incomplete. Its first job is to make omissions visible and assignable. An examiner who sees a living inventory with owners and dates is likely to trust the rest of the program. An examiner who sees a pristine inventory created the week before the request is likely to dig deeper.

## Where this fits in the larger exam

Exhibit A is the first exhibit because every other answer depends on it: the tool says regulators use the Exhibit A responses to decide what to ask for next.[^1] Exhibit B tests whether your governance covers the systems you listed. Exhibit C asks for details on the high-risk systems you flagged. Exhibit D traces the data behind those systems. If the inventory is wrong, the later exhibits stop demonstrating control and start logging corrections. Sorting that list into the tiers Exhibit C asks about is [a separate pass over the register](/identify-high-risk-ai-systems/).

An inventory has a narrow job. It shows that a marketing model quietly shapes eligibility; it has no opinion on whether that model should. Once the system map is stable, [use the decision evidence pack](/insurance-ai-decision-evidence-pack/) to test whether one real AI-assisted transaction can be reconstructed.

[^1]: 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
[^2]: NAIC, "Use of Artificial Intelligence Systems by Insurers," Model Bulletin adopted December 4, 2023: https://content.naic.org/sites/default/files/inline-files/2023-12-4%20Model%20Bulletin_Adopted_0.pdf