AI Accountability in Banking: Who Owns the AI Decision, What Happens When No One Does, and How RBI Expects Accountability to Work All the Way to the Board

When a credit officer's decision turns out wrong, the accountability trail is uncomfortable but traceable: the officer decided, a supervisor signed off, and a file shows the reasoning at the time. When an AI model's decision turns out wrong, that trail frequently doesn't exist in any usable form. A policy document may name the Model Risk Head as accountable for AI performance — but if that person can't pull the specific input features behind a specific decision, doesn't know when the model was last validated, and can't produce a plain-language reason for the output, accountability exists on paper and nowhere else. I've sat across the table from examiners who stopped asking about policy the moment they realized this, and started asking the model risk owner to actually open the case file in front of them.

What an examiner actually tests is whether the named owner can exercise accountability, not whether a document assigns it. Do they have data access, investigative authority, and the standing to remediate harm? Most banks are further along on the paperwork than on the operating muscle.

Four accountability dimensions a bank has to cover, not just document

Decision ownership has to sit below the portfolio, at the use-case level. "The Model Risk Head owns all credit AI" is a title, not an operating model — it names nobody who can answer for a specific declined application. Every AI system producing a decision or recommendation that touches a customer or a business process needs one named person who answers for that outcome, and that person is never "the model."

Design accountability is a separate chain from outcome accountability. Someone approved the training data, the feature set, the validation methodology, and the go/no-go to deploy — and if a model later disadvantages a protected group because of a feature choice made in development, that approver owns it, not the business line that only consumed the model's output. Banks routinely conflate the two and end up with no one accountable for design-stage decisions once the model is in production.

Vendor AI accountability cannot be delegated to the vendor, full stop. When a vendor model makes a discriminatory or wrong decision, the bank answers to the customer and to RBI, not the vendor — so the accountability chain has to be built into the contract itself: explainability rights, audit rights, and advance notice of model changes. A vendor's SLA on uptime says nothing about who explains a bad decision to a customer six months from now.

Board accountability has to be demonstrable, not nominal. RBI examiners test whether board members can explain the risk tier of material AI deployments and whether they approved the risk appetite governing them — not whether their names appear on a governance charter. A board that receives a quarterly AI slide deck but can't answer a direct question about a Critical-tier model's performance will not survive that line of questioning.

RACI for AI: who is Responsible, Accountable, Consulted, and Informed

Row five is the one that actually breaks under pressure. Deployment RACI is well-rehearsed at most banks because it gets exercised every release cycle. Remediation RACI — who owns the harm, who designs the fix, who tells the regulator, what the customer actually receives — usually only exists as a generic incident process that was never built for AI-specific failure modes: harm at scale from a systematic bias, harm that needs a model redesign rather than a one-off correction, or harm where the customer explanation requires re-running the model on corrected inputs. The first time this gets tested for real, in my experience, is the worst possible time to discover the gap.

India-specific accountability obligations

Data Fiduciary accuracy duty, not a right to explanation. What the DPDP Act does give a customer is the right to access what personal data the bank holds (Section 11) and to seek correction or erasure (Section 12) — real statutory hooks that still require someone in the accountability chain who can pull a specific customer's decision-relevant data and act on the request within the Act's timelines.

The Fair Practices Code is where the real explanation obligation lives. RBI's Fair Practices Code requires lenders to communicate reasons for credit rejection. When an AI model drives the decision, the reason given has to reflect the model's actual logic, not a disclaimer that "our automated system has assessed your application." Most banks have no single person accountable for whether those customer-facing explanations are both compliant and factually accurate — it falls into the gap between the model team, who owns the SHAP output, and compliance, who owns the letter template.

BC-network accountability doesn't transfer to the Business Correspondent. For AI-assisted decisions delivered through BC networks, the chain runs: AI recommendation → BC agent mediates the interaction → customer, who often has limited ability to push back. A BC agent's thin governance capability does not transfer the bank's accountability obligation — the bank's AI accountability framework has to extend to BC-assisted deployments, including override rights and explanation rights for the rural customer on the other end of that interaction.

What a bank should do this quarter

1. Pull the model inventory and check: does every Critical and High-tier AI system have a named individual owner — not a team, not a title — who can be reached within 24 hours of an incident?
2. Build a remediation RACI as a distinct workflow from deployment RACI. If it doesn't exist as a separate document today, it doesn't exist.
3. Audit vendor AI contracts for explainability rights, audit rights, and change-notification rights. A vendor SLA without these clauses leaves the bank accountable with no tools to act on it.
4. Assign one named owner for the accuracy and compliance of customer-facing adverse-action explanations — distinct from the model owner who produces the underlying SHAP output.
5. Test board accountability directly: can a board member explain, unscripted, the risk tier and approved risk appetite for your three largest AI deployments?

Request a demo of Zytra's governance module to see how use-case-level RACI, remediation tracking, and DPDP data-subject-rights fulfillment map onto a single accountability record.