Governance Build Sheet

How to read this build sheet

The Governance module explains what model risk is and why the scope is now enormous. This page is the parts list: the frameworks to map against, the tooling that makes each control real, what it costs, and the three builds.

This is the last of the nine build sheets, and it is the one that decides whether the other eight survive contact with a supervisor.

What counts as a model now

Start here, because it invalidates most existing model inventories.

The RBI's draft Guidance on Regulatory Principles for Model Risk Management, 2026 (Press Release 2026-2027/528, 24 June 2026) broadens "model" dramatically. It covers AI and ML systems, scoring algorithms, rule engines, and material spreadsheets that influence business decisions such as lending rates or customer pricing.

The draft applies to eleven categories of regulated entity: commercial banks, small finance banks, payments banks, local area banks, regional rural banks, urban and rural co-operative banks, NBFCs of all layers, All-India Financial Institutions, asset reconstruction companies and credit information companies.

Where it sits in the lineage: a draft on model risk in credit (5 August 2024), then the FREE-AI committee report (13 August 2025) with its seven sutras, 26 recommendations and six pillars, then this. FREE-AI gave the direction; this draft is the control layer.

Three lines, and what each actually does

Three lines of defence is the structure every framework here assumes. It is worth being concrete about what each one actually does, because the common failure is three names and one team.

The board and its risk management committee retain ultimate accountability, and high-risk models require explicit committee approval under the draft. That is a real constraint on shipping: a high-risk model is not something a product team can deploy on its own authority.

Raw materials — frameworks to map against

Raw materials — the tooling

Almost every control below has a free tool that makes it real. The gap between a governance document and a governance programme is whether these are wired into CI.

How to use each one — inventory and tiering

Finding what you have is most of the work

The draft is explicit that unlisted active models are prohibited. That single sentence turns the inventory from documentation into a control, and it means the reconciliation — comparing the list against what is genuinely running — has to be automatic.

from dataclasses import dataclass, field
from datetime import date

@dataclass
class ModelRecord:
    # --- identity ---
    id: str
    name: str
    version: str
    kind: str                    # "ml" | "rules_engine" | "spreadsheet" | "llm" | "vendor"
    # A rules engine IS a model. A pricing spreadsheet IS a model. If it
    # influences a business decision, it belongs in this list.

    # --- accountability: the three fields most inventories are missing ---
    owner: str                   # a NAMED PERSON, not a team
    validator: str               # who challenged it, and is not the owner
    approver: str                # who accepted the residual risk

    # --- the field that prevents the most failures ---
    fallback: str                # what happens when this model is unavailable
    fallback_rehearsed: date     # when it was last ACTUALLY exercised
    kill_switch: str             # the concrete mechanism, not "we'd turn it off"

    # --- risk ---
    tier: str                    # "high" | "medium" | "low"
    decisions_affected: str      # what changes for a customer because of this
    population: int              # how many people it touches per month

    # --- lifecycle ---
    deployed_on: date
    last_validated: date
    next_validation_due: date
    upstream_data: list = field(default_factory=list)
    downstream_models: list = field(default_factory=list)

def inventory_gaps(records, today=None):
    today = today or date.today()
    issues = []
    for m in records:
        if m.tier == "high" and not m.approver:
            issues.append((m.id, "high_risk_without_named_approver"))
        if m.validator == m.owner:
            issues.append((m.id, "validator_is_owner"))
        if not m.fallback:
            issues.append((m.id, "no_defined_fallback"))
        if (today - m.fallback_rehearsed).days > 365:
            issues.append((m.id, "fallback_never_rehearsed_this_year"))
        if m.next_validation_due < today:
            issues.append((m.id, "validation_overdue"))
    return issues

# WHAT TO CHECK
# [ ] UNLISTED ACTIVE MODELS ARE PROHIBITED under the draft guidance. Reconcile
#     the inventory against what is actually deployed, automatically, monthly.
#     A list maintained by hand is a list that is wrong
# [ ] owner is a person. "The risk team" cannot be woken at 2am
# [ ] validator != owner, asserted in code. This is the single most common
#     finding and the easiest to prevent
# [ ] fallback_rehearsed is a DATE, not a boolean. An unrehearsed fallback is a
#     hypothesis
# [ ] upstream_data and downstream_models give you blast radius. When a feed
#     breaks you need to know every model that consumed it, in seconds
# [ ] vendor models get the SAME record. You cannot rely on a supplier's safety
#     certificate -- you remain accountable and must validate independently
# [ ] spreadsheets that set prices or rates are in scope. Go and look for them

The gotcha nobody documents: fallback_rehearsed as a date rather than a flag. Every model inventory has a fallback column and almost all of them contain a sentence describing what would happen. A fallback that has never been exercised in production is a hypothesis, and the day you discover it does not work is the day you needed it. Put a date in the field, run the rehearsal on a schedule, and let the inventory go red when it ages out. This is the governance equivalent of the fall-back-rate metric in Build Sheet 08.

Tiering, and what it actually buys you

Tier on materiality and complexity, and let the tier drive real differences in process rather than a label on a spreadsheet:

How to use each one — kill switch, override, bias

The draft's AI-specific controls name four risks directly — hallucination, data drift, operational bias and discrimination, and adversarial attack — and require anti-automation-bias measures: human-in-the-loop, human override, and an immediate emergency kill switch.

import time

# The draft requires human-in-the-loop controls, human override, and an
# IMMEDIATE emergency kill switch to take a malfunctioning model offline.
# "Immediate" rules out a code deploy. It has to be a runtime flag.

class ModelGate:
    def __init__(self, model_id, flags, fallback_fn, audit):
        self.model_id, self.flags = model_id, flags
        self.fallback_fn, self.audit = fallback_fn, audit

    def decide(self, features, context):
        # 1. KILL SWITCH -- checked first, every call, no caching beyond seconds
        if self.flags.is_killed(self.model_id):
            out = self.fallback_fn(features)
            self.audit.write(self.model_id, "killed", out, context)
            return out

        # 2. the model
        try:
            out = self.model.predict(features)
        except Exception as e:                      # unavailable == fall back
            out = self.fallback_fn(features)
            self.audit.write(self.model_id, f"error:{type(e).__name__}", out, context)
            return out

        # 3. ANTI-AUTOMATION-BIAS: a human override must be possible AND
        #    recorded. An override nobody can see is not oversight.
        if context.get("human_override") is not None:
            self.audit.write(self.model_id, "human_override", context["human_override"],
                             context, model_said=out)
            return context["human_override"]

        self.audit.write(self.model_id, "model", out, context)
        return out


def rehearse(gate, sample, expect_degraded_ok=True):
    """Run in production, on a schedule, on a traffic slice. A fallback you have
    never exercised is a hypothesis, not a control."""
    gate.flags.kill(gate.model_id)
    t0 = time.time()
    results = [gate.decide(f, {"rehearsal": True}) for f in sample]
    gate.flags.unkill(gate.model_id)
    return {"n": len(results), "seconds": round(time.time() - t0, 2),
            "all_returned": all(r is not None for r in results),
            "rehearsed_on": time.strftime("%Y-%m-%d")}

# WHAT TO CHECK
# [ ] the kill switch is a RUNTIME FLAG. If disabling a model needs a deploy,
#     you do not have a kill switch, you have an intention
# [ ] who may pull it is written down, and it is not only the model owner. The
#     person who most wants a model to keep running should not be the only one
#     who can stop it
# [ ] the fallback produces a decision for EVERY input, including the awkward
#     ones. A fallback that errors on 3% of traffic is a 3% outage
# [ ] rehearsal runs on real production traffic, on a schedule, and writes its
#     date back to the inventory
# [ ] HUMAN OVERRIDES ARE RECORDED WITH WHAT THE MODEL SAID. The override rate
#     and its direction is the most useful oversight metric you will have --
#     near-zero means nobody is really reviewing
# [ ] the audit record is append-only and includes the model version and the
#     threshold configuration in force at that moment

The gotcha nobody documents: the human override rate, and its direction. Every governance programme records that human review exists. Almost none measures whether it is doing anything. If reviewers override the model in under 1% of cases, you have a rubber stamp rather than oversight, and that is worse than no human in the loop because it manufactures the appearance of control. If they override in more than about 20%, the model is not fit for the decision it has been given. Both numbers are actionable and neither appears on a standard dashboard.

Bias testing as a programme, not an event

Run it before deployment, on a schedule afterwards, and on any material retrain. Three things make the difference between a test and a programme:

• Decide the metric first, in writing. Demographic parity, equalised odds and predictive parity are mutually incompatible in most real datasets. Picking after you see the results is choosing the answer you like.
• Record the disparity even when it is within tolerance. The trend matters more than any single reading, and you cannot reconstruct a trend from tests you did not keep.
• Write down what you will do if a disparity appears before it appears. The options — retrain, reweight, restrict the feature set, route to human review, withdraw — are much harder to evaluate honestly while a live model is under scrutiny.

Cost per unit

The honest framing for a small firm: certification is worth it when a customer, an investor or a regulator is asking for third-party verification, or when you place high-risk systems on the EU market. If none of those apply, NIST AI RMF plus a genuinely maintained inventory delivers more governance per rupee than a certificate would.

Best combinations

Combinations that conflict

• Validator reporting to the model owner's business line. Competence does not substitute for independence.
• An inventory maintained by hand. It is wrong within a quarter, and being wrong is now a finding.
• Relying on a vendor's safety certificate. Explicitly insufficient. You remain accountable and must validate independently.
• A kill switch that needs a deploy. Not immediate, therefore not a kill switch.
• Picking the fairness metric after seeing the results. That is choosing the answer, not measuring.
• Treating LLM features as outside model risk. They are models, they influence decisions, and they are in scope.
• ISO 42001 presented as EU AI Act compliance. It is not, and the claim is its own exposure.
• Excluding rule engines and spreadsheets from the inventory. The draft includes them by name.

Three recommended builds

Strong and expensive

Build: a standing second-line model risk function → a commercial governance platform → ISO 42001 certification → external validation for every high-risk model → board-approved framework with a risk committee that meets on a schedule and keeps minutes.

Use when: you are a bank or a large NBFC with an examination cycle and enough models that coordination is the bottleneck.

Cost shape: headcount dominates. The platform and the certificate are rounding errors next to the people.

Trade: process weight slows deployment. That is the intended effect, and the complaint that governance is slowing things down is usually a sign it is working rather than a problem to solve.

Strong and reasonable — the default

Build: NIST AI RMF as the structure → the RBI draft as the control checklist → MLflow as the registry, reconciled automatically against deployments → named owner, validator and approver on every record → tiering that drives real process differences → external validators engaged for high-risk models only → kill switches as runtime flags, rehearsed on a schedule → Evidently and Great Expectations in CI → Fairlearn on a written metric chosen in advance → an append-only evidence file.

Use when: you have engineers, you have models in production, and you would like the examination to be uneventful.

Cost shape: tooling free, external validation per engagement, and the real cost is the calendar.

Trade: you build and maintain the programme yourself. That is the right trade, because the programme is your regulatory position and no vendor can hold it for you.

Strong and lean

Build: one spreadsheet that is genuinely complete — every model, rule engine and pricing spreadsheet, with owner, fallback and tier → a written statement of what is high risk and why → documented self-assessment for everything below it → a kill switch that works → monitoring you actually look at.

Use when: pre-scale, few models, no dedicated risk function.

Cost shape: time only.

Trade: it does not scale past a handful of models, and the spreadsheet will go stale. Accept that and set a date to replace it. A small, complete, honest inventory beats a sophisticated programme with gaps — examiners find the gaps, and an incomplete list is worse than a short one because it implies a control that is not there.

Where this section closes

That is the ninth and final build sheet. The section now has a module and a build sheet for every stage of a fintech AI stack, from the first document a customer uploads to the committee that signs off the model reading it.

One closing observation, which is the thread running through all nine. Across every enforcement action, penalty notice and supervisory finding referenced in this section, almost none turned on the model being insufficiently accurate. They turned on an escalation path that did not exist, a record that was not kept, a threshold nobody had approved, or a control that had never been tested. The engineering in these nine sheets is genuinely hard and worth doing well. It is not what the examination is about.

The nine build sheets

Sources

Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which numbers are primary-sourced and which are industry reporting — they are not equivalent, and treating them as if they were is how a confident wrong number gets repeated.