Someone on your team pasted client data into ChatGPT this week. You probably didn’t know about it, and they probably didn’t think it was a big deal.
on Unsplash
That’s the shadow AI problem in a sentence. It’s not a future risk or a theoretical concern — it’s happening right now in SMBs across every industry, and the gap between “employees using AI” and “IT knowing which AI employees are using” is where your next data incident is most likely to start.
This post is about closing that gap. Not with a policy memo nobody reads, but with a practical sequence: figure out what’s actually running, assess what that exposure looks like, and put controls in place that don’t require a full-time compliance team to operate.
What Shadow AI Actually Looks Like
The phrase “shadow AI” sounds dramatic, but the reality is mundane — and that’s what makes it dangerous. This isn’t employees going rogue. It’s your account manager summarizing meeting notes in an AI tool she found in the Chrome Web Store. It’s your HR coordinator using an AI writing assistant to draft offer letters, not realizing it’s training on submitted content. It’s a developer who wired up an API key to a third-party model because it was faster than waiting for IT to provision something approved.
None of these people are trying to create a compliance problem. They’re trying to do their jobs faster. The tool was free, or cheap, or just there. Nobody asked whether it retained data, who owned the outputs, or whether using it violated your client contracts.
Browser extensions are a particularly underappreciated vector here. There are dozens of AI-powered extensions that sit inside the browser and can read page content, form inputs, and clipboard data. An employee installs one to help draft emails, and suddenly every email they compose — including the ones containing PHI or PII — is passing through a third-party model hosted somewhere they’ve never heard of. Your DLP tool might not catch it because the data never left the browser in a way the tool recognizes as a transfer.
The other common pattern is copy-paste. Employees who don’t have an integrated AI tool will often just copy text from internal documents — contracts, support tickets, financial summaries — into a public-facing chatbot interface to get a summary or a draft response. The data goes in. Where it goes after that depends entirely on the service’s data retention and training policies, which most employees haven’t read.
Why This Is Harder to Detect Than Classic Shadow IT
With traditional shadow IT — an employee spinning up a personal Dropbox account to share files, or using a personal email for work — there’s usually a detectable network event. Data moved somewhere. A login happened from an unusual location. Your SIEM or DLP had a chance to catch it.
AI tool usage is harder to detect for two reasons. First, many AI interactions happen entirely in the browser, using the employee’s own credentials on a consumer account you have no visibility into. The traffic looks like HTTPS to a common endpoint (api.openai.com, claude.ai, gemini.google.com). Without deep packet inspection or endpoint controls, it’s nearly invisible. Second, the risk isn’t always a file transfer — it’s information typed into a text box. That’s much harder to catch after the fact.
This means your standard shadow IT playbook — block the domains, watch the logs, educate users — needs some adjustment when you’re dealing with AI specifically.
The Discovery Phase: What to Actually Do First
Before you can govern AI usage, you need a realistic picture of what’s actually running. Most IT managers at SMBs underestimate this number significantly when they first go looking.
Start with your DNS and proxy logs if you have them. Query for traffic to known AI endpoints: openai.com, anthropic.com, gemini.google.com, character.ai, perplexity.ai, and the API subdomains for each. If you’re not doing DNS logging today, that’s a gap worth fixing regardless of the AI question — it takes about an afternoon to stand up with most firewalls or through a DNS security service.
Next, survey your browser extension inventory. If you manage endpoints through an MDM or group policy, you can pull an inventory of installed extensions across the fleet. Sort by permissions — any extension requesting “read and change all your data on the websites you visit” deserves a second look regardless of what it claims to do. Cross-reference against the AI-focused extensions that have meaningful user bases: Compose AI, Merlin, Monica, and similar tools show up constantly in enterprise audits.
Then ask. Send a short, non-threatening survey to department heads asking which AI tools their teams use regularly, what they use them for, and whether they’re using personal or company accounts. Frame it as inventory, not investigation. You’ll be surprised how candid people are when they don’t feel like they’re in trouble. This also gives you a qualitative picture that your logs won’t: the use cases, the workflows, the actual business value people are getting. That matters when you start making decisions about what to sanction versus block.
Combine those three inputs — traffic logs, extension inventory, and self-reporting — and you’ll have a working picture of your AI tool landscape within a week or two.
Assessing the Actual Risk
Not every unsanctioned AI tool is the same risk. A developer using an AI code completion tool on a machine that never touches production data is a different conversation than an HR employee using a consumer chatbot to draft termination letters that include salary history and performance notes.
When you’re assessing a specific tool’s risk, the questions that actually matter are: Does this service retain input data, and for how long? Is it used for model training by default, and can that be opted out? Where is the data processed and stored geographically? Is there a business associate agreement or data processing addendum available if you need one? Does using this tool create any conflict with your client contracts or your cyber insurance policy?
For tools that touch regulated data — anything covered by HIPAA, GLBA, state privacy laws, or contractual data handling requirements — those questions aren’t optional. The FTC has made clear through its enforcement posture and guidance documents that data shared with third-party AI services can constitute a disclosure under applicable privacy frameworks, even when it was accidental. If your business operates in a regulated sector and an employee is using a consumer AI tool that retains and trains on submitted content, you may have a disclosure problem you don’t know about yet.
For a practical framework on how to evaluate third-party AI tools specifically, NIST’s AI Risk Management Framework (AI RMF) is the most useful publicly available reference — it’s not prescriptive, but it gives you a structured way to think about what questions to ask. The EU AI Act is also worth monitoring if you have any European customers or vendors, since it introduces risk-tiered obligations that will affect AI procurement decisions regardless of where you’re based.
Building Controls That Actually Work
Once you know what’s running and which tools carry meaningful risk, you have three options for each tool you’ve identified: sanction it with controls, block it, or escalate it to a risk acceptance decision with documented rationale. What you don’t want to do is leave things in an undecided state, which is effectively the same as implicit approval.
For tools you sanction, the minimum bar is a documented acceptable use policy for that specific tool, a review of the vendor’s data processing terms, and user guidance on what categories of information are off-limits for that tool. If it’s a tool that touches regulated data, you need a signed DPA or BAA before anyone uses it for real work. Many enterprise tiers of major AI platforms offer these — but the default consumer accounts don’t, and the distinction matters.
For tools you decide to block, enforcement matters more than the policy document. Add the relevant domains to your DNS blocklist or web filter. Push a policy through your MDM to restrict unapproved extensions. The goal isn’t perfect enforcement — determined employees can always find a workaround — but raising the friction level so that casual, thoughtless usage stops.
The hardest part of this isn’t the technical controls. It’s the culture piece. If you block tools without providing alternatives, you’ll drive the behavior further underground. The most effective IT teams I’ve seen handle this by doing the blocking and the enablement simultaneously — here’s what you can’t use, and here’s the approved tool that does the same thing, set up on an enterprise account with proper controls in place. When employees have a sanctioned path to the capability they want, they’re much more likely to use it.
Keeping Pace as the Tooling Changes
Here’s the reality of AI governance at an SMB in 2026 and beyond: the tooling is moving faster than any static policy document can track. A policy you write today about permissible AI tools will be partially obsolete in six months because new tools will exist, existing tools will change their data practices, and your employees will find things you haven’t seen yet.
This means your governance approach needs to be systematic rather than reactive. Build a lightweight quarterly review into your existing IT calendar: pull traffic logs, check for new extensions in your fleet, run a quick update survey with department heads, and review any changes to the data policies of your sanctioned tools. Four hours a quarter is enough to keep your picture current if you’ve done the initial inventory work.
Document what you find and what decisions you make. Not for an auditor, necessarily — although that’s a useful side effect — but because the decisions you make about AI tools today will be referenced when something goes wrong later. Showing that you assessed the risk, made a reasoned decision, and enforced that decision is the difference between a defensible governance posture and a liability.
Shadow AI is uncomfortable to confront because it usually means finding out that things you assumed weren’t happening actually were. But the discovery process is also where you get the information you need to build something better. Most employees aren’t trying to create security problems — they’re trying to be useful. Give them a governed path to the tools that help them do that, and the shadow problem mostly solves itself.