Shadow AI in Banking: You Can't Govern What You Can't See
A credit analyst has a memo due before noon. To save an hour, the borrower's financial statements go into a free AI chatbot for a first draft. No one approved that tool, and no one in IT, Risk, or Compliance knows it happened. That is shadow AI in banking, and it is likely happening in your institution today, with or without a formal AI strategy.
For many banks, the first AI challenge is identifying where AI is already being used, what information it can access, and how its outputs enter business decisions. An approved platform can still be used outside its authorized purpose, with unapproved data or excessive permissions. The unit of governance should therefore be the use case, its data access and its business impact, not the tool alone.
Where is shadow AI already being used in your bank?
The risk already has a precedent. On May 5, 2026, Community Bank, a subsidiary of CB Financial Services, learned that nonpublic customer information had been handled with an unauthorized AI-based application. According to the Form 8-K filed with the SEC, the exposed data included names, Social Security numbers, and dates of birth.
The company determined the incident was material on May 7 and disclosed it on May 11. Operations, payment systems, and core infrastructure were never disrupted. The disclosure highlights an important distinction: a data-handling incident can be material even when payment systems and core infrastructure continue operating normally. The filing stated that the investigation into scope and root cause remained ongoing
Shadow AI usually shows up in four places: browsers; personal accounts opened with corporate email; desktop and coding assistants; and AI features switched on inside software you already approved. No single signal finds all of them, so you need to combine sources:
- Network and DNS logs show traffic to known AI domains, although they miss much of what happens inside the browser.
- Identity and SSO records show AI services accessed through the bank’s identity provider and OAuth permissions granted to applications. They do not provide a complete inventory of accounts created directly with an email address and password.
- Endpoint and browser telemetry on managed devices surfaces extensions, desktop clients, and coding assistants.
- SaaS admin consoles list AI features that vendors have added to tools you licensed years ago.
Logs provide evidence of activity within monitored channels. Team interviews help establish the business purpose, data involved, and uses those channels may miss. A short survey or workshop with lending, operations, compliance, and marketing usually surfaces the purposes behind the traffic: summarizing policies, drafting customer letters, cleaning up spreadsheets.
Build a use-case register that records the business owner, tool and account type, data accessed, connected systems, intended output, approval status, and required controls. Prioritize cases involving customer information, broad connector permissions, or outputs used in customer-facing decisions. Before introducing new employee monitoring, have Legal and HR review notice and privacy requirements.
Classify data for AI before you classify tools
Most banks already have a data classification scheme: public, internal, confidential, restricted. The gap is that it rarely says where each class can go when AI is involved. If your data governance program is solid, extend it with one rule per class: which AI environments may receive that data.
Some information should never enter a public AI tool, whatever the use case:
- Customer nonpublic personal information, such as account numbers, Social Security numbers, and loan files.
- Credentials, API keys, and system configurations.
- Material nonpublic information about the bank or its clients.
- Internal audit findings, exam reports, and regulatory correspondence.
- Source code for core and customer-facing systems.
Banks already must protect the security and confidentiality of customer information under the Interagency Guidelines Establishing Information Security Standards. Generative AI gives that same data one more way out of the bank.
Approved, restricted and prohibited AI use cases
A practical AI acceptable use policy sorts use cases into three tiers and ties each one to an environment. Where a task runs is as important as the task itself.
Consumer tools are the free or personal versions anyone can sign up for, and their data handling depends on terms the bank never negotiated. An enterprise label is not an approval. The bank should verify contractual terms for data use, retention, and subprocessors, then confirm that identity controls, access restrictions, connector permissions, and audit capabilities are configured and tested for the intended use case.
|
Tier |
Example use cases |
Conditions |
|
Approved |
Summarizing public regulations; brainstorming with public or synthetic information |
Authorized environment, permitted data and a named business owner |
|
Restricted |
Summarizing customer complaints; drafting credit memos; analyzing loan portfolios; generating production code |
Explicit use-case approval, authorized data access, defined validation and review, and appropriate traceability |
|
Prohibited |
Entering customer information into unauthorized tools; exposing credentials; connecting systems without approval; using AI outputs in customer decisions outside approved controls |
Must not proceed; suspected exposure follows the bank’s incident-response process |
Human review is a control, not an approval category. A reviewer must have the information, authority, and time needed to challenge the output before it affects a customer or business decision.
Decisions that affect customers raise their own questions of explainability, which we explored in our article on responsible AI in mortgage lending. Review the tiers every quarter, because new use cases appear faster than annual policy cycles.
Data protection addresses only one part of the risk. A credit memo generated inside an approved environment can still misstate a financial ratio, omit a covenant, or cite an outdated policy. For consequential uses, define what must be checked against source records, who approves the output, and whether it may enter a system of record. A named employee remains accountable for its use.
Logging, access controls and traceability
Governance without evidence won't hold up in an exam. For any AI interaction that touches sensitive data, you should be able to answer four questions: who used the tool, which tool, with what data, and for what purpose.
Getting there takes four controls:
- Route enterprise AI access through SSO, so every session ties to a named user.
- Assign permissions by role, so a teller and a credit analyst don't get the same AI capabilities or data connectors.
- Define the evidence required for each restricted use case. Retain prompts and outputs where justified, protect them according to their sensitivity, and limit access and retention. Logging should not create an unnecessarily broad second repository of customer information.
- Apply and test DLP controls across supported browsers, endpoints, and AI integrations, and document the channels and data types they do not cover.
When discovery indicates that sensitive information may have entered an unauthorized service, route the case into the bank’s incident-response process. Preserve available evidence, contain access, and involve Security, Privacy, and Legal to assess the exposure and any notification obligations.
These controls depend on how your AI architecture is designed. We covered the main layers in our piece on security in generative AI architectures.
Your vendors are adding AI too
Shadow AI also arrives through software you already pay for. CRM, help desk, document management, and productivity suites ship AI features in routine updates, sometimes turned on by default. A tool your vendor management team approved three years ago may now send data to a model provider you have never assessed.
Add third-party AI risk questions to due diligence and renewals. Which features use AI? Which model providers receive our data, and do they use it for training? Can we disable features by user or group? The Interagency Guidance on Third-Party Relationships already covers the full relationship lifecycle, so AI features fit into that same review.
Do not wait for renewal to reassess a material change. Define review triggers for new AI features, model providers, data uses or connector permissions, and assign an owner who can restrict or disable the feature while the change is assessed.
Why bans and AI committees alone won't stop shadow AI in banking
Blocking unauthorized services can reduce exposure on managed channels, but it doesn't address the business demand driving their use. Pair restrictions with approved alternatives, a clear approval process and a defined response time for new use-case requests.
What works is an approved alternative that is easier to use than the unapproved one: single sign-on, access to the internal documents people need, and a clear answer on what is allowed. When the sanctioned tool is also faster, you remove the main reason people go around it.
An AI committee or a written policy has the same limit. A written policy tells people what to do. Detection, access controls, and logs tell you whether they did it. Give your committee a monthly view of tools detected, users in approved environments, policy exceptions, and vendor AI features under review.
Start with what you can see
Use the first 30 days to establish a baseline and address the highest-risk findings. Deliver a prioritized use-case register, contain suspected sensitive-data exposures, assign owners and remediation dates, and offer approved alternatives for the most common legitimate tasks. Report monitoring coverage and unresolved gaps alongside the findings.
Leadership should be able to show which exposures have been contained, which legitimate workflows now have an approved path, and which risks remain unresolved—with an owner and a deadline.
At Pragma, we help banks put AI to work with governance built in, from detection and data rules to the enterprise environments and controls examiners expect to see. Our artificial intelligence practice can help you turn that first inventory into a program your teams will use.
Share this
Subscribe to
Pragma Blog
You will receive a monthly selection of our content on Digital Transformation.