Shadow AI in Financial Services: What the First SEC Form 8-K, the GLBA Safeguards Rule, and OCC 2026-13 Mean for Your Undocumented AI Inventory

On May 5, 2026, Community Bank — the wholly owned subsidiary of CB Financial Services, Inc. — discovered that one of its employees had used an unauthorized AI application to process non-public customer information. Names. Social Security numbers. Dates of birth. None of it ever ran through an approved tool, a vendor assessment, or a contractual confidentiality framework.

Six days later, CB Financial filed a Form 8-K under Item 1.05.

It was the first-ever SEC cybersecurity disclosure triggered by an employee’s shadow AI use, as opposed to an external attack. The company determined the incident material based on the volume and sensitivity of the exposed data alone. Not a ransomware hit. Not a third-party intrusion. An employee using an AI tool nobody had approved.

TL;DR

• CB Financial Services filed the first SEC Form 8-K for unauthorized employee AI use on May 11, 2026 — a materiality call based on volume and sensitivity of exposed PII, not financial loss
• Shadow AI creates direct GLBA Safeguards Rule liability under § 314.4(b) (data inventory gaps) and § 314.4(c)(2) (no vendor contract, no security assessment)
• 73.8% of ChatGPT enterprise use runs through personal accounts — outside DLP monitoring and logging visibility
• OCC 2026-13 excludes GenAI from formal model risk scope, but examiners are asking about it anyway; a separate AI-specific RFI is coming
• IBM 2025: 1 in 5 organizations suffered a breach because of unapproved AI tool use
• Every bank and fintech needs an AI inventory, an amnesty survey, and an acceptable use policy with teeth — before the next exam

Why “Shadow AI” Is Different from Shadow IT

Shadow IT — employees using Dropbox, personal Gmail, or unapproved SaaS tools — has been a compliance headache for a decade. Shadow AI is more dangerous for two reasons.

First, the data exposure is more concentrated and more sensitive. When an employee uses an unapproved cloud storage tool, they’re typically moving files. When they use an unapproved AI tool, they’re actively feeding the model context — customer account summaries to generate talking points, client portfolio data to produce trend analysis, AML case notes to draft SAR narratives, loan files to generate credit memos. They’re pasting the most sensitive data they touch directly into a system with no access controls, no contractual data protections, and no logging.

Second, the output is influencing regulated workflows. A compliance employee using ChatGPT to draft a SAR narrative is running a decision-adjacent workflow through an undocumented, unvalidated tool. An underwriter using a free-tier AI model to summarize a borrower’s financial statements is doing the same. None of it is logged. None of it is in scope for model risk management.

Research shows 73.8% of ChatGPT usage in enterprise environments occurs through personal accounts, creating monitoring blind spots. Employees authenticate unauthorized AI apps against their corporate email and document stores — handing those apps persistent access to correspondence, onboarding files, and counterparty data. The institution never consented to that relationship and has no contract governing what the AI provider does with the data.

The GLBA Safeguards Rule Trap

The FTC’s GLBA Safeguards Rule (16 C.F.R. Part 314) requires financial institutions — including non-bank financial institutions like mortgage companies, auto dealers, payday lenders, and investment advisers subject to the FTC’s jurisdiction — to implement comprehensive information security programs to protect customer information.

Two provisions are directly implicated when shadow AI is in play:

§ 314.4(b) — Data Inventory. The Safeguards Rule requires financial institutions to maintain an inventory of where customer information resides, where it flows, and how it’s transmitted. Shadow AI systematically undermines this requirement. When customer data is pasted into an unauthorized AI tool, it leaves the institution’s controlled environment with no log entry, no data flow record, and no corresponding risk assessment. The inventory is incomplete by definition.

§ 314.4(c)(2) — Service Provider Oversight. The Safeguards Rule requires institutions to select service providers that maintain appropriate safeguards and to require those safeguards contractually. When an employee downloads an AI productivity app or logs into a free-tier LLM through a personal account, there is no vendor selection process, no security assessment, no due diligence questionnaire, and no contract requiring data protection. The institution has created a de facto service provider relationship with zero of the required oversight.

The CB Financial incident made the Safeguards Rule implications concrete. An employee used an unauthorized AI application to process names, Social Security numbers, and dates of birth. That data transmission was precisely what the Safeguards Rule’s § 314.4(b) and § 314.4(c)(2) were designed to prevent. The institution couldn’t log it, couldn’t monitor it, couldn’t prevent it — because it didn’t know the tool existed.

The National Law Review’s analysis of shadow AI and the GLBA Safeguards Rule puts it plainly: an employee’s unauthorized transmission of nonpublic customer data to an external AI platform may constitute a failure of required safeguards, regardless of the employee’s intent.

The OCC 2026-13 Gap — and What Examiners Are Actually Asking

OCC Bulletin 2026-13 — the revised model risk management guidance that replaced SR 11-7 in April 2026 — is explicit about scope: generative AI and agentic AI are not covered by the formal model risk management framework. The agencies acknowledged these systems are “novel and rapidly evolving” and that the formal guidance isn’t designed for them.

This creates a documentation gap that works against institutions, not for them. The formal MRM framework doesn’t require institutions to document their generative AI exposure — but the OCC has signaled that a separate request for information specifically addressing AI is coming. And current exam practice is already ahead of the formal guidance.

Per reporting from TechTimes, AI oversight has expanded to every bank exam, with examiners routinely asking about generative AI exposure. Two specific areas emerged as common exam lines of questioning: model kill-switch protocols and regulatory reporting procedures for AI failures. 72% of banks report being least prepared in exactly those two areas.

Shadow AI makes both problems worse. You can’t have a kill-switch protocol for a tool you don’t know exists. You can’t report an AI failure if the tool was never in your documentation inventory.

The bottom line: OCC 2026-13 doesn’t formally require shadow AI documentation yet, but examiners are asking about your exposure — and the institutions that can demonstrate they’ve inventoried and governed their AI use are building credibility before the formal AI guidance drops. The institutions that shrug and say “we don’t know what our employees are using” are building a different kind of file.

For a deeper look at what OCC 2026-13 changed and the GenAI governance gap, see SR 26-2 and OCC 2026-13: What the New Model Risk Management Guidance Changes.

What Shadow AI Is Actually Doing in Financial Services Right Now

The CB Financial incident involved customer PII fed into an unauthorized AI. That’s the compliance officer’s nightmare scenario — but it’s not the most common shadow AI use case.

Here’s what’s actually running in financial institutions, unlogged and undocumented:

SAR narrative drafting. AML analysts are using ChatGPT and similar tools to draft suspicious activity report narratives. They paste transaction summaries, account details, and investigation notes into the tool and get a polished SAR narrative back. The tool is helpful. The data is highly sensitive. None of it is in any authorized workflow.

AML case notes and case management support. Case managers are summarizing case histories, generating follow-up questions, and drafting internal memos using AI tools. The customer data in those case summaries leaves the institution’s systems with every session.

Credit analysis and underwriting support. Underwriters are pasting financial statements, borrower profiles, and loan summaries into AI tools to generate analysis and recommendations. The AI output may be influencing credit decisions that have no AI governance documentation behind them.

Risk and compliance memo drafting. Risk and compliance staff are generating exam-response memos, policy summaries, and board presentations using AI tools — tools that sometimes receive confidential examination communications or nonpublic regulatory correspondence as context.

Vendor due diligence shortcutting. Procurement and third-party risk staff are running third-party risk assessments with AI assistance — sometimes uploading vendor contracts, financial statements, or security questionnaire responses to an unapproved tool.

Each of these use cases represents a data exposure, a missing audit trail, and a governance gap. For regulated institutions, all of them also implicate specific regulatory frameworks — and none of them are being logged by anyone in the institution right now.

Building a Shadow AI Discovery Program

The goal isn’t to prohibit employees from using AI. It’s to know what’s being used, get it documented, and either sanction it through proper channels or stop it. A functional shadow AI discovery program has four components.

1. AI Acceptable Use Policy

This should exist before you survey employees. Without a policy, you’re asking employees to self-report against an undefined standard. The policy needs to:

• Define “unauthorized AI” with examples
• Specify what categories of data may never be input into an unapproved AI tool (customer PII, nonpublic financial information, examination communications, personal health information)
• Establish an approval pathway for employees who want to use a new AI tool
• Specify consequences for unauthorized use

The policy needs employee acknowledgment — a signed attestation — and enforcement provisions. A policy that exists but has no acknowledgment and has never been enforced is worse than nothing: it’s evidence that management knew about the risk and ignored it.

2. AI Inventory Amnesty Survey

An amnesty survey is a confidential, no-penalty survey distributed organization-wide asking employees to disclose AI tools they’re currently using — whether officially approved or not. The framing matters: this is about visibility and governance, not enforcement of past behavior.

Distribute it to engineering, product, operations, compliance, risk, legal, finance, and support. Expect to be surprised. The tools that surface in an amnesty survey are rarely the ones your CISO assumed. Focus the survey on:

• AI tools used for work tasks (writing, analysis, coding, research)
• AI features embedded in software already approved (e.g., Copilot in Microsoft 365)
• AI tools that access corporate data, accounts, or email
• AI tools employees paid for personally but use for work

3. Technical Discovery

Self-report alone won’t find everything. Technical controls should supplement the amnesty survey:

• DLP tooling configured to flag large uploads to known AI platforms (OpenAI, Anthropic, Google)
• Browser monitoring / secure web gateway policies blocking unauthorized AI tools at the network level
• Cloud Access Security Broker (CASB) to enumerate which SaaS applications are connecting to corporate identity credentials
• Email OAuth app review — many employees grant AI apps permission to read email as part of setup

The goal of technical discovery is to find what the survey missed — and to establish an ongoing monitoring capability so new shadow AI tools are identified within days, not months.

4. Shadow AI Register

Once discovered, unauthorized AI tools need to go somewhere. Create a Shadow AI Register that documents:

• Tool name and vendor
• Employee or team using it
• Data types being processed
• Discovery method (amnesty survey vs. technical discovery)
• Disposition (approved, prohibited, pending review)

This register feeds into your AI model inventory — a core component of OCC 2026-13 compliance expectations and a standard ask during exams. It also creates the documentation trail the CB Financial incident made painfully clear was missing.

For a complete governance framework covering model inventory, the Shadow AI Register, and the amnesty survey methodology, see our AI Risk Assessment Template & Guide — which includes pre-built tabs for all three.

If you’re also dealing with agentic AI exposure — AI systems that take autonomous actions rather than just generating text — see Agentic AI in Financial Services 2026: The Governance Framework Your Board Doesn’t Know It Needs.

The Vendor Approval Gap — and Why “We Have a Policy” Isn’t Enough

Even institutions with AI policies often have a process problem: the approved AI tool list is outdated, the approval process takes weeks, and employees who genuinely want to do the right thing route around the process because waiting three months for a tool approval isn’t compatible with a project deadline.

If shadow AI is proliferating at your institution despite having a policy, the policy isn’t the problem. The bottleneck is the approval process. A shadow AI program that reduces unauthorized use needs to make authorized use easier — a reasonable approval process with a defined timeline, criteria, and expedited pathway for lower-risk tools.

Some institutions have implemented a tiered approach:

Making the approval process predictable and reasonably fast reduces the incentive to go around it.

So What?

The CB Financial 8-K was the first, not the last. The combination of OCC exam attention, GLBA Safeguards Rule liability, and potential SEC materiality exposure means the “we’ll deal with it when it becomes a problem” posture has a specific cost now.

What to do this week:

1. Run a shadow AI amnesty survey. Don’t announce a crackdown — announce a governance program. You want disclosure, not compliance theater.
2. Review your GLBA Safeguards Rule data inventory. Does it account for where customer data actually flows, including employee workflows? If you can’t answer what happens to customer data when an employee uses a productivity tool, the inventory is incomplete.
3. Add shadow AI to your AI model inventory. Even if you’re not formally subject to SR 26-2 / OCC 2026-13 validation requirements for LLMs, having a documented inventory is what an examiner will expect to see.
4. Check your AI Acceptable Use Policy. Does it define unauthorized AI? Does it prohibit specific data types? Has every employee signed an acknowledgment? If not, those are the three things to fix first.
5. Build the approval pathway. Every employee who asks “can I use this AI tool?” should have a clear answer within five business days. If the process is broken, the shadow will grow.

The institution that filed the first Form 8-K for shadow AI was a community bank. Not a large institution with hundreds of AI tools and a dedicated AI team. The risk isn’t proportional to size — it’s proportional to how many employees have internet access and how well-lit your AI governance program is.

Sources: Wilson Sonsini — “Shadow AI” Triggers First SEC Form 8-K | OCC Bulletin 2026-13 | National Law Review — Shadow AI and the GLBA Safeguards Rule | Forbes — Shadow AI Has Reached Financial Infrastructure | CB Financial Services Form 8-K (SEC EDGAR)