An enterprise AI framework must account for AI already in production

SBI's proposed bank-wide AI programme does not begin with an empty production environment.

YourStory reports that CIO Abhay Pandey outlined plans for roughly $1 billion of AI investment and a bank-wide framework. Separately, Business Standard's August 12 report quotes managing director Rama Mohan Rao Amara on AI's use in underwriting nearly ₹1 trillion of MSME loans in FY26.

The dollar figure is a reported plan, not evidence that the money has already been spent. The lending figure describes existing activity, not proof that credit decisions were wholly autonomous. Together, they make the implementation problem more interesting than another discussion about escaping pilots.

My claim: a bank-wide AI framework has to explain how existing production workflows enter it. A blueprint that covers only the next use case leaves a substantial part of the organisation outside the picture.

Start with the workflows that already matter

The reports do not establish that SBI previously lacked governance. They also do not show which existing systems the proposed framework will replace. Reading either conclusion into the announcements would confuse an enterprise programme with a verdict on everything that came before it.

The useful practitioner question is how to connect old and new controls without breaking the work already being done.

As an illustration, I would begin a hypothetical bank's framework project with one active lending workflow. I would map where AI contributes, which human or system makes the consequential decision, where the evidence is retained and who handles an exception. That map would describe actual operational responsibility before introducing a new platform layer.

Then I would compare it with the proposed framework. Which existing controls can remain? Which need a shared interface? Which decisions require a new owner? A migration plan should make those changes visible instead of treating every current system as an implementation detail to be discovered later.

The same exercise would reveal dependencies that an architecture diagram can miss: a manual review queue, a vendor-specific output, a model version tied to a business rule, or a downstream report needed by another team. These are illustrative possibilities, not claims about SBI's systems.

A new standard needs an adoption path

An enterprise framework can offer consistent evaluation, access management and monitoring. Its value depends partly on whether operational teams can adopt those capabilities while preserving the controls they already rely on.

I would therefore ask each migration proposal to name the old behaviour, the intended replacement and the evidence required to switch. For a consequential workflow, the team also needs a way to identify a regression and return to an agreed state. “Onboarded to the framework” is too vague to serve as the acceptance criterion.

There is a sequencing choice here. The most visible new use case may demonstrate the platform neatly, while an existing workflow may expose the integration problems that will determine whether it can become an enterprise standard. I would include at least one existing workflow early enough for those findings to influence the design.

Before the next AI architecture workshop, ask for a production inventory with accountable owners. It need not be a grand catalogue to start. One carefully traced workflow can reveal whether the discussion is about genuine integration or merely a new place to host future experiments.

The reported scale of SBI's existing AI use makes that distinction worth watching. The harder question is how a broad programme accommodates the decisions, dependencies and operating knowledge that are already in place.

An enterprise AI framework earns its scope by bringing existing production workflows into it.