Shadow Automation Is the New Shadow IT

Every business that's been around a while has a shadow IT story.

Maybe it was the salesman who started keeping customer files in his personal Dropbox because the shared drive was slow. Maybe it was the office manager who built a spreadsheet in 2011 that somehow ended up running your month-end reporting. Maybe a department bought its own software on a company card and mentioned it to nobody. That's shadow IT: technology the business depends on that the business never officially chose.

Nobody involved was being sneaky. They had a job to do, the approved tools weren't doing it, and they solved their own problem. That's usually a sign of a good employee, not a bad one.

The IT world spent twenty years learning to find that stuff. There were reliable places to look — the credit card statement, the list of software installed on each machine, the network traffic going out to services nobody approved. Shadow IT left a paper trail, because somebody always had to sign up for something.

That's the part that just stopped being true.

What's different this time

Shadow IT meant your employee started using somebody else's software. Shadow automation means your employee wrote their own.

An office manager who would never call herself technical can now describe a chore to an AI assistant in plain English — "every Monday, open these reports, pull the totals, and email me a summary" — and get back something that works. She tries it. It works. She uses it every Monday after that.

There's no vendor. No signup. No invoice, no license, no new icon on the desktop that anyone would notice. Nothing shows up on the credit card statement, because nothing was bought. The entire thing might be a file in her Documents folder and an entry in the machine's task scheduler.

So every method the business would normally use to discover unofficial technology comes up empty. Not because the automation is hidden — because there's genuinely nothing to find in any of the usual places.

Why it stays invisible

The other reason nobody reports it is that nobody thinks it's worth reporting.

Ask an employee "are you running any scripts or automations on your computer?" and you'll get a blank look and an honest no. In her mind she didn't build software. She figured out a shortcut for a chore that used to eat her Monday mornings. It's in the same mental category as a good email filter or a spreadsheet formula — a personal trick, not a business system.

And it isn't only the AI-written kind. The same blind spot covers the Excel macro someone recorded years ago, the rule quietly forwarding a mailbox, the scheduled task set up by an IT person who left in 2019. Automation earns its invisibility by working. Once something has run correctly for six months, everyone stops seeing it — including the person who built it.

Meanwhile the business quietly reorganizes around it. Deadlines get set assuming the Monday summary lands. Another person starts using the output. Nobody ever decided to depend on it; the dependence just accumulated, the same way we described in Part 1.

The failure nobody sees coming

When people imagine this going wrong, they picture a crash — an error message, a phone call, something obviously broken. That version is fine. Loud failures get fixed.

The failure that actually hurts is the quiet one. A report gets renamed and the automation, finding nothing where it expects a file, dutifully emails a summary of nothing. Or it keeps sending last week's numbers because the step that refreshes them silently stopped working. Nobody notices for a month, because the email still arrives every Monday and it still looks right.

That's the real risk in shadow automation: not that it stops, but that it keeps going while being wrong — and it's making decisions look well-informed the whole time. A process nobody owns is a process nobody is checking.

Then there's the version that hurts on a specific Tuesday. The person who built it takes another job. What she left behind is a working automation nobody else can read, doing a job nobody else fully understands, on a machine still being backed up like a disposable PC. What walks out the door isn't a script. It's the only copy of how part of your business works.

How to find it without starting a witch hunt

The instinct to crack down is the wrong one. Ban it and you lose real productivity and drive the rest of it underground, where you'll find it during a disaster instead of on a calm Tuesday. The goal is to know what exists, not to punish the people who built it.

Which means the question you ask matters more than anything. "Are you running any automations?" gets you nothing. These do better:

"What part of your job happens without you doing it?"

"If your computer died tomorrow, what would stop working that isn't in the cloud?"

"Is there anything you'd have to rebuild from scratch, and would you remember how?"

Ask them the way you'd ask about a useful trick, because that's what it is. You'll be surprised what surfaces — and the same conversation usually turns up two or three things that ought to be automated properly.

What to do with what you find

Not everything needs the same treatment. Sort what you find by one question: what happens to the business if this quietly stops or starts lying?

If the answer is "somebody's Monday gets tedious again," write it down and move on. If the answer involves money going out, invoices going unsent, numbers people trust, or anything a customer sees, then it's a business system that was never treated like one. Three things make it real: someone other than the builder knows it exists and what it's for, the machine it runs on is protected like the critical machine it has become, and somebody would actually notice if the output went wrong.

None of that requires banning anything or hiring a programmer. It mostly requires admitting the automation is load-bearing — which is the step almost everyone skips.

Next in this series: what these automations leave behind while they run — the logs, tracking files, and little databases that often turn out to be the most important and least protected data in the building.

← Back to all articles