Shadow AI: the tools your team is already using
The short answer
Your team is already using AI tools you have not approved. The only question is how many. Shadow IT accounts for roughly a third of a company's applications and up to 40% of SaaS spend in some organisations, with IT controlling just 15% of SaaS spend by Zylo's 2026 measurement. With AI the risk changes shape: the exposure is not the subscription cost, it is company and customer data pasted into a tool nobody vetted. Banning it does not work. A short, clear policy does.
Why this is different from ordinary shadow IT
An unapproved project management tool costs money and fragments information. Annoying, and recoverable. An unapproved AI tool can take your customer list, your contract drafts or your source code and send it somewhere you have no agreement with, under retention terms nobody read.
Under India's DPDP framework you remain accountable as the Data Fiduciary regardless of which tool an employee chose. A processor you never approved is still your exposure, and the fact that a junior employee pasted the data rather than the company does not change the obligation.
Adoption is outrunning control, and for a small business that gap is the real risk. A large company has procurement friction that slows this down. A ten-person company has none, which is exactly why it happens faster there.
How it actually happens
Nobody sets out to leak data. The sequence is mundane, and that is what makes it hard to prevent by policy alone.
Someone has a deadline
A report due tomorrow, a contract to review, a bug to find. Time pressure is the constant in every version of this story.
A tool makes the task faster
They paste in a customer email thread to get a summary, or a contract to get a plain-language explanation, or a log file to find an error.
It works
The task that would have taken an hour takes ten minutes. This is the point at which the behaviour becomes permanent, because it delivered.
They tell a colleague
Now two people are doing it. Then four. None of them think of it as a data decision, because it does not feel like one.
Six months pass
A meaningful amount of your business has passed through a service you have no contract with, and nobody can tell you what or how much.
Why banning it does not work
Two reasons, and both are practical rather than philosophical. A ban moves usage to personal devices and personal accounts, where you have no visibility at all, so the risk does not reduce, it just becomes invisible. And it removes any opportunity to guide what is safe, because nobody asks permission for something already forbidden.
The businesses handling this well provide approved tools and clear rules rather than prohibitions people quietly ignore. That framing also matters for the conversation: an employee who used an unapproved tool to hit a deadline was trying to do their job, and treating that as misconduct guarantees the next person hides it.
A policy short enough that people read it
One page, four sections. Longer than that and it becomes a document nobody opens.
- Approved tools, named. If a tool is not on the list, ask before using it, and keep the approval process to a day or people will route around it.
- What must never be pasted, specifically rather than abstractly: customer personal data, anything under NDA, credentials and API keys, financial records, unreleased product information, and source code if that is your position.
- What is fine, which is equally important and usually missing: public information, general questions, your own drafts, anonymised examples. A policy that only forbids reads as a ban.
- What to do if it already happened. No punishment for reporting. Someone who pasted a customer list six weeks ago needs to be able to say so without consequence.
The controls worth having
Business-tier accounts
Approved tools on business plans typically offer clearer data-handling terms than consumer tiers, plus admin visibility over who is using what.
A named approver
One person who can say yes within a day. Approval that takes a week is functionally a ban, and produces the same workaround behaviour.
A quarterly review
What is being used, by whom, and is it still needed. This doubles as a cost audit, since unused AI subscriptions carry the highest waste rate of any software category at 41%.
A processor inventory entry
If an AI tool processes customer data, it belongs in your vendor list alongside hosting and email, because under DPDP that is what it is.
From our own practice
We pay for Claude, ChatGPT and Gemini alongside roughly fifteen other tools, and our rule is narrow and written down: AI helps write code, and nothing else. Logic, security and performance decisions are made by the team, and no AI output is implemented without being verified several times.
Client code and client data are handled under that same rule. Being specific about what is allowed is what makes a policy usable. A blanket ban would simply move the usage somewhere we could not see, which is worse for the client than a rule people actually follow.
The narrow scope has a second benefit at renewal time. A tool used for one well-understood purpose is easy to evaluate. A tool used vaguely for everything is impossible to justify or cancel.
Frequently asked questions
Need help writing the policy?
We work with AI tools daily under a written internal rule, and we can help you build one that people will actually follow.