What are the seven stages of AI model lifecycle management for banking?

The seven stages of AI model lifecycle management for banking, with the key governance requirements at each stage: Stage 1 — Problem definition and risk pre-assessment: Before any model development begins, the intended use case must be defined and risk-tiered. The risk tier (Critical, High, Medium, Low, Minimal) determines what governance requirements apply to subsequent stages. Critical and High tier determinations require risk committee approval before development resources are committed. Stage 2 — Data governance and feature engineering: Training data must meet the data governance requirements for the intended use case: lineage documentation, fairness testing for the applicable demographic variables, DPDP Act compliance review for personal data features, proxy variable assessment. A model cannot proceed to training if data governance requirements are not met. Stage 3 — Model development and documentation: During development, the model card must be started — not completed post-development but built as development proceeds. Conceptual soundness documentation written as the architecture decisions are made. SR 11-7 requires that documentation be sufficient for an independent validator to understand the model without the original developer. Stage 4 — Independent validation: Model validation is conducted by an independent function (internal MRM team or external validator). For Critical tier: external validator required for India BFSI under RBI FREE-AI. Validation covers conceptual soundness, data quality, performance benchmarking, fairness assessment, explainability review, security assessment. A model with outstanding validation findings cannot proceed to production. Stage 5 — Staged deployment: Progressive deployment (sandbox → UAT → limited production → full production) with performance monitoring at each stage gate. For LLM systems: behavioral consistency baseline established before full production. For agentic AI: scope manifest approved before any production deployment. Stage 6 — Production monitoring and maintenance: Ongoing performance monitoring, drift detection, fairness monitoring (segment-level), security monitoring. Re-validation triggers defined and enforced: material model change, significant performance degradation, distribution shift beyond threshold, material regulatory change. Stage 7 — Decommission: Controlled retirement of AI systems with regulatory record retention requirements. RBI requires that audit trails and decision records be retained for regulatory inspection periods even after the model is decommissioned. Model card archived; Forensic Replay capability maintained for post-decommission examination requests.

What triggers re-validation of an AI model in banking under RBI and SR 11-7?

Both RBI FREE-AI and SR 11-7 require that AI models be re-validated when material changes occur to the model or its environment. The following events trigger mandatory re-validation: Model changes: (a) Material change to model architecture — adding or removing neural layers, changing feature set by more than a defined threshold, changing model type (e.g., from logistic regression to gradient boosting). The definition of 'material' must be documented in the bank's model governance policy before deployment. (b) Retraining on new data — when a model is retrained on data from a different time period, a different customer population, or with different preprocessing, the trained model is substantively different from the validated model and requires re-validation. Routine retraining on expanding datasets (adding new months of data to the same distribution) may not require full re-validation but requires outcome analysis and documented sign-off. (c) Deployment context change — if a model validated for one use case is repurposed for a different use case (even if the model architecture is unchanged), re-validation is required because the use case determines what fairness, explainability, and performance requirements apply. Performance-based triggers: (d) Performance degradation beyond threshold — accuracy, recall, precision, AUC-ROC below re-validation threshold defined at validation; segment-level FPR/FNR exceeding defined bounds. (e) Distribution shift beyond threshold — KS statistic or Population Stability Index beyond defined bounds indicating the model is operating outside its validated distribution. External triggers: (f) Material regulatory change affecting the model's use case or the demographics it serves. (g) Significant incident involving the model — a customer complaint upheld by ombudsman, a regulatory finding, or an internal audit finding may trigger re-validation depending on severity. RBI eMRM June 2026: behavioral consistency failure for LLM systems is an additional re-validation trigger not present in SR 11-7.

What must a bank retain after an AI model is decommissioned?

Banks must retain AI model artifacts and decision records after decommissioning to satisfy regulatory inspection requirements and potential legal disputes. Retention requirements under Indian regulations: Under RBI's 2024 AI Circular and the DPDP Act 2023: (1) Decision records: all AI decisions affecting customers (credit approvals/rejections, fraud flags, pricing decisions) must be retained for the regulatory inspection period — typically 7–10 years for Indian banks under RBI guidelines. The retention must include the feature values used in each decision, not just the output. This is required for DPDP Act data subject access requests ('which personal data drove my loan rejection decision?') that may arrive years after the model has been decommissioned. (2) Model card: the final version of the model card for any decommissioned model must be archived. If a regulatory dispute arises about a decision made by that model, the model card documents the model's known limitations, performance characteristics, and fairness assessment at the time of deployment. (3) Validation reports: all validation reports for the model, including those for each retrained version, must be archived. These documents demonstrate that the bank conducted appropriate independent review of the model during its production life. (4) Audit trail: the access logs, governance approval records, exception reports, and incident records for the model's production life must be archived. An examiner reviewing a past incident involving a now-decommissioned model will want to understand the governance record. (5) Forensic Replay capability: the model's output for any specific past decision must remain reconstructable after decommissioning. This means retaining either the feature vectors per decision or the combination of input data and model artifact sufficient to reproduce the output. Physical model deletion is acceptable if the feature vectors are retained and can reproduce the explanation.

AI Model Lifecycle Management for Banking: Development to Decommission, RBI and SR 11-7 Requirements at Each Stage

Seven Stages, Seven Gates: What RBI and SR 11-7 Actually Require Before an AI Model Moves in Indian Banking

Model lifecycle governance is not a checklist that gets ticked off in retrospect. It is a sequence of gates, and at each one, specific evidence has to exist before the model is allowed to move forward. A model doesn't go from development to validation without documentation good enough for a validator who wasn't in the room when it was built. It doesn't go from validation to production while High findings are still open. And decommissioning a model doesn't close the bank's obligations — decision records and replay capability still have to survive for the regulatory retention window, however long after the model stopped running.

This article walks through the seven stages, the gate at the end of each one, and what RBI's frameworks and the Federal Reserve's SR 11-7 actually require — not what a generic compliance checklist assumes they require. Along the way, one clarification is unavoidable: ****. Similarly, SR 11-7 doesn't publish the pinpoint section numbers (§I, §II, §III...) this article cites stage-by-stage; references below describe the relevant expectation instead of inventing a section marker.

Stage 1: Problem Definition and Risk Pre-Assessment — What the Risk Committee Must Sign Off Before Development Starts

This stage defines the use case, the customer population it touches, and the output type — a score, a decision, a generated response — before a single line of model code gets written. The model gets risk-tiered: Critical, High, Medium, Low, or Minimal. For anything tiered Critical or High, the risk committee has to approve the use case before development begins, not after a prototype already exists and someone needs a rubber stamp.

The India detail: for a scheduled commercial bank, this approval usually routes through an existing Model Risk Management Committee or the Risk Management Committee of the Board — bodies that already exist because of RBI's outsourcing and IT governance expectations. A mid-size NBFC often doesn't have that committee structure yet, which means the "risk committee approval" step either gets invented on the spot (a slide deck to the CRO, informally) or skipped. Neither is a gate; both get flagged in an eMRM-aligned review.

In practice, risk tiering gets gamed long before anyone notices. Teams tier a model "Medium" not because it's actually medium-risk, but because Medium doesn't trigger the committee approval step that Critical and High do. The honest test isn't "what tier did we assign" — it's "would this tier survive an examiner asking why a credit-decisioning model touching 2 million customers isn't Critical." Stage gate: risk tier documented and approved, with the rationale defensible on its own, not just the label. Citations: RBI FREE-AI Framework (Aug 2025) · RBI Draft MRM Guidance (June 2026) risk-tiering mandate · SR 11-7's scope and risk-based supervisory approach.

Stage 2: Data Governance and Feature Engineering — Why India's Fairness Pre-Check Can't Copy the US Protected-Class Model

Training data lineage gets documented here, and a fairness pre-assessment runs before training starts — specifically, proxy variable testing for caste, religion, language, and disability status, since Indian datasets essentially never carry these as direct fields. A DPDP Act 2023 compliance review (consent basis, purpose limitation, data minimisation) and a data governance sign-off close the stage.

The India detail: unlike US fair-lending law, which has a standardized list of protected classes and well-worn proxy tests (redlining via ZIP code, for instance), India has no equivalent sanctioned proxy list. Surname, pincode, preferred language, and the location of the banking correspondent branch are the commonly used proxies for caste, religion, and region in practice — but teams building this pre-check are largely inventing the methodology themselves, bank by bank. That gap is real and worth naming rather than glossing over.

What actually happens without this gate: a lending model trained on historical approval data inherits whatever bias was baked into the historical approvals, and nobody notices until a regulator or a journalist runs the correlation. A fairness pre-assessment done properly takes a data scientist a day or two of genuine proxy testing — not a checkbox in a Jira ticket. Stage gate: data governance sign-off, including a documented India fairness pre-check with the specific proxies tested. Citations: RBI FREE-AI Framework (Aug 2025) Fairness and Equity Sutra · DPDP Act 2023 · India proxy-variable testing practice.

Stage 3: Model Development and Documentation — The Difference Between a Model Card Written During Development and One Written After the Fact

The model card gets started during development, as architecture decisions get made — not reconstructed afterward from memory and old Slack threads. Conceptual soundness documentation — why this architecture, what alternatives got rejected, and why — gets written in real time. SR 11-7's documentation expectations are explicit on this point: documentation has to be sufficient for an independent validator who wasn't part of the build team to actually assess the model, not just skim a summary.

A post-hoc model card has a distinct smell. It's generic — "the model uses gradient boosting for improved accuracy" — because the person writing it six months after deployment doesn't remember which three architectures got tried and discarded, and nobody saved the evidence. Rejected design alternatives are the first thing to vanish from memory, and they're often the most useful thing a validator wants to see. A model card written live, section by section, as decisions get made, costs the development team maybe an extra half-day a week; a model card reconstructed post-hoc costs the validation team weeks and still comes out thinner.

The India detail: EU AI Act Art. 11's technical documentation requirements are directly relevant for Indian banks with EU-facing operations, GIFT City entities serving European clients, or group structures with an EU subsidiary — not yet a blanket requirement for a purely domestic retail book, but increasingly the template RBI's own draft guidance is converging toward in depth. Stage gate: model card sections 1–4 complete and conceptual soundness documented before the model leaves development. Citations: SR 11-7's documentation expectations · RBI FREE-AI Framework (Understandable by Design Sutra) · EU AI Act Art. 11.

Stage 4: Independent Validation — What "External Validator Required" Actually Means for an NBFC vs. a Scheduled Commercial Bank

Independent validation covers conceptual soundness, data quality, performance benchmarking, fairness (the same India proxy variables from Stage 2, now tested against live model outputs), explainability, and security. For Critical-tier models, India requires an external validator. No model moves to production with an outstanding Critical or High finding sitting open.

The India detail, concretely: a large scheduled commercial bank typically already has a Model Validation Unit sitting organizationally apart from the model-development team — that internal separation often satisfies "independent" for High-tier models, and the bank reserves genuinely external validators (a specialist firm, an academic partner, an empanelled panel) for Critical tier only. A mid-size NBFC usually has no such internal separation — the people who could validate the model are the same people, or the same small team, who built it. For that NBFC, "external validator required" isn't a Critical-tier-only rule; it's often the only way to satisfy independence at all, which makes the cost and lead time of engaging one a real planning constraint, not a formality.

Validation reports that just say "passed" without a finding log don't satisfy this gate — and don't survive an examiner asking what was actually tested. Stage gate: validation report with every finding tracked to resolution, and zero outstanding Critical/High findings before production. Citations: SR 11-7's independent validation requirements · RBI FREE-AI Framework (Aug 2025) · RBI Draft MRM Guidance (June 2026).

Stage 5: Staged Deployment — Where the Kill Switch and the Agentic Scope Manifest Have to Exist Before Go-Live

Deployment moves through sandbox, UAT, limited production, and full production, with performance monitored at each step. LLM-based systems need a behavioral consistency baseline established before full production — a snapshot of how the model behaves today, so drift later has something to be measured against. Agentic AI systems need a scope manifest — an explicit statement of what actions the agent is permitted to take — approved before any production deployment, not retrofitted after the agent is already live and doing something unexpected.

RBI's Draft MRM Guidance (June 2026) is specific here in a way worth citing directly rather than paraphrasing: it expects a human-in-the-loop or kill-switch mechanism for models in production, and it expects deployment approval to be documented, not assumed. For an agentic system specifically, "kill switch" is not a nice-to-have resilience feature — it's the control that lets the bank stop an agent mid-task without taking down the whole system around it. Teams that skip this discover the hard way that there's a real difference between "pause the model" and "pause the five downstream actions it already triggered."

The India detail: limited production for a retail-facing model in India usually means a defined branch or regional rollout — not a percentage-based canary the way a pure-tech company would run it — because RBI examiners expect to be able to point to a specific, bounded population and ask what happened to it. Stage gate: each deployment stage clears its performance threshold, and the agentic scope manifest is approved before go-live. Citations: RBI Draft MRM Guidance (June 2026) kill-switch and deployment-approval requirements · RBI FREE-AI Framework (Aug 2025) Safety, Resilience and Sustainability Sutra.

Stage 6: Production Monitoring and Maintenance — Why "Forensic Replay" Is Worthless If It Doesn't Actually Exist

Once in production, the model gets watched on four axes: performance, drift, fairness, and security. Re-validation triggers are defined up front and actually enforced, not written into a policy document and forgotten. The model card gets updated every time the model changes. Risk gets reported at board level. And forensic replay — the ability to reconstruct exactly what a model decided, on what inputs, at a specific past date — has to be real, not aspirational.

Here's what "not real" looks like: an examiner asks for the decision record behind a loan rejection from three years ago. The team pulls logs and discovers the model version running today isn't the one that made that decision, the feature values at decision-time weren't snapshotted (only the current feature store exists), and the explanation the customer received references a model card that's since been overwritten with no version history. Reconstructing that decision now takes a frantic week of forensic log archaeology, and even then the answer is an approximation, not a replay. Banks that treat forensic replay as a paperwork line item rather than an engineering requirement find this out at the worst possible time — during an actual regulatory inquiry.

RBI's Draft MRM Guidance (June 2026) adds a requirement the original frameworks didn't carry explicitly: periodic review for automation bias and decision fatigue among the human reviewers who are supposed to be exercising oversight over the model, not rubber-stamping it. That's a monitoring obligation on the humans in the loop, not just the model. Stage gate: re-validation triggers defined and actually enforced (threshold breach, material model change, regulatory change), with forensic replay verified to actually work — tested, not assumed. Citations: SR 11-7's ongoing monitoring expectations · RBI FREE-AI Framework (Aug 2025) Safety, Resilience and Sustainability Sutra · RBI Draft MRM Guidance (June 2026) automation-bias review requirement.

Stage 7: Decommission — What Survives After the Model Is Switched Off

Retiring a model doesn't retire the bank's obligations. Decision records, the archived model card, archived validation reports, and the full audit trail all have to survive the model itself — and forensic replay capability has to keep working after decommission, which is precisely when it's hardest to maintain because nobody is actively maintaining the pipeline anymore.

On retention length: RBI doesn't publish a specific "7–10 years for AI models" rule, and claiming one overstates what's actually written down. What RBI does have is longstanding general record-retention expectations for credit and audit records, commonly cited in the 7–8 year range under existing banking regulation provisions. The defensible position for a bank's own AI governance policy is to retain decommissioned-model records for 7–8 years as a matter of the bank's own conservative policy choice, consistent with those general expectations — and to say so explicitly in the policy document rather than attributing a precise figure to RBI that RBI hasn't actually specified for AI models as such.

The India detail: the practical failure mode isn't the retention clock running out — it's that the archived model card references a feature store or inference environment that got decommissioned alongside the model, so even though the record technically exists, nobody can actually run the replay anymore. Decommissioning the infrastructure and decommissioning the model need separate sign-off, with the former gated on the latter's replay capability being proven first. Stage gate: retention records confirmed, and forensic replay capability verified to work post-decommission — not just claimed. Citations: RBI FREE-AI Framework (Aug 2025) and RBI's general record-retention expectations for credit and audit records · DPDP Act 2023 · SR 11-7's model retirement and retention expectations.

Re-Validation Triggers: What Forces a Model Back Through the Gate

A model doesn't sit in production indefinitely just because it passed validation once. The following triggers force a defined response — full re-validation, outcome analysis, an investigation window, or, for Critical-tier models, an outright deployment pause.

Trigger Category	Specific Trigger	Required Response
Model change	Material change to model logic, features, or architecture	Full re-validation
Retraining	Retraining on materially new data distribution	Full re-validation
Retraining — routine	Scheduled retraining on refreshed data, no architecture change	Outcome analysis
Context change	Change in use case, customer population, or deployment context	Full re-validation
Performance degradation	Metric breach against defined threshold	Investigation window
Distribution shift	Input or output distribution drift beyond threshold	Investigation window
Regulatory change	New or amended RBI/regulatory requirement affecting the model	Full re-validation
LLM/Agentic — RBI eMRM	Behavioral consistency baseline breach, or agentic scope deviation	Deployment pause (Critical tier)

The "routine retraining" row matters more than it looks. Treating every scheduled retrain as a full re-validation event burns validation capacity on changes that don't need it, which is exactly how validation teams end up rubber-stamping the retrains that do matter, out of fatigue. Reserve full re-validation for retrains that actually shift the data distribution or the model's behavior — and be honest with yourself about which one you're looking at.

Action Checklist: What to Do Before Your Next Model Hits Stage 1

Pull your current model inventory and check it against the seven stages above. Any Critical/High-tier model missing a documented risk-committee approval, a fairness pre-check with named India proxies, or a completed model card from development (not reconstructed after) is already out of gate.
Test forensic replay on one real model, today, not during the next exam. Pick a decision from 18+ months ago and try to actually reconstruct it — inputs, feature values, model version, explanation. If you can't, you've found your real gap before an examiner does.
Separate your retention policy language from your legal citation. State "7–8 years, per the bank's conservative retention policy, consistent with RBI's general record-retention expectations" — not a specific AI-only figure RBI hasn't published.
Confirm your Critical-tier models actually have an independent validator, not just an independent-sounding sign-off. For NBFCs without a separate validation function, budget the lead time to engage an external validator now, not when a Critical-tier model is already waiting at the gate.
Write the kill-switch and scope-manifest requirement into your agentic AI deployment checklist explicitly, citing RBI's Draft MRM Guidance (June 2026) by name — this is one of the few places where the real regulatory text is more specific than most internal policies currently are.

Related: AI model governance lifecycle

MODEL DOCS

AI model documentation banking

7-section model card for lifecycle stages 3-7

MODEL VALIDATION

AI model validation banking

Stage 4 independent validation requirements

MODEL MONITORING

AI model monitoring banking

Stage 6 production monitoring requirements

DECOMMISSIONING

AI model decommissioning banking

Stage 7 — what to retain, successor validation, DPDP

AI model lifecycle governance from development to decommission — one platform

Stage gate approvals tracked in GRC workflows. Model card auto-generated and maintained. Validation findings tracked to resolution. Production monitoring with re-validation triggers. Forensic Replay capability maintained post-decommission. RBI examination-ready evidence at every lifecycle stage.

Request a demo Explore governance platform →

AI Model Lifecycle Management for Banking: Seven Stages from Development to Decommission, the Governance Stage Gates Between Them, and What RBI and SR 11-7 Require at Each