AI Model Inventory for Banking: 9 Required Fields, What RBI Examiners Look For, and How to Include LLMs and Agentic Systems

When an RBI examiner asks for a bank's AI model inventory, they are not asking for an MLflow export or a SageMaker Model Registry listing. They're asking for a governance document that answers: what AI systems does this bank run, who is accountable for each one, what's its risk classification, and is it actually compliant with the bank's own model governance requirements? Most banks that have invested in MLOps infrastructure have a model registry — a technical catalogue of versions, parameters, and artifacts. Very few have an AI model inventory in the governance sense: a complete, current, auditable record covering third-party vendor AI, embedded AI inside vendor platforms, and whatever shadow AI business units deployed without central review.

Either way, that gap matters for the same reason: the scope RBI is clearly moving toward covers a far broader set of deployments than a typical internal MLOps catalogue was ever built to track.

What the inventory must contain: 9 fields

1. System identifier and description. A unique ID, a human-readable name, the business function (credit decisioning, fraud detection, customer service, document extraction, regulatory reporting), the deployment pattern (batch, real-time, agentic), and the owning business unit. The same model deployed for two different use cases is two inventory entries with two different risk profiles — never one entry covering both.

2. Risk tier classification. Critical, High, Medium, Low, or Minimal, with documented rationale, since tier drives everything downstream — validation frequency, monitoring rigor, committee oversight, board reporting inclusion. A model used in credit decisioning can't be classified Low risk without a documented exception a committee actually reviewed. For LLMs and agentic systems, tier criteria need to go beyond accuracy and performance to cover autonomy scope, irreversibility of actions, and the customer population served.

3. Model type and technology. Statistical model, ML model, LLM, agentic system, rules-based-with-ML, or vendor black-box — plus the specific technology: foundation model and version for LLMs, framework for ML models. For vendor models, record vendor name, product name, and version, and flag explicitly when the version is floating rather than pinned — a floating vendor LLM API deployment is a governance finding in itself, not just a technical detail.

4. Validation status and next review date. Most recent validation date, who validated it, the outcome, and the scheduled next review. An overdue validation without a documented exception and committee sign-off is a finding examiners catch quickly, because it's one of the easiest things to check against the inventory alone.

5. Business and model owner. A named business owner (accountable for the model's use in the business process, at VP/director level — never a team name), a named model owner (accountable for technical governance), and an escalation path if either is unavailable. "Orphaned" models — where the original owner left and no successor was assigned — are one of the most common findings examiners surface, precisely because nobody budgets time to clean up ownership after someone's departure until an examiner forces the issue.

6. Regulatory coverage and compliance status. Applicable frameworks for this system (RBI's model risk guidance, EU AI Act Annex III where relevant, SR 11-7/SR 26-2, SEBI algo rules, DPDP Act) and compliance status against each: compliant, compliant with conditions, in remediation, or non-compliant with a documented exception. Non-compliant with no documented exception is an immediate escalation item, not a line item to revisit next quarter.

7. Monitoring status and last threshold review. Whether active monitoring exists, what's tracked, when thresholds were last reviewed, and the last alert or exception. "Manual quarterly review" is not adequate monitoring for a Critical or High tier system in production — specify exactly what's being monitored (performance, fairness, behavioral consistency, drift, output distribution) with a documented rationale for each threshold.

8. Data residency and third-party classification. Internal vs. third-party, the data residency of training and production data (India-resident, cross-border, mixed), and for vendor models, whether the contract includes the governance clauses the bank requires. For cross-border data, document the legal basis and any applicable localization assessment — this is specifically important for Indian banks given RBI's payment-data localization directive, even though it applies more narrowly than a blanket personal-data rule.

9. For LLMs and agentic systems — authorization scope and constraints. Foundation model and version (pinned or floating), system prompt/behavioral constraints, tool authorization scope for agentic systems (what tools, what accounts, what transaction limits), human-in-the-loop design, and multi-agent dependencies. An agentic system without a documented authorization scope in the inventory is an ungoverned autonomous system — arguably the highest-risk category in the whole inventory, and the one most likely to be missing entirely.

Common inventory gaps at examination

India-specific inventory requirements

Data localization field. Every entry should document where training and inference data resides — Indian jurisdiction, cross-border, or mixed — with the inventory as the single source of truth for which systems have a documented data residency exception and its approval basis.

Proxy variable fairness coverage field. For credit, fraud, or segmentation models, record whether India proxy variable fairness testing (caste/religion/language/disability) has been run, when, and with what outcome. A credit model entry with no proxy variable fairness record is a visible gap in the fairness domain examiners probe — detectable from the inventory alone, without even reaching the validation report.

DPDP Act data fiduciary classification. For every system processing personal data of Indian residents, record whether the bank acts as data fiduciary or processor, the consent basis, and how a customer can exercise deletion, correction, or access rights for data used in that decision. This field is genuinely new as of 2023, and most legacy inventory templates still don't have a column for it.

What to fix in the inventory this quarter

1. Run a shadow AI discovery exercise across business units now, with self-certification required from unit heads — don't wait for an examiner to find the gap first.
2. Pin every floating LLM version in production, or explicitly reclassify unpinned deployments as higher risk with tighter monitoring.
3. Add a DPDP data fiduciary classification field if the current template doesn't have one.
4. Run an owner-confirmation sweep this quarter and tie future sweeps to HR offboarding triggers automatically.
5. Add a proxy variable fairness coverage field to every credit, fraud, and segmentation model's inventory entry.

Zytra's AI asset registry auto-discovers deployments across cloud providers, model registries, and vendor platforms, flagging governance gaps as it populates the inventory. Request a demo to see one inventory view covering internal, third-party, and shadow AI together.