RBI’s AI risk deadline makes data governance a board issue

At a glance

What this is: Seclore says the RBI has moved AI risk from policy discussion to board-level accountability by requiring a gap assessment and action plan, with data governance and tokenisation at the centre of compliance.

Why it matters: This matters to IAM and security teams because AI risk now depends on who can see, unmask, log, and approve sensitive data across workflows, which is a governance problem as much as a technical one.

Context

The core issue here is not AI adoption itself, but whether institutions can govern sensitive data once AI systems, copilots, and public models enter the workflow. A board-approved assessment only has value if the organisation can show where data lives, how it is transformed, and who can re-identify it. For banks, that makes AI risk a control problem, not just a policy exercise.

That control problem crosses traditional boundaries between data security, access governance, and model usage. If employees, vendors, and analytics teams can reach AI tools without discovery, tokenisation, logging, and approved boundaries, the institution cannot produce evidence that its AI use is contained. In regulated environments, that missing evidence becomes the real governance gap.

Key questions

Q: How should banks assess AI risk when customer data can enter public models?

A: Banks should assess AI risk by tracing where sensitive data appears, how it is transformed, and whether it ever leaves approved boundaries in raw form. The assessment needs to cover chatbots, copilots, vendor-embedded AI, retrieval layers, and human workarounds, because blocking access alone does not create evidence of control or compliance.

Q: Why is tokenisation more effective than blocking AI outright?

A: Tokenisation is more effective because it preserves usable data for AI while removing the raw values that create exposure and compliance risk. Blocking may stop direct use, but it also drives shadow usage and leaves no audit trail. Tokenised workflows give security teams something they can prove, log, and defend to regulators.

Q: What breaks when sensitive data is only masked at the prompt?

A: Prompt-only masking breaks as soon as the same data reappears in retrieval results, tool outputs, agent memory, or final responses. That is why AI governance has to protect the whole workflow, not a single input field. If downstream stages can surface the original value, the control is incomplete.

Q: Who should own AI risk accountability in a regulated bank?

A: Board and executive leadership should own AI risk accountability, with clear operational responsibility assigned across data, security, and AI teams. Regulators are no longer looking for informal consensus or departmental policy statements. They want a traceable decision model, defined approvals, and evidence that the institution can produce on demand.

Technical breakdown

Why AI risk becomes a data-governance problem

AI changes the control plane because the main risk is no longer only model output, but the movement of sensitive content through prompts, retrieval layers, tool calls, and session memory. In banks, data may already exist in structured systems, support notes, logs, and documents, so simple perimeter controls miss the real exposure. Once AI touches those sources, governance depends on discovery, classification, and traceable handling of the underlying data, not on whether a chatbot was blocked at the firewall.

Practical implication: Treat AI risk assessments as data-flow reviews, not application inventories.

Why tokenisation has to happen before the model sees the data

Tokenisation replaces sensitive values with consistent surrogates so the model works on protected data rather than raw customer information. That matters because prompt masking alone leaves other pathways open, including retrieval-augmented generation, API responses, agent memory, and downstream logs. If the original value can reappear later in the workflow, the protection model is incomplete. Effective AI governance therefore depends on source-level protection that persists across every stage where data can resurface.

Practical implication: Apply tokenisation before data enters any AI workflow and extend it to retrieval, memory, and outputs.

Board approval changes accountability, not just paperwork

A board-approved AI risk assessment shifts the issue from IT control activity to institutional accountability. That means the organisation must be able to explain what data was assessed, what was blocked or tokenised, who could re-identify it, and what evidence exists for each decision. Without that chain of custody, compliance is only a statement. With it, AI governance becomes defensible to regulators and auditable across teams.

Practical implication: Build board reporting around evidence of control, not around policy language.

NHI Mgmt Group analysis

AI risk is now a data governance issue, not a model governance side note. The RBI directive makes that clear by tying accountability to board-approved assessments and time-bound action plans. If the institution cannot discover where sensitive data sits and how it flows into AI, it cannot claim to govern AI risk at all. The practitioner conclusion is straightforward: AI governance starts with data visibility and ends with auditable handling.

Tokenisation before model exposure is the decisive control pattern. The article’s real insight is that blocking AI does not produce evidence, but tokenised workflows do. That shifts the governance standard from denial to controlled use, which is more realistic for regulated environments. The practitioner conclusion is that data should be protected at source, not after the model has already seen it.

Boundary control must cover the entire AI lifecycle, not just the prompt. Retrieval, tool calls, agent memory, and outputs all reintroduce exposure if only the input is masked. That creates what we can call a tokenisation gap: protection that exists at the front door but disappears inside the workflow. The practitioner conclusion is that controls must persist across every stage where data can reappear.

Board accountability will expose weak ownership between data, security, and AI teams. When a regulator asks who approved the risk assessment, who can re-identify data, and where the evidence lives, informal ownership will not be enough. This is where many programmes will stall, because the control issue spans IAM, data security, and AI governance at once. The practitioner conclusion is to assign clear decision rights before the next review cycle.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Tokenisation gap: banks will increasingly be judged on whether protection survives the full AI workflow, not just whether chat interfaces are blocked. If the raw data can resurface in retrieval, memory, or outputs, the governance model is incomplete. That changes the programme objective from denial to demonstrable containment.

Regulators are effectively forcing a convergence of IAM, data security, and AI governance. The practical challenge is no longer a single control failure, but the absence of an end-to-end ownership model for sensitive data that AI can touch. Teams should prepare for board questions that demand evidence, not assurance language.

For practitioners

• Map all AI touchpoints to sensitive data sources Inventory chatbots, copilots, vendor-embedded AI, and employee experimentation paths, then trace which structured and unstructured data they can reach.
• Tokenise sensitive values before AI processing Replace names, account numbers, and other regulated fields with consistent tokens at source so the model never receives raw customer data.
• Extend protection beyond prompt masking Apply the same control model to retrieval-augmented generation, tool outputs, agent memory, and final responses so data cannot reappear downstream.
• Define re-identification approval paths Restrict unmasking to authorised workflows and record every access to original values with who approved it and why.
• Build exportable evidence for board review Log masking decisions, access events, and exceptions in a format that can be handed to regulators and used in board reporting.

Key takeaways

• AI risk becomes a board-level governance issue when the regulator asks for an approved gap assessment and action plan.
• The central control problem is whether sensitive data is discovered, tokenised, logged, and kept inside approved boundaries throughout the AI workflow.
• Banks that rely on blanket blocking will struggle to demonstrate compliance, while evidence-rich data governance will become the defensible operating model.

Key terms

• AI Risk Assessment: AI Risk Assessment is the structured process of identifying, analyzing, and prioritizing risks created by using artificial intelligence systems. It examines model behavior, data quality, security exposure, privacy impact, bias, misuse, and operational failure. In practice, it maps AI-specific threats to controls, owners, and residual risk decisions.
• Tokenisation: Tokenisation replaces a sensitive value with a non-sensitive substitute that preserves workflow utility without revealing the original data. It is useful when systems need to process or display records while keeping direct personal identifiers out of normal operating paths.
• Re-identification: Re-identification is the process of linking supposedly anonymous or low-risk data back to a person. It often happens when organisations combine datasets across systems, exports, or analytics environments. For identity and privacy teams, the risk is that reuse can turn safe-looking data into identifiable information.
• Data boundary: A data boundary is a policy-defined set of trusted destinations, account types, and application paths where sensitive information is allowed to move. It shifts control from scanning every transfer to containing movement outside approved work zones, which is better aligned to AI-era workflows and mixed-device environments.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to broader security and compliance responsibilities.