The New Shadow IT: Hidden Risks and Costs of Building with AI

Right now, there’s probably software being built in your company without IT knowing about it. Not by a department secretly buying a system, but by a marketer who builds a customer portal in an afternoon with a few AI prompts, or a controller who creates a calculation tool that’s used by three teams within a week. That’s vibe coding: you describe what you want in plain language, the AI writes the code, and you barely look at what’s under the hood. The promise is faster experimentation without waiting for a packed IT backlog, but every app created out of sight is shadow IT that no one manages, patches, or has checked for security.

The question isn’t whether you can stop this. You can’t, and a ban won’t solve anything. The real question is whether you realize what you’re taking on when you build this kind of software yourself, and when you’re better off with a company that develops professional software.

Author: Alan Linnenbank

Published: 5 November, 2026

What’s Really Changing Now

Building software used to have a barrier: you needed a developer. That barrier is almost gone. With tools like Lovable, Claude Code, and the Power Platform, you describe an idea and get a working app back—without reading a single line of code.

It’s happening everywhere, as Dutch research shows. According to the Awareways report, 78 percent of employees use AI without IT’s approval, while organizations themselves only see about 11 percent of actual usage. The Cybersecurity Survey Alert Online 2026 reveals that nearly half of Dutch employees use private AI for work. Those same tools are now being used to build software, often by people who aren’t developers.

The difference from classic low-code is significant: here, the AI generates real code, with real dependencies and real security choices, made by someone who doesn’t recognize those choices as such. The result works and solves a real problem, and that’s exactly why it gets used before anyone asks who’s managing it.

Why This Is Different from the Old Shadow IT

Shadow IT is software or technology that employees use or build without IT’s knowledge or approval. We’ve seen this for years. In the past, it was mostly in Excel: a macro that grew into a business-critical calculation model, a spreadsheet quietly running an entire process. Annoying, but manageable, because it stayed within the company walls. What’s happening now is more advanced and riskier: real web applications with databases and integrations, often simply accessible on the open internet.

The numbers don’t lie. A security company found 380,000 publicly accessible apps built with vibe coding tools. About 5,000 of them leaked sensitive data. The cause was usually simple: on many platforms, an app is public by default unless someone changes it manually. This isn’t a distant problem—Eindhoven municipality reported a data breach because personal data ended up in a public AI tool.

AI-generated code can also compromise quality if not used correctly. It leaks secrets twice as often as handwritten code and is rarely properly reviewed. Builders without a development background can’t review it anyway—they can’t read the code and don’t know what to look for. The law doesn’t care how something is built, only what data it contains. A vibe-coded tool with personal data falls under the same GDPR obligations as any other system, just without a DPIA and often without anyone knowing a DPIA is needed. The IBM breach report 2025 links 20 percent of data breaches to shadow AI. On average, these incidents cost $670,000 more each.

“Let people experiment. But as soon as customer data is involved or colleagues rely on it, it’s no longer a prototype. Then it’s software, and that requires craftsmanship.”

– Alan Linnenbank, CTO bij Dolphiq

Your IT Landscape Becomes Fragmented

The security risks are the visible part. The quieter problem is architectural. A custom application you have built fits into an existing landscape: it communicates with your other systems through agreed integrations, is listed in your overview, has an owner, and a place in the lifecycle. A vibe-coded app doesn’t do that. It runs on an external platform, with its own copy of your data, outside your overview and any architectural diagram. It’s not a building block in your landscape, but an isolated island next to it.

There’s also an access problem. Such an app usually connects via the account of the employee who built it, including all the rights that person has on the network. The app inherits a human’s access, while a properly built system should have its own limited service account with only the permissions needed for its task. If the builder has broad rights, so does the app, and it can access much more data than intended. No one notices as long as it works, but this is exactly the kind of invisible access that leads to data breaches.

Someone needs to manage that island, and usually no one does. No patch policy, no monitoring, no documentation, often not even saved source code. As long as the builder is around and it works, no one notices. As soon as that person leaves or the app breaks, the problem lands with a team that has no idea how it works. You end up reverse-engineering something that was created in an afternoon.

The costs are exactly in that tail end and are mostly invisible upfront: ongoing subscriptions, duplicate data that gets out of sync, integrations that still need to be built, and often a rebuild to make the app secure and maintainable. In the end, you pay more for something that seemed free and fast than for regular custom work—just spread out and after the fact. The biggest cost isn’t on any invoice: once dozens of these apps exist side by side, you no longer have a clear IT landscape. You can’t see where your data is, what depends on what, or where your next incident will come from. And that overview is the foundation for security, compliance, and further development.

Banning Doesn’t Work, Clear Oversight Does

People quickly think of a ban. Understandable, but counterproductive. A ban drives the behavior underground, to a private account on a home laptop, and then you lose the last bit of visibility. You haven’t removed the risk, just made it invisible.

And oversight is exactly what you need. Only when you know what’s running can you decide what’s important enough to have built professionally. So the question isn’t how to stop it, but how to get a clear picture of what’s happening and what’s too important to leave to chance.

Make All Software Visible

You can’t make decisions about things you can’t see. So the first step isn’t policy, but inventory: what’s being built, by whom, on which platforms, and with what data? Then classify by risk, not by how it was built:

Green (no sensitive data, low impact)

Think of an internal spreadsheet or a standalone tool. Here, you mainly want to know it exists.

Orange (business data or multiple users)

A tool colleagues rely on. Basic requirements apply here: you know where it is, who has access, and whether there’s a backup.

Red (personal data, customer data, or a core process)

This doesn’t belong in a self-built app on an external platform. Have it built or rebuilt professionally, with security, review, and maintenance.

Green, Orange, and Red

This green, orange, and red classification gives you an instant agenda. Leave green alone, clean up or manage orange, and red is your short list of things that really need to be built properly. That’s how an invisible jungle becomes a clear list of choices.

How to Get a Grip on the Software in Your Company

You don’t have to set this up all at once. A workable order:

Inventory Without Blame

Ask teams which tools and apps they use, and make it clear the goal is to help, not punish. You’ll only get an honest picture if people aren’t afraid.

Classify by Data

Go through the list: green, orange, red. It takes an afternoon and immediately shows where you need to focus.

Decide per App

Keep, clean up, or have it built professionally? Anything involving customer data or a core process belongs in the last category.

Write a Short AI Policy

Not forty pages, just a few clear rules: what’s allowed with which data, what always goes through a skilled developer with review, and where do you report if something goes wrong?

When to Have Software Built Professionally

Vibe coding is a great way to test an idea: a disposable prototype, a quick test, or an internal tool that can’t do any harm. Let people experiment. The misconception is that such a prototype is ready for the real world. As soon as customer data is involved, colleagues rely on it, or it supports a process, it’s no longer an experiment but software. And software you can’t account for is a risk, not a saving.

Building good software is a profession. It’s not just about functionality, but also about security, integrations, maintenance, and review. AI doesn’t change the bar, but it does change the speed. An experienced team working with AI delivers faster, with the quality and control a self-built tool lacks. That’s how we work at Dolphiq: custom solutions on the Laravel stack, according to ISO 27001 and as a processor of customer data, with AI throughout the development process and a four-eyes principle.

So start by making visible what’s been created in your company. Then you’ll know what you can safely leave as is and what’s better left to professionals. Want to discuss this? We’re happy to help.