Shadow AI in the Workplace: Find It Without Punishing Anyone

Shadow AI in the workplace is any use of AI tools, accounts or automations that the company has not reviewed or approved, and it almost always starts with someone trying to finish real work faster. The practical response is to find it through open conversation and light technical signals, sort it by the data and actions involved, and replace the risky habits with approved tools that are at least as easy to use. Treat every instance you find as information about an unmet need, not as a disciplinary case.

Key takeaways

• Shadow AI is a symptom of unmet needs. People reach for unsanctioned tools because the approved path is missing, slow or unclear.
• Discovery works best when it starts with a safe conversation and is backed by account, expense and app-permission signals, not surveillance.
• Sort what you find by what data goes in and what the tool can do, not by how alarming the tool sounds.
• Adoption of an approved alternative depends on speed, quality and low friction. A policy alone will not move anyone.
• Run discovery as a repeating habit with a named owner, because new tools appear constantly.

What counts as shadow AI, and why does it appear?

Shadow AI covers more than a chatbot in a browser tab. It includes:

• Personal accounts on public AI assistants used for work text, analysis or code.
• AI features switched on inside tools the company already pays for, without anyone reviewing the new data flows.
• Browser extensions and meeting note-takers that join calls or read pages.
• Automations people built by connecting an AI service to email, a shared drive or a spreadsheet through their own login.
• Custom assistants or scripts that a technically inclined employee built for their team and never documented.

The cause is usually ordinary. A sales coordinator needs a first draft of a proposal by the afternoon. An analyst has a spreadsheet nobody has time to summarize. A manager wants clean notes from a long meeting. The approved route either does not exist, takes weeks to request, or produces worse results than a free tool. So people solve the problem themselves, and they rarely mention it because they expect a no.

The risk is real and specific: company or client data pasted into services with unknown retention terms, outputs used in client work without review, access tokens granted to apps nobody can list, and no way to answer a client who asks where their information went. Naming those risks precisely matters, because it lets you respond to the risk and not to the brand of the tool.

Why does a punitive approach make shadow AI harder to find?

If the first message is a ban, people stop talking. Usage moves to personal phones and home networks, where no signal reaches you. The employees most likely to go quiet are the resourceful ones, who are also the ones whose workflows you most want to learn from.

A non-punitive approach is not a lenient one. It follows a clear order: ask, understand, sort, offer, then set firm boundaries around the genuinely dangerous cases. Leaders say plainly that past use found during discovery will be treated as input, not evidence. The line that matters runs forward: once an approved option exists for a need, the high-risk shortcuts stop. That promise has to be kept. One person disciplined for honest disclosure ends the program.

The NIST AI Risk Management Framework treats governance as something that begins with knowing which systems are in use and who is accountable for them. You cannot govern a map you have not drawn, and employees will only help you draw it if doing so is safe.

How do you find shadow AI without turning it into an investigation?

Combine human sources and technical signals. Neither is enough alone.

Human sources:

• A short survey, anonymous if people prefer, asking which AI tools they use, for which tasks, and what they wish they could do.
• Team conversations led by a manager or operations lead, framed as a request to show how the work gets done rather than a request to confess.
• A standing channel where anyone can ask whether a tool is fine to use and get an answer within a working day.

Technical signals:

• Expense reports and company card statements, which often reveal subscriptions to AI services.
• Single sign-on and identity provider logs showing which third-party apps employees have signed into with work identities.
• The list of third-party app authorizations in your email and file-sharing suite. OAuth grants (Google's OAuth 2.0 documentation explains how scopes work) show exactly which apps can read mail, calendars or files.
• Browser extension inventories, if you already manage devices.
• Admin settings of existing tools, where AI features may have been enabled by default.

Keep this proportionate. You are looking for patterns and permissions, not reading individual conversations. Tell people what you are checking before you check it. If you have no IT department, start with the human sources and the authorization list, which a capable operations person can review in an afternoon.

Then record each finding in a simple register with these columns: the tool, who uses it, the task, the data involved, the access granted, and the need behind it. The last column is the most valuable one, because it becomes the brief for your approved alternative.

Which uses are urgent and which can wait?

Not every finding deserves the same response. Use these questions in order, and stop at the first yes:

• Does the tool hold broad access, such as a mailbox, shared drive or customer system, through a personal or unreviewed login? Treat it as urgent: revoke the grant or move it to a company-controlled account first.
• Is regulated or confidential data going in, such as personal data about customers or candidates, contracts under confidentiality, or financial records? Treat it as urgent and agree an interim alternative quickly. If you operate in Brazil, the LGPD checklist for AI agents covers the questions to settle.
• Does the output reach clients or feed decisions without a human reading it? Add a review step now, even before the tool is replaced.
• Is the data low sensitivity, such as public information, internal brainstorming or generic drafting? Allow it for now, document it, and fold it into the approved set later.

This order protects you from a common mistake: spending energy on a harmless writing assistant while an unreviewed automation quietly reads a shared mailbox.

How do you offer approved alternatives people will actually adopt?

People adopt what is faster, better or safer than their workaround. Approval alone provides none of those. Design the alternative around the need column in your register.

• Match the real task. If people use public assistants to summarize long documents, the approved option must handle documents of that kind and size, with the right access to them.
• Remove friction. Use company sign-in, skip a separate request form for every use, and give a short onboarding that shows a few tasks done well.
• Publish a short list of approved tools with a plain-language rule for each: what data is allowed, what is not, and who to ask. A longer policy can sit behind it, and the guide on writing an AI acceptable use policy for employees shows how to structure one people will read.
• Consolidate. Several overlapping tools bought by different teams recreate the visibility problem the shadow tools caused. The method in reducing AI tool sprawl helps you decide what to keep.
• Offer a fast lane for new requests, so a tool can be reviewed on data, access and retention terms instead of waiting in a queue.
• Close the loop. Ask the people who moved over what is still missing, and act on it.

Illustrative scenario: a finance coordinator pastes supplier invoices into a free assistant to extract totals and due dates, using a personal account. The discovery conversation reveals the actual need: reading invoices quickly and producing a payment schedule. The company does not simply forbid the habit. It sets up an approved role that reads invoices from a controlled folder, proposes a schedule, and asks the coordinator to confirm before anything is recorded. The coordinator keeps the speed, the invoices stay inside company systems, and the approval step is explicit. The shadow tool loses its reason to exist.

What does a step-by-step plan look like?

Use this sequence as a repeatable cycle:

• Step one: name an owner, usually someone in operations, with authority to speak across teams and a direct line to leadership.
• Step two: announce the purpose and the ground rules. State that discovery is about understanding needs, and say what will be reviewed.
• Step three: run the survey and the team conversations first.
• Step four: check expense, identity and app-authorization records to fill the gaps.
• Step five: build the register and sort it with the urgency questions above.
• Step six: close the urgent exposures with interim measures, such as revoking an app grant or moving a workflow to a company account.
• Step seven: choose approved alternatives for the most common needs, and test them with the people who had the workaround.
• Step eight: publish the approved list and the fast lane for new requests.
• Step nine: repeat on a schedule, and review the register whenever a new tool appears.

The OWASP Top 10 for LLM Applications is a useful reference when you reach step five, since it names risks such as sensitive data disclosure and excessive agency. You do not need to apply all of it at once. Use it to phrase the review questions you ask about each tool.

How does a managed approach handle this?

Be Human designs, implements and operates personalized AI infrastructure for companies, and shadow AI findings feed directly into that work. A first engagement defines one useful role, the memory and tools it needs, approval boundaries and an observable success criterion, often taken from a need uncovered in a conversation like the one above. The agent keeps its own identity and scoped permissions under human control, and managed operations can include monitoring, permission review, integration maintenance and controlled improvements, so the approved path stays current as needs change. The scoping resembles what happens in the discovery phase of an AI agent project.

Frequently asked questions

Should we ban public AI tools while we sort this out? A blanket ban usually pushes use out of sight, which removes your ability to see and reduce risk. A better interim step is a short rule naming the data that must never be entered, such as customer personal data or confidential contracts, combined with a fast way to ask for an approved option.

Do we need monitoring software to find shadow AI? Not to begin. Conversations, a survey, expense records and the list of app authorizations in your email and file suite reveal most of what matters. Add technical monitoring later if gaps remain, and tell employees what it covers.

What if someone disclosed a serious exposure during discovery? Fix the exposure first: revoke the access, move the data, or add a review step. Handle the person as a source of useful information, not as a suspect, unless there was deliberate misconduct unrelated to the program. Protecting honest disclosure is what keeps the next disclosure coming.

How often should we repeat discovery? Treat it as a recurring habit instead of a one-time project. A light review on a regular schedule, plus a check whenever a team asks for a new tool or a vendor adds AI features, keeps the register useful without creating a heavy process.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.