AI Use Case Registry in Banking: Cataloguing Every AI System and Preventing Shadow AI

The Question a Registry Exists to Answer on Demand

If a regulator asked "show me every AI system you run in credit decisioning, right now," could the bank answer in an afternoon, or would it take three weeks of emailing business units and hoping nobody forgot one? Without an accurate use case registry, risk tiering is incomplete because you can't tier what you haven't catalogued, monitoring coverage has unknown gaps, and board reporting is built on whatever fraction of the portfolio happened to get reported up. The registry is the data structure every other governance process depends on — not a compliance checkbox sitting alongside them.

The traditional model inventory that SR 11-7 and RBI's model risk guidance describe covers statistical models. It was never built for LLMs, computer vision tools, document extraction pipelines, or — the fastest-growing blind spot — AI features embedded in vendor platforms the business adopted without IT ever knowing AI was involved. The use case registry has to extend past the model inventory to cover that full landscape, plus the business-accountability layer model inventories typically skip entirely.

Five Fields That Make a Registry Actually Useful

Identity and purpose: name, unique ID, domain, deployment type, and a plain-language description written by someone who understands the business use — because that's the field a board member or examiner reads first, and a technically accurate but unreadable description fails its only job.

Risk tier: Critical/High/Medium/Low/Minimal, the classification criteria, the date, and who classified it — reviewed at every material change and at least annually, because an untiered system is an automatic examiner flag.

Accountability: three named individuals — accountable business owner, technical owner, risk owner. "The team" is not an owner. Update these the moment someone changes role, not at the next scheduled review.

Lifecycle and validation status: current stage (development/UAT/production/under review/decommissioned), last validation date, validation expiry, and status — with automated alerts as expiry approaches, because a production system with overdue validation is exactly the condition that generates findings.

Regulatory framework and third-party status: which frameworks apply, active disclosures, and for vendor AI specifically — vendor name, contract reference, last assessment date, and whether the contract actually gives the bank enough documentation access to govern the thing. Third-party AI without that access is a gap, not a detail to note and move past.

Shadow AI Is a Process Failure, Not a Rogue-Developer Problem

Most shadow AI in banking today isn't a developer circumventing controls — it's a vendor shipping a generative AI feature into a product update that a business unit already had a contract for, and nobody re-flagged the tool as "now an AI system" because it never was one when it was originally procured. That's a process design gap, and it closes with three controls working together, not with more developer training.

A mandatory intake process means no AI system reaches production without a registry record — enforced by making deployment authorization impossible without one, not by asking nicely. Annual self-attestation by business units creates a documented trail that matters the day an unregistered system is eventually discovered. And procurement keyword flagging — "AI," "machine learning," "generative," "intelligent" triggering an automatic intake workflow — catches third-party AI at the point of purchase instead of after it's already live. None of this requires major technology investment; a well-designed intake form and a procurement keyword rule deliver governance value well out of proportion to what they cost to build.

India BFSI Context: Board Evidence, PMJDY Flagging, and NPCI Exposure

The board-oversight direction set by RBI's FREE-AI Committee report (constituted December 2023, published August 2025) requires that the board have visibility into the full AI portfolio, not just a handful of flagged high-risk systems. **** A complete registry is the only evidence artifact that actually demonstrates that board-level visibility is real rather than claimed.

Systems serving PMJDY account holders need an explicit registry flag, because that population's low credit history, informal income documentation, and first-generation banking access make it the segment most likely to be poorly served by a model that performs fine on average — and you can't check segment-level fairness for systems you haven't flagged as touching that segment. Priority-sector systems (agricultural credit, MSME) carry their own examination scrutiny under RBI's priority-sector guidelines and deserve the same flagging treatment for the same reason. Any system processing personal data may carry DPDP Act sub-processor obligations through its AI vendors, and an accurate third-party flag is what lets the bank manage those obligations systematically instead of discovering them reactively when a vendor relationship goes wrong. AI embedded in UPI transaction processing or real-time payment decisioning should be flagged distinctly too, so any NPCI reporting obligation that applies doesn't get missed simply because nobody connected the system to its regulatory category.

A Registry Decays Unless Someone Owns Keeping It Current

A registry that was accurate once and never checked again is worse than no registry — it creates false confidence that coverage is complete when it's actually drifting. Split the maintenance responsibility three ways: system owners keep their own records current and flag changes as they happen; the governance function owns intake and periodic completeness review; internal audit tests completeness by actually verifying that production systems show up in the registry and match their real deployed state. An annual completeness audit against the IT asset inventory and the validation worklog catches drift before an examiner does. Retire records, never delete them — a decommissioned model's record, including why it was retired and under whose accountability it ran, may be needed years later if a decision it made is ever challenged.

Action Checklist for Your Use Case Registry

1. Make deployment authorization technically impossible without a corresponding registry record — no exceptions process that quietly bypasses this.
2. Flag every system touching PMJDY, priority-sector, or UPI/payment processing explicitly, not just by inferring it from domain tags.
3. Require three named owners (business, technical, risk) per system, updated the moment any of them changes role.
4. Run an annual completeness audit comparing the registry against the IT asset inventory and validation worklog.
5. Retain decommissioned system records permanently — never delete a retired model's registry entry.