Here's a question that should make you uncomfortable: how many of your employees are using unsanctioned AI tools? Not whether they're using them, but how many. Not experimenting. Using. Daily. In production workflows, often through personal accounts IT never approved.
Before context, CI speed, and feedback loops comes governance: where AI-generated code enters a bank's codebase without sufficient visibility or oversight, new risks can accumulate.
There is a useful governance parallel with opaque financial exposures before the 2008 crisis: what institutions cannot adequately observe is difficult to manage. Shadow AI presents a different kind of risk, but the lesson about visibility and oversight still applies.
Tab-Speed development
Watch a developer work in 2026. Three characters, Tab. Four characters, Tab. Accept, accept, accept. Except this is production code for your payment service.
I call this Tab-Speed development. With Copilot or Claude Code, developers navigate suggestions. Agents go further: creating files, running tests, and submitting PRs. Shadow copilots leak context. Shadow agents act on it.
Review queues were designed for human-written changes. Now reviewers see diffs even the author hasn't fully read.
The Approval Queue Paradox
Some developers may paste proprietary code into personal AI accounts. Blanket bans can drive that behaviour underground, making it harder to detect and govern.
Shadow AI is a governance vacuum. You cannot solve a governance vacuum with a technology ban. You need risk-based triage, policy enforcement, and a record of how AI-assisted changes were produced.
An agent generates a diff in seconds; an engineer needs minutes to review it. According to Faros AI's 2025 research, high-AI-adoption teams merged 98% more pull requests, while review time was 91% longer and pull-request size 154% larger. These are observed associations, not proof that AI alone caused the changes. As review workloads grow, oversight risks becoming a formality. Source: https://www.faros.ai/blog/ai-software-engineering
The Approval Queue Paradox: the faster code is generated, the more valuable review becomes - and the less time you have for it. If changes then pile up before deployment, the bottleneck merely moves.
Green / Yellow / Red
If banning doesn't work, what's the middle path? Triage changes, not developers. Route each diff by risk. I call this Green / Yellow / Red.
Green means auto-advance. Changes meet conservative criteria: sufficient tests, architectural policy checks, low-risk surfaces, and limited complexity. Routine documentation, configuration, or dependency updates can move through the pipeline automatically.
Yellow means human-in-the-loop with a suggested fix. The system flags a problem and proposes a fix. The reviewer accepts, rejects, or escalates.
Red means escalation without recommendation. Changes to authentication, payments, customer data, or security-sensitive systems require senior review with full context.
This approach is consistent with broader risk-management principles, such as the NIST AI Risk Management Framework, though that framework does not prescribe this specific traffic-light model. Reference: https://www.nist.gov/itl/ai-risk-management-framework
This is risk-based governance, familiar to banking. Green isn't about trusting the machine; it's about removing signatures nobody was really giving.
The false-positive math
Set the Green threshold too low and risk accumulates invisibly. Set it too high and every change still needs human review. You've just moved the bottleneck from writing code to reviewing it.
For illustration, if a human review costs $150 and an escaped issue costs $5,000 to fix, a simplified model suggests the Green bucket would need a success rate above roughly 97% for automatic approval to offer an expected cost advantage. This is an illustrative calculation, not a universal banking threshold: real decisions must account for the likelihood and severity of failures, including security and customer harm. Put your own numbers in.
As checks improve, Green grows. Yellow decisions and Red escalations provide feedback. Standards don't fall; checks get smarter. This is compound interest in governance.
Continuous Modernization
Automatic decisions enable a maintenance crew working the night shift: updating that old Java tool or long-pinned library nobody dares touch.
AI agents and deterministic tools can upgrade dependencies, run tests, and send PRs through Green / Yellow / Red. Small changes accumulate without a three-month migration project.
The audit trail: where Visdom AI Tracing fits
Then comes traceability. An auditor will ask: Where did this code come from? Which model and context? Who reviewed it? When was it deployed?
The minimum viable audit trail for AI-generated code is five fields: origin model, timestamp, context, approver, and deployment date. Without them, you're accumulating compliance debt alongside code.
Visdom AI Tracing is one example of a product designed to address this problem. According to its developer, it records prompts, model calls, tool usage, file changes, commits, and code attribution to help trace how code was produced and approved. Banks should independently assess such capabilities against security, privacy, retention, and regulatory requirements Visdom
For a bank, that kind of traceability can function like a flight recorder for AI-assisted delivery, making AI activity more observable and controllable. Governance must work at machine speed, or it risks being routed around.
What to do now
First, assess the shadow. Ask developers what tools and accounts they use, and why. The goal is visibility, not discipline.
Second, provision rather than prohibit. Offer sanctioned alternatives that meet the same needs with appropriate data governance and access controls.
Third, start Green / Yellow / Red conservatively. Measure approved changes and escalations, then calibrate your thresholds.
Fourth, build the audit trail into the pipeline. Record origin, timestamp, context, approver, and deployment information.
Finally, expand Green as automated checks improve. Reserve human attention for architecture, security, and business logic with real downside.
The question is no longer whether
Shadow AI isn't going away. Neither is Tab-Speed development. The question isn't whether to allow it - that ship sailed while you wrote your AI policy document. The question is whether you'll have visibility, traceability, and intelligent triage before the first serious audit finding, or after it.
About the Author
Artur Skowronski is the Head of Application Development at VirtusLab. His article examines the governance challenges of AI-assisted software development in banking, including risk-based code review, traceability and oversight.
Visdom AI Tracing is presented as a product example, not an independently verified endorsement. Any commercial relationship between the author and the product provider should be disclosed alongside publication.