The compliance problem in AI banking is where no system is watching
Most banks treating AI compliance as a policy problem are looking in the wrong place. The real exposure sits in the whitespace between systems - the handoffs and exception workflows that no platform owns and no audit trail reaches. That whitespace is not a minor operational footnote. Research behind Backbase's Banking OS value proposition puts it plainly: roughly 50% of frontline banking work happens in this unowned space. That is where AI compliance risk concentrates first.
When AI agents operate inside fragmented infrastructure, they work on partial data, follow inconsistent rules pulled from different sources, and write results back to whichever system happens to be upstream. That is not automation in any meaningful sense. Backbase's internal research describes it as "chaos at higher speed" - a failure mode that produces decisions regulators cannot examine. Customers cannot challenge those decisions, and banks cannot reconstruct them after the fact. The architecture produces the compliance problem before any policy choice enters the picture.
Regulators in 2026 are shifting focus toward exactly this layer. Supervisory reviews are starting to ask not just what an AI model decided, but where that decision executed. They also ask what data it acted on, and whether any authority boundary governed the action. Banks that built their execution layer across disconnected systems have a compliance problem that documentation cannot close.
Why governance layers added after deployment fail at the execution layer
Most compliance responses to AI risk follow the same pattern: deploy the AI agent first, then add reporting overlays, audit logs, and model risk checklists on top. That approach assumes the underlying infrastructure is coherent enough to support those controls. In most banks, it is not. AI agents running on fragmented infrastructure operate on partial data, follow inconsistent rules, and write back to different systems of record. The result is not controlled automation - it is chaos at higher speed. That is exactly the failure mode regulators will target under OCC model risk guidance and EU AI Act supervisory review.
The core problem is structural. When 50% of frontline activity lives in the whitespace between disconnected systems, there is no single source of truth for an AI agent to act on. Compliance controls added after deployment cannot fix that. A reporting overlay can flag anomalies after the fact, but it cannot stop an agent from acting on incomplete customer data at the moment a decision is made. That is where audit trails break down and where regulated banks carry real liability. AI compliance for banking operations requires tracing this structural root cause.
As Jouk Pleiter put it in a recent conversation on agentic banking: "If you don't solve the guard function, I don't see AI at scale in banks at all. I basically see the risk and compliance argument paralyzing innovation." The guard function is not a governance document or a risk committee sign-off. It is a structural property of how AI agents are built into the execution layer. Banks that treat compliance as a retrofit will find that every new AI deployment restarts the same problem from scratch.
What the EU AI Act and OCC guidance demand from your execution architecture
The EU AI Act and OCC model risk guidance share a thread that most banks miss. Both require banks to demonstrate, at the point of action, what authorized a decision, who or what carried it out, and under what defined limits. That means the compliance requirement lives in the execution layer, not the reporting layer. McKinsey's risk and resilience research makes the same point: compliance architecture that cannot keep pace with AI deployment creates the liability it was meant to prevent.
Regulators are converging on a specific expectation: governed delegation. Every AI agent operating inside a bank needs an explicit, traceable chain of authority - what it is permitted to do, on whose behalf, and with what constraints. Fragmented systems cannot answer those questions in real time. When frontline work is split across disconnected tools, authority chains exist only on paper, not in the execution layer where decisions happen.
Banking OS is designed to enforce that governed delegation across customers, employees, and agents operating on the same unified frontline. Every action runs through a single execution layer that carries the authorization record with it. Regulators do not need to take your word for it - the audit trail is built into how the action was taken, not reconstructed afterward from scattered logs. That structural difference is what emerging regulation is implicitly demanding, whether the policy language has caught up to it yet or not. What AI-native banking means architecturally shapes how that enforcement layer is built.
Auditability by design means every AI-driven action carries its own proof
Most banks treat auditability as a reporting problem. After an AI-driven action occurs, a logging layer captures what happened and assembles the record. That approach breaks down under regulatory scrutiny because the log is separate from the decision. It can be incomplete, delayed, or missing context that only existed at the moment of execution. PwC's analysis of AI in banking highlights this disconnect between documentation and real-time governance.
Banking OS takes a different position. It issues a Decision Token for every AI-driven action at the point of execution - not as an overlay added afterward, but as a native property of the operational runtime. The token travels with the action. Compliance teams do not need to reconstruct what happened from scattered logs. The proof is already attached.
That distinction matters when regulators ask how a specific AI decision was made, who authorized it, and what policy governed it at that exact moment. A retrofit logging layer cannot answer those questions with confidence, but a token issued at execution can. For banks preparing for AI model governance reviews in 2026 and beyond, this is the difference between auditability that holds up and auditability that approximates. Backbase's Sentinel solution is built around exactly this principle.
Governed agent authority is the missing control plane compliance teams need
Most banks cannot answer a question regulators will eventually ask: what is each AI agent authorized to do, under whose authority, and within what limits? Across more than 120 bank implementations, the answer is almost never stored anywhere. Agent authority was never defined in the execution layer to begin with. When half of frontline banking work lives in the whitespace between systems - handoffs and exception workflows that no single system owns - there is no control plane to audit. AI agents operating in that whitespace act on partial data and inconsistent rules. That is exactly where compliance risk concentrates. The link between agentic AI and customer experience makes this governance exposure even more consequential.
Backbase's Banking OS is built to eliminate that whitespace by enforcing governed delegation across every actor on the frontline. Customers, employees, and AI agents operate under the same authority framework. Every agent has an explicit authorization scope - what it can initiate, what it must escalate, and what it cannot touch. That is not a governance layer added after deployment; it is enforcement built into the execution layer itself. The agentic servicing solution reflects this design philosophy end to end.
Compliance teams need a control plane they can demonstrate to regulators, not describe to them. When agent authority is defined and enforced at the architecture level, every AI-driven action carries a governed audit trail by design. Banks stop relying on retrospective log analysis to reconstruct what happened, because the record exists as a condition of the action having run at all.
How compliance teams should prepare for an architecture-first regulatory environment
The most important question a compliance officer can ask in 2026 is not "does our AI model have an audit log?" - it is "where does our AI execute, and does governance live there too?" OCC guidance and EU AI Act enforcement are both moving toward accountability at the point of action. Regulators want to see that controls exist where decisions happen, not in a reporting layer added afterward. Deloitte's AI governance framework reaches the same conclusion about where accountability must be anchored.
Jouk Pleiter put the risk directly: if banks do not solve the guard function, AI at scale simply will not happen. That is not a warning about policy - it is a warning about architecture. Ask your technology partner one question first: can every AI-driven decision be traced to a governed policy at the exact moment it ran, across every system the agent touched? If that answer requires reconstruction from logs rather than retrieval from the execution record, the architecture is not ready.
In 2027, enforcement attention will concentrate on exactly what that question exposes - the whitespace between disconnected systems where no audit trail, no policy check, and no single source of truth currently exists. Compliance teams that wait for a governance layer added after deployment will find it too late. The preparation work starts now, at the architecture level, not at the reporting layer. How to build an AI-native bank lays out the foundational steps in practical terms.
Banks that treat compliance readiness as an architecture decision - rather than a governance document - will be the ones able to demonstrate auditable, bounded AI authority when regulators come looking in 2027.
Frequently asked questions
What does the EU AI Act require banks to demonstrate about AI-driven decisions in regulated processes?
The EU AI Act requires banks to show, at the exact point of action, what authorized a decision, who or what carried it out, and within what defined limits. This is an architectural requirement, not a reporting one. Governed delegation must exist in the execution layer where decisions happen, not only in documentation.
How is OCC guidance on model risk management evolving to cover autonomous AI agents in banking?
OCC model risk guidance is converging on accountability at the point of action. Regulators now ask not just what an AI model decided, but where that decision executed. They also ask what data it acted on, and whether any authority boundary governed the action. Banks running agents across fragmented systems will find those questions extremely difficult to answer.
Why can't traditional RegTech compliance overlays keep up with AI agents operating across multiple banking systems?
Compliance overlays added after deployment assume the underlying infrastructure is coherent enough to support controls. In most banks it is not. When roughly half of frontline work lives in whitespace between disconnected systems, no single source of truth exists. A reporting overlay can flag anomalies after the fact but cannot stop an agent acting on incomplete data in the moment.
What is a Decision Token and how does it support regulatory audit requirements for AI in banking?
A Decision Token is issued by Backbase Banking OS at the exact moment an AI-driven action executes, traveling with that action as a native property of the operational runtime. Compliance teams do not need to reconstruct what happened from scattered logs afterward. The authorization record, governing policy, and audit proof are already attached to the decision itself.
How should compliance teams assess whether their bank's AI architecture is ready for emerging regulatory scrutiny?
Compliance officers should ask their technology partners whether every AI-driven decision can be traced to a governed policy at the moment it ran, across every system the agent touched, and whether that trace comes from the execution record or requires reconstruction from logs. Those answers reveal architecture readiness, not just policy readiness.
