The New Shadow IT: How AI Gave It Superpowers
AI didn’t invent shadow IT. It just removed every limit that used to keep it small.
Someone on your team is copying account summaries into ChatGPT every Monday to prep for her calls. She’s not trying to cause a problem. She found a faster way to do her job.
A few months ago, a project manager connected your CRM into your support inbox with an AI workflow. It started as ticket categorisation. It’s grown since — it now sends automated replies to customers on your behalf, and no one reviews them.
A product manager added an AI writing assistant to your Notion workspace three months ago. Half the team uses it now. It can read your product roadmap and your pricing strategy.
None of them created a ticket. None of them asked IT for approval. And you probably don’t know about any of it.
This is the new shadow IT.
Shadow IT Already Existed. AI Gave It Superpowers.
The old version of shadow IT was manageable. Marketing signs up for an unapproved SaaS tool. Finance builds a spreadsheet of macros nobody else understands. These scenarios had some risk, but the risk was limited.
That constraint is now gone.
A non-technical person with an AI assistant can now build in an afternoon what used to take a developer, a sprint, and a ticket to track. This workflow pulls data between systems, runs on a schedule, makes decisions, and acts — and it’s built by someone whose job has nothing to do with engineering.
This scenario isn’t hypothetical. It might already be running inside your company, in the gap between what IT knows about and what’s actually live.
Three Reasons This Is Different
It touches live systems. Old shadow IT was typically a separate application. AI-built tools now connect straight into the systems you run on: your CRM, your inbox, your live database. That’s what makes them useful, but that’s also the problem — there’s no safe place for them to go wrong. When the logic is off, it doesn’t break a test copy. It emails a real customer or changes real data without anyone noticing.
It’s invisible by default. Old shadow IT would leave a trace: a new vendor on an invoice, a login no one recognised, a contract to sign. AI-built tools don’t. They run on access a person already has, inside tools you’ve already approved — there’s no additional bill and no new account to flag. They skip the usual checkpoints: no code review, no ticket, nothing IT would normally see. And the person who built it wouldn’t think of it as software. To them it’s a time-saving shortcut, so they wouldn’t see a reason to mention it.
It compounds. These tools start small and grow step by step, while each step is too minor to feel like it needs approval. People start to depend on them; other tools get built on top. Without anyone deciding it, it becomes part of how the company works. By the time you notice, turning it off fixes one problem but creates several.
Blocking Is Not the Answer
The instinct is to lock it down — restrict access, block the tools, write a policy. It’s the same move organisations made with shadow IT twenty years ago, and it failed then for the reason it will fail now: it ignores why people built these things in the first place.
People had a real problem, a real deadline, and a faster route than the official one. Banning that route doesn’t remove the need. It pushes the behaviour underground, where it’s less visible and harder to manage. The risk doesn’t disappear; it just moves somewhere you can’t see.
So the real question is: What would make the approved path easier than the workaround?
Not All AI Use Carries the Same Risk
The first move is to stop treating all AI use as one problem. It isn’t one problem, and most of it isn’t the part that should worry you. There are roughly three layers.
Individual productivity — drafting an email, summarising a meeting, cleaning up a document. This risk is not small, but it’s the simplest to manage: give people one properly contracted tool, with the right data terms in place, and most of the exposure disappears — not because anyone was told to be careful, but because the fast option and the safe option became the same tool.
AI inside the product — recommendations, chat bots, generated content in customer-facing features. This already has a home in your existing software delivery and release process. The real risk here isn’t shadow IT — it’s knowing when an AI feature should only recommend, and when it’s being trusted to decide. I’ve written separately about where AI should and shouldn’t be allowed to decide.
Internal workflows — this is the layer that can be dangerous. Most of it isn’t custom-coded; it’s a no-code platform — Zapier, Make, Power Automate — with an AI step dropped in. That combination removed the last real barrier: you no longer need to understand triggers, conditions, or field mapping, you just describe what you want and it wires itself together. Sorting tickets, summarising accounts, updating the CRM, moving data between systems, sending replies under your name — built in a tool that was never designed to be reviewed. This is where shadow IT becomes shadow operations — and where your attention belongs.
What to Do About It
Let people experiment, inside a real boundary. If it stays on synthetic or already-public data, doesn’t touch a live system, and doesn’t send anything to anyone outside the company, let it run. This is where speed matters most, and it’s the layer that was never actually the problem.
The trigger isn’t scale. It’s contact. The moment a workflow reads or writes real customer data, connects to a live system, or sends something to someone outside the company, it needs review — whether one person uses it or fifty. A workflow touched by a single person can already be updating a production record or emailing a real customer under your name. Scale doesn’t matter here; usage numbers measure popularity and not risk.
Once it crosses that line, treat it like software. That means more than one person looks at it before it goes further: someone who can tell whether it fits the architecture you already run, or it duplicates something that exists; someone who can assess the data it touches — quality, sensitivity, where it ends up; someone who can judge whether it holds up on security and legal grounds; and someone who can judge whether people will actually keep using it. This doesn’t require a big committee — just the right few people, before the workflow goes further.
Someone has to own the decision — not just whether it’s safe, but whether it should exist at all. A workflow can pass every check above and still be the wrong way to solve the problem. Someone needs the authority to decide whether it earns a permanent place in the process, not just whether it currently works.
The Takeaway
Shadow IT was always a symptom of speed outpacing process. Today, AI scaled that gap dramatically, and put that power in the hands of far more people than ever before.
Read that as good news. It means your teams are ready to move faster than your processes currently let them.
Build a process fast enough that people don’t need a workaround. Then keep learning together — because the tools, and the risks, will keep changing faster than any policy can.
Enjoyed this Article?
Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization. Insights, strategies, and actionable tips—delivered straight to your inbox.