
Shadow AI in the Workplace: How to Find It Without Punishing Staff
Learn how to find informal AI use at work without punishing anyone, and offer approved alternatives that lower the risk of data leaks across your team.
Want to apply this in your company?
Book a call with Juan →Shadow AI in the Workplace: How to Find It Without Punishing Staff
Shadow AI in the workplace is the use of artificial intelligence tools without approval from management or IT, usually with good intentions and no clear rule. The safest path is to find that use through conversation and a simple inventory, without punishment, define which data must never leave the company, and offer an approved alternative that is easier than the improvised one. Banning without offering a way out tends to push the use further out of sight.
Key takeaways
- Shadow AI almost always starts from a real need on the team. Treating it as indiscipline hides the problem instead of solving it.
- Discovery works best with a stated amnesty, conversations by department and a simple inventory, not with surveillance or blind blocking.
- The central risk is the type of data leaving the company (customers, contracts, finance, WhatsApp conversations), not the tool itself.
- An approved alternative only works if it is accessible, fast and covers the tasks people already do.
- The policy needs to be short, reviewed often and backed by hands-on training.
What shadow AI is and why it appears
The term comes from shadow IT, the use of systems and apps the technology team does not know about. With AI, the typical picture looks like this: someone pastes a customer email into a free assistant to improve the wording, another person uploads a spreadsheet to get a summary, a third installs a browser extension that reads open pages, and a manager records a meeting with a personal transcription app.
None of these people is trying to cause an incident. They are trying to deliver faster. That is why leadership's first move is to understand the demand behind the use. If many people use AI to draft customer replies, there is a customer support need. If they use it to summarize documents, there is a reading and triage need. Informal use is a free map of the tasks where AI already helps.
People who use AI in secret are almost always trying to work better, not cause an incident.
The risk is still concrete. Personal data of customers and employees can be sent to services with no proper contract, no retention controls and no clarity on which country does the processing. That touches LGPD, and it is worth reading what the law requires in international data transfer when using AI providers. There is also the risk of wrong answers used without review, and the risk of losing the record of what was decided with AI support.
How to find informal use without a witch hunt
Discovery is not investigating people. It is building an inventory of tools, tasks and data types. The order matters: first create safety so people can speak up, then collect, then decide.
A step-by-step plan that tends to work:
- Announce an amnesty: for a defined period, anyone who declares what they use faces no consequence for past use. Put it in writing by email, signed by someone with the authority to guarantee it.
- Explain the goal: reduce risk and provide better tools, not measure individual performance.
- Hold short conversations by department, twenty to thirty minutes, with open questions: which tasks do you already do with AI, with which tool, and what kind of information do you paste in.
- Add an optional anonymous form for people who prefer not to speak in a group.
- Review what the company can already see: browser extensions installed on company machines, apps connected to email and calendar accounts (the list of authorized apps on work accounts often shows a lot), and recurring charges on cards or expense reports.
- Consolidate everything in a spreadsheet with tool, department, task, data type and risk level.
- Report the result back to the team: what will be approved, what will be replaced, what must stop, and when an alternative will be available.
One caution: technical monitoring of networks and devices should be proportionate, communicated and aligned with legal counsel. If the team feels watched, the next round of conversations will produce nothing. For the balance between tracking usage and respecting people, see how to measure AI productivity without surveillance on your team.
Which data cannot leave, and how to classify risk
Not all informal use carries the same weight. Asking for headline ideas for a company blog post is very different from uploading a customer list. Before discussing tools, define three simple data levels. You can adapt them to your reality.
- Free: public information or anything unrelated to people and business, such as generic text drafts, topic ideas and explanations of concepts.
- Restricted: internal information that may only be used in an approved tool, such as procedures, proposals without personal data and working documents.
- Prohibited in any unapproved tool: personal data of customers and employees, health or financial data, contracts, credentials, proprietary code, full support conversations and meeting recordings.
This classification should fit on one page. If nobody remembers the rules at the moment of pasting text, the rules are too long. Concrete examples help more than legal definitions: show three everyday situations from your own company for each level.
Some tasks deserve their own attention. Transcribing customer voice messages and recording meetings involve personal data and often third parties who do not know they are being processed. Two articles go deeper on these points: recording meetings with AI and privacy law (LGPD) and transcribing WhatsApp voice messages with AI.
How to offer approved alternatives people will actually use
The practical rule is simple: the approved option must be at least as easy as the informal one. If the safe path requires opening a ticket and waiting, the team goes back to the personal app at the first deadline pressure.
A decision guide for choosing what to offer, based on the inventory:
- Task with free data and low impact: approve a tool on a business plan, with a company account and usage guidance. Check in the terms of the plan you buy how data is retained and whether it can be used to train models. That point must be read in the contract, not assumed.
- Task with restricted data: use a business account with access control, central administration and the ability to switch users off. Record who uses it and for what, at team level.
- Task with sensitive data and recurring volume: evaluate a dedicated workflow, with minimum permissions, a decision log and human review. In some cases a locally run model can keep data inside the company's own infrastructure, and running Ollama local models in a company explains what that demands in operations.
- Task that AI should not do: say so clearly and explain why. The article what not to delegate to AI in business helps frame that conversation.
In every case, pair the tool with a short hands-on training session. One hour with real examples from your own company is worth more than a policy document sent by email. For the written part, company policy for employee ChatGPT use shows what usually goes into the allow and ban lists.
Illustrative scenario: from hidden use to approved workflow
This is an illustrative scenario, not a real case. A services company that handles support on WhatsApp finds out, after the amnesty, that several people copy customer messages into a free assistant to write clearer replies. The messages include names, addresses and contract details.
Leadership skips the scolding and makes four moves. First, it thanks people for their openness and explains why that kind of data should not go into a personal account. Second, it records the real task: writing better replies with context. Third, it sets up a pilot with a single flow, for example answers to frequently asked questions, using an approved tool, with personal data removed or masked, human review before sending and a simple log of what was suggested and what was sent. Fourth, it agrees a success criterion before starting, such as response time and quality as perceived by the supervisor, and a date to decide whether to expand, adjust or end the pilot.
The expected result is not a number. It is a change in behavior: the team now has a legitimate path for the same task. If the flow evolves into an agent that replies directly on WhatsApp, other requirements come in, such as action limits and handoff to a human, covered in how to integrate AI into your company's WhatsApp.
How the map, limit, pilot and hand over method applies
The same reasoning used to deploy AI also works for treating what already exists informally. This section describes a working practice, not a promised outcome.
- Map: inventory tools, tasks and data types, and record how the process works today, before any change.
- Limit: define which data and which actions stay out of AI's reach, and which permissions each approved tool really needs.
- Pilot: choose one real workflow, with logs and an agreed success metric, instead of releasing everything at once.
- Hand over: pass the operation to the team with a named owner, and decide from the logs whether to expand, adjust or stop.
For reference material, go to primary sources. The NIST AI Risk Management Framework organizes risk management into govern, map, measure and manage. The OWASP Top 10 for LLM applications describes risks such as sensitive information disclosure. For the Brazilian context, the website of ANPD, the national data protection authority, collects official guidance on data protection. All of that is official documentation. What we describe about amnesty, department conversations and the pilot is implementation experience and should be adapted to each company's culture. That an amnesty reduces the fear of declaring use is a reasonable hypothesis, not a guarantee.
How to keep control after the first round
The inventory goes stale quickly, because new tools and features appear all the time. A few habits keep the subject alive without weighing the team down.
- Name an AI owner in the company, even if it is a shared role, with an open channel for questions like whether a given tool can be used for a given task.
- Create a light request process: the person describes the tool, the task and the data, and gets an answer within an agreed short deadline.
- Review the inventory at regular intervals and whenever a tool or vendor changes in a relevant way.
- Treat incidents as learning: if someone sent data they should not have, the focus is to contain it, notify whoever needs to know and fix the process, with legal support when personal data is involved.
- Follow the regulatory environment, which is still under discussion. A good starting point is Brazil AI regulation: what companies should watch and do now.
Finally, avoid the opposite extreme: allowing everything without criteria is also a form of shadow AI, just with a stamp on it. The goal is for AI use to be visible, justifiable and proportionate to the risk.
Frequently asked questions
What is shadow AI and why is it a problem?
Shadow AI is the use of AI tools without the company's knowledge or approval. The main problem is that customer data, contracts and internal information can slip out of control without anyone knowing, which creates LGPD exposure and makes any incident response harder.
Should I ban AI use until I have a policy?
A total ban is usually hard to sustain and tends to push use onto personal devices. It is more effective to prohibit specific data categories right away, allow low-risk uses with guidance and publish an approved alternative for the most common tasks.
How can I find out who uses AI without it feeling like surveillance?
Start with a stated amnesty, conversations by department and an anonymous form, and use technical data only in a proportionate and communicated way. The inventory should focus on tools, tasks and data types, not on individual performance.
Do I need a local model to solve the problem?
Not always. For many tasks, a business account with suitable terms and access control is enough. A local model makes sense when the data is very sensitive or the volume justifies it, but it requires operations, updates and a named owner.