Working with IT

Shadow IT vs. sanctioned tools: how to build things without making IT your enemy

Somewhere in your company right now, someone is pasting work data into a personal AI account, or running a clever little script nobody approved. It's called shadow IT — and while it usually comes from the best instincts, it's how promising AI adoption gets banned company-wide.

What shadow IT is, and why good people do it

Shadow IT is any tool, app, or workaround used for work without the knowledge of whoever manages your company's technology. The classic examples used to be personal Dropbox accounts and rogue spreadsheets. AI has supercharged the temptation, because now the workaround isn't just storing files — it's a tireless assistant that seems to solve your worst chores in minutes.

And let's be honest about the motive: people go around IT because they're trying to do their jobs better. The instinct deserves respect. The method, though, carries real risks the person at the keyboard usually can't see: customer data leaving company systems, tools with no backup or owner when their creator leaves, and compliance obligations quietly violated.

Why IT says no (it's not because they hate fun)

IT departments get caricatured as the department of no. But their no usually decodes to: "I'm accountable for where company data goes, and I can't be accountable for a tool I don't know exists." That's a fair position. The data that makes your AI tool useful — customer lists, pricing, job records — is exactly the data your company is obligated to protect.

Here's the reframe that changes everything: IT's concerns are design requirements, not obstacles. "Data can't leave our systems" doesn't kill your tool idea — it tells you the tool should run locally. Handled that way, the same instinct that produces shadow IT produces something better: a sanctioned tool with an ally behind it.

The sanctioned path (it's shorter than you think)

  • Bring IT the problem, not a fait accompli. "I spend five hours a week on this — I'd like to build something small to automate it. What are your requirements?" is a conversation IT almost never gets and almost always welcomes.
  • Prefer designs with nothing to fear. Many of the best small tools are local, deterministic scripts — they run on your machine and send data nowhere (the "no token tax" pattern). For an IT reviewer, that's an easy yes.
  • Use approved AI accounts for the building. If your company sanctions an AI tool, use that one — and when possible, use AI to help build the tool rather than piping live company data through it every day.
  • Leave a paper trail. A one-paragraph note on what the tool does, where it runs, and what data it touches turns your build from a liability into an asset someone else can maintain.

The person who asks IT "what would make this safe?" ends up with more freedom to build than the person who never asked — because trust, once established, compounds.

If you're the owner or the manager

Shadow IT flourishes where there's no sanctioned path. If your people have no approved way to try AI on their work, they will find an unapproved one — the pull is too strong. The fix isn't surveillance; it's an easy front door: a named person to ask, a fast yes/no, and approved tools that are genuinely good enough to use. That's the environment where homegrown tools multiply safely — and it's exactly what my training sets up.

The takeaway

Don't build in the shadows and hope. Bring IT the problem early, treat their concerns as design requirements, and favor local tools that give them nothing to fear. You'll build more, not less.

Want a sanctioned path instead of a shadow one?

I help teams build the safe way — with IT as an ally from day one. Let's talk about how that looks in your company.

Book a free intro call