An AI use case inventory template for an insurer needs 21 fields on day one, and every one of them can be traced to a text a regulator or standards body has published: what the system is and which version runs, whether it is in use, in development or retired, what it does and with which inputs, whether it was built or bought, its risk tier and owner, its validation, monitoring and discrimination testing, its change log and approvals, and the rules that apply where it is used. The template below lists each field with its source. The harder question is how to fill it: from a survey of business units, which misses the AI that arrives inside vendor software, or from the contracts, release notes and invoices where that AI shows up. That second route is what Botminds' AI Governance & Model Inventory automates.
The fields matter because the inventory is the first document an examiner asks for. The NAIC's model bulletin lists an insurer's inventories and descriptions of predictive models and AI systems among the documents a department may request (NAIC Model Bulletin, Section 4), and the NAIC's draft evaluation tool, piloted by twelve states in 2026, says so in its instructions for high-risk systems:
“[R]egulators may request information on the company’s risk assessment and a model inventory if such information has not otherwise already been provided.”
NAIC AI Systems Evaluation Tool, draft 4.0, Exhibit C instructions
What should an AI use case inventory template include?
It should include the fields that three groups of texts ask for, and little else at first. The NAIC bulletin asks for inventories and descriptions of predictive models, detailed documentation of their development and use, and assessments of drift and auditability (guideline 3.3). New York's Circular Letter No. 7 asks for an up-to-date inventory that covers systems in use, systems under development and systems recently retired, and for a description of how each system operates, including its inputs and their sources and its purpose (NY DFS, 11 July 2024, ¶29). Colorado's amended regulation 10-1-1 asks life, private passenger auto and health insurers for a “Documented up-to-date inventory, including version control,” with each model's purpose and outputs (3 CCR 702-10, section 5.A.9).
Two other texts fill out the columns. The NAIC's evaluation tool asks, for each high-risk system, its name and version, model type, implementation date, whether it was developed internally or by a third party with the vendor's name, the company's risk classification, its risks and limitations, and whether it automates, augments or supports a decision (NAIC tool, Exhibit C). And NIST's AI Risk Management Framework makes the inventory a governance control in its own right: GOVERN 1.6 calls for mechanisms to inventory AI systems, resourced according to risk, and GOVERN 1.7 for processes to decommission them safely (NIST AI 100-1).
An AI use case inventory template for insurers: 21 fields and the text behind each
| Field | What to write | Asked for by |
|---|---|---|
| 1. System ID, name and version | A stable ID, a plain name and the version in use | NAIC tool, Exhibit C; Colorado 5.A.9 (version control) |
| 2. Status | In use, in development, or retired (with the date) | NY Circular Letter 7, ¶29 item 2 |
| 3. Business area and use case | Pricing, underwriting, claims, fraud, service, marketing or other; one sentence on the use | NAIC tool, Exhibits A and C |
| 4. Purpose and outputs | What decision it informs and what it produces | Colorado 5.A.9; NY ¶29 item 3 |
| 5. Inputs and their sources | Each input, internal or external, with the supplier | NY ¶29 item 3; NAIC tool, Exhibit D |
| 6. AI type and degree of autonomy | Machine learning or generative; supports, augments or automates a decision | NAIC tool, Exhibits C and D |
| 7. Built or bought | In-house, third party or hybrid; vendor name, product and contract reference | NAIC tool, Exhibit C; NAIC bulletin 4.0 |
| 8. Implementation date | When it went live, or when a vendor switched it on | NAIC tool, Exhibits A and C |
| 9. Consumer and financial impact | Direct consumer impact (yes/no); material financial impact (yes/no) | NAIC tool, Exhibit A |
| 10. Risk tier and reason | Your tier, and the sentence of policy that puts it there | NAIC tool, Exhibit C; NAIC bulletin, Section 3 |
| 11. Known risks and limitations | What it cannot do, and where it is weak | NAIC tool, Exhibit C |
| 12. Model owner and business owner | Named people, not teams | NAIC bulletin 2.3; NIST GOVERN 2.1 |
| 13. Validation | Last date, method, validator, next date due | NAIC bulletin 3.4; NAIC tool, Exhibit C |
| 14. Monitoring and drift | What is monitored, how often, last result | NAIC bulletin 3.3; Colorado 5.A.12; NY ¶29 item 6 |
| 15. Unfair discrimination testing | Method, last date, result, next date | NY ¶17; Colorado 5.A.11 |
| 16. Change log | Each material change, its rationale and who approved it | NY ¶29 item 4; Colorado 5.A.10 |
| 17. Approvals | Who approved use, and when; who approved each change | NAIC bulletin 3.1 |
| 18. Rules that apply | States and lines where it is used, and the rules each brings | Your rule map |
| 19. Consumer notice and complaints | How consumers are told and how a complaint reaches the owner | NAIC bulletin 1.9; Colorado 5.A.7 |
| 20. Retirement | Date, reason, what replaced it, what was kept | NY ¶29 item 2; NIST GOVERN 1.7 |
| 21. Evidence links | Where each document behind the row is held | NAIC bulletin, Section 4 |
Is the unit a model, a system or a use case?
Use one row per AI system in one use, and note the model versions inside it. The texts do not agree on the unit. The bulletin speaks of AI systems and predictive models; the NAIC tool's Exhibit A counts “AI System Model(s)” by operational area and lists use cases beside them; Colorado inventories each external data source, algorithm and model. The tool itself admits the ambiguity: “There may be some instances where a company feels information should be provided in relation to the AI System and not the Model or vice-versa,” and tells companies to settle it with the regulator.
A row per system-in-use survives those differences. If a fraud score is used both to refer claims to the special investigations unit and to set a payment hold, that is two uses with two risk tiers, and two rows sharing a model ID. If a vendor ships a new model version inside the same product, the row stays and the version field changes, which triggers the change log. The NAIC tool's Exhibit A then becomes a count of rows by business area, and Colorado's inventory a filter on rows that use external consumer data.
Why does the template need retired and in-development rows?
Because New York asks for them, and because an examiner reviewing outcomes from last year is examining systems that may no longer run. Circular Letter No. 7's inventory covers systems implemented, under development and recently retired, and the NAIC bulletin's program covers every phase of a system's life cycle through retirement. A template with only a production list cannot answer either.
In-development rows have a second use: they are where approval happens. If a system enters the inventory only when it goes live, the inventory shows decisions only after they were made. In the fictional sample register described below, the fictional exam's inventory question was answered as 148 systems in use, 7 in development and 6 retired in the last 24 months. Our guide to Circular Letter No. 7 explains what “recently retired” means in practice and what to keep for a retired system.
Where do you fill each field from? Not only from a survey
Fill each field from the document that already holds it, and use the survey to confirm rather than to discover. An annual survey of business units finds the models a team built and remembers. It misses three kinds of AI: features a vendor switches on in a release of software the insurer already licenses, tools a department buys on a purchase order, and generative assistants added to platforms the insurer uses for something else. In the NAIC's homeowners survey, 42% of the 2,413 models insurers listed were developed by a third party (NAIC, 2023), and those are only the ones the respondents knew to list.
Take a sample insurer as it runs through AI Governance & Model Inventory: Calder Ridge Insurance Group, a fictional carrier writing personal auto, homeowners, small commercial and term life in 14 states. By 12 October 2026 its register held 148 systems, and 17 of them had been found in documents rather than filed by an owner: a call-summary tool in an order form, a letter-drafting assistant on an invoice for 180 seats, a claim document summariser in release notes, and a reserve recommender in a contract amendment. In the quarter, the AI finder read 412 documents: 61 contracts, 118 release notes, 203 invoices and 30 vendor questionnaires.
Who fills which fields of the inventory, before and after agents read the documents
Today
Sends the annual survey, chases replies by email and merges spreadsheets by hand.
With agents
Starts from rows proposed from contracts, release notes and invoices, each with its clause quoted, and registers or dismisses them.
Still theirs: Decides what goes on the register
Today
Writes the description from memory when asked, often after go-live.
With agents
Confirms a drafted model card where every line cites its source document.
Still theirs: Accepts ownership in writing
Today
Learns of a refit or vendor retrain at the next scheduled review.
With agents
Sees the validation field marked expired the day a change lands, with the tests the tier needs.
Still theirs: Signs the validation
Today
Holds the contracts but not the list of AI features they allow.
With agents
Sees, per vendor tool, audit rights over the model, test evidence and the renewal date.
Still theirs: Negotiates the terms
Today
Maps systems to state rules once a year in a separate sheet.
With agents
Reviews a rule map kept per system, state and line, with every gap listed.
Still theirs: Signs the compliance link
A row filled from a contract, not a survey, in AI Governance & Model Inventory
Is a model card the same as an inventory row?
No: the inventory row is the index, the model card is the page behind it. The row holds the fields an examiner filters on, such as status, tier, owner, vendor and validation date. The card holds the description the bulletin and New York ask for in prose: purpose, where the system runs, inputs, output, training data, who uses it, why it carries its tier and its known limits. Most model card templates in circulation were written for teams who build models; an insurer's card also has to work for a model it bought and cannot see inside.
The discipline that makes a card defensible is citation. In the sample, the model card writer drafted the reserve recommender's card from three documents, the amendment, the release notes and the claim system's usage report, and every line points to its source. Where no document answers a field, the field stays empty: the card says the vendor supplied no test for unfair discrimination, rather than guessing at one.
A model card in AI Governance & Model Inventory, every line cited
An AI risk assessment template, in one sentence per tier
The risk field needs a rule, not a score. The NAIC bulletin asks insurers to scale controls to their own assessment of risk, weighing the decision a system informs, the harm a consumer could suffer, how far humans are involved, how explainable the outcome is and how much the insurer relies on third parties. The NAIC tool asks for “Model risk classification (high, medium, low, etc.)” and leaves the criteria to the company, then asks how the company assesses risk.
A one-sentence rule per tier answers that question. In the sample insurer's policy, High means the output sets or changes a consumer's price, eligibility, claim payment or fraud referral, validated every 12 months; Medium means it reaches a consumer but decides nothing, every 24 months; Low means internal use only, every 36 months. The reserve recommender is High because reserves set settlement authority and offers on injury claims. The tier field in the template then carries the tier and the clause of policy that put it there, which is what an examiner reads.
How do you know the inventory is complete on day one?
You reconcile it against every place AI enters the company, and you write down what you checked. Completeness cannot be proved by the inventory itself; it is shown by the sources it was compared against. The NAIC bulletin makes the point indirectly: among the documents a department may request is the program's scope, including any AI systems the program does not address.
Eight reconciliations before calling an AI inventory complete
- The contract repository
Every software and data contract, amendment and order form: search for rights to enable AI or machine-learning features.
- Vendor release notes
Each release of licensed platforms since the last review: features switched on by default are the usual gap.
- Accounts payable
Software and services invoices above a threshold: tools bought by departments surface here first.
- The model repository and change requests
Every model with a deployment, refit or change request, including those under development.
- Rate and form filings
Rating plans and underwriting rules that rely on scores or models, internal or licensed.
- Vendor questionnaires and SOC reports
What vendors disclose about AI in their own products.
- Last year’s retirements
Systems switched off in the last 24 months, with their final documentation kept.
- The business-unit survey
Last, to confirm owners and uses for rows already found, and to catch anything homegrown.
Free template or software?
Start with the template; move when keeping it current costs more than the software. A spreadsheet with the 21 fields above is a sound first inventory, and the table on this page is free to copy. What a spreadsheet cannot do is notice that a vendor has switched on a feature, reopen a validation when a model is retrained, or keep a history of who signed what. Those are the points at which teams either add weekly reconciliation work or add software.
The measure that decides it is the time to answer an examiner's AI questionnaire and the number of systems found that nobody filed. Our guide to AI governance software shows how to take both baselines before buying, and what to ask any product, including this one.
Questions people ask
Is there a free AI inventory template for insurers?
The 21-field table on this page is free to copy. Each field names the text it comes from, so you can drop the ones that do not apply: Colorado's fields, for example, bind only life, private passenger auto and health insurers that use external consumer data in Colorado.
What is the difference between an AI inventory and an AI use case inventory?
An AI inventory lists systems; a use case inventory lists what each system is used for. Insurers need both views, because one model can serve two uses with different risk, and the NAIC evaluation tool counts systems by business area and asks for use cases beside them.
How often should an AI inventory be updated?
Continuously for status and changes, and with a documented review at least annually. New York asks for an up-to-date inventory, and Colorado asks for comprehensive annual reviews of the governance framework and its documentation (3 CCR 702-10, 5.A.14). An annual refresh alone will miss vendor releases between reviews.
Should vendor AI tools be on the inventory?
Yes. The NAIC bulletin's program covers AI systems used in regulated practices whether developed by the insurer or a vendor, and the evaluation tool asks for the vendor's name for each high-risk system. In the sample register, 87 of 148 systems came from vendors.
What goes in an AI model card for insurance?
Purpose, where the system runs, inputs and their sources, output, training data, users, the reason for its risk tier, known limits and any interim controls, each with the document it came from. For a vendor model, add the contract clause that switched it on and what evidence the vendor has supplied.