As India’s banking, insurance and non-banking finance sectors embrace enterprise AI, one critical shift demands attention. Organisations are moving away from dashboards towards conversational AI. While this enables customers' queries and issues to be resolved almost instantly, it also comes with a cost: information flows within the organisation become far more accessible.
For institutions operating under RBI, SEBI and IRDAI oversight, that shift raises a question sharper than most technology transitions: who gets to see what, and can the organisation prove it?
This is becoming a pressing issue for firms in the sector because the Guidance on Regulatory Principles for Model Risk Management, 2026, by the RBI mandates board-level oversight, model classification, ‘kill switch’ mechanisms, and mandatory human oversight of automated decisions. The framework applies across commercial banks, small finance banks, payments banks, cooperative banks, NBFCs and credit information companies.
Supratik Shankar, Co-Founder of enterprise data platform Dview, argues that this is the real inflection point in enterprise AI adoption—and one the industry has been slow to grapple with. “A dashboard is pre-scoped by a data team, but a natural language interface is unbounded, so governance can no longer live inside report design.”
Dview has built its data and analytics stack, comprising a data ingestion layer, a query engine, and a conversational analytics layer, for banks, NBFCs and fintechs that cannot afford to treat data exposure as merely a security lapse. In these sectors, Shankar notes, a governance failure is a regulatory event.
Access Control Before the Model Sees a Query
The company’s core design decision, according to Shankar, is to resolve permissions before a question ever reaches the language model. “The system resolves user identity, role and permissioned data scope at the moment of query, not at the moment of responses.”
In practice, this means a chief risk officer and a branch collections officer asking an identical question receive answers drawn from different, role-appropriate slices of the same dataset.
This becomes particularly relevant given the newer risks that conversational interfaces introduce, such as adversarial phrasing designed to extract data outside a user’s authority. Shankar says the platform treats this as an engineering problem rather than a policy one. “No prompt engineering can circumvent a data access boundary that is enforced below the model.”
Shams Tabrej, CEO of Ezeepay, tells AIM that the cost of compliance will be high in the early years. “Given the governance, documentation, monitoring, audit trails and expertise that need to be built, NBFCs and fintechs will likely need heavier investment in technology, people and oversight than large banks with mature governance already.”
Srividhya Sridhar of Vivriti Next offers a counterpoint, noting that automated decision-making is already more prevalent at new-age NBFCs and fintechs than at legacy banks. As a result, the governance gap may not necessarily track institutional size in the way many assume.
Avoiding a Rebuild of Legacy Infrastructure
A recurring obstacle for large financial institutions is that their data sits across legacy on-premise systems and multiple cloud providers, often without consistent metadata. This is precisely the condition that migration-heavy vendors have historically used to justify multi-year rebuilds.
Dview argues that this is unnecessary. Its data ingestion layer connects to more than 100 source systems, from core banking applications to spreadsheets, without requiring organisations to replace existing infrastructure.
Sitting above that ingestion layer is the Unified Knowledge Layer, which encodes what a given data field means to different business functions. “This context precision eliminates the ambiguity that is the source of most enterprise AI hallucinations,” Shankar says, describing the layer as central to both accuracy and speed of deployment.
Measuring Return Before Committing Capital
Enterprise AI projects are frequently criticised for stalling at the proof-of-concept stage because financial outcomes remain unclear. Ezeepay’s approach, Tabrej says, is to anchor every deployment to a cost or loss already visible on the client’s books before any platform code is written.
He cites a public sector bank example where the company projected a reduction in annual fraud losses against a comparatively modest platform investment.
The company also runs a 15-day proof of concept inside a client’s own production cloud environment, rather than a vendor-hosted demonstration. “Multi-year contracts are signed after evidence, not before it,” Tabrej says, describing this as central to how the company avoids the stalled-pilot problem common across the sector.
What Happens to Existing Data Teams
As natural-language querying absorbs routine data retrieval work, there is a broader industry question about what happens to analysts and engineers whose jobs have historically involved exactly that task. Shankar was clear that the company does not view this as a displacement story.
“The shift is structural, not subtractive,” he says, arguing that time freed from ad-hoc reporting is redirected towards data product development, model fine-tuning and governance architecture—roles he described as increasingly scarce across regulated industries.
On-Premise Deployment & the Compliance Requirement
For sectors where regulation prohibits sensitive operational data leaving a regulated entity’s own infrastructure, Dview deploys its full stack inside a client’s Virtual Private Cloud, including fine-tuned language models that run without external inference calls. Shankar was careful not to overstate the guarantees this provides around accuracy across all possible queries.
“No probabilistic system can offer a mathematical guarantee of 100% precision across all possible queries at all times,” he says, adding that the aim instead is to make deviations from precision detectable and traceable before they become compliance events.
A Broader Industry Pattern
Dview’s account of its own architecture reflects a wider pattern visible across enterprise AI vendors serving regulated sectors: the technical difficulty of conversational analytics has increasingly moved away from language model capability itself and towards the infrastructure surrounding it—identity resolution, metadata, audit logging and deployment location.
For banks, insurers and NBFCs weighing whether to adopt these tools, that shift suggests the more useful due-diligence questions are less about model performance and more about where data sits, who can query it, and what evidence exists if a regulator asks.


Your reaction
Discussion
What's your take on this story?
No comments yet — be the first to share your view.