How to Handle Shadow AI on Your Team Without Banning It

Key Takeaways

• Shadow AI is not a discipline problem. People reach for a personal account because the approved path is slower than the deadline.
• Bans move the behavior, not the data. Block one site and the same paste happens on a phone, off your network, with no record at all.
• Start with an amnesty inventory, not an audit. Ask what people already use and why, with no consequences for answering honestly.
• The fix is a sanctioned place to do the work, where access is granted per tool, output is reviewable, and someone owns the account.
• Write the two lists that actually matter: what may never leave your systems, and what is fine to hand to a machine.
• Measure the gap you closed, not the tools you blocked. If shadow use drops and work still ships, the policy is working.

Your team is already doing this

A support lead has a customer thread that will not resolve itself. She copies the last twenty messages, including the customer's full name, order history and a chunk of an invoice, into a personal AI account on her phone, gets a decent reply in nine seconds, edits it, sends it. Nobody sees any of that except her. The record of what left the company is a chat history in an account IT has never heard of, tied to an email address that is not hers at work.

That is shadow AI. Not a hacker, not a leak, not malice. A person with a deadline picking the fastest tool in reach.

We see the same pattern in every ops team we talk to, and the details barely change: sales pastes call notes to write follow-ups, finance pastes a spreadsheet range to explain a variance, a founder pastes an entire investor thread and asks for a summary. All of it works. None of it is visible.

The instinct is to ban it. That is the one response guaranteed to fail, because the behavior does not depend on your network.

Why the ban never holds

A block list assumes the work goes away when the tool does. It does not. The support lead still has the thread, still has the deadline, and now has a phone.

Three things happen when you ban instead of replace:

• The fastest people go furthest underground, because they are the ones whose speed depends on it.
• You lose the record. A blocked tool produces no logs, no prompt history, no way to answer "what exactly did we send".
• You still carry the risk. The data already left on the days before the ban, and it keeps leaving on personal devices after it.

The honest framing: shadow AI is demand showing up in the wrong place. Somebody on your team already built a workflow that helps them. Your job is to move it, not to kill it.

The inventory that actually gets answers

Before a policy, get the map. Send one message, and mean it: no consequences for anything anyone reports in the next week.

Ask four questions and nothing more:

1. Which AI tools do you use for work right now, including personal accounts?
2. What task do you use them for, in one sentence?
3. What do you paste in?
4. What would you lose if it disappeared on Monday?

Question four is the one people answer honestly, and it tells you which workflows to rebuild first. Question three tells you your actual exposure, which is almost never the thing security teams guess. In the inventories we have seen, the scary paste is rarely source code. It is customer email threads, contract clauses and payroll-adjacent spreadsheets.

Run it as a form, give it a deadline, and publish the aggregate back to the team. Publishing matters. It converts an audit into a shared problem.

The two lists, and nothing else

Most AI policies fail because they are three pages long and nobody can apply them at 4:45 PM. Write two lists instead, on one page, in plain words.

Never leaves our systems. Customer records that identify a person, anything under a signed confidentiality clause, credentials and keys, payroll and compensation, unannounced financials, legal advice, security findings.

Fine to hand to a machine. Public docs, your own marketing copy, anonymized examples, code you have already open sourced, meeting notes you would forward externally without flinching, anything already on your website.

Then the rule that makes both lists usable: if the data is on the first list, the work happens in the sanctioned place, not the personal account. People can follow that at 4:45 PM. They cannot follow "exercise appropriate judgment when handling sensitive information".

If you want a longer version of the access side of this, our security checklist for AI tool access covers the permission questions in more detail.

Shadow AI versus a sanctioned AI employee

The difference is not model quality. Both give the support lead a good reply. The difference is everything around the reply.

The last two rows are where most of the risk actually sits. A pasted thread has no scope. A connected tool does. And when the output is a draft in a channel instead of a message already sent, someone else gets a chance to catch the mistake. We wrote about that habit separately in how to keep a human in the loop with your AI employee.

Rebuild the top three workflows in public

Take the three tasks that came up most in your inventory and move them, one at a time, into a place where the whole team can watch them run.

For the support lead, that is the same job she was already doing, except the customer context comes from the tool of record instead of a paste, and the reply lands as a draft:

@Viktor pull ticket 4482 from Zendesk plus this customer's last three orders in Shopify, draft a reply that explains the shipping delay and offers the reshipment, post it here for me to check before it goes out

For finance, the paste was a spreadsheet range. The replacement reads the source:

@Viktor compare July spend by vendor in QuickBooks against June, flag anything up more than 20 percent, and put the three biggest movers in this channel with the invoice links

For the founder, the paste was a thread. The replacement never needs the thread:

@Viktor every Friday at 4pm summarize what shipped this week from Linear and the #releases channel, keep it to eight bullets, post it here as a draft I can edit before I send it to investors

Three things changed and none of them is the model. The data stopped being copied by a human, the work became visible to more than one person, and the output waits for approval.

An AI employee that lives in Slack can do this because it holds its own connections. Viktor connects to 3,200+ integrations with real read and write access, so the context arrives through a permissioned connection rather than a clipboard. Which tools it can touch is a decision you make once and change whenever you want, as described in how to control what your AI employee can access.

Name an owner, or it drifts back

Every shadow AI story we have heard has the same missing role: nobody owns the sanctioned path. So it gets set up, it works for a month, an integration expires, and the fastest person quietly reopens the personal account.

Give one person the job. Not a committee. They own four things:

• The connection list, and who requested each one.
• The two lists, reviewed once a quarter with whatever new tools appeared.
• A quick monthly read of what the AI employee actually did, so nobody is surprised by a routine they forgot existed.
• The intake path when someone needs a tool that is not connected yet, with a response time short enough that waiting beats pasting.

That last one is the whole game. If your approval path takes four days, you have rebuilt the conditions that created shadow AI. Aim for same week, and say so publicly.

For the trust questions that will come up in that role, where your data lives with an AI employee walks through hosting and deletion, and Viktor maintains SOC 2 Type I.

How to tell if it worked

Do not measure blocked domains. Measure these:

• Repeat the inventory in 90 days. Personal-account use for work tasks should drop, and the drop should be biggest in the workflows you rebuilt.
• Count the requests to connect a new tool. Going up is good. It means people are asking instead of pasting.
• Check whether the rebuilt workflows still run. A dead routine sends people straight back to the phone.
• Ask the fastest person on the team whether the sanctioned path is faster. If the answer is no, fix that before you write another policy line.

Shadow AI ends when the visible path is the quick one. Every other approach is a bet that your team will choose slower work, and that bet loses every time.

Frequently Asked Questions

What is shadow AI?

Shadow AI is any use of AI tools for work that the company has not approved or does not know about. In practice it is usually a personal account on a phone or a browser tab, used for a real task, with company data pasted in by hand.

Is shadow AI a security incident?

Not by itself. It becomes one when data from your never-leaves list ends up in an account you do not control. Treat the first inventory as fact finding rather than incident response, then handle any specific exposure you find through your normal process.

Should we block AI tools on company devices?

Blocking alone moves the behavior to personal devices where you have no record at all. Blocking works only after a sanctioned path exists and is genuinely faster for the tasks people actually do.

How do we write an AI policy people will follow?

Keep it to one page and two lists: what may never leave your systems, and what is fine to hand to a machine. Add one rule that says work touching the first list happens in the sanctioned place. Anything longer gets skimmed once and ignored.

Who should own AI tool access on a small team?

One named person, usually whoever already owns operations or IT. They own the connection list, the quarterly review, and the intake path for new tool requests. See who should manage your AI employee for how that role plays out day to day.

What happens to shadow workflows when someone leaves?

They leave too, which is one of the quieter costs. A workflow that lives in a personal chat history cannot be handed over. One that runs in a shared channel with a shared account stays behind and keeps running.