Employees Building Their Own Apps With AI: Empowerment or the Next Shadow IT?

By Victor Hoang · Updated Oct 10, 2026

A finance analyst gets tired of rebuilding the same month-end reconciliation by hand. On a Tuesday afternoon she describes the problem to an AI coding tool, pastes in a sample export, and by dinner she has a small web app that does the job in seconds. It works. Her team loves it. By Friday, three other people are using it, and it's reading from a shared drive full of customer invoices.

Nobody in IT knows it exists. Nobody reviewed it. And the analyst who built it is the only person who understands how it works.

That's the real question for leaders: when anyone can build software, who owns the software that anyone builds? The answer isn't "ban it," and it isn't "let it run." It's a light registry and a clear handoff rule, and the rest of this piece shows what those look like.

Why this is different from the spreadsheet era

Business users have always built their own tools. Spreadsheets, macros, and mail-merge hacks were the original citizen development. So it's fair to ask what's new.

Three things changed.

The ceiling went up. A spreadsheet is a calculation surface. An AI-built app can have a login page, a database, an API connection, and a public URL. It can read from your CRM and write to your billing system. The same afternoon of effort now produces something that behaves like a real application.

The author can't read the code. A spreadsheet builder can at least see the formulas. Someone who prompted an app into existence often can't tell you what it does with credentials, where it stores data, or what happens when an input is malformed. They know it worked in the demo.

Distribution is frictionless. A link can be shared in one message. The app spreads by usefulness, not by procurement, which is exactly why it escapes every control designed around purchases.

None of this makes the builders reckless. They're solving a real problem with the best tool in reach. The risk lives in the system around them, which never decided what happens next.

The empowerment case is real

It would be easy to write this as a warning label. That would miss why it's happening.

Every operations leader has a backlog of small, painful problems that never reach engineering's roadmap because they're too minor to justify a sprint. A tool that routes a form, reformats a report, or checks a document against a checklist is worth a few hours a week to the people who need it. It will never be worth a quarter of an engineer's time.

AI building tools close that gap. The people closest to the problem build the fix, and they understand the edge cases better than any requirements document would capture. That's speed you can't buy, and a ban gives it up.

The employees are also voting with their feet already. Microsoft's 2024 Work Trend Index, a survey published in May 2024, found that 78% of AI users were bringing their own AI tools to work. If your people are willing to use unapproved tools to answer questions, they will use them to build things too.

What actually goes wrong

The failures are boring and predictable. They look like the problems of any unowned system.

Data exposure. An app built to answer sales questions gets connected to the full customer table because that was the easiest way to make it work. Nobody scoped the access. Anyone with the link can see more than they should.

Insecure code. AI-generated code isn't reliably safe. Veracode's 2025 GenAI Code Security Report, a vendor study published in July 2025, tested more than 100 large language models and found that 45% of code samples failed security tests and introduced OWASP Top 10 vulnerabilities. A professional developer would run scanners and review the output. A citizen builder usually doesn't know to.

Silent errors. The research on spreadsheets is a useful warning for anything business users build. Raymond Panko's paper Spreadsheet Errors: What We Know. What We Think We Can Do summarizes fifteen years of study showing that spreadsheet errors are common and significant, and concludes that only cell-by-cell code inspection had been shown to work as a fix. An app that looks polished is no more likely to be correct than a spreadsheet that looks tidy. Polish just makes people trust it faster. If you're already worried about checking AI output, the verification tax on AI time savings covers the same trap from the productivity side.

Orphaned logic. The builder changes roles or leaves. The app keeps running, quietly encoding a business rule that nobody else knows exists. This is the same pattern described in the undocumented know-how problem, except now the knowledge is hiding inside a running system.

Breach cost. IBM's 2025 Cost of a Data Breach research reported that a high level of shadow AI, meaning workers using unapproved AI tools, added USD 670,000 to the global average breach cost, and that 63% of organizations surveyed had no AI governance policies to manage AI or prevent workers from using shadow AI. That study is about unapproved AI use broadly, not just home-built apps, but the mechanism is the same: systems touching data that nobody is accountable for.

Why bans don't work

The instinct is to write a policy: no employee may build or deploy software without IT approval. It feels responsible. It fails for the same reason most AI policies fail, which the governance gap explains well: the policy doesn't change the conditions that produce the behavior.

The analyst still has the reconciliation problem. IT still can't get to it for two quarters. So the app gets built anyway, but now it's hidden, and the builder won't ask for help when something breaks because asking means admitting they broke the rule.

A ban doesn't reduce the number of apps. It reduces how many you know about.

A light model: visible, scoped, owned

You don't need a review board. You need three properties for every citizen-built app, and a simple way to check for them.

Visible. Someone in the company can list every internal app, who built it, what data it touches, and who uses it. This is the registry. It can be a shared sheet with seven columns and one owner.

Scoped. The app touches only the data it needs, through accounts made for it, not through the builder's personal login. OWASP's Low-Code/No-Code Top 10 project exists because citizen development environments carry their own security risks, and it's worth handing to whoever sets your access rules.

Owned. Every app has a named owner and a named backup. If the owner leaves, the app is reassigned or retired. No app runs without a human who answers for it.

The registry: seven fields

Keep it small enough that people will actually fill it in:

1. App name and one-line purpose
2. Builder and named owner (plus a backup)
3. Data it reads and writes, by sensitivity tier
4. Number of regular users
5. Where it runs and how it's accessed
6. Whether it writes to a system of record
7. Review date

Registration should be easy and rewarded, not feared. A builder who registers an app gets a quick check and, if it's useful, a path to support. A builder who hides one gets the same outcome they would've gotten from a ban. Make the first outcome much better than the second.

The handoff rule: when an app leaves the builder

The core decision isn't whether to allow citizen-built apps. It's when an app has outgrown the person who built it. Two variables answer that for most cases: how sensitive the data is, and how many people depend on the app.

Illustrative thresholds. Adjust the user counts to your company's size and risk appetite.

A few notes on reading the table. "Hand off" doesn't mean "take away." The builder usually stays involved as the product owner, because they understand the problem better than anyone. IT or a platform team takes over hosting, access, monitoring, and maintenance. And when an app crosses a threshold, say it grows from five users to forty, the registry is how you notice.

Customer-facing is its own category. If external people use the app, or it processes their data, treat it as production software from day one.

What this looks like in practice (illustrative)

Take a 150-person services firm. An account manager builds a client-status dashboard that reads from the project tracker. Eight people use it, and it holds no personal data. Under the table above, it stays with her. She registers it, names a backup, and moves on.

Six months later someone connects it to the invoicing system so the dashboard can show payment status. Now it touches financial data and has twenty users. The registry's review date catches the change. The app moves to the platform team, the account manager stays as product owner, and the connection gets rebuilt with a dedicated service account. Total cost: an hour of review and a short handoff meeting.

Compare that with discovering the same app during an audit, running on the account manager's personal credentials, after she's left the company.

What to do next

You can put this in place in a few weeks without buying anything.

1. Name one owner. Usually an operations or IT leader. This person runs the registry and decides when an app hands off. Without a name, nothing here happens.
2. Run an amnesty. Ask teams to list every tool they've built or use that someone in the company built. Promise no penalties for what's found. You'll learn more in a week than a policy would teach you in a year.
3. Publish the table. Adapt the handoff rules to your thresholds and make them a one-page reference that builders can read in two minutes.
4. Offer a safe place to build. Give builders an approved environment, with access to sanctioned data and no personal logins. If there's no safe path, the unsafe one wins. This is the same logic as AI agent security questions for leaders, which lists what to ask of any system that acts on company data.
5. Add a review date to every entry. Quarterly is enough. Retire what nobody uses.
6. Measure it. Track apps registered, hand-offs completed, and hours saved. Tying this to measuring AI ROI beyond time saved keeps the program honest about what the speed is actually worth.

Don't wait for the perfect program before you start. The cost of waiting is more unregistered apps, which is the exact thing you're trying to prevent, and deciding whether to move now or wait for AI to mature is a question your builders have already answered for you.

Also check how this fits with your obligations. If these apps touch regulated data, the rules around AI compliance that survives regulation changes will apply to them as much as to anything IT builds. For the basics of classifying data and vendors, the library guide on AI security and compliance is a good starting reference.

Key Facts

• AI building tools let non-engineers produce working internal apps in hours, with databases, logins, and live data connections that a spreadsheet never had.
• Citizen-built apps fail in predictable ways: broad data access, insecure code, silent logic errors, and no owner when the builder moves on.
• A vendor study found that 45% of AI-generated code samples failed security tests (Veracode, July 2025).
• IBM's 2025 breach research linked a high level of shadow AI to USD 670,000 in added average breach cost (IBM).
• Bans hide apps instead of preventing them. A registry with seven fields and a handoff rule keeps them visible.
• The handoff test: data sensitivity first, user count second. Apps that touch personal, financial, or customer data, or write to a system of record, belong with IT at department scale and above.

Learn More

• The Governance Gap: What Leaders Get Wrong About AI at Work
• AI Agent Security Questions for Leaders
• Measuring AI ROI Beyond 'Time Saved'