Notifications
Clear all
Topic starter
18/08/2026 2:17 pm
TL;DR: The RBI has told banks and regulated entities to complete a board-approved AI risk gap assessment and action plan by the end of June, pushing AI governance from policy language into executive accountability, according to Seclore. The real control issue is not whether AI is blocked, but whether sensitive data is discovered, tokenized, logged, and kept inside approved boundaries before models touch it.
NHIMG editorial — based on content published by Seclore: RBI’s June Deadline on AI Risk: What Banks and Regulated Entities Need to Do Now
Questions worth separating out
Q: How should security teams govern AI access to sensitive financial data?
A: They should combine identity governance with data classification so access decisions reflect both who is acting and what data is involved.
Q: Why do blanket AI bans often fail in regulated environments?
A: Blanket bans usually fail because they do not create evidence, do not stop shadow usage on personal devices, and do not support regulated testing or oversight.
Q: What do security teams get wrong about tokenizing data for AI?
A: Teams often assume tokenizing the prompt is enough, but data can resurface in retrieved documents, tool outputs, agent memory, and final responses.
Practitioner guidance
- Map sensitive data before approving AI use cases Inventory where customer and employee data exists across structured systems, documents, tickets, logs, and collaboration tools, then classify which stores can feed AI workflows.
- Tokenize sensitive fields at source Use format-preserving tokenization so AI models and external tools operate on protected values while original identifiers remain inside approved environments.
- Treat re-identification as privileged access Require approval, logging, and periodic review for any workflow that can restore original values, and restrict that capability to named roles with a business justification.
What's in the full article
Seclore's full blog covers the operational detail this post intentionally leaves for the source:
- The article’s step-by-step data protection flow for AI workflows, including discovery, tokenization, and logging.
- The practical handling of sensitive fields such as PAN and Aadhaar inside regulated AI use cases.
- The architecture guidance for keeping sensitive data inside approved geographic and infrastructure boundaries.
- The evidence and audit model for showing regulators how AI interactions were controlled.
👉 Read Seclore’s analysis of RBI’s AI risk deadline for banks and regulated entities →
AI risk assessments and data tokenisation: what banks must do now?
Explore further
18/08/2026 3:10 pm
Board accountability is now part of AI security governance. The RBI’s framing moves AI risk out of the technical pilot layer and into leadership responsibility. That shift matters because many institutions still treat AI controls as a policy add-on rather than a governed operating model. In practice, board approval only has value if the institution can show which data was exposed, who could re-identify it, and how that access was reviewed.
A question worth separating out:
Q: Who should be accountable for AI data exposure in banking?
A: Accountability should sit with leadership, supported by IAM, PAM, security, and risk teams. Board approval matters only if the institution can show who can re-identify data, which workflows are allowed to do it, and how every decision is logged for audit and regulatory review.
👉 Read our full editorial: RBI’s AI risk deadline makes data governance a board issue
