Shadow AI Tools: What Your Team Really Uses

Ask most IT or security leaders which AI tools their organisation uses, and you'll get a short, tidy list: the ones that were formally approved. Ask individual employees the same question and the real list is usually much longer, a browser extension someone installed to summarise emails, a free transcription app a manager uses for one-to-ones, a personal ChatGPT account a marketer relies on for first drafts. That gap between the approved list and the actual list is shadow AI, and closing your eyes to it doesn't shrink it.

What counts as shadow AI, exactly?

Any AI tool used for work, on work data, that hasn't gone through your approval process, even briefly, even once. That includes obvious cases like an unsanctioned chatbot, and less obvious ones: an AI feature quietly switched on inside software you already pay for, a personal account used for a single urgent task 'just this once', or an approved tool being used on someone's personal free account instead of the vetted business one. The common thread isn't the tool's name. It's whether anyone with authority over vendor risk knew it was happening before the data went in.

How is this different from shadow IT?

Shadow IT is the older, broader problem: any software, hardware or cloud service used without IT's knowledge, from a random cloud-storage account to an unapproved project-management tool. Shadow AI is a subset of that, but it deserves its own name because it carries a risk most shadow IT doesn't: the data you paste in may be used to train a model, potentially shaping outputs someone else sees later, rather than just sitting quietly in an unmanaged database. A shared spreadsheet nobody approved is a visibility problem. A chatbot nobody approved, that trains on what you paste into it, is a visibility problem and a data-leakage problem at the same time.

Why it happens

AI tools are uniquely easy to adopt without anyone noticing. There's often no purchase order, no IT ticket, nothing beyond a browser tab and an email address, and many of the best tools are free to start with, so there's no invoice to trip a review either. An employee under deadline pressure who finds a tool that saves an hour isn't trying to create risk. They're solving today's problem with whatever's available, and a formal procurement process is rarely open at 4pm on a Thursday, or ever, at a company small enough not to have one. Peer pressure plays a part too: once one person on a team mentions a tool that halved their workload, the rest tend to sign up quietly rather than wait for someone above them to formally bless it.

Where the risk actually sits

The risk isn't the tool existing; it's what goes through it once real data enters the picture. An in-house paralegal at a small law firm we spoke to had been uploading client contracts to a free summarising tool for months to save time before a partner discovered it during an unrelated audit. Nobody had decided that was against the rules. Nobody had decided it was fine, either. It simply never went through a process where anyone with authority over vendor risk got to weigh in, and the tool's data policy could have changed at any point in those months without anyone at the firm noticing, because nobody was watching for it.

Does banning AI tools actually work?

Rarely. A ban doesn't remove the pressure that drove adoption in the first place, so usage doesn't stop; it just moves further out of sight, onto personal devices and personal accounts with even less visibility than before, often literally a personal phone rather than a company laptop. A policy nobody can realistically comply with produces quiet non-compliance, not compliance, and it teaches people that raising an AI tool with management is more trouble than just not mentioning it.

What actually closes the gap

Four moves work better than a ban. Find out what's really in use, through expense reports, SSO or OAuth app logs, or by simply asking teams directly, which is usually faster and more accurate than either. Build a living tool register, not a one-time survey, since new tools get adopted faster than any annual review cycle can track, so the register needs to be something people add to as they go, not something filled in once a year under duress. Vet quickly, not eventually: a fast, lightweight check on training posture, DPA, BAA and SOC 2 beats a slow formal process people route around out of necessity rather than malice - see our AI risk assessment guide for the fuller version of that check, or our step-by-step guide on how to vet an AI tool for the specific questions worth asking before rollout. And give tier-specific guidance: 'use the business plan of this tool, not the free one' is often the single highest-leverage instruction you can give, since it removes the risk without removing the tool anyone actually relies on.

Is shadow AI a GDPR problem?

It can be, the moment personal data is involved. Regulators expect organisations to know where personal data goes and under what lawful basis, and an unapproved tool nobody's assessed makes that impossible to answer honestly, which is itself a finding in a data-protection audit even before anything goes wrong. The ICO's guidance on AI and data protection is a useful reference if EU or UK personal data is anywhere near what staff are pasting into these tools, and the underlying GDPR principles apply regardless of whether the tool was ever formally approved.

The realistic goal

You're not trying to reach zero unapproved tools; that isn't achievable and chasing it wastes effort better spent elsewhere. The realistic goal is a register that reflects what's actually happening, which is essentially the NIST AI RMF's MAP function applied to tools nobody bought on purpose, a fast path to vet new tools as they surface, and clear tier guidance for each one. Start with the free AI vendor risk assessment, and pair it with a short AI usage policy so the approved path is easier to reach than the shadow one ever was.