That question is harder to answer than it sounds. A written AI policy doesn't answer it, because a policy describes intent, not what actually happened in a specific case.
Mitch Siegel, Principal and Partner for Financial Services Consulting at EY in the US, raised this on the Banking Reinvented podcast. He's spent thirty years in financial services helping banks. He explained that most bank AI programs are run "by committee," not by a single owner.
This piece goes deeper on the part most banks get stuck on, and the point Siegel raised during his conversation with me on the episode: proving, case by case, who was accountable for what an AI agent did.
For the broader picture on frameworks, controls, and policy, see our complete guide to AI governance in banking.
Why this question matters now
Three regulators started requiring that proof within weeks of each other. In the US, the OCC and the Federal Reserve have made AI a standing question in every routine bank exam since June 2026, covering governance frameworks, vendor risk, kill switches, and data boundaries. Singapore's MAS released its SAFR framework on July 2026, building governance checkpoints into how AI agents are allowed to act. The EU AI Act's high-risk obligations become fully enforceable on August 2026.
Three different regulators in three regions are landing on the same requirement at almost the same time. Whatever shape a bank's AI program already takes, proving accountability just moved from best practice to requirement.
What regulators are asking for
Regulators are now telling banks that AI decisions need to be documented, with a clear audit trail behind them. Siegel frames this as a bigger shift than it sounds: Banking regulation has traditionally worked backward, reviewing a decision after the fact to see what went wrong. He argues that AI flips that model. A bank now has to look forward and prove a decision will hold up before an AI agent is ever allowed to act on it.
That's the difference between a flight recorder and a pre-flight checklist. One explains what happened after something goes wrong. The other exists to stop it from going wrong in the first place. Siegel's point, in different words: banks need to build the checklist, not just keep a better recorder.
Why most banks can't answer it yet
Ask most banks who owns their AI program, and the answer is usually a committee, not a name. "CEO is always involved, usually getting updated, but when you get to the real steer of the decision makers, it tends to involve a number of those stakeholders," Siegel said.
Those stakeholders don't see the problem the same way. The CIO has a very specific thing, while the chief digital officer has a slightly different lens on it. Meanwhile, the heads of retail and commercial banking bring their own priorities into the room too, and everybody adds a different angle on what the bank should be solving for.
CFOs are increasingly in that room as well. Since they own the balance sheet and have to answer to analysts on earnings calls, they need confidence that the reasoning behind an AI decision will hold up if a regulator, or an investor, asks about it later.
In practice, that means a loan approval or a fraud flag gets shaped by several people with different priorities before an AI agent is ever allowed near it. Getting that group to agree fast is already hard. Getting them to produce one clean explanation six months later, when an examiner asks, is harder still.
Building the record isn't instant either
Even once a bank knows who's accountable, producing a reliable audit trail depends on data most banks don't have in usable shape.
"Data is all over the place. It's siloed all over organizations," Siegel said. Getting to some semblance of a source of truth across all the different silos isn't a quick fix nor a six month process, but a multi-year journey.
That fragmentation isn't an abstract IT problem. It's a loan file sitting in one system, KYC documents in another, and the customer's actual transaction history in a third, none of them fully agreeing with each other. An AI agent acting on that mess doesn't produce a slightly-off answer. It produces a fast, confident one that happens to be wrong, which is a much harder thing to catch and explain later.
Two ways banks are answering it right now
Banks are testing two different AI governance models right now. A case study on Banco Bradesco and TELUS, published this year, documented a multi-tiered AI governance framework built around committees: strategic steering groups and mandatory human sign-off on every review cycle. That's the AI governance committee model, formalized rather than informal. Commonwealth Bank of Australia and Lloyds went the other way, each naming a chief AI officer this year, betting on one clear owner to govern AI risk instead of a group.
Neither approach has proven itself the winner yet, and it may be years before one clearly does. What both are reaching for is the same thing: a way to answer "who decided this" without relying on someone's memory of a meeting that happened months earlier.
What a governed AI agent needs to prove accountability
The mechanics matter as much as than the org chart. Whether a bank runs on committees or a single owner, every action an AI agent takes needs an authorization and a reason attached to it the moment it happens, in a form that outlives the meeting where it was discussed.
Picture a fraud agent that freezes a customer's card at 2 AM in a bank that lacks the right foundation underneath it (the version most banks are one bad audit away from): The reason for freezing the card lives in a log file nobody monitors, and the authorization sits in a spreadsheet someone updates on Fridays. The policy that triggered the freeze was last reviewed eight months ago, in a meeting three of the five approvers barely remember.
The customer calls in furious, certain it's a mistake. A regulator's request lands a year later, asking for the exact explanation nobody kept. Nobody can produce a straight answer.
On the other hand, with the right foundation underneath it, that single action carries who authorized it, the confidence threshold it cleared, and the policy it followed - automatically and within the instant it happens. If a regulator asks about it a year later, the answer isn't "let me check with the team." It's already on file.
This is close to what the Backbase Banking OS calls Sentinel and the Decision Token. Sentinel is where the bank defines what an agent may do. Every authorized action then produces a Decision Token, a real-time record carrying scope, constraints, and a reason code. The bank sets the autonomy level for each action. The system holds the reason on record, so proving it later doesn't depend on anyone's memory. The same governed foundation carries through into how Customer Operations resolves work end to end, not just how it's authorized to start.
Continue reading: Why AI can't reason across a fragmented bank
The bet that matters
Committees and single owners are both live experiments right now, and it's genuinely too early to call a winner. What isn't up for debate is what regulators are asking for underneath either structure: one clean, checkable answer to who authorized an action and why.
The structure matters less than what survives it. A committee can absolutely make a good call. The real question is whether that call has an owner and a reason attached to it the moment it's made, recorded somewhere durable enough to survive the meeting where it happened.
That's the gap every bank running AI agents will eventually have to close, regardless of whether one person signs off or twelve do. The regulators asking the question aren't going away, and neither is the number of decisions banks are handing to agents. Building the record now costs a lot less than reconstructing one after an examiner asks for it.
Continue reading: Banks have an org chart problem, and it's stalling agentic AI
Frequently asked questions
How do regulators expect banks to audit and explain decisions made by AI agents?
Regulators expect a documented, traceable record for every consequential decision an AI agent makes, covering what the agent did, what authorized it, and why. In the US, the OCC and the Federal Reserve now ask about this in every routine exam. The EU AI Act requires it explicitly for high-risk systems starting August 2, 2026. Singapore's MAS SAFR framework builds the same expectation into how agents are allowed to act. The common thread across all three: documentation happens before or during the action, not after something goes wrong.
How do banks enforce AI governance policies?
Policies get enforced at the point of action, not in a document. That means attaching an authorization check to every AI-driven decision before it executes, logging the reason and the actor behind it, and routing anything outside defined limits to a person for approval. A policy that lives separately from the system making decisions is difficult to enforce consistently and even harder to prove during an audit.
How do banks govern AI risk?
Banks govern AI risk by defining who can authorize which actions, at what confidence level, and under what conditions a human has to step in. That authority has to be attached to the action itself, not just written into a policy document, so it can be checked and audited after the fact. Banks that treat this as an architecture requirement, rather than a compliance afterthought, are better positioned to scale AI past a pilot.
What does an effective AI governance framework in banking need to include?
An effective framework needs clear ownership of each AI-driven decision, documented reasoning attached to every action in real time, defined autonomy levels by task and risk, and a way to shut an agent down or escalate to a human when conditions call for it. A framework that only exists as a document, without being enforced at the point an agent acts, won't satisfy a regulator asking for proof after the fact.
.png)
