AI Use-Case Inventory vs. Model Inventory: A Two-Register Reconciliation Crosswalk

Most SR 26-2 implementation plans focus on the model inventory. The harder governance problem is everything that doesn’t make it in.

A credit-decisioning model? In the inventory, validated, tiered High. A contract-drafting LLM your legal team uses daily? Probably in a Shadow IT spreadsheet somewhere, or nowhere at all. A vendor-embedded fraud-scoring feature inside your payments stack? Same gray zone. SR 26-2 and OCC Bulletin 2026-13 drew sharper lines around what counts as a model. That clarity is useful—but it created a governance gap for the AI tools that sit below that line and still need oversight.

The solution isn’t squeezing everything into the model inventory. It’s running two registers—an AI use-case register for everything, a model inventory for what meets the model definition—and building a crosswalk that keeps them reconciled.

TL;DR

• SR 26-2 (April 2026) retains the enterprise model inventory requirement from SR 11-7, but draws a sharper boundary around what qualifies as a “model”
• That sharper boundary means many AI tools—LLMs, vendor-embedded features, decision-support tools—fall outside model risk management but still carry material operational and compliance risk
• The practical solution: maintain two registers (AI use-case inventory + model inventory) and a reconciliation crosswalk with shared IDs, scope decisions, and status tracking
• The FS AI RMF (Treasury, February 2026) and NIST AI RMF both require AI inventory as a foundational governance output—so the use-case register isn’t optional

What SR 26-2 Actually Changed About the Inventory

SR 26-2, issued jointly by the Federal Reserve, OCC, and FDIC on April 17, 2026, kept the enterprise model inventory as a foundational requirement. Every system that meets the model definition—a quantitative method that produces outputs materially influencing consequential business decisions—must be inventoried with ownership, use case, risk tier, validation status, monitoring status, and last review date.

What changed is the definition’s practical application. SR 11-7’s broad language had institutions inventorying nearly anything that touched a number. SR 26-2’s risk-based approach is more precise: the rigor of model risk management practices should scale with the model’s risk profile. The implication is that examiners will now push back on two failure modes: under-inventorying (missing actual models) and over-inventorying (treating every spreadsheet and rule engine as a full model requiring independent validation).

That precision creates a boundary. On one side: the model inventory, subject to full MRM oversight. On the other side: a growing population of AI tools that don’t meet the model definition but carry real risk.

The Gap SR 26-2 Didn’t Fill

The tools that fall below the SR 26-2 model threshold include some of the highest-volume AI in most institutions:

Employee-facing LLM tools. Microsoft Copilot, ChatGPT Enterprise, and similar tools used for document drafting, code generation, and internal analysis. They’re producing outputs that influence decisions without technically being the decision engine. They’re not in your model inventory. They’re probably in your shadow AI register—if you have one.

Vendor-embedded AI. Your payments processor’s fraud-scoring feature, your KYC vendor’s document-verification engine, your core system’s anomaly-detection module. These tools run under vendor contracts. You don’t own the model. But you’re responsible for the outputs. SR 26-2 requires third-party model oversight for vendor models that meet the model definition—but many of these embedded features don’t.

Decision-support tools. Risk-scoring tools that output a score your analysts then use to make a decision. Rule-based engines augmented with ML components. These occupy a gray zone: the output is quantitative, the influence is material, but a human is nominally in the loop. Whether they meet the model definition depends on how they’re used—and that determination needs to be documented somewhere.

SR 26-2 doesn’t govern these tools through model risk management. But the Treasury FS AI RMF, released in February 2026 with 230 control objectives, makes AI inventory its own control objective (GV-1.6), covering everything from shadow IT discovery to portfolio-level risk analysis. And the NIST AI RMF names inventory as a GOVERN 1.6 output, with the MAP function depending on it for all downstream measurement and management.

The inventory isn’t a model-risk-only requirement. It’s an AI governance requirement. Which means you need a register that covers both.

Two Registers, One Crosswalk

The architecture that handles this cleanly is two registers connected by a shared ID:

Register 1 — AI Use-Case Register: Captures every AI tool in use, regardless of whether it meets the model definition. This is the discovery layer. Everything goes here first. Fields include use-case name, business unit, tool/vendor, data inputs, output type, customer impact (Y/N), PII involved (Y/N), risk tier, scope determination (model or non-model), and governance routing.

Register 2 — Model Inventory: Contains only the systems that meet your SR 26-2 model definition. Fields include model ID, model name, model type, use case, development source (in-house vs. vendor), risk tier, validation status, validation date, monitoring status, last review date, owner, and MRM approval status.

The crosswalk connects them through a shared use-case ID assigned at intake. Every new AI tool gets an ID in the use-case register before it goes anywhere else. If it meets the model definition, an entry is created in the model inventory under the same ID. If it doesn’t, the scope determination is documented in the use-case record with the reviewing authority’s sign-off.

Crosswalk Fields

How Status Changes Flow

Three status changes require crosswalk updates:

Scope escalation (use-case → model): The tool’s outputs begin directly driving a consequential decision, the tool is retrained on proprietary data, or volume/customer impact increases to a material level. Action: create a model inventory entry, update the use-case record with the model ID and status “escalated to MRM,” route to model validation queue.

Decommissioning: The tool is retired. Update both registers to “decommissioned” status. Retain the use-case record and any model validation artifacts per your records retention schedule. Document the decommissioning authority and date.

Scope de-escalation (model → use-case): Rare but real—a model’s use changes so that it no longer drives consequential decisions. Requires CRO or model risk officer sign-off. Update the model inventory to “decommissioned,” document the rationale in the use-case record, and route to the appropriate non-model governance program.

Avoiding the Three Common Crosswalk Failures

Orphaned models. A model in the inventory with no use-case record means it bypassed intake. Orphaned models lack scope rationale, data-handling review, and business-unit ownership documentation. Pull the model inventory and use-case register side by side in your quarterly reconciliation. Any model ID with no use-case counterpart is an orphan.

Scope decisions without rationale. “We decided this isn’t a model” is not a defensible determination under SR 26-2. The crosswalk must capture who made the determination, what criteria they applied, and when. Examiners asking about your AI governance program in 2026 are increasingly asking about the out-of-scope decisions, not just the inventory itself.

Stale status. A use-case record that says “pilot” for an AI tool that’s been in production for 18 months is a documentation control failure. Link your intake and change-management process to the use-case register so that status changes (pilot to production, v1 to v2, active to sunsetting) automatically trigger a crosswalk review.

The Reconciliation Cadence

Run reconciliation quarterly. The agenda for a 60-minute reconciliation session:

1. Pull both registers by shared ID — exports should be date-stamped
2. Flag unmatched IDs — use-case entries with no model counterpart (scope check needed) and model entries with no use-case counterpart (orphaned models)
3. Flag status mismatches — active in one register, decommissioned in the other
4. Review escalation candidates — use-case entries with unchanged “non-model” scope that have been in production more than 12 months (particularly vendor-embedded tools)
5. Document dispositions — each flag gets a disposition (confirmed, escalated, corrected) logged in the crosswalk exception register
6. Update last-reconciliation dates in both registers

For institutions subject to SR 26-2 examination, the crosswalk reconciliation log is the artifact examiners will ask for when they probe your AI governance completeness. “We reconcile the registers quarterly” without the log to show for it is the same as no reconciliation at all.

So What?

SR 26-2 didn’t make AI governance simpler. It made the model boundary crisper—which means more AI tools now sit in a governance gray zone that your AI use-case register has to cover. The practical gap isn’t between compliant and non-compliant institutions. It’s between institutions that know what AI they’re running, have documented scope decisions, and can show a reconciled picture on demand—and those that can’t.

Two registers with a maintained crosswalk isn’t exotic. It’s what a defensible AI governance program looks like when the model definition has teeth. Build the intake process, assign the shared IDs, and run the quarterly reconciliation before an exam forces you to reconstruct it in real time.

If you’re building or refreshing your AI use-case inventory, the AI Risk Assessment Template & Guide includes an AI use-case inventory tab with auto-tiering, an eight-example worked set, and a shadow AI discovery register you can use to close the gap between what you think you have and what’s actually running in production.

Related reading:

• SR 26-2 and OCC 2026-13: What the New Model Risk Management Guidance Changes
• AI Model Inventory Template: Fields Examiners Ask For First
• Shadow AI Governance: Detection and Controls