During Super Bowl LX, a no-code AI platform ran a primetime campaign. The premise: an employee builds a budgeting app in minutes. Her coworkers see this and start building their own—inventory tracking, dieting logs, book sharing. The message to 120 million viewers was unambiguous: anyone can build software now. No code. No waiting for IT. Just describe what you want.
The conversation that follows will be about security. Data leaks. Shadow AI. Unauthorised access. Those are real concerns. But they’re not the ones that should keep you up at night.
When every employee can build apps, your processes start forking—and nobody notices until it’s too late.
The Variation That Used to Be Harmless
Employees have always worked differently. One person has thirty browser bookmarks. Another can’t distinguish the address bar from the search bar. Someone writes reports in Word, someone else in Excel, and someone prints emails to read them.
That was always fine. Why? Because the variation was in execution, not in process. The underlying workflow—what fields are required, what approvals are needed, what the output looks like—stayed stable. People had personal style, not personal infrastructure.
AI app builders change this equation fundamentally. Now an employee doesn’t just work differently. They encode their way of working into software and operationalise it. They create apps that enforce their own fields, their own rules, their own definitions. They automate exceptions that nobody ever approved as policy.
This isn’t “working in your own style.” This is process forking—and it happens silently, one helpful little app at a time.
Five Things That Break
1. Your SOPs Become Fiction
Your company thinks it has standard operating procedures. Documentation. Flowcharts on a SharePoint somewhere. But the actual work is running through dozens of micro-apps built by individual employees, each encoding slightly different assumptions. The procedure you think you have is not the procedure being executed.
This is process drift, and it’s invisible until something fails an audit or produces contradictory results.
2. Your KPIs Lose Their Meaning
This is the one that should terrify every executive.
If anyone can build reporting tools, anyone can also invent definitions. What counts as a “completed task”? What’s a “qualified lead”? What’s an “incident”?
When five people build five dashboards with five definitions of the same metric, leadership isn’t managing reality anymore. They’re managing five parallel realities and don’t know it. This isn’t an Excel problem. This is a governance crisis wearing a productivity costume.
3. Bus Factor Goes Existential
Every organisation has that one spreadsheet. It runs half a department, it has 47 tabs, nobody understands the formulas, and if the person who built it leaves, operations halt.
Now scale that up. Instead of a spreadsheet, it’s a full application—with logic, automations, data pipelines, and daily decisions flowing through it. No documentation. No version control. The builder leaves, and you inherit an undocumented operational system that nobody can maintain, nobody can audit, and nobody can safely turn off because they don’t know what depends on it.
4. Management Loses Visibility
Until now, if you wanted to understand how a department works, you could look at the tools, the workflows, the reports. They were shared, known, auditable. Now each employee has their own black box. The manager doesn’t know what runs inside it, doesn’t know if the numbers are correct, doesn’t know if the logic is sound. The organisation becomes opaque from the inside out.
5. Automation Industrialises Errors
Here’s what nobody in those cheerful product demos tells you. When someone in accounting makes a judgement error manually, they make it once. When they build an app that encodes that same error into automated logic, every single transaction carries that error. Systematically. Silently. At scale.
Automation doesn’t eliminate mistakes. It industrialises them. And the scariest part? The app “works perfectly”—it just works perfectly wrong.
The One Thing That Finally Gets Fixed
Any honest analysis has to acknowledge the other side.
For years, every employee had micro-problems that were never important enough to reach IT’s backlog. “I need a tool that does this one specific thing.” The answer was always: “We’ll look at it in six months.” Six months later, it was still in the queue.
Now that employee solves it in twenty minutes. That’s genuinely empowering. That’s real productivity. And any governance framework that ignores this benefit is dead on arrival—because people will build anyway, just outside your visibility.
The Human Cost Nobody’s Talking About
There’s an elephant in the room that goes beyond process and governance.
Not everyone can—or wants to—build apps.
The moment “vibe coding” becomes a workplace capability, a new hierarchy emerges. The employee who can prompt an AI into building useful tools gains influence, visibility, and perceived value. The one who can’t—or doesn’t want to—starts looking like dead weight, even if their actual job performance is excellent.
This is the new digital divide, and it’s happening inside organisations, not between them:
- The “builder” becomes the new power user—the person everyone depends on
- The non-builder becomes dependent, or worse, invisible
- Technical aptitude—even at the “just describe what you want” level—becomes a proxy for competence
This is the same dynamic we saw with Excel VBA power users in the early 2000s, but amplified. Then, the gap was about a specific skill in a specific tool. Now, the gap is about the ability to create tools themselves.
Organisations need to acknowledge this. Not everyone’s value lies in building. Some people’s value is in judgement, relationships, domain knowledge, or execution. A company that lets “can you build an app?” become the new measure of relevance will lose people it can’t afford to lose.
Guardrailed Freedom: A Practical Model
The question isn’t “should we allow this?” That train has left. The question is: what operating model makes this work without destroying organisational coherence?
The principle is straightforward: standardise interfaces, not implementation. If you try to control how people build, you’ll fail—they’ll build outside your control, just like shadow IT always worked, only faster. Instead, standardise what matters:
- Common data vocabularies—canonical definitions that everyone must use
- Mandatory fields for specific outputs
- Approval gates at defined control points
- Logging and traceability for specific actions
A tiered approach works:
Tier 0—Personal tools. Build whatever you want for personal use. No shared datasets, no official outputs. Your sandbox, your rules.
Tier 1—Team tools. The moment an app is used by more than one person: register it. Name, owner, purpose, data it touches. Basic requirements: backup capability, access permissions, change log.
Tier 2—Business-critical apps. If the business depends on it: change management, defined data contracts, support model, auditability. The same rigour you’d apply to any production system—because that’s exactly what it is.
The role of IT shifts accordingly. IT no longer builds every tool. IT governs the platform—controlling what data employees can access, what outputs must meet standards, which processes are non-negotiable, and what happens when someone leaves.
And If You’re in the EU, There’s a Layer Most People Aren’t Seeing Yet
Everything above is about organisational coherence. But for companies operating in or targeting the EU market, there’s a harder edge to this.
The EU AI Act doesn’t care whether your AI system was built by a software team or by an employee on their lunch break using a no-code platform. What matters is: does the system produce outputs that people rely on to make decisions? Is there documented human oversight? Are risks identified and mitigated? Is there traceability?
Now think about what happens when employees across your organisation are building AI-powered apps that filter data, generate reports, automate approvals, or score leads—and none of these have risk assessments, documentation, or audit trails.
These aren’t “internal tools” in the eyes of a regulator. They’re AI systems producing outputs that influence business decisions. And the moment one of those outputs reaches a client, a partner, or an auditor, your cheerful little citizen-built app may fall squarely within regulatory scope.
The legal risk of employee-built AI apps is not a future problem. It’s a current blind spot. And it’s one more reason why the tiered governance model above isn’t optional—it’s the minimum viable compliance posture for any EU-facing organisation that lets employees build.
Shadow IT’s Final Form
One more thing nobody’s discussing: when each employee picks their own AI platform—Bolt, Lovable, Cursor, or whatever they saw in a Super Bowl ad—the organisation develops micro-dependencies on dozens of vendors that no one at the organisational level chose, evaluated, or contracted.
What happens when one of those platforms changes pricing? Or shuts down? Or gets acquired and pivots? You now have business processes running on infrastructure that exists entirely outside your procurement, your security review, and your continuity planning.
This is shadow IT’s final form. And it’s arriving to a Super Bowl audience.
The Bottom Line
Your company is becoming a software-producing organism. Not by strategy. Not by choice. By the simple fact that the tools now exist and people will use them.
The question for leadership is binary: do you want that software to be invisible and fragmented, or visible and governable?
Because “prevent it” is not an option. The only options are managed freedom or unmanaged chaos. And the organisations that thrive will be the ones that admit their current governance structures aren’t ready—and start building the framework before the framework builds itself.
The era of “IT builds, employees use” is over. The era of “everyone builds, someone governs” has begun. The only question is whether “someone” exists in your organisation yet.
Navigating the shift from centralised IT to governed employee-built tools? Let’s talk about building the framework before the chaos builds itself.