Shadow AI is already inside your organization. Start with an inventory, not a ban.

If you have not looked for AI in your organization, it is still there. It is in the browser, in the software you already license, and in the expense reports nobody connected to risk. A ban will not remove it. It will only make it harder to see. The better first move is an inventory: find what is in use, sort it by risk, and give people an approved path that is easier than the workaround.

Why a ban backfires

I understand the instinct. A leader reads about confidential data pasted into a public chatbot and wants the door closed. Blocking a few well-known sites feels decisive.

In practice, a blanket ban does three things. It moves use to personal devices and personal accounts, where the organization has no logging and no contract. It tells employees that the risk function is not interested in how they actually work. And it creates a false sense of control, because the AI features arriving inside approved software are not affected by the block at all.

People use these tools because they help with real work: drafting, summarizing, coding, research. That demand does not disappear when a site is blocked. The question is whether the organization can see it and shape it.

Where shadow AI actually lives

When I built an AI use-case intake process and enterprise inventory, the most useful lesson was that very little AI arrives through the front door. Most of it shows up through channels that were never designed to flag it. You find it by looking in several places at once.

Source	What you are likely to find	Who can help	What to ask for
Existing vendor software	AI features added in a release and enabled by default: meeting summaries, writing assistants, ticket triage	Vendor management, application owners	Release notes, admin consoles, feature settings for each major platform
Browser and endpoint	Extensions with AI functions, desktop assistants, plug-ins for office tools	Endpoint and desktop engineering	Installed extension and application lists, sorted by count
Network and CASB signals	Traffic to AI services, uploads to AI domains, unsanctioned SaaS	Security operations	Top AI destinations by user count and data volume
Code and cloud	API keys for AI providers in repositories, AI services in cloud accounts	Engineering, cloud security	Secrets scanning results, cloud service inventories, billing line items
Expense and card data	Personal subscriptions to AI tools claimed as business expenses	Finance, accounts payable	Card and expense transactions matching AI vendor names
Procurement and contracts	New tools bought below review thresholds, renewals with new AI terms	Procurement, legal	Recent purchases, contract amendments mentioning AI or machine learning

No single source gives you the full picture. Network data shows destinations but not purpose. Expense data shows who is paying but not what data they share. Vendor release notes show features but not whether anyone turned them on. Put them together and a clear outline appears.

Embedded copilots deserve special attention. They are the easiest to miss because they sit inside platforms that were approved years ago, under contracts that never contemplated generative features. Consider a firm whose collaboration suite adds an AI meeting summary feature, switched on by default. Nobody submitted a use case. Yet recordings of client calls may now be processed in ways the original risk assessment never covered.

Triage by risk tier

Once you have a list, resist the urge to treat every entry the same way. A spell-checking assistant and a tool that scores loan applicants do not deserve the same review. I sort discovered uses into tiers based on what the tool touches and what it influences.

Tier	Typical characteristics	Example	Expected response
Low	Public or non-sensitive data, output reviewed before use, no customer impact	Drafting an internal announcement with an approved assistant	Register it, confirm acceptable use terms, move on
Moderate	Internal or confidential data, output informs work but does not decide	Summarizing internal policy documents	Confirm data handling, contract terms, and an owner; review annually
High	Customer data, regulated information, or output that affects customers, employees, or financial reporting	Screening applicants, drafting customer communications at scale, supporting credit decisions	Full intake, documented owner, testing, monitoring, and second-line review before continued use
Prohibited	Uses that breach policy, law, or contract	Uploading customer personal data to a consumer tool with no agreement in place	Stop immediately, assess exposure, and route to incident handling where warranted

The tier drives the effort. Most discovered uses will sit in the lower tiers, and that is good news. It means the governance team can register them quickly and spend its time on the small number that carry real exposure.

Map the tiers to a framework so the approach is defensible. The NIST AI Risk Management Framework expects organizations to inventory their AI systems as part of its Govern function and to understand context and impact under Map. ISO/IEC 42001 expects an organization to understand the AI systems within the scope of its management system and to assess their risks and impacts. An inventory with tiers is the practical foundation for both.

Make the approved path easier than the workaround

This is where most programs win or lose. If the sanctioned route takes six weeks and three committees, people will keep using personal accounts. The approved path has to be faster, clearer, and more useful.

What that looks like in practice:

• Offer a sanctioned tool for common tasks. If people need a writing and summarizing assistant, provide one under an enterprise agreement with clear data terms. Demand that has a good outlet stops looking for a bad one.
• Keep intake short for low-risk uses. When I designed intake, the goal was a form a business user could complete in minutes, with the deeper questions triggered only when the answers pointed to higher risk.
• Publish a plain acceptable use policy. I wrote the AI acceptable use policy for my organization, and the most important part was the list of things people can do, not only the things they cannot. People follow rules they can understand.
• Review vendors before features go live. I reviewed AI-enabled vendors before approval, and a short, standard set of questions about data use, model training, and subprocessors catches most issues early.
• Offer amnesty for what is found. If someone has been using an unapproved tool for legitimate work, the response should be to bring it into the program, not to punish them. Otherwise the next discovery exercise will find nothing, because people will hide better.

A GRC platform helps here. When I built and managed OneTrust for GRC and third-party risk, linking AI use cases to vendor records and assessments meant a new AI feature from an existing vendor could be traced to the contract, the owner, and the prior review in one place.

What audit should test

Internal audit should not wait for a perfect program before looking. In fact, an early review often helps management prioritize. These are the questions I would test:

• Completeness. Does the inventory draw on more than one source? Compare it against network data, expense data, and vendor feature lists. Gaps between the inventory and those sources are findings.
• Embedded features. Has the organization reviewed AI features in its largest existing platforms, including features enabled by default?
• Tiering. Is there a documented method for assigning risk tiers, and is it applied consistently? Pick a sample and re-perform the tiering.
• Ownership. Does each moderate and high tier entry have a named owner who knows they own it?
• Response to discovery. When an unapproved use was found, what happened? Look for evidence that it was registered, restricted, or stopped.
• Currency. When was the inventory last refreshed? An inventory built once and never updated is a snapshot, not a control.

A practical starting checklist

If you are starting from nothing, these steps will get you to a working inventory without a large project.

1. Pull the top AI-related destinations from network or CASB data and note user counts.
2. Ask vendor management for AI features released by your ten largest software providers in the past year, and check which are enabled.
3. Search expense and card data for AI vendor names.
4. Run secrets scanning for AI provider API keys in code repositories.
5. Ask procurement for recent purchases and renewals that mention AI.
6. Consolidate the results into one register with an owner, data type, and purpose for each entry.
7. Assign a risk tier to each entry using a short, documented method.
8. Act on prohibited and high tier entries first.
9. Publish the acceptable use policy and the approved tool options.
10. Set a refresh schedule, and assign someone to run it.

Closing

Shadow AI is not a sign that employees are reckless. It is a sign that they found something useful before the organization offered a safe way to use it. The response that works is visibility first, then proportion, then a better path. Start with what is already there.

---

This article reflects my professional perspective and is general information, not legal or regulatory advice. Apply it in light of your organization’s obligations and risk appetite.