Why Change Classification Is the Control That Makes Everything Else Work
A validated model that drifts through undocumented changes is not a validated model anymore — it's a model that was validated once, at a point in time that keeps receding further into the past. The fix is not more validation; it's a classification system that routes every change to the right level of scrutiny before it ships, so trivial changes don't drown the governance function and material changes don't slip through as if they were trivial.
Major Changes: Full Independent Validation, Committee Approval
Changes to core algorithms, the training data universe, output definitions, or an LLM's underlying base model version are major changes by definition — they can shift decision logic in ways a spot-check won't catch. These require full independent validation before deployment and Model Risk Committee approval, and realistically take 30–90 days depending on model complexity and committee cadence. Trying to compress this timeline to meet a product launch date is how a major change gets waved through with minor-change scrutiny.
Minor Changes: Expedited Review, Not Skipped Review
Retraining within the original data parameters, threshold recalibration, and system prompt modifications are minor changes — they don't warrant a full revalidation, but they still need the validation function's expedited review, typically landing in a 5–15 business day window. The risk in this tier isn't that minor changes get reviewed too slowly; it's that "expedited" quietly becomes "waved through" once a team is under delivery pressure.
Cosmetic Changes: Owner Sign-Off, Documented, Not Escalated
UI updates and logging configuration changes belong here — owner approval and documentation within 1–3 business days, with no validation review required. The discipline this tier needs isn't more scrutiny, it's a clear enough definition that teams can't reclassify a borderline change as "cosmetic" just to avoid the review queue.
The Change Category Banks Routinely Fail to Govern: The Vendor Changed the Model Under You
A bank that validated GPT-4 and woke up running GPT-4.1 behind the same API call did not approve a model change — the vendor did, unilaterally, and the bank found out when behavior shifted or didn't notice at all. The practical reality: once a provider ships a new base model version, the model the bank validated is no longer the model in production, whether or not the bank treated that as an event. Base model version updates have to be classified and governed as major changes — monitored for through provider communication channels and version-pinning where contractually available, and run through expedited-but-substantive governance review rather than treated as an administrative notification to file away.
India BFSI Context: Board Visibility, Priority Sector Impact, DPDP Review
Indian banks carry change-management obligations beyond the tiered-approval structure above. Material AI model changes in Critical or High-tier systems warrant board-level visibility, consistent with the board-accountability direction set out in RBI's FREE-AI Committee report (constituted December 2023, report published August 2025) — even ahead of any specific binding circular codifying the exact threshold. Changes to credit models touching priority-sector lending (agricultural credit, MSME, housing) should carry an explicit impact assessment on that segment specifically, not just an aggregate performance check, since RBI examination attention has historically concentrated on priority-sector and financial-inclusion outcomes first. ****
Action Checklist for Your Change Management Policy
- Write down the tier definitions precisely enough that a team under delivery pressure cannot talk a major change down into the minor-change queue.
- Treat every LLM provider base-model version update as a major change by default, with a monitoring process to actually detect when the provider has shipped one.
- Route priority-sector and PMJDY-segment-affecting credit model changes through an explicit segment-level impact assessment, not just aggregate validation.
- Require a documented DPDP Act review for any change that alters personal data processing, retention, or sharing.
- Give the board visibility into material changes to Critical and High-tier systems as a standing agenda item, not a reactive disclosure.
Related Articles
Change management built into the governance workflow.
Zytra automatically classifies model changes, routes them to the right approval gate, and tracks validation status — including third-party LLM version updates that change model behavior without the bank initiating the change.
Talk to sales