AI has turned citizen development into everyday work. People in every department now build working apps without an engineering role, and most of those apps run outside IT's view. That is how shadow IT grows. For IT leaders, the answer is a governed self-service path that is faster than the workaround, with ownership, guardrails and an audit trail built in.
It usually starts like this. On Monday, a sales manager describes a quarterly dashboard to an AI assistant. By the afternoon, the whole team uses it. On Thursday, it stops loading.
Who gets the call? The sales manager can't read a stack trace. IT has never seen the code. Nobody is sure where the app is hosted or which data it reads.
Right now, this topic comes up at every event I attend and in almost every customer meeting.
Asked about exposed apps built with its tool, the AI app builder Lovable said, as quoted by Wired, that the configuration of an app is ultimately the responsibility of its creators. Those creators are today's citizen developers, and most of them have never been responsible for running software. I think that answer is too easy. Responsibility has to be built in at every level: the vendor of the tool, the platform the app runs on and the company that deploys it.
"Every company is a software company" has been a keynote cliché for fifteen years. For most companies, it wasn't true, because building software required scarce specialists. With AI, that constraint is gone.
In a representative survey published in September 2026, the German Economic Institute (IW Cologne) found that 29.1% of employees who use AI at work use tools their employer never provided. Among people under 30, it's 38.4%, among managers 34.6%. A survey by the low-code vendor Retool points in the same direction: of 817 builders, most of them Retool customers, 51% have already built software their teams use in production.
This is good news. The people who know the business best can build the tools they need without waiting a year in an IT backlog. Every employee can become a creator. For leadership teams, that changes three things at once: ideas become working software in weeks, small automations that never justified an IT project become worth doing, and every one of those apps has to be operated, secured and paid for.
Shadow IT used to mean an unauthorised SaaS subscription. Today it means unauthorised software: apps that no developer wrote, no architect reviewed and no operations team knows about.
Blocking the tools rarely holds, and the IW Cologne study hints at why. Where employees say their employer actively builds their AI skills, 44.5% use shadow AI. Where that support is missing, it's 21.3%. The authors call it a correlation. My reading: the training works. People learn what AI can do for their job, and then they use it. The company's infrastructure just hasn't caught up. The study's title puts it well: employees are faster than their companies.
Meanwhile, the apps end up somewhere. In May 2026, the security vendor Red Access reported more than 2,000 publicly reachable apps from vibe-coding platforms that held sensitive corporate, operational or personal data, many of them granting admin access to anyone with the URL. These figures come from a vendor's own research, so read them with care. According to Red Access, the organisations behind these apps were passing their audits at the time. Audits check the systems IT knows about. An app built in an afternoon and hosted on a personal account never makes that list.
A ban only pushes those apps further out of sight.
AI has made building far easier. Operating is as demanding as it always was. If that's true for an experienced infrastructure engineer, imagine what it means for the sales manager with the quarterly dashboard.
Gartner expects 60% of vibe-coded applications to be retired by 2028. The other 40% quietly become part of how the company runs, often with no owner and no entry in any inventory. Gartner also expects 30% of software engineering teams to experience material capacity strain from maintaining apps built by citizen developers and business users.
The cost shows up later, as questions nobody planned for:
When a company bought software, the vendor carried most of these answers. When a department builds it, the answers default to IT, the people who know least about what the app is for.
People take the easiest route. So IT needs to offer governed self-service: a path that is safer than the workaround and at least as fast. It helps to split the life of an internal app into three phases:
| Phase | Who | Where | How |
|---|---|---|---|
| Build | Anyone in the company | Sandbox | With AI tools such as Claude, Cursor or ChatGPT |
| Deploy | A named, responsible person | In the company's own environment | Through a self-service path with guardrails built in |
| Run | The same person, backed by IT | In the company's own environment | Largely automated: updates, monitoring, scaling, audit trail |
Building can happen in a sandbox. Deploying and running belong in more stable environments within the company's guardrails. Gartner makes the same point in the title of its June 2026 report: "Govern Vibe Coding for Citizen Developers With Self-Service Platforms". Vibe coding governance belongs in the platform people deploy to.
For platform teams, this means a new kind of user: business users who have never deployed anything, and increasingly AI agents acting on their behalf. Nobody can expect them to know the rules, so the platform has to enforce them. From what we see with customers, a governed path has five properties:
A few more decisions should be made before the first app goes live that can become expensive afterwards: which data sources are open by default, when an unused app gets retired, which cost center pays and who gets the first call when something breaks. By app number fifty, whatever you decided, or didn't, has become a habit.
Neele-Vat, a global logistics company based in Rotterdam, went down this road. The team moved its core shipping and tracking application off virtual machines onto a governed Kubernetes platform on Azure, and now uses that same platform to give newer, AI-built apps a place to run under the same guardrails and visibility, instead of a personal cloud account nobody on the platform team can see.
Agents execute code nobody has read, and what matters is what sits next door when they do. On a laptop, that means SSH keys, cloud credentials and every tool that trusts the project folder. In July 2026, researchers at Pillar Security published sandbox escapes affecting Cursor, OpenAI's Codex CLI, Google's Gemini CLI and Google Antigravity. The agents followed every rule and wrote files that trusted tools outside the sandbox later executed. Isolation has to come from the environment around the agent. In a proper sandbox, next door is sand.
That is what an AI agent sandbox is for: secure code execution for AI agents in an isolated environment, with outbound traffic denied by default and every action logged against an identity. That audit trail is where AI agent governance becomes practical: what runs in production, who deployed it and under what controls. For me, this is where digital sovereignty gets concrete. You know where your code runs, and you can prove who touched it.
Citizen development with AI is already happening in your company, with or without a strategy. The open question is whether it happens where IT can see it.
The first step costs nothing: ask every department which tools they have built or started using in the last six months, and where those tools run. Then build the governed path, and make it the fastest option in the building.
Your AI strategy is your platform strategy. Every team member can become a creator. Our job is to make sure what they create is safe to run.
Templates with guardrails, plain-language rules and an audit trail for every AI-built app, on your own Kubernetes.
Subscribe to our newsletter and stay on top of the latest developments
