The AI Policy You Wrote
Last Quarter Is Already Wrong

During a routine third-party risk assessment at a regional community bank—approximately $2 billion in assets, nothing unusual on the surface—we asked the compliance team to pull their AI tool inventory. They produced a list of three approved applications. Over the following two weeks, working through department managers and a targeted technology audit, we found eleven. Six departments. Eleven tools. None of them in the risk register. Several were processing customer PII. The "AI acceptable use policy" had been finalized four months earlier. It was already a historical document.

This is not an edge case. It is, at this point, the expected finding. The community bank had done more than most: they had written a policy, circulated it, and filed it. What they hadn't done was build governance infrastructure capable of keeping pace with the rate at which AI tools multiply and migrate into daily workflows. Those are not the same thing, and the difference between them carries real regulatory and operational weight.

Shadow AI is shadow IT, except the velocity is higher, the data exposure surface is broader, and the regulatory scrutiny in financial services is sharpening by the quarter. The organizations that get ahead of this are not the ones with the best-drafted policies. They're the ones that have built continuous visibility into what their employees are actually using.

Shadow IT took years to become a serious governance problem. Employees started using personal Dropbox accounts, then departmental SaaS subscriptions, and IT eventually caught up with discovery tooling and procurement controls. The cycle moved slowly enough that most organizations adapted before catastrophic data loss events became common.

Shadow AI is moving on a different timeline. The tools are free or near-free at the individual tier. They require no IT involvement to activate. They are designed to be immediately useful—often more useful in the first ten minutes than anything the organization has provisioned. And critically, they are not perceived as risky by the people using them. Asking an AI assistant to summarize a document or draft a client email doesn't feel like a security decision. It feels like working efficiently.

The exposure profile, however, is materially different from most shadow IT scenarios. When an employee uploads a loan application to an unapproved AI document tool, they are not just violating a policy. They may be transmitting nonpublic personal information (NPI) to a third party with no executed data processing agreement, no FFIEC-compliant vendor due diligence, and no visibility in your vendor inventory. The model provider's retention practices, training data policies, and security controls are unknown. The regulators do not consider "we didn't know" an acceptable compliance posture.

The community bank's acceptable use policy named specific tools. It was written in the months immediately after generative AI became a board-level topic, when the conversation was still largely framed around ChatGPT and whether employees should be using it. That framing was already outdated when the policy was finalized.

By the time we conducted the assessment, the AI landscape inside that bank included tools employees would not have classified as "AI" in the policy sense: a vendor-embedded document analysis feature in their loan origination system, an AI-assisted email drafting function in their CRM, and a third-party call transcription service a regional manager had subscribed to independently. None of those appeared in the policy by name. Employees using them had no reason to think they were out of scope.

This is the taxonomy problem. Policies written around named tools or product categories ("generative AI," "large language models") create definitional gaps that users navigate through without realizing they're doing it. A more durable policy architecture is capability-based and use-case-based: it governs what the tool does with data, not what the tool is called.

The finding that troubled the compliance team most was not the volume of tools. It was that several of these use cases had legitimate business value. The employees using them were not being reckless. They were solving real workflow problems with tools that were readily available. The governance failure was that no approved alternative existed, no intake process existed, and no one had created a path for employees to surface these tools before adoption.

Financial services regulators have been clear that existing supervisory frameworks apply to AI, even as AI-specific guidance continues to develop. The OCC's model risk management guidance (SR 11-7, which the OCC adopted by reference) covers any quantitative or algorithmic tool used in decision-making. FFIEC examination procedures address third-party risk management in terms that squarely capture AI vendor relationships. NYDFS has been explicit: regulated entities are expected to manage AI-related risks through their existing enterprise risk management programs, not to wait for AI-specific rulemaking.

What that means operationally: an AI tool used in a customer-facing process is a model. It requires validation, documentation, and ongoing monitoring. An AI vendor without a data processing agreement in place is an unmanaged third party. A process that routes NPI through an unapproved tool is a potential data security incident, depending on the vendor's data handling practices.

The NYDFS cybersecurity regulation (23 NYCRR 500) and its 2023 amendments add further specificity for covered entities. The requirement to maintain a current asset inventory, conduct risk assessments of third-party service providers, and implement access controls does not carve out "tools employees found on their own." Examiners are beginning to ask about AI tool inventories explicitly. The organizations that cannot produce them are creating documentation gaps that compound other findings.

The foundational governance problem is not policy language. It is visibility. An organization without a current, accurate AI tool inventory cannot make risk-based governance decisions. It cannot prioritize remediation. It cannot answer examiner questions with confidence. And it cannot tell whether its policies, however well-drafted, are actually being followed.

Building the inventory is harder than it sounds, because AI tool adoption does not follow the same procurement pathways as traditional enterprise software. Some tools arrive through individual employee subscriptions. Some arrive embedded in vendor platforms that procurement approved for a different primary purpose. Some arrive through departmental credit card purchases that don't trigger IT review. Effective discovery requires combining technical detection with operational interviews—because technical controls alone will miss tools that operate entirely in browser sessions and leave no installed footprint.

The inventory needs to capture more than a tool name. For each entry: the department using it, the use case, whether it processes regulated data (NPI, MNPI, PII), what the vendor's data retention and training policies are, whether a DPA is in place, and the current governance status (approved, under review, prohibited). That's a living document—not a spreadsheet updated annually.

One practical accelerant: declare a safe-harbor disclosure period. Communicate clearly that employees who surface unapproved tools during the disclosure window will not face disciplinary action. The tools you find during a safe-harbor period are invariably more numerous than what any technical scan produces. More importantly, employees who participate in governance become more careful about future adoption decisions. The act of asking surfaces the culture change you need.

Effective AI governance is not a policy document. It is an operational capability. The policy is one component—the rules of the road. But governance requires the infrastructure to enforce those rules, the process to onboard new tools without creating a black market, and the oversight function to detect when the landscape has changed. Most mid-market financial institutions have the policy. They are missing the infrastructure.

The architecture has four elements that must work together:

The intake process deserves particular attention because it is the operational element most likely to determine whether governance works in practice. Employees faced with a useful tool and a slow approval process will make a predictable choice. A well-designed intake workflow asks the right questions (what data will this touch, what's the use case, what's the vendor's data handling policy), routes to appropriate reviewers based on risk tier, and returns a decision in days—not weeks. That is achievable. Several of our clients have built functional intake processes using existing GRC workflow tools they already own.

For mid-market organizations that need to close the gap between policy and operational governance, a focused 90-day sprint is a realistic scope. This is not a full AI risk management program buildout—that takes longer. This is the foundation: visibility, initial risk classification, and a repeatable process for ongoing governance.

The 90-day scope is achievable for organizations that commit a cross-functional team: IT, compliance, risk, legal, and at least two business line representatives who understand the operational workflows. The work is not technically complex. What it requires is organizational will to prioritize it before an examiner or incident forces the issue.

Every organization working through this for the first time has a contingent that wants the answer to be a blanket prohibition. No AI tools, no problem. It is a tempting position and an operationally untenable one.

The community bank's loan officers were using AI transcription tools because they were managing twice the call volume they had two years ago. The marketing team was using generative AI because they had lost a headcount to budget constraints and were expected to maintain output. The developers were using AI coding assistants because their sprints were scoped for a larger team than the one they had. These are not frivolous use cases. They are responses to genuine resource pressure, and the employees were solving real problems.

A prohibition policy that does not address those underlying pressures does not eliminate shadow AI. It drives it deeper. Employees become less likely to disclose, less likely to ask for guidance, and more creative about hiding tool use from IT visibility. You achieve the appearance of compliance while the actual exposure continues—now with the added problem that your detection capability has been degraded by a culture of concealment.

The goal is not zero AI. The goal is governed AI—tools that have been evaluated against your risk criteria, procured with appropriate vendor terms, deployed with appropriate controls, and monitored on an ongoing basis. That is a harder governance posture to build than a prohibition. It is also the only one that works.

The community bank we worked with completed their 90-day sprint. They went from eleven undocumented tools and a four-month-old policy to a current inventory, a functioning intake process, three vendor assessments completed, and two tools formally approved with appropriate controls. One tool was prohibited outright after vendor due diligence revealed unacceptable data retention terms. The rest are pending risk review on a documented schedule.

None of that required large capital investment. It required organizational commitment, clear process ownership, and the willingness to treat AI governance as an operational discipline rather than a documentation exercise. That distinction—between governance as a living program and governance as a filing cabinet artifact—is the one that will matter most when the examiners arrive.