Shadow AI: Warum Unternehmen jetzt ihre KI-gebauten Apps inventarisieren müssen

Die aktuelle Diskussion rund um “vibe-coded” Apps klingt auf den ersten Blick wie ein weiteres Sicherheitsdrama aus der KI-Welt. Sicherheitsforscher von RedAccess haben laut Berichten von WIRED und anderen Medien tausende öffentlich erreichbare Apps gefunden, die mit Tools wie Lovable, Replit, Base44 oder ähnlichen Plattformen gebaut wurden und kaum Zugriffsschutz hatten. Auf X wurden daraus schnell die erwartbaren Schlagzeilen: KI-Apps leaken Daten, App-Builder sind gefährlich, Vibe Coding ist ein Sicherheitsproblem.

Das ist nicht komplett falsch. Aber für Unternehmen ist die wichtigere Lektion eine andere.

Das Problem ist nicht nur, dass einzelne KI-gebaute Apps schlecht abgesichert sein können. Das größere Problem ist, dass diese Apps oft gar nicht im offiziellen Systembild des Unternehmens auftauchen.

Ein Produktmanager baut am Wochenende ein kleines Kundenformular. Ein Vertriebsteam lässt sich ein internes Dashboard generieren. Jemand aus Operations verbindet eine Airtable, eine Supabase-Datenbank oder ein CRM mit einer schnell gebauten Weboberfläche. Eine Gründerin baut einen Demo-Prozess, der erst nur für Investoren gedacht war und drei Wochen später echte Kundendaten enthält.

Keiner dieser Schritte fühlt sich wie ein großes IT-Projekt an. Genau deshalb passiert er.

Und genau deshalb braucht jedes Unternehmen, das KI-App-Builder ernsthaft nutzt, jetzt ein Inventar.

Shadow AI ist nicht mehr nur ChatGPT im Browser

Viele Unternehmen denken bei Shadow AI noch an Mitarbeitende, die sensible Texte in ChatGPT kopieren. Das ist relevant, aber es ist nur die erste Phase.

Die neue Phase ist produktiver und riskanter: Mitarbeitende bauen echte Software.

Nicht immer große Software. Nicht immer gute Software. Aber Software, die erreichbar ist, Daten verarbeitet, Entscheidungen unterstützt und manchmal Kunden, Partner oder interne Teams berührt.

Das verändert die Risikolage.

Ein Chat-Verlauf ist ein Datenschutzthema. Eine öffentlich erreichbare App mit Datenbank, Login, Formularen, Exporten und Admin-Funktionen ist ein Architektur- und Betriebsproblem. Sie braucht Eigentümer, Zugriffskontrolle, Protokollierung, Backup-Überlegungen, Datenklassifizierung und einen Plan für den Tag, an dem etwas nicht funktioniert.

Der gefährliche Teil ist nicht, dass Menschen experimentieren. Experimente sind gut. Viele interne Tools entstehen genau aus der Nähe zum Problem. Fachbereiche wissen oft besser als zentrale IT, wo der Prozess wirklich weh tut.

Gefährlich wird es, wenn aus einem Experiment stillschweigend ein Betriebssystem wird.

Gestern war es ein Prototyp. Heute nutzt ihn ein Team. Morgen liegen echte Kundendaten darin. Nächste Woche verlässt sich ein Geschäftsprozess darauf. Niemand hat einen Go-live entschieden. Niemand hat Security gefragt. Niemand hat die App ins Architekturbild aufgenommen.

Das ist Shadow AI als Produktionsoberfläche.

Die erste Frage lautet nicht: Ist die App sicher?

Die erste Frage lautet: Welche Apps gibt es überhaupt?

Viele Sicherheitsdiskussionen springen zu schnell zur Checkliste. Authentifizierung. Rollen. Secrets. Rate Limits. Logs. Alles wichtig. Aber diese Punkte helfen nur bei Systemen, von denen man weiß.

Wenn ein Unternehmen nicht weiß, welche KI-gebauten Apps existieren, kann es sie nicht absichern.

Ein pragmatisches Inventar muss nicht mit einem großen Governance-Programm beginnen. Es kann sehr einfach starten:

• Welche AI-App-Builder werden im Unternehmen genutzt?
• Welche Domains, Preview-URLs und Deployment-Plattformen sind damit verbunden?
• Welche Apps sind öffentlich erreichbar?
• Welche Apps enthalten echte Daten statt Demo-Daten?
• Welche Apps werden von mehr als einer Person genutzt?
• Welche Apps berühren Kunden, Partner, Zahlungen, Verträge oder personenbezogene Daten?
• Wer ist fachlich verantwortlich?
• Wer kann die App abschalten, ändern oder reparieren?

Das ist keine Bürokratie um der Bürokratie willen. Es ist die Mindestvoraussetzung, um Verantwortung übernehmen zu können.

Gerade für deutsche Unternehmen ist dieser Punkt wichtig. Viele Mittelstandsteams haben bereits eine gewachsene Landschaft aus SaaS-Tools, Excel-Workarounds, Datenexporten, Automationen und kleinen internen Anwendungen. KI-App-Builder beschleunigen diese Entwicklung erheblich. Was früher ein halbes Jahr in einer Fachabteilung gären musste, kann heute in zwei Tagen als Web-App online sein.

Das ist produktiv. Aber ohne Inventar wird daraus ein blinder Fleck.

Nicht jede KI-App braucht denselben Prozess

Der Fehler vieler Governance-Ansätze ist, dass sie jedes Tool gleich behandeln.

Eine interne Demo mit künstlichen Daten braucht keinen Konzernfreigabeprozess. Ein öffentlich erreichbares Kundenportal mit personenbezogenen Daten schon. Ein kleines Dashboard für eine einzelne Person ist anders zu bewerten als eine App, die Rechnungsdaten verändert oder Support-Entscheidungen dokumentiert.

Deshalb sollte das Inventar nicht nur eine Liste sein. Es sollte Apps grob klassifizieren.

Eine einfache Einteilung reicht oft:

• Experiment: Nur Demo-Daten, kleine Zielgruppe, keine operative Abhängigkeit.
• Internes Hilfsmittel: Echte interne Nutzung, aber keine sensiblen Daten und kein kritischer Prozess.
• Datenführende App: Verarbeitet Kunden-, Mitarbeiter-, Finanz- oder Vertragsdaten.
• Externe App: Für Kunden, Partner oder Öffentlichkeit erreichbar.
• Betriebskritische App: Ein Geschäftsprozess hängt davon ab.

Diese Kategorien müssen nicht perfekt sein. Sie müssen nur helfen, die richtige Diskussion zu führen.

Für Experimente sollte die Hürde niedrig bleiben. Sonst wandern sie noch stärker in den Schatten. Für datenführende, externe und betriebskritische Apps braucht es dagegen klare Mindestanforderungen: Zugriffsschutz, Eigentümer, Datenmodell, Logging, Backup, Fehlerbehandlung, Dokumentation und einen Review, bevor echte Nutzung beginnt.

Das Ziel ist nicht, KI-App-Builder zu verbieten. Das Ziel ist, den Übergang vom Experiment zum Betrieb sichtbar zu machen.

Der Übergang ist der riskante Moment

Die meisten Probleme entstehen nicht am Anfang.

Am Anfang ist allen klar, dass etwas ein Experiment ist. Die Daten sind erfunden. Die Nutzer sind intern. Niemand erwartet Stabilität. Wenn etwas kaputtgeht, ist es egal.

Dann funktioniert der Prototyp überraschend gut.

Jemand teilt den Link mit einem Kollegen. Ein Kunde sieht eine Demo. Ein Team nutzt das Tool für einen echten Vorgang, weil es schneller ist als der alte Prozess. Eine Integration wird ergänzt. Eine Datenbank wird angebunden. Ein Export wird erzeugt.

Dieser Übergang braucht eine Grenze.

Bei McDougall Digital nennen wir solche Grenzen gerne Produkt- und Architekturentscheidungen, nicht nur technische Checks. Denn es geht nicht nur darum, ob der Code kompiliert. Es geht darum, ob das System eine Verantwortung übernimmt, die vorher nicht existierte.

Ein guter Übergangspunkt ist zum Beispiel:

• Sobald echte personenbezogene Daten verwendet werden.
• Sobald externe Nutzer Zugriff bekommen.
• Sobald die App einen Kundenprozess unterstützt.
• Sobald Entscheidungen dokumentiert oder ausgelöst werden.
• Sobald Daten in ein anderes System geschrieben werden.
• Sobald ein Team sich im Tagesgeschäft darauf verlässt.

Ab dann ist die App kein Spielzeug mehr. Sie muss nicht sofort perfekt sein. Aber sie braucht einen Besitzer, einen Zweck, ein Risikoprofil und einen Plan.

Sicherheit beginnt bei Daten- und Verantwortungsgrenzen

Viele KI-gebaute Apps sehen harmlos aus, weil die Oberfläche klein ist. Ein Formular. Eine Tabelle. Ein Dashboard. Ein Chatbot.

Aber die eigentliche Frage ist: Welche Grenze überschreitet diese App?

Greift sie auf Kundendaten zu? Kann sie Datensätze ändern? Sieht ein Nutzer Daten eines anderen Kunden? Werden interne Dokumente verarbeitet? Gibt es Admin-Funktionen? Werden API-Keys oder Tokens verwendet? Wird ein CRM, ERP, Ticketsystem oder eine Buchhaltung angebunden?

Diese Fragen sind für einen AI-App-Builder schwer zu beantworten, wenn der Mensch sie nicht stellt. Ein Modell kann eine Login-Maske bauen und trotzdem kein belastbares Berechtigungskonzept liefern. Es kann eine Datenbank anbinden und trotzdem Mandantentrennung falsch modellieren. Es kann ein Admin-Dashboard erzeugen und trotzdem keine Audit-Spur hinterlassen.

Darum ist Architektur so wichtig.

Sicherheit entsteht nicht durch ein nachträgliches “Mach das bitte sicherer” im Prompt. Sicherheit entsteht durch klare Grenzen:

• Wer darf welche Daten sehen?
• Wer darf welche Aktionen ausführen?
• Welche Daten dürfen die App verlassen?
• Welche Systeme darf die App verändern?
• Welche Ereignisse müssen protokolliert werden?
• Welche Fehler dürfen nicht stillschweigend passieren?
• Wer trägt Verantwortung, wenn ein Prozess falsch läuft?

Diese Regeln sind Produktwissen. Sie stehen selten vollständig im Code. Sie müssen mit dem Team herausgearbeitet werden.

Was ein leichtgewichtiges Governance-Modell leisten sollte

Ein gutes Modell für KI-Apps muss zwei Dinge gleichzeitig schaffen: Es muss Experimente erlauben und Risiken begrenzen.

Wenn der Prozess zu schwer ist, umgehen Menschen ihn. Wenn er zu leicht ist, landen echte Daten in zufälligen Tools. Die Lösung liegt in klaren, einfachen Schwellen.

Ein pragmatisches Setup kann so aussehen:

1. Erlaubte Experimentierzone: Teams dürfen mit KI-App-Buildern arbeiten, solange sie keine echten personenbezogenen, finanziellen, vertraglichen oder kundenspezifischen Daten verwenden.
2. Registrierung vor echter Nutzung: Sobald eine App echte Daten, externe Nutzer oder operative Prozesse berührt, wird sie in ein einfaches Inventar eingetragen.
3. Pflichtfelder: Zweck, Eigentümer, Tool, URL, Datenarten, Nutzergruppe, Integrationen, Kritikalität und Abschaltmöglichkeit.
4. Review nach Risiko: Kleine interne Hilfsmittel bekommen einen schnellen Check. Datenführende oder externe Apps bekommen eine technische und fachliche Prüfung.
5. Produktionsanforderungen: Authentifizierung, Autorisierung, Secrets, Logging, Backup, Fehlerbehandlung, Datenschutz und Supportzuständigkeit.
6. Regelmäßige Aufräumrunde: Prototypen werden archiviert, gehärtet oder bewusst abgeschaltet.

Das klingt banal. Genau deshalb funktioniert es.

Viele Unternehmen brauchen kein großes AI-Governance-Board für jede kleine Idee. Sie brauchen Sichtbarkeit, Schwellen und eine klare Verantwortungskette.

Warum Verbote selten funktionieren

Der Reflex nach solchen Sicherheitsberichten ist oft: Dann verbieten wir diese Tools eben.

Manchmal ist das für bestimmte Daten oder Branchen richtig. Aber als allgemeine Strategie ist es schwach. Menschen nutzen solche Werkzeuge, weil sie echte Probleme lösen: langsame interne Prozesse, fehlende Entwicklerkapazität, schlechte SaaS-Anpassbarkeit, manuelle Exporte, fragile Excel-Abläufe.

Ein Verbot beseitigt diese Probleme nicht. Es macht sie nur unsichtbarer.

Für Gründer, CTOs und Produktverantwortliche ist die bessere Frage:

Wie können wir die nützliche Energie dieser Tools nutzen, ohne die Kontrolle über Daten, Architektur und Betrieb zu verlieren?

Die Antwort ist selten ein einzelnes Tool. Sie ist ein Betriebsmodell.

Welche Arten von Apps dürfen Teams selbst bauen? Wann muss Engineering helfen? Wann braucht es Security? Wann wird aus einem Prototyp ein internes Produkt? Welche Daten dürfen niemals in eine Experimentierumgebung? Welche Plattformen sind akzeptabel? Wie werden erfolgreiche Prototypen in eine stabile Architektur überführt?

Das ist nicht nur Compliance. Es ist Produktführung.

Die Chance: bessere interne Software

Die positive Seite sollte nicht untergehen.

Viele Unternehmen haben einen enormen Bedarf an besseren internen Tools. Mitarbeitende arbeiten mit Workarounds, weil die offiziellen Systeme nicht zum Prozess passen. Daten werden exportiert, transformiert, wieder importiert. Entscheidungen hängen an Tabellen, die niemand besitzt. Kundenprozesse werden durch manuelle Zwischenschritte gebremst.

KI-App-Builder machen diese Lücken sichtbar. Wenn ein Fachteam innerhalb eines Tages ein Tool baut, das einen echten Schmerzpunkt löst, ist das ein Signal. Vielleicht sollte daraus kein wildes Schattenprodukt werden. Aber vielleicht zeigt es sehr klar, wo das Unternehmen bessere Software braucht.

Ein gutes Inventar ist deshalb nicht nur defensiv. Es ist auch eine Produkt-Roadmap.

Welche selbstgebauten Apps werden wirklich genutzt? Welche lösen ein echtes Problem? Welche sollten gehärtet, neu gebaut oder in bestehende Systeme integriert werden? Welche zeigen, dass ein SaaS-Tool falsch konfiguriert oder ein interner Prozess unnötig kompliziert ist?

So wird Shadow AI von einem Risiko zu einer Quelle für Produkt- und Prozesswissen.

Wie McDougall Digital helfen kann

Für McDougall Digital ist diese Entwicklung ein sehr praktisches Architekturthema.

Wir helfen Unternehmen nicht dabei, KI-Hype in noch mehr unkontrollierte Tools zu verwandeln. Wir helfen dabei, nützliche KI-Entwicklung in belastbare Software- und Betriebsstrukturen zu bringen.

Konkret kann das heißen:

• bestehende KI-gebaute Apps und interne Tools inventarisieren;
• Datenflüsse, Zugriffe und Integrationen sichtbar machen;
• Risiken nach Geschäftswirkung priorisieren;
• Prototypen vor echter Nutzung prüfen;
• sinnvolle Apps härten und in eine saubere Architektur überführen;
• leichtgewichtige Regeln für KI-gestützte Entwicklung etablieren;
• interne Software so bauen, dass sie wartbar, sicher und betreibbar bleibt.

Der Punkt ist nicht, jedes Experiment zu verlangsamen. Der Punkt ist, die Grenze zwischen Experiment und Betrieb ernst zu nehmen.

KI macht Software schneller sichtbar. Unternehmen brauchen deshalb schneller Klarheit darüber, welche Software sie tatsächlich betreiben.

Wer das Inventar beherrscht, kann KI-App-Builder produktiv nutzen. Wer es ignoriert, wird irgendwann von den eigenen Prototypen überrascht.