RBI’s June Deadline on AI Risk: What Banks and Regulated Entities Need to Do Now

The Reserve Bank of India has asked banks and other regulated entities to complete a board-approved gap assessment of AI risks and formulate a time-bound action plan by the end of June. The trigger is the arrival of frontier AI models that have demonstrated the ability to identify zero-day vulnerabilities, security flaws unknown even to the developers who wrote the code, before malicious actors find them. Finance Minister Nirmala Sitharaman called this class of capability “a new challenge” back in April, and the regulator has now converted that concern into a deadline.

Two details in the directive deserve more attention than they are getting. First, the assessment must be board-approved, which means accountability for AI risk now sits with the institution’s leadership, not with a working group inside the IT department. Second, the deadline is weeks away. This is no longer a strategy conversation. Everyone needs to act now.

What the RBI Is Actually Expecting

Three obligations sit at the core of the directive.

The first is a structured cybersecurity framework that accounts for AI. Not a policy document that mentions AI in passing, but a framework built on knowing where AI touches the institution’s data today. That includes the obvious surfaces, like any chatbot or copilot the bank has piloted, and the less obvious ones: employees pasting content into public tools from personal devices, vendors quietly embedding AI into products the bank already runs, and analytics teams experimenting with models nobody formally approved.

The second obligation is AI-led adversarial testing. The regulator expects institutions to use capable AI models to probe their own defences. Notice what this expectation assumes: that the institution can put AI to work. You cannot run AI-led tests against your environment while keeping AI entirely outside the perimeter.

The third is identifying existing vulnerabilities. Most institutions will read this as a network and application exercise, and it is partly that. But the most underexamined vulnerability class in any bank today is data exposure, because the moment an institution begins evaluating publicly available AI models for use cases, which is exactly what the article says Indian financial entities are now expected to do given that access to the most advanced models remains limited, the first question every risk committee will ask is a simple one. What happens to our customer data when it touches these models?

Why Blocking Is Not the Answer, and Not What the RBI Implies

For most Indian banks, their primary AI risk control today is total prohibition. Large language models and GenAI apps are blocked across the enterprise, and the assumption is that a ban equals safety.

The directive itself points away from that posture. Read its requirements again: undertake AI-led adversarial testing, evaluate advanced models that are already publicly available for potential use cases. None of that is achievable from behind a blanket ban. The regulator is not telling banks to shut AI out. It is telling them to understand it, test against it, and engage with it in a structured and accountable way. An institution that submits a gap assessment concluding “we block everything, therefore we have no AI risk” has misread the assignment, because the assignment treats frontier AI as a reality to be managed rather than a threat to be exiled.

Regulatory compliance now requires demonstrating how AI handled sensitive data, not merely asserting that it was blocked. A ban produces nothing demonstrable. No logs, no evidence trail, no record of what was protected and when. When the question arrives, and it will, of how the institution’s AI interactions handled customer information, prohibition has no answer to give, because prohibition generates no proof. Blocking also generates a false sense of control. Employees route around blocks through personal devices and unsanctioned tools, static blocking rules are bypassed with simple rewording, and the institution loses visibility into how its data flows, which is the opposite of what a gap assessment is supposed to produce.

The legacy security stack does not close this gap either. Traditional tools were built to inspect what enters and exits a perimeter. Inside AI workflow, the risk lives in the actions the system takes, the APIs it calls, the tools it invokes, and the answers an agent assembles from a dozen internal sources. This extends to discovery also. Most tools that scan an environment for sensitive data were built before LLMs existed, relying on regex patterns and dated ML models that recognize formats rather than meaning. They miss data written informally, inconsistently, or buried in unstructured content, which is precisely where most of a bank’s real exposure lives. You cannot protect what you cannot see, and you cannot certify what you never found.

Blocking also creates a problem it claims to solve. Employees who need AI to do their jobs will find a way to use it, and the way they find is almost always a personal device and a public chat interface with no enterprise guardrails in sight.  So blocking fails the directive, fails as a control, and the legacy toolset was never designed for the problem. That leaves one question worth answering: what must an institution do to its data before AI is allowed to touch it?

Where Institutions Should Start

Know your sensitive data first.. You cannot assess AI risk against data you have never mapped. Customer identifiers live in structured systems where every column is known, but they also live in support tickets, call summaries, logs, and documents, places where nobody catalogued them. Discovery across both structured and unstructured sources is the precondition for everything that follows, because every later control depends on knowing what needs protecting and where it sits.

Tokenize before AI ever sees it, and keep that protection alive across the entire workflow. This is the foundational move, and it changes the nature of the problem. When sensitive fields such as names, account numbers, PAN, and Aadhaar are replaced with consistent, format-preserving tokens before data enters any AI pipeline, the question “is it safe to use this model?” transforms. The model never receives real data, so evaluating frontier models, running adversarial tests, or piloting use cases stops being a data exposure event. A balance attached to a token is just a number. And because the tokens preserve format and consistency, the AI’s reasoning and the analytics built on top of it keep working as if the original data were there.

The critical caveat is that masking the prompt alone is not enough, because data leaks across the full AI lifecycle. Sensitive information resurfaces in retrieved documents during RAG, in the outputs of tools and APIs the system calls, in agent memory carried across sessions, and in the final response handed back to a user. Protection has to be enforced at every one of those points, not just at the input. An institution that protects only the prompt has secured one door in a building with six.

And rather than blocking GenAI chats or blocking their prompts completely and thus restricting its use, give Employees the option to use them, but making sure that the information which is sensitive is tokenized. So you don’t loose innovation and keep governance and privacy in check.

Keep the data inside the boundary. Indian banks face a constraint that makes this entire exercise harder: customer data cannot cross geographic boundaries, yet many of the most capable AI models are hosted outside India. The way through is architectural. When the protection layer is deployed on-premises or in the institution’s own private cloud, the sensitive data never leaves the approved boundary. Only tokenized content travels to the external model, and the original values stay behind the bank’s own firewall. Sovereignty is preserved, and the institution still gets to use the models the regulator expects it to evaluate.

Control who can see the real values, and when. Tokenization only works as a control if re-identification is governed. Authorized teams unmask specific values when a workflow genuinely requires them, for instance when a risk model flags a particular customer for review and an investigator needs the actual identity. Everyone and everything else, including the AI itself, works on tokens. This is the access story a board can defend.

Log everything, and make the log exportable. This step converts the action plan from a document into evidence. Every detection, every masking decision, and every access to an original value gets recorded with who, what, and when. When the regulator asks how the institution’s AI handled sensitive data, the answer is not a policy citation. It is a record that can be exported and handed over.

The June deadline is the starting point, not the Finish Line

The RBI’s June 2026 deadline for gap assessments is not the end of this conversation. It is the beginning of a longer process of building AI governance infrastructure that regulators will expect to mature over time. Banks that treat the gap assessment as a documentation exercise will find themselves back in the same position at the next regulatory cycle.

The banks that come out ahead will use this moment to build a genuine foundation: data discovered and mapped before AI touches it, sensitive values tokenized at source with context preserved through the full AI pipeline, every access decision logged and auditable, and the entire architecture deployed within approved geographic boundaries.

That is not a compliance response. That is how an institution earns the right to move fast with AI while the rest of the sector is still arguing about whether to allow it.

How are you turning your AI risk assessment into a foundation for fearless AI adoption? Seclore’s ARMOR platform helps financial institutions discover sensitive data, protect it at source, and produce the audit-ready evidence regulators expect, all without sending customer data outside your approved environment. Get in touch to explore how a context-aware intelligence applies to your environment.

Let’s discuss in depth – Book time with us

Learn more about ARMOR AI-DLP www.seclore.com/armor/aidlp