Shadow AI: Find It, Govern It, Keep the Upside

Shadow AI is the use of AI tools, features and models that your organization has not approved, reviewed or contracted for: the free chatbot an analyst pastes customer data into, the browser extension that summarizes every page an employee opens, the meeting bot a sales rep invited to a client call, or the AI setting a vendor switched on in a system you already own. It is the AI version of shadow IT, and it is happening in organizations of every size. The right response is not a ban, which fails quietly, but a short policy, approved tools that are as good as the unapproved ones, discovery that is proportionate, and a review path fast enough that people use it.

What shadow AI is

Shadow AI covers four kinds of unapproved use:

• Personal accounts on consumer AI tools used for work tasks, with company data in the prompts.
• AI-enabled apps and browser extensions installed without review, many of which read page content, email or files by design.
• AI features inside sanctioned software, such as a CRM, a help desk or a document platform, turned on by the vendor or by a user without anyone assessing what data they process.
• Home-built automations, where an employee connects an API key to a spreadsheet or a workflow tool and starts sending data to a model.

People do this for ordinary reasons. The approved tools are missing or worse than the free ones, procurement takes months and the task is due today. Nobody said it was not allowed, or the policy is a 20-page document nobody read, and the work gets done faster, which is rewarded. Any governance that ignores those reasons will be ignored in return.

It is also worth separating shadow AI from AI use you simply have not documented. If someone uses an enterprise tool under contract for an unexpected purpose, that is a scope question for your inventory, not a shadow problem. The distinguishing feature of shadow AI is that the organization has no contract, no control and no visibility.

Shadow AI risks

The risks are concrete, and most of them are about data leaving the organization under terms nobody read.

• Data leakage and training. Consumer AI terms often allow the provider to retain prompts and use them to improve models. Customer records, source code, financials, contract drafts and personal data pasted into such tools are now held by a third party under their terms, not yours.
• Regulatory exposure. Health information sent to a tool without a business associate agreement is an impermissible disclosure under HIPAA. Personal data of EU or California residents sent to an unvetted processor breaks privacy law commitments. Payment card data in a chatbot violates PCI DSS scope. Each of these can be a reportable incident.
• Contract breaches. Customer agreements and NDAs usually restrict where their data may go. A single prompt can breach one, and the breach is discoverable in the provider’s logs even if it is invisible in yours.
• Legal privilege and intellectual property. Drafts shared with a third-party tool may weaken privilege claims, and ownership of AI-generated output depends on the tool’s terms and on evolving law. Code generated from an unlicensed tool can carry licensing problems into your product.
• Wrong answers in real decisions. Unreviewed output goes into reports, customer replies, pricing, hiring notes and clinical or financial work. Nobody knows which decisions were AI-assisted, so nobody can check them when a pattern of errors appears.
• Security. Browser extensions with broad permissions, OAuth grants to AI apps that can read mail and files, meeting bots that record and store everything, prompt injection against agents that take actions, and API keys stored in spreadsheets all widen the attack surface.
• Cost and sprawl. Dozens of individual subscriptions on expense reports, each with its own data in it, none of which can be cancelled or exported cleanly when a person leaves.

The counterweight is real too. Shadow AI is evidence of demand. The people using unapproved tools have found use cases that work, and a governance program that captures those use cases gets a free roadmap.

Discovery methods

You cannot govern what you cannot see. Discovery should be proportionate to your size and your data sensitivity, and it should be announced, not covert. The sources below are listed from least to most effort.

Method	What it reveals	Effort and fit
Ask, with amnesty	A short survey or team conversations: which tools, for what tasks, with what data. Works best with a clear statement that the goal is to approve tools, not punish people	Low effort; the right first step for every size of organization
Expense and card statements	Individual AI subscriptions and API spend charged to personal or departmental cards	Low effort; finance already has the data
Identity provider app inventory	OAuth grants and third-party app sign-ins in Microsoft Entra ID or Google Workspace, including the permissions each app holds	Low to medium effort; high value, because it shows what apps can read, not only that they exist
Browser extension inventory	AI extensions installed on managed browsers, via device management or browser policy reporting	Medium effort; needs managed devices
DNS, proxy and secure web gateway logs	Which AI domains are visited, by how many users, how often. Many gateways now categorize generative AI services	Medium effort; needs network or endpoint logging in place
SaaS management and CASB tools	Automated discovery of SaaS and AI apps from logs, with risk ratings and usage counts	Medium to high effort and cost; fits organizations with many users or regulated data
Data loss prevention	Attempts to paste classified data into AI tools, with the option to warn or block	High effort; requires data classification to be in place first
Code and automation scans	API keys for model providers in repositories, spreadsheets and workflow tools	Medium effort; essential for engineering teams

Whatever you find goes into a single AI inventory: tool, owner, purpose, data involved, account type, and status (approved, under review, retired). The inventory is the central artifact of AI governance, and shadow AI discovery is usually how it gets its first fifty rows. Our guide on AI governance tools and platforms covers when a spreadsheet stops being enough.

Governing without banning

Blanket bans move usage to personal phones and home laptops, where you have no visibility at all. The alternative is to make the approved path easier than the unapproved one. Six moves do most of the work.

1. Publish a one-page AI acceptable use policy. It should say which tools are approved for which classes of data, what may never go into any AI tool, when human review is required, and how to request a new tool. Our AI acceptable use policy template is built for this.
2. Provide approved tools that people actually want. Enterprise versions of the popular assistants, under contracts that switch off training and set retention, with single sign-on. Match the tools people already use where the terms allow it, rather than imposing an unfamiliar one.
3. Tie permissions to data classification. Public and internal data: approved tools, no review. Confidential data: only tools with contractual protections, logged. Regulated data: only tools inside the compliance boundary, with a BAA or data processing agreement. If you have not classified data yet, start with those three classes.
4. Create a fast review path. A request form, a named reviewer, a standard set of vendor questions and a decision within a defined working window. Approve the common case quickly and spend the review time on the risky ones. Slow approval is the single largest cause of shadow AI.
5. Put technical guardrails where they are cheap. Single sign-on for approved tools, OAuth app approval in the identity provider, browser extension allow-lists, and gateway categories that warn rather than block for most users. Reserve blocking for regulated data environments.
6. Train with real examples and revisit quarterly. Show staff the difference between a safe prompt and a leaky one in their own work. Review the inventory, the request queue and the discovery data every quarter and adjust the approved list.

A founder with five staff can do this in an afternoon: one policy page, two enterprise accounts and a shared inventory. A growing company adds the identity provider controls and a reviewer. A department inside a larger organization usually has to work within a corporate policy and should focus on the inventory and the request path. The broader program is described in what AI governance is.

Where PS3G fits

PS3G’s AI governance services start with exactly this problem: finding the AI already in use, building the inventory, writing a policy people will follow, setting up the approved tools and the review path, and configuring the identity, device and gateway controls that make the policy real. We scope the work to the organization, from a short engagement for a small team to a program that fits inside a corporate governance structure, and we align it with NIST AI RMF and ISO 42001 where a customer or regulator expects that. Because we also build AI applications, we can turn the use cases shadow AI reveals into properly governed tools.

Related reading

• AI Acceptable Use Policy Template for Employees (Free, Editable)
• What Is AI Governance? A Practical Guide for Any Size of Organization
• AI Governance Tools and Platforms: Do You Need One?
• AI governance services from PS3G

Frequently asked questions

What is the difference between shadow AI and shadow IT?

Shadow IT is any technology used without the organization’s approval; shadow AI is the subset involving AI tools and features. The difference in practice is the data flow. Most shadow IT stores data; shadow AI tools ingest data, may retain it for training, and produce output that goes back into decisions. That makes the data leakage and accuracy risks larger and the discovery problem broader.

Should we just block AI tools?

Blocking on the corporate network moves usage to personal devices, where you have no visibility, and it signals that the organization has no plan. A better approach is to approve a small set of tools under proper terms, state clearly what data may be used with them, and reserve blocking for environments that hold regulated data. Most organizations that start with a ban end up here anyway.

How do we find unapproved AI tools without spying on staff?

Start by asking, with a clear promise that the goal is to approve useful tools, not to punish anyone. Then use data you already hold: expense reports, the identity provider’s list of connected apps, and browser extension inventories on managed devices. Network logs and discovery tools add coverage for larger organizations. Announce what is being monitored and why; covert discovery damages the trust that governance depends on.

What should an AI acceptable use policy contain?

Approved tools and the data classes allowed in each, the categories of data that may never be entered into any AI tool, when a human must review output before it is used, disclosure rules for AI-generated content, how to request a new tool, and who to contact when something goes wrong. One or two pages is the right length. A longer document will not be read.

Is shadow AI a compliance issue or a security issue?

Both, and often a legal one. Regulated data in an unapproved tool is a compliance incident under HIPAA, privacy laws or PCI DSS, while extensions and OAuth grants with broad permissions are a security issue. Breaching customer contract terms or weakening privilege is a legal issue. That is why the review path should include security, compliance and whoever owns customer contracts, even if in a small company that is one person.