Shadow AI: why companies need an inventory of AI-built apps

The current discussion around “vibe-coded” apps sounds, at first, like another AI security drama. According to reporting by WIRED and others, researchers at RedAccess found thousands of publicly reachable apps built with tools such as Lovable, Replit, Base44 and similar platforms that had little or no access protection. On X, the story quickly became the expected set of headlines: AI apps leak data, app builders are dangerous, vibe coding is a security problem.

That is not entirely wrong. But for companies, the more important lesson is slightly different.

The problem is not only that individual AI-built apps can be poorly secured. The bigger problem is that many of these apps never appear in the company’s official view of its systems.

A product manager builds a small customer form over the weekend. A sales team generates an internal dashboard. Someone in operations connects Airtable, Supabase or a CRM to a quick web interface. A founder builds a demo process for investors, and three weeks later it contains real customer data.

None of these steps feels like a major IT project. That is why they happen.

And that is why every company that seriously uses AI app builders now needs an inventory.

Shadow AI is no longer just ChatGPT in the browser

Many companies still think of shadow AI as employees pasting sensitive text into ChatGPT. That matters, but it is only the first phase.

The new phase is more productive and more dangerous: employees are building real software.

Not always large software. Not always good software. But software that is reachable, processes data, supports decisions and sometimes touches customers, partners or internal teams.

That changes the risk profile.

A chat transcript is a data protection concern. A publicly reachable app with a database, login, forms, exports and admin functions is an architecture and operations concern. It needs ownership, access control, logging, backup thinking, data classification and a plan for the day something breaks.

The dangerous part is not that people experiment. Experimentation is healthy. Many internal tools come from people who are close to the problem. Business teams often understand the painful workflow better than central IT does.

The danger begins when an experiment quietly becomes an operating system.

Yesterday it was a prototype. Today a team uses it. Tomorrow it contains real customer data. Next week a business process depends on it. Nobody made a go-live decision. Nobody asked security. Nobody added the app to the architecture map.

That is shadow AI as a production surface.

The first question is not: is the app secure?

The first question is: which apps exist?

Security conversations often jump too quickly to the checklist. Authentication. Roles. Secrets. Rate limits. Logs. All of that matters. But those controls only help for systems you know about.

If a company does not know which AI-built apps exist, it cannot secure them.

A pragmatic inventory does not need to begin as a large governance programme. It can start very simply:

Which AI app builders are used in the company?
Which domains, preview URLs and deployment platforms are connected to them?
Which apps are publicly reachable?
Which apps contain real data rather than demo data?
Which apps are used by more than one person?
Which apps touch customers, partners, payments, contracts or personal data?
Who owns the business process?
Who can shut the app down, change it or repair it?

This is not bureaucracy for its own sake. It is the minimum requirement for responsibility.

For German and European companies, this matters especially. Many mid-sized teams already have a landscape of SaaS tools, spreadsheet workarounds, data exports, automations and small internal applications. AI app builders accelerate that pattern dramatically. What used to take months of quiet pressure inside a department can now become a web app in two days.

That is productive. But without an inventory, it becomes a blind spot.

Not every AI app needs the same process

The mistake in many governance models is that they treat every tool the same way.

An internal demo with fake data does not need a corporate approval process. A public customer portal with personal data does. A small dashboard for one person is different from an app that changes invoicing data or records support decisions.

So the inventory should not be only a list. It should classify apps roughly.

A simple model is often enough:

Experiment: Demo data only, small audience, no operational dependency.
Internal helper: Real internal use, but no sensitive data and no critical process.
Data-bearing app: Handles customer, employee, financial or contract data.
External app: Reachable by customers, partners or the public.
Business-critical app: A business process depends on it.

These categories do not need to be perfect. They only need to create the right conversation.

For experiments, friction should stay low. Otherwise they will move further into the shadows. For data-bearing, external and business-critical apps, the minimum bar needs to be clear: access protection, ownership, data model, logging, backups, error handling, documentation and a review before real usage begins.

The goal is not to ban AI app builders. The goal is to make the transition from experiment to operation visible.

The transition is the risky moment

Most problems do not begin at the start.

At the start, everyone knows something is an experiment. The data is fake. The users are internal. Nobody expects stability. If it breaks, it does not matter.

Then the prototype works surprisingly well.

Someone shares the link with a colleague. A customer sees a demo. A team uses the tool for a real process because it is faster than the old workflow. An integration is added. A database is connected. An export is generated.

That transition needs a boundary.

At McDougall Digital, we treat those boundaries as product and architecture decisions, not just technical checks. The question is not only whether the code runs. The question is whether the system has taken on a responsibility that did not exist before.

Good boundary triggers include:

real personal data is used;
external users get access;
the app supports a customer process;
decisions are recorded or triggered;
data is written into another system;
a team relies on the app in daily operations.

From that point on, the app is no longer a toy. It does not need to be perfect immediately. But it needs an owner, a purpose, a risk profile and a plan.

Security starts with data and responsibility boundaries

Many AI-built apps look harmless because the interface is small. A form. A table. A dashboard. A chatbot.

The real question is: which boundary does this app cross?

Does it access customer data? Can it change records? Can one user see another customer’s data? Does it process internal documents? Are there admin functions? Are API keys or tokens involved? Does it connect to a CRM, ERP, ticketing system or accounting tool?

Those questions are hard for an AI app builder to answer if the human does not ask them. A model can build a login screen and still fail to provide a real authorization model. It can connect a database and still model tenant isolation incorrectly. It can generate an admin dashboard and still leave no audit trail.

That is why architecture matters.

Security does not come from adding “please make this secure” to a prompt after the fact. Security comes from clear boundaries:

Who may see which data?
Who may perform which actions?
Which data may leave the app?
Which systems may the app change?
Which events must be logged?
Which failures must not happen silently?
Who is responsible if a process goes wrong?

These are product rules. They rarely live completely in the code. They need to be drawn out with the team.

What lightweight governance should do

A good model for AI-built apps has to do two things at once: allow experimentation and limit risk.

If the process is too heavy, people route around it. If it is too light, real data ends up in random tools. The answer is clear, simple thresholds.

A pragmatic setup can look like this:

Allowed experimentation zone: Teams may use AI app builders as long as they do not use real personal, financial, contractual or customer-specific data.
Registration before real usage: Once an app touches real data, external users or operational processes, it goes into a simple inventory.
Required fields: Purpose, owner, tool, URL, data types, user group, integrations, criticality and shutdown path.
Risk-based review: Small internal helpers get a quick check. Data-bearing or external apps get a technical and business review.
Production requirements: Authentication, authorization, secrets, logging, backups, error handling, privacy and support ownership.
Regular cleanup: Prototypes are archived, hardened or deliberately shut down.

This sounds basic. That is why it works.

Many companies do not need a large AI governance board for every small idea. They need visibility, thresholds and a clear ownership chain.

Why bans rarely work

The reflex after security stories like this is often: then we ban these tools.

Sometimes that is right for specific data or regulated contexts. But as a general strategy, it is weak. People use these tools because they solve real problems: slow internal processes, limited developer capacity, SaaS products that cannot be adapted easily, manual exports, fragile spreadsheet workflows.

A ban does not remove those problems. It only makes the work less visible.

For founders, CTOs and product owners, the better question is:

How do we use the useful energy of these tools without losing control of data, architecture and operations?

The answer is rarely a single tool. It is an operating model.

Which kinds of apps may teams build themselves? When does engineering need to help? When does security need to review? When does a prototype become an internal product? Which data may never enter an experiment? Which platforms are acceptable? How are successful prototypes moved into stable architecture?

This is not only compliance. It is product leadership.

The opportunity: better internal software

The positive side should not get lost.

Many companies have a deep need for better internal tools. Employees work around official systems because those systems do not fit the real process. Data is exported, transformed and imported again. Decisions depend on spreadsheets nobody owns. Customer workflows are slowed down by manual steps.

AI app builders make those gaps visible. If a business team can build a tool in a day that solves a real pain, that is a signal. It may not deserve to become an uncontrolled shadow product. But it may show exactly where the company needs better software.

A good inventory is therefore not only defensive. It is also a product roadmap.

Which self-built apps are actually used? Which solve a real problem? Which should be hardened, rebuilt or integrated into existing systems? Which reveal that a SaaS product is misconfigured or that an internal process is unnecessarily complicated?

Handled well, shadow AI becomes a source of product and process intelligence.

How McDougall Digital can help

For McDougall Digital, this is a practical architecture topic.

We do not help companies turn AI hype into more uncontrolled tools. We help turn useful AI-supported development into reliable software and operating structures.

In practice, that can mean:

inventorying existing AI-built apps and internal tools;
mapping data flows, access paths and integrations;
prioritising risks by business impact;
reviewing prototypes before real usage begins;
hardening useful apps and moving them into clean architecture;
creating lightweight rules for AI-supported development;
building internal software that remains maintainable, secure and operable.

The point is not to slow every experiment. The point is to take the boundary between experiment and operation seriously.

AI makes software visible faster. Companies therefore need faster clarity about which software they are actually operating.

The teams that master the inventory can use AI app builders productively. The teams that ignore it will eventually be surprised by their own prototypes.