Are We Losing Control of the IT Estate? 

Simon Suarez
September 28, 2026
•
min read

Every IT department has a war story like this one. Mine involves an Excel workbook so large it had its own gravitational pull, VLOOKUPs reaching across network drives, live database connections nobody remembered authorising, and macros that to understand felt like VBA archaeology. Our support team called it Dante's Inferno, because it had nine layers of hell and, we were fairly sure, a tenth we never found. 

Shadow IT isn't new. What's new is how fast AI is reproducing the exact same pattern, just with better production values. 

The Same Problem, Wearing a Nicer Outfit 

The current version looks like this: a single-page HTML dashboard, knocked together in an afternoon, pulling data from an Excel template, calling out to an API with the authorisation key sitting in plain sight in the file. No environments, no version control, no audit trail, no idea what happens when the person who built it leaves the business. It's the Access database problem all over again, except this one was built by prompting rather than programming, and it shipped in a day instead of a quarter. 

Here's the bit that makes this round genuinely harder to argue against though. Ten years ago, you could point at the shadow IT tool and say, "look how ugly and fragile that is" and win the argument on sight. Today's version often looks and feels better than the enterprise system you're trying to get people to use. Clean interface, instant results, built around exactly what the user needed rather than what a requirements document said they needed eighteen months ago. Telling someone to abandon that for the "proper" system is a much tougher sell when the proper system is the one that feels like homework. 

The Obvious Fix, and Why It's Not That Simple 

The natural response is to point people at a managed AI deployment and hosting platform. Let the business build these things, just do it somewhere IT can see, with proper guardrails, rather than on someone's laptop. 

Sensible in principle. In practice, it runs straight into a few things’ architects lie awake thinking about: 

  • SSO and identity. A lot of these platforms bolt on authentication as an afterthought. If it doesn't plug cleanly into your existing identity provider, you either end up with another set of standalone credentials floating around, or someone shares a login "just for now" and now has an unmanaged group account touching live data indefinitely. 
  • Security and data exposure. These tools tend to be built by someone solving their own problem quickly, not by someone thinking about attack surface. API keys sit in plain text in the file itself, permissions are usually "give it access to everything so it stops complaining," and there's no patching cycle because nobody's officially responsible for it. It's not that anyone's being careless, it's that "move fast and ship a dashboard" and "think like an attacker" are very different mindsets, and only one of them was in the room when this got built. 
  • Hosting control and multi-cloud policy. Most enterprises have opinions, often contractual ones, about where workloads live and which vendors touch which data. A well-meaning platform choice made by a business team can quietly put customer data through infrastructure that never went near a vendor risk assessment, in a region nobody checked, under a data processing agreement nobody signed. 
  • Exit and dependency risk. These tools are often built on somebody else's roadmap. If the platform changes its pricing, its terms, or simply gets acquired and shut down, the business logic quietly baked into that dashboard goes with it, and there's no migration plan because nobody classified it as something that needed one. 

So "just give them a proper platform" solves the craftsmanship problem and immediately hands you a governance problem of equal size, just in a different shape. 

Where That Leaves Us 

None of this means the answer is to clamp down and ban the tools, because that approach has never once worked with shadow IT and it isn't going to start working now. A few directions worth exploring instead: 

  • A short, genuinely lightweight registration process for AI-built tools, so they exist on a list somewhere rather than existing nowhere. 
  • A small number of pre-vetted, SSO-integrated platforms that architecture has already stress-tested, so the path of least resistance is also the path IT can live with. 
  • Treating this as an extension of existing EUC and information governance policy, rather than inventing an entirely new AI-specific framework from scratch. 
  • Getting architects into the conversation at the point someone has an idea, not at the point the dashboard already has forty active users and a name. 

I don't think there's a clean answer here yet, and I'd be suspicious of anyone who claims there is. So, the question still stands: how do we govern the rise of AI tooling but still take a strategic advantage by enabling vibe coders within the business? 

‍

More Resources