Shadow IT durch KI: Risiken, Governance und wie man von Abteilungen erstellte Apps reguliert

Wenn Fachabteilungen KI-Apps ohne IT-Beteiligung erstellen

KI hat die Art und Weise verändert, wie Schatten-IT entsteht. Früher kaufte eine Abteilung eine SaaS-Lösung, ohne die IT zu informieren. Heute kann sie in wenigen Tagen eine kleine App, einen Workflow, ein Dashboard oder ein internes Tool erstellen, es mit Tabellen, CRM, E-Mails, Tickets, Dokumenten oder Datenbanken verknüpfen und es nutzen, als wäre es ein offizielles Unternehmenssystem.

Das Problem ist nicht, dass die Fachabteilungen ihre Probleme lösen wollen: Das Problem ist, dass eine nützliche Lösung unsichtbar werden kann. Kein Inventar, kein technischer Verantwortlicher, keine geregelten Zugriffe, Daten außerhalb des Perimeters, persönliche API-Keys, öffentliche Links, fehlende Aufbewahrungsfristen und kein Plan, falls etwas ausfällt.

Für CIOs, CISOs, IT-Manager und Fachbereichsleiter lautet die konkrete Frage: Welche mit KI erstellten Apps existieren bereits, welche Daten verarbeiten sie und welche müssen reguliert werden, bevor sie kritisch werden?

Warum KI die Verbreitung von Schatten-IT beschleunigt

KI-App-Builder und “Vibe-Coding”-Tools senken die technische Hürde erheblich. Ein Marketing-Team kann ein Tool zur Segmentierung von Leads erstellen, die Finanzabteilung kann Abstimmungen automatisieren, die Personalabteilung kann ein Formular mit Genehmigungsworkflow bauen und der Betrieb kann Tabellen, E-Mails und Tickets in wenigen Tagen verknüpfen. Viele dieser Initiativen entstehen aus legitimen Gründen: langer IT-Backlog, operative Dringlichkeit, begrenztes Budget, Bedarf an schnellem Prototyping.

Der kritische Punkt ist: Sobald die App echte Daten, Benutzer, Integrationen oder operative Entscheidungen verarbeitet, ist sie kein Experiment mehr. Im Gegensatz zur traditionellen Schatten-IT ist die App maßgeschneidert und nicht als fertiges Produkt gekauft: Das macht es schwieriger, sie zu erfassen, und macht es umso wichtiger zu verstehen, wie sie aufgebaut ist – einschließlich Code, Konfigurationen, Speicher, Workflows, APIs, Anmeldedaten, Domänen, Protokollen und Daten.

Die erste Kontrolle: Existiert die App im Inventar?

Der erste Schritt besteht darin, zu wissen, dass die App existiert. Wenn die IT sie nicht sieht, kann sie kein SSO, Backup, Logging, Schwachstellenmanagement, Datenrichtlinien, Incident Response oder Stilllegung anwenden. Ein nützliches Inventar muss mindestens diese Elemente enthalten:

Name der App und verantwortliche Abteilung
Operativer Zweck
Verwendetes Tool zur Erstellung
Interne oder externe Benutzer
Verarbeitete Daten
Integrationen und APIs
URLs, Domänen, Vorschau- und Umgebungslinks
Verwendete Anmeldedaten und Konten
Kritikalität für den Geschäftsprozess

Man muss nicht mit einer perfekten Bestandsaufnahme beginnen. Es braucht einen wiederholbaren Prozess: Umfragen in den Abteilungen, Discovery von Domänen und SaaS, Überprüfung von OAuth-Apps, Kontrolle der Repositories, Analyse der Cloud-Kosten und einen einfachen Kanal, um bestehende Apps zu melden, ohne Angst vor einer sofortigen Sperrung haben zu müssen.

Daten klassifizieren und Auswirkungen bewerten

Nicht alle Schatten-IT-Apps stellen das gleiche Risiko dar. Ein Tool, das öffentliche Texte neu formatiert, unterscheidet sich stark von einem Dashboard mit Kundendaten, Rechnungen, Tickets, Personaldaten oder Gesundheitsinformationen. Die Klassifizierung muss einige wesentliche Fragen beantworten:

Werden personenbezogene Daten oder Kundendaten verarbeitet?
Enthält sie vertrauliche, kommerzielle, finanzielle, HR- oder Vertragsdaten?
Liest oder schreibt sie in Unternehmenssysteme?
Sendet sie Daten an externe Anbieter oder KI-Modelle?
Trifft sie operative Entscheidungen oder erstellt sie nur Berichte?
Wird sie von mehreren Personen, Abteilungen oder externen Parteien genutzt?
Was passiert, wenn sie ausfällt, Daten verliert oder Informationen offenlegt?

Die Antworten bestimmen den Weg: Tolerieren mit minimalen Kontrollen, regulieren, testen, auf eine genehmigte Plattform migrieren oder stilllegen.

Zugriffe: Geteilte Links, persönliche Konten und fehlende Rollen

Viele in Fachabteilungen entstandene Apps beginnen mit einfachen Zugriffen – geteilter Link, gemeinsames Passwort, persönliches Konto, manuelle E-Mail-Liste, “Editor”-Berechtigungen für alle. Solange die Nutzung eingeschränkt ist, scheint es zu funktionieren, aber wenn ein neues Team, ein Berater oder ein externer Benutzer hinzukommt, bricht das Modell zusammen. Die minimalen Kontrollen, die angewendet werden müssen, sind:

Personenbezogene Konten
SSO und MFA, wo möglich
Entfernung von geteilten Konten
Widerruf der Zugriffe, wenn eine Person die Rolle wechselt oder das Unternehmen verlässt
Rollen, die mit Lesen, Bearbeiten, Exportieren und Administration übereinstimmen
Protokollierung von Zugriffen und kritischen Aktionen

Bei Apps mit Kundendaten oder abteilungsübergreifender Nutzung ist es sinnvoll, auch den direkten Zugriff zu testen: Kann ein Benutzer ID, URL, Filter, Workspace oder Parameter ändern und Daten sehen, die ihm nicht gehören?

Integrationen und API-Keys: Das versteckte Risiko

Um nützlich zu sein, verbindet sich eine Schatten-IT-App oft mit etwas: Google Workspace, Microsoft 365, CRM, Ticketing, E-Mail, Speicher, ERP, Datenbanken, Slack, Webhooks oder Zahlungsdienste. Die Verbindung erfolgt typischerweise über persönliche Token, kopierte API-Keys, nicht genehmigte OAuth-Apps oder Dienstkonten mit übermäßigen Berechtigungen. Dies ist einer der kritischsten Punkte: Eine kleine App kann weitreichenden Zugriff auf Unternehmensdaten haben, und wenn sie kompromittiert wird, bleibt der Schaden nicht auf die App selbst beschränkt.

Die praktischen Kontrollen umfassen:

Inventar von Token, OAuth-Apps, Dienstkonten und Webhooks
Minimale Scopes für jede Integration
Unternehmens-Anmeldedaten, keine persönlichen
Regelmäßige Rotation der Schlüssel
Segmentierung nach Umgebung
Audit-Logs für die sensibelsten Aufrufe
Widerruf von nicht mehr genutzten Integrationen

Öffentliche Exposition, Vorschauen und temporäre Domänen

App-Builder machen es einfach, eine Vorschau oder eine temporäre Domäne zu veröffentlichen. Die Fachabteilung kann sie mit Kollegen, Partnern oder Kunden teilen, ohne dies als Exposition im Internet wahrzunehmen. Die zu kontrollierenden Elemente sind:

Öffentliche URLs und noch aktive Vorschauen
Benutzerdefinierte Domänen und temporäre Subdomänen
Indizierung durch Suchmaschinen
Webhooks, die ohne Authentifizierung erreichbar sind
Admin- oder Debug-Endpunkte
Öffentlicher Speicher
Zu weit gefasste CORS- und Callback-Einstellungen

Wenn die App online erreichbar ist und Logins, APIs, echte Daten oder Rollen verwaltet, reicht das Inventar nicht aus: Es ist ein technischer Test erforderlich. In diesen Fällen überprüft das Web Application Penetration Testing das tatsächliche Verhalten der Anwendung, nicht nur die deklarierte Konfiguration.

Protokolle, Exporte, Aufbewahrung und Löschung

Von Fachabteilungen erstellte Apps drehen sich oft um Exporte und Tabellen: CSV aus dem CRM, Finanzberichte, Kundenlisten, Tickets, Anhänge, hochgeladene Dateien. Das Risiko ist nicht nur der unbefugte Zugriff, sondern die unkontrollierte Ansammlung sensibler Daten. Es ist notwendig zu wissen, wo Protokolle und Ausgaben gespeichert werden, wer Daten exportieren kann, wie lange Dateien und Transkripte aufbewahrt werden, ob Backups existieren, wie Daten gelöscht werden und was passiert, wenn das Projekt aufgegeben wird.

Eine App, die nicht mehr genutzt wird, aber noch mit Unternehmensdaten verbunden ist, ist ein stilles Risiko: Sie hat weiterhin aktive Anmeldedaten, Links und Speicher, erhält aber keine operative Aufmerksamkeit mehr.

Regulieren, ohne den Wert zu blockieren

Wenn die IT nur kommt, um zu verbieten, versteckt sich die Schatten-IT. Ein effektiver Weg muss klassifizieren und regulieren und für jede App eine klare Entscheidung treffen: beibehalten, korrigieren, migrieren, testen oder abschalten. Es reicht nicht, sie “irgendwann in Ordnung zu bringen”.

Klasse	Beispiel	Aktion
Geringes Risiko	Tool ohne echte Daten, individuelle Nutzung	Besitzer und Ablaufdatum registrieren
Mittleres Risiko	Internes Dashboard mit nicht-kritischen Daten	SSO, Zugriffe, Aufbewahrung, Backup
Hohes Risiko	App mit Kundendaten, APIs oder operativem Workflow	Risikobewertung, technische Überprüfung, Test
Kritisch	Öffentliche App, Mehrbenutzer, sensible Daten	WAPT/VA, Sanierung vor ausgedehnter Nutzung
Nicht akzeptabel	Geteilte Anmeldedaten, verbotene Daten, nicht genehmigter Anbieter	Stilllegung oder Migration

Checkliste für mit KI erstellte Schatten-IT-Apps

Ist die App in einem IT-/Sicherheitsinventar erfasst?
Gibt es einen fachlichen und einen technischen Verantwortlichen?
Welche Daten verarbeitet sie und aus welchen Systemen stammen sie?
Verwendet sie personenbezogene, Kunden-, HR-, Finanz- oder Vertragsdaten?
Ist sie aus dem Internet, von Partnern oder nur aus dem internen Netzwerk erreichbar?
Verwendet sie SSO/MFA oder geteilte Konten?
Welche API-Keys, OAuth-Apps, Webhooks oder Integrationen nutzt sie?
Welche Rollen existieren und wer kann Daten exportieren?
Wo landen Protokolle, Dateien, Exporte, Backups und Transkripte?
Existieren Vorschauen, temporäre Domänen oder alte Versionen, die noch aktiv sind?
Wurde mindestens ein Zugriffstest mit verschiedenen Benutzern durchgeführt?
Ist klar, was zu tun ist, wenn die App kompromittiert wird oder stillgelegt werden muss?

Wann ISGroup einbeziehen

Der Ausgangspunkt kann eine leichte Bewertung sein: Inventar, Daten, Exposition, Eigentümer, Integrationen und Risiko. Die anschließende Kontrolle hängt davon ab, was zum Vorschein kommt.

Szenario	Hauptrisiko	Empfohlene Kontrolle
Viele nicht erfasste Apps aus Fachabteilungen	Schwache Governance und fehlende Eigentümerschaft	Virtual CISO
Daten, Auswirkungen und Prioritäten müssen klassifiziert werden	Risiko nicht verstanden oder nicht priorisiert	Risikobewertung
Exponierte Apps, Hosts, Domänen, Vorschauen oder Dienste	Bekannte Schwachstellen und offene Konfigurationen	Schwachstellenbewertung
Web-Apps oder APIs mit Login, Daten, Rollen oder echten Benutzern	Anwendungsmissbrauch von außen	Web Application Penetration Testing

Die Wahl besteht nicht darin, “Sicherheit für alles” zu machen. Es geht darum, zu entscheiden, welche Apps tolerierbar sind, welche reguliert werden müssen, welche einen technischen Test erfordern und welche abgeschaltet werden müssen – bevor sie zu einem operativen oder regulatorischen Problem werden.

Nützliche Nachweise für eine Überprüfung

Um eine strukturierte Überprüfung zu starten, ist es hilfreich, Folgendes zu sammeln: Liste der Apps, Eigentümer, URLs, verwendete Tools, verarbeitete Daten, Benutzer, Rollen, Integrationen, API-Keys, OAuth-Apps, beteiligte Anbieter, Protokolle, Exporte, Backups, Domänen, Vorschauen, Umgebungen und Prozesskritikalität. Ebenfalls nützlich sind konkrete Beispiele wie Screenshots, Exporte, Workflows, Datenschemata, Zugriffskonfigurationen, Liste der Konnektoren, Benutzerliste und eine Beschreibung, was passiert, wenn die App nicht verfügbar ist.

Häufig gestellte Fragen

Muss durch KI generierte Schatten-IT immer blockiert werden?
Nein. Sie muss entdeckt und klassifiziert werden. Einige Apps können mit minimalen Kontrollen operativ bleiben, andere müssen je nach Risiko reguliert, getestet, migriert oder stillgelegt werden.
Was ist die erste Kontrolle, die durchgeführt werden muss?
Das Inventar. Ohne zu wissen, welche Apps existieren, welche Daten sie verarbeiten und wer sie nutzt, kommt jede technische Kontrolle zu spät und ohne Kontext.
Wann ist ein Web Application Penetration Test erforderlich?
Wenn die App online erreichbar ist, APIs offenlegt, Logins, echte Daten, Rollen, Uploads, Zahlungen oder von mehreren Benutzern genutzte Workflows verwaltet.
Wann reicht eine Risikobewertung aus?
Wenn das Hauptproblem darin besteht, Prioritäten, Eigentümer, verarbeitete Daten, geschäftliche Auswirkungen und den Regulierungspfad zu bestimmen, bevor technische Tests gestartet werden.
Wer muss für die App verantwortlich sein?
Es braucht mindestens einen fachlichen Eigentümer für Prozess und Daten sowie einen IT-/Sicherheitsverantwortlichen für Zugriffe, Kontrollen, Integrationen und den Regulierungspfad.

[Callforaction-RA-Footer]

ISGroup Cybersicherheitsberatung