A salesperson pastes a client’s email into a chatbot to get a more polite reply. A developer copies in an error message along with the configuration file. Someone in finance uploads a spreadsheet so the AI can summarize it. None of this is malicious. People want to work faster, and the tool is one browser tab away.
When this happens without the organization’s knowledge and approval, it is called shadow AI. This article covers the actual risk, how to find out what is going on in your organization, and the rules and technical controls that keep it in check.
What counts as shadow AI
Any AI tool or AI feature that IT and the security officer do not know about and that has no contract signed in the organization’s name. The best-known form is a public chatbot used with a personal account, but the category is wider:
- AI services a team has subscribed to on someone’s personal card,
- browser extensions that send the content of the open page off for processing,
- note-taking and transcription tools that join meetings,
- AI features switched on later in SaaS applications you already use,
- AI apps that an employee has given access to their mailbox or files through their corporate account.
The last two are the hardest to spot because no new website is involved. The data flows out in the background, through a system that is already approved.
What data can leak
Whatever an employee types in, uploads, or lets the tool read ends up with the provider. What happens to it there (whether it is stored, for how long, whether it is used to train the model further, who can access it) depends on the provider’s terms. With a personal account, nobody has reviewed those terms on the organization’s behalf.
Typical types of data:
- personal data of clients and employees, such as emails, complaints, and CVs,
- contracts, proposals, negotiation material, and other trade secrets,
- source code, system descriptions, network and configuration data,
- logs and error messages, which often still contain a password, token, or API key,
- meeting audio and transcripts, including details that would never have been put in writing.
With personal data this is also a data protection issue: the data is transferred to a party with whom there is no data processing agreement. On top of that, the damage often cannot be assessed even afterward, because nobody can say what left the organization and when.
How to uncover it
The goal is an inventory: which AI tools are in use, by whom, and with what data. That takes several sources, because none of them sees everything.
- Network logs. Proxy, DNS, and firewall logs show which AI services are reached from inside the organization, how much traffic goes to them, and from which users or machines.
- Identity platform. The corporate directory shows which external apps users have given access to their accounts, and with what permissions (reading mail, accessing files).
- Endpoints. The list of installed applications and browser extensions reveals the tools that do not work through a website.
- SaaS settings. In the admin console of the cloud services you already use, you can check which AI features are switched on and where they send data.
- Expense claims. Subscriptions paid by card often only turn up among expense reimbursements.
- Talking to employees. A short survey or interview tells you what people use the tools for, and that matters at least as much as the list.
On that last point, tone decides the outcome. If the assessment feels like people are being called to account, the use carries on, only better hidden. It is better to say up front that the aim is to set up safe ground rules, and that nothing people share now will lead to disciplinary action.
What belongs in an AI usage policy
A policy works if an employee can find out within a minute which tool they may use for a given task and with what data. A total ban rarely holds, because people work around it. It is better to have an approved tool and clear rules on what may be entered into it. What the policy should cover:
- Approved tools. Listed by name, with the condition that they may only be used with a corporate account.
- Data categories. Built on the organization’s existing data classification: what may go into any approved tool, what only into the internal or contracted tool, and what into no AI at all.
- Requesting a new tool. Who to ask, who decides, and on what criteria (where the data is stored, model training, contract).
- Extensions, note-takers, integrations. A separate rule that an AI tool may only get access to mail, files, or meetings with approval.
- Responsibility for output. Whoever uses text, code, or analysis written by AI checks it and takes responsibility for it.
- What to do if data has leaked. Whom to tell and how quickly, so that any data protection notification can be made in time.
- Review. Tools and features change fast, so the policy needs an owner and regular updates.
A policy stays on paper if nobody explains it. At rollout, a short training session built on examples is worth more than a long document.
Technical controls
The policy says what is right. Technical controls help people stick to it and make deviations visible.
- Web filtering for the AI category. Access to unapproved AI services can be blocked or tied to a warning, which steers traffic toward the approved tools.
- Data loss prevention for traffic going to AI. DLP rules detect when personal data, card numbers, source code, or passwords are about to be sent to an AI service. Start in monitor mode so the rules can be tuned to real usage, and only block after that.
- Restricting app consent. On the identity platform you can require administrator approval before any external app gets access to a corporate account.
- Managing extensions. Browsers can be configured centrally to allow only specific extensions.
- Logging and reporting. A regular report on which AI services are used, by whom, and how much. This shows where the policy or the set of approved tools needs to change.
No control is complete. The corporate network cannot see a chatbot opened on a personal phone, so technology only gives real protection together with the policy and training.
Where to start
The order is roughly the same everywhere: first the inventory, then risk classification, then the policy built on it, and finally the technical controls the inventory shows you actually need. Organizations that start with the controls often block a tool nobody uses and miss the real data outflow.
Our shadow AI assessment with an AI usage policy helps with this: we build an inventory of the AI tools and data flows in use, classify the risk for each tool, write the AI usage policy for your employees, and recommend the technical controls you need. We covered general AI risks in detail in our article on enterprise AI adoption.
