Not in the literal sense of a single emergency button that shuts every AI system down. RBI's draft guidance does not use the phrase "kill switch," and framing it that way risks understating what's actually being asked for.

What the draft does point toward is a broader operational capability — the ability to move a model through a defined sequence when something goes wrong:

​

That distinction matters because a literal kill switch is a blunt instrument: it stops everything, including the parts of a system that were working fine. A bank that can only turn a model fully on or fully off will either over-restrict (disabling fraud detection because one edge case misfired) or under-restrict (leaving a faulty credit model running because switching it off entirely isn't operationally realistic). The capability regulators are edging toward is closer to a graduated set of controls than an off switch — detection identifies model drift, anomalous outputs, or control failures; risk assessment determines severity and business impact before a response is chosen; usage restriction reduces or stops a specific use case without disabling the entire system; human escalation routes critical events to accountable teams for review and sign-off; remediation corrects the model, data, configuration, or surrounding controls; suspension temporarily halts model-driven decisions while the issue is investigated; decommissioning permanently retires a model when remediation isn't viable; and recovery validates the model before it's returned to production.

Read this way, "AI kill switch" is industry shorthand for a governance capability RBI's draft is building toward — not a specific technical requirement with a defined interface. Banks that treat it as the latter risk building a literal shutdown button and missing the graduated control layer regulators actually care about.

Whatever the final wording of RBI's guidance turns out to be, the underlying operational needs are already clear from the draft, from FREE-AI, and from where global model-risk practice has been heading for several years. Five capabilities form the foundation.

1. AI/Model Inventory

Nothing else on this list is possible without first knowing what's running. Banks should be able to answer, for every model in production:

•     Which AI models and agents are deployed, and where

•     Who owns each one, and who is accountable for it

•     What decisions or actions it influences or executes

•     Which vendors or third parties supplied it, wholly or in part

•     Which downstream systems and workflows depend on it

•     What data it consumes, and what actions it can trigger

2. Risk Tiering

Not every AI system carries the same stakes, and treating them identically wastes control effort on low-risk systems while under-controlling the ones that matter. A practical (not RBI-prescribed) tiering approach might separate:

•     Low-risk internal productivity AI — drafting, summarization, internal search

•     Customer-facing conversational AI — chatbots, virtual assistants

•     Fraud detection and transaction monitoring

•     Credit decisioning and underwriting

•     AML and sanctions screening

•     Trading, treasury, and market-risk models

•     Autonomous AI agents that can take direct action on accounts or systems

RBI has not published a fixed set of risk categories for AI specifically; the categories above are a practical starting point drawn from how banks are approaching risk-based classification generally, not a regulatory checklist.

3. Runtime Monitoring

Governance that ends at model approval misses everything that happens after deployment — which is where most real-world failures occur. Ongoing visibility should cover:

•     Model behavior and output drift over time

•     Input and output anomalies

•     Policy violations and accuracy degradation

•     Unexpected tool calls or access attempts by AI agents

•     Data leakage and prompt manipulation

•     Changes in third-party or vendor model behavior after an update

4. Intervention Controls

This is the operational layer that makes "kill switch" thinking useful without being literal. A practical intervention layer should support the ability to:

•     Pause a specific model or workflow

•     Restrict a use case without disabling the underlying system

•     Route a decision to human review

•     Reduce an agent's permissions or disable specific tools it can call

•     Roll back to a previous model version

•     Adjust decision thresholds

•     Isolate an affected workflow from the rest of the estate

•     Decommission a model permanently when remediation isn't viable

5. Auditability

Every intervention needs a record a regulator can follow after the fact:

•     Who triggered the intervention, and why

•     Which model, agent, or version was affected

•     What risk signal prompted the action

•     What action was actually taken, and when

•     Who approved restoring the system to production

•     What validation occurred before that restoration

Traditional AI follows a simple, single-step pattern: input goes in, a model processes it, an output comes back. Agentic AI looks different:

Goal → Reasoning → Tool selection → API/tool call → Data retrieval → Action → Feedback → Next action

An agent can initiate a transaction, access internal systems, call external APIs, modify records, communicate directly with a customer, or trigger a downstream workflow — and it can do several of these in sequence, autonomously, before a human ever sees the result. Stopping the "model" doesn't stop an in-flight sequence of actions that's already underway across several systems.

This is why banks deploying agentic AI need action-level controls, not just model-level shutdowns: the ability to intervene on a specific tool call, a specific permission, or a specific step in a chain — not only on the model generating the reasoning behind it.

This is a recommended preparation sequence, not an RBI-mandated timeline — the draft guidance does not specify a 90-day compliance window. It's a practical pace for getting ahead of whatever the final requirements turn out to be.

Days 1–30: Discover

•     Build a complete AI/model inventory

•     Identify owners and accountable teams for each system

•     Map dependencies between models, agents, and downstream applications

•     Identify high-impact use cases first

•     Document every third-party and vendor-sourced AI system in use

Days 31–60: Control

•     Establish risk tiers across the inventory

•     Define intervention policies for each tier

•     Implement runtime monitoring where it doesn't yet exist

•     Define clear escalation procedures and ownership

•     Create formal model suspension and decommissioning procedures

Days 61–90: Test

•     Run AI incident simulations against real workflows

•     Test model shutdown and restriction procedures under realistic conditions

•     Test rollback to a prior model version

•     Test human-escalation paths end to end

•     Test that audit trails actually capture what they're supposed to

•     Run red-team exercises against agentic workflows specifically

•     Validate that recovery and restoration procedures work as designed

Building this capability manually — spreadsheet inventories, ad hoc monitoring scripts, escalation over email — doesn't scale past a handful of models, and it collapses entirely once agentic AI enters the picture. A dedicated AI governance and security platform is one practical way to operationalize inventory, risk tiering, runtime monitoring, and intervention controls in one place rather than stitching them together after the fact.

Trusys is built for exactly this kind of continuous governance — spanning pre-deployment evaluation, adversarial red-teaming, runtime observability, and inline policy enforcement across the AI agent lifecycle. You can explore the platform at Trusys, an AI governance and security platform. To be clear: using a platform like Trusys doesn't equate to RBI certification or approval — no such regulatory certification currently exists for AI governance tooling. What it does is give a bank the operational evidence and control layer that RBI's direction of travel appears to be asking for.

It's worth being precise about how RBI's two AI-relevant initiatives relate to each other, because they're often conflated:

FREE-AI — the broader, principles-based framework from the August 2025 committee report. It sets out seven guiding "Sutras" (including safety, transparency, accountability, and explainability) and 26 recommendations across governance, risk management, data stewardship, model lifecycle management, stakeholder engagement, and innovation enablement. You can read more in Trusys's breakdown of the RBI FREE-AI framework.

Model Risk Management Guidance — the June 2026 draft that operationalizes model-level governance and risk controls specifically: board-approved frameworks, risk tiering, validation, monitoring, and — the focus of this article — the ability to restrict, remediate, and decommission models when something goes wrong. Trusys's guidance on building an audit trail that can survive a regulator review covers the evidence and logging side of this in more depth.

Put together, the two form a reasonably coherent picture: FREE-AI sets the principles a bank's AI program should be built around; the MRM guidance sets out how those principles should show up in concrete, auditable model-level controls. A practical way to operationalize both is a single architecture that runs:

Principles → Inventory → Risk Tiering → Validation → Monitoring → Intervention → Audit → Continuous Governance

Banks shouldn't wait for RBI's final rule to find out whether they can actually control their own AI systems. Whatever specific language the final Model Risk Management guidance lands on, the underlying operational need is already visible in the draft, in FREE-AI, and in the Governor's own public remarks: the ability to identify, monitor, restrict, escalate, remediate, suspend, and safely decommission high-risk AI systems — with clear ownership and a full audit trail behind every action taken.

That capability is what "AI kill switch" is really shorthand for. Building it now, ahead of the final rule, is the more defensible position than building it in response to an enforcement finding — and it's the same capability banks will need regardless of how RBI's language ultimately reads, as AI moves from pilot projects to production-scale, increasingly autonomous deployment across the sector.

Ready to see what continuous, audit-ready AI governance looks like in practice? Book a demo with Trusys.