Fragt man einen IT-Sicherheitsverantwortlichen, wie viele KI-Tools aktuell auf Unternehmensdaten zugreifen, erhält man eine verlässliche Zahl. Diese wird jedoch falsch sein, und zwar nicht, weil etwas verheimlicht wird. Die meisten im Verborgenen eingesetzten KI-Tools hinterlassen keine Spuren: keine Installation, keine Lizenz, keine Positionsbuchung. Ein Browsertab und ein persönliches Konto genügen. login Das ist ausreichend. Die Diskrepanz zwischen der von Ihrer Richtlinie abgedeckten KI und der tatsächlich in Ihrem Unternehmen eingesetzten KI ist die Hauptursache für das Risiko von Schatten-KI. Dieses hat sich von einer Randnotiz der IT zu einem der dynamischsten Themen im Bereich Anwendungssicherheit entwickelt. Dieser Leitfaden beschreibt, wie Schatten-KI in der Praxis erkannt und eliminiert werden kann, und erläutert die Erkennungssignale sowie die Governance-Maßnahmen, die auch nach Abschluss des Audits Bestand haben.
Die Risiken von Schatten-KI in einem Absatz
Unter Schatten-KI versteht man alle KI-Tools, -Modelle, -Agenten oder API-Aufrufe, die innerhalb Ihrer Organisation ohne Sicherheits- oder IT-Prüfung operieren. Es ist der direkte Nachfolger von Schatten-IT, aber schwerer aufzudecken: Schatten-IT hinterließ üblicherweise Beschaffungsnachweise oder Netzwerksignaturen, die ein CASB abgleichen konnte. Schatten-KI hinterlässt oft keines von beidem. Ein Mitarbeiter fügt einen Vertrag in einen Chatbot ein, der mit einem privaten Konto angemeldet ist, oder ein Entwickler integriert einen API-Schlüssel eines Modellanbieters direkt in ein Skript – und all dies geschieht ohne Zugriff auf den Bestand eines Anbieters. Zwei unabhängig voneinander veröffentlichte Zahlen verdeutlichen das bereits bestehende Risiko durch Schatten-KI: Laut dem Bericht „State of Shadow AI 2026“ von Unseen Security nutzen 80 % der Mitarbeiter KI-Tools, die von ihrem Unternehmen nicht genehmigt wurden, und 86 % der Unternehmen geben an, keinen Einblick in die tatsächlichen Datenflüsse zu und von den bereits eingesetzten KI-Tools zu haben.
Warum das Risiko von Schatten-KI das Risiko von Schatten-IT überstieg
Drei Entwicklungen erklären, warum sich das Risiko von Schatten-KI schneller ausbreitete als die zur Bekämpfung von Schatten-IT geschaffenen Governance-Strukturen, und keine dieser Entwicklungen ist umkehrbar.
- KI benötigt keine Installation mehr. Die Werkzeuge, die Schatten-IT definierten (nicht genehmigte SaaS-Dienste, unerlaubte Browsererweiterungen), hinterließen Spuren in einem Anlageninventar. Ein KI-Assistent, der in einem Browsertab geöffnet wird, oder eine Modell-API, die mit einer persönlichen Karte aufgerufen wird, hinterlässt keine Spuren, die von der Endpunktüberwachung oder der Beschaffung erkannt werden könnten.
- Die KI wurde in die von Ihnen bereits freigegebenen Tools integriert. Funktionen im Copilot-Stil sind nun in bereits zugelassenen Plattformen integriert. Die Plattform wurde überprüft. Die KI-Funktion wurde im Hintergrund aktiviert, war aber normalerweise nicht aktiv.
- Das Volumen verlagerte sich von einer vom Menschen ausgelösten zu einer maschinengesteuerten Dimension. Das ThreatLabz-Team von Zscaler analysierte 536.5 Milliarden Transaktionen im Bereich KI und maschinelles Lernen. in seiner Cloud und verzeichnete einen Anstieg von 3,464.6 % im Vergleich zum Vorjahr. enterprise KI/ML-Datenverkehr. Genau dieses Ausmaß an Veränderungen ist der Grund, warum eine vor einem Jahr durchgeführte Schatten-KI-Risikobewertung bereits veraltet ist und warum punktuelle Prüfungen angesichts eines sich monatlich verschärfenden Problems immer wieder scheitern.
Wo sich Schatten-KI tatsächlich versteckt
Sicherheitsteams, die mit Hilfe von Schatten-IT-Tools nach Risiken durch Schatten-KI suchen, erhalten in der Regel eine unvollständige Liste, da die Verstecke unterschiedlich sind:
- Browserbasierte Tools ohne Endpunkt-Fußabdruck. Die KI läuft vollständig in einem Tab. Kein Agent muss erkannt, nichts installiert werden.
- KI-Funktionen, die in genehmigte Plattformen integriert sind. Die Plattform wurde geprüft. Die später darin integrierte KI-Funktion wurde in der Regel nicht geprüft.
- Privat abgerechnete API-Nutzung. Ein Entwickler platziert eine Modell-API auf einer persönlichen Karte und ruft sie direkt aus dem Code auf. Da sie nie die Beschaffungsabteilung erreicht, gelangt sie auch nie in den Lagerbestand.
- Ungeprüfte Agentenanweisungen und Qualifikationsprofile. Agentenbasierte Codierungswerkzeuge folgen zunehmend Anweisungen, die direkt in ein Repository geschrieben werden (Fähigkeitsdateien, Agentenregeln), und diese Dateien können einen Agenten mit einem Modell, einem Datensatz oder einem MCP-Server verbinden, für den niemand seine Zustimmung erteilt hat.
Wie man Schatten-KI erkennt und eliminiert
Zu wissen, wie man Schatten-KI erkennt und beseitigt, bedeutet, sie als zwei separate Probleme zu behandeln, die gleichzeitig angegangen werden müssen: herauszufinden, was bereits vorhanden ist, und sicherzustellen, dass es nicht unkontrolliert wieder auftaucht.
Erkennen Sie es: drei Signale, die zusammenarbeiten
Kein einzelner Scan kann alle Risiken durch Schatten-KI aufdecken, da jeder der oben genannten Verstecke eine andere Spur hinterlässt.
- Netzwerk- und Proxy-Protokolle. Ihre Firewall, Ihr Proxy und Ihre DNS-Protokolle erfassen bereits ausgehende Aufrufe an Endpunkte von KI-Anbietern, unabhängig davon, ob das Tool genehmigt wurde oder nicht. Häufige API-Aufrufe von einem einzelnen Host, große ausgehende Datenmengen oder automatisierter Datenverkehr außerhalb der Geschäftszeiten zu einem Modellendpunkt sind Muster, die es wert sind, genauer untersucht zu werden.
- Identitäts- und Zugriffssignale. Netzwerkprotokolle zeigen an, dass ein Tool verwendet wird; Ihr Identitätsanbieter verrät Ihnen, wer dahintersteckt und welche Zugriffsrechte gewährt wurden. Achten Sie auf OAuth-Berechtigungen für nicht geprüfte KI-Anwendungen, Anmeldungen bei KI-Tools mit privaten statt geschäftlichen Konten und unerklärliche API-Aktivitäten von Dienstkonten.
- Ermittlung von Assets und Code auf Ebene der Codebasis. Dies ist die Schicht standard Die Schwächen der Schatten-IT-Tools liegen darin, wie KI in Software dargestellt wird: Modelle, Datensätze, Inferenzendpunkte, Agenten, MCP-Server und KI-Codierungswerkzeuge, die direkt in Repositories referenziert werden. pipelines und Skill-Dateien, nicht nur im Browserverkehr. Ohne diese Ebene können Sie sehen zur Abwicklung, Integrierung, Speicherung und Es wurde eine Modell-API aufgerufen; Sie können nicht sehen welche Der Agent hat es angerufen, von welche pipelineoder womit es verbunden ist, nämlich genau dort Das Risiko durch Schatten-KI führt zu einem Lieferkettenvorfall eher als ein Verstoß gegen die Richtlinien.
Beseitigen Sie es: Vier Schritte, die es dauerhaft machen
Die Erkennung zeigt Ihnen, was bereits aktiv ist. Um daraus etwas Dauerhaftes zu machen, sind vier Schritte nötig, die als Schleife und nicht als einmalige Prüfung durchgeführt werden sollten, da sich das Risiko von Schatten-KI schneller ändert, als es jede jährliche Überprüfung erfassen kann.
- Erstellen Sie ein einziges Lager, nicht drei. Traditionelle Vermögenswerte (Repos, pipelineKI-Ressourcen (Modelle, Datensätze, Agenten, MCP-Server, Codierungswerkzeuge) und Container müssen in derselben Ansicht dargestellt werden, wobei die Beziehungen zwischen ihnen abgebildet sein müssen. Ein KI-Tool, das für sich genommen harmlos erscheint, kann sich als echtes Sicherheitsrisiko erweisen, sobald man sieht, welche Datensätze es speisen und mit welchen Endpunkten es kommuniziert.
- Klassifizieren Sie die Daten, bevor Sie die Police ausarbeiten. Eine Regel, die „sensible Daten in KI-Tools“ verbietet, ist wertlos, wenn niemand festlegen kann, welche Daten relevant sind. Es ist wichtig zu wissen, wo regulierte und vertrauliche Daten gespeichert sind, und diese Klassifizierung sollte darüber entscheiden, welche KI-Anwendungsfälle zulässig sind und welche niemals das Gebäude verlassen dürfen.
- Gebt den Teams einen schnelleren Genehmigungsprozess, nicht eine längere Sperrliste. Viele greifen auf Schatten-KI zurück, weil die offizielle Option langsamer ist als die bereits geöffnete. Ein verwalteter Katalog zugelassener Modelle und Agenten, dessen Zugangsdaten für Entwickler nicht zugänglich sind, beseitigt den Grund, die Richtlinien zu umgehen.
- Setzen Sie dort ein, wo das Risiko tatsächlich besteht: bei der Installation und beim Anruf. Das Blockieren eines Modells in einem Dokument hindert einen Agenten nicht an dessen Installation. Die Durchsetzung muss an der Stelle erfolgen, an der ein Paket installiert oder eine API aufgerufen wird, sodass eine blockierte Aktion automatisch fehlschlägt, anstatt davon abhängig zu sein, dass sich jemand an die Regel erinnert.
Welche Bedeutung das Risiko von Schatten-KI für die Anwendungssicherheit und nicht nur für die IT hat
Die meisten Leitlinien zu Schatten-KI behandeln dies ausschließlich als Problem der Datenverlustprävention (DLP), und DLP ist ein legitimer Bestandteil davon. Ein wachsender Anteil des Schatten-KI-Risikos ist jedoch im Browser gar nicht sichtbar: Er äußert sich beispielsweise in Form eines fehlerhaft installierten Pakets, eines ungeprüften MCP-Servers oder eines Programmierassistenten mit permanentem Zugriff auf ein Repository, für das er nie autorisiert war. Das ist keine Schatten-IT mit KI-Label. Es handelt sich um eine neue Kategorie von Risiken in der Software-Lieferkette, die dieselbe Sorgfalt erfordert, die AppSec bereits für jede andere Abhängigkeit anwendet: Wissen, was vorhanden ist, es überprüfen und die Überprüfung automatisieren, anstatt darauf zu hoffen, dass jeder Entwickler daran denkt, dies zu überprüfen.
Hören Sie auf, KI über eine Tabellenkalkulation zu steuern.
Das Problem ist nicht mangelnder Aufwand, sondern fehlende Transparenz: Den meisten Teams fehlt ein zentraler Ort, an dem KI-Ressourcen, Code und … pipelineSie tauchen gemeinsam auf, was genau die Distanz zwischen „Wir haben eine Schatten-KI-Richtlinie“ und „Wir können sie auch tatsächlich durchsetzen“ darstellt.
Das ist das Problem Xygeni AI Security basiert darauf. AI Inventory erkennt kontinuierlich und automatisch alle KI-Assets in Ihren Repositories. pipelineund Entwicklerumgebungen: Modelle, Frameworks, Datensätze, Inferenzendpunkte, Agenten, MCP-Server und KI-Codierungswerkzeuge wie Copilot, Cursor oder Claude Code, abgebildet als Beziehungsgraph mit einer bei jedem Scan generierten KI-Stückliste. DevAI Es fungiert in denselben Umgebungen als aktive Schutzbarriere, validiert Skill-Dateien und Agentenanweisungen und blockiert schädliche Installationen, bevor ein Agent aktiv wird – eine Aufforderung ist nicht erforderlich. Und weil CoreAI Wendet dieselbe KI-gestützte Korrelation und Governance auf die Ergebnisse Ihrer bestehenden Scanner an wie auf die eigenen Ergebnisse von Xygeni; das Risiko der Schatten-KI verschwindet nicht in einem weiteren isolierten Tool, sondern wird in dieselbe Risikoansicht wie alle anderen Daten Ihres Systems integriert. SDLC.
Kostenlos starten. Sign up with GitHubMelden Sie sich bei GitLab oder Google an und erhalten Sie Einblick in bis zu 25 Repositories und 50 KI-Scans pro Monat kostenlos und ohne Kreditkarte.
FAQ
Was ist das Risiko von Schatten-KI, einfach ausgedrückt?
Das Risiko von Schatten-KI entsteht durch KI-Tools, -Modelle, -Agenten oder API-Aufrufe, die innerhalb einer Organisation ohne Sicherheitsprüfung ausgeführt werden. Da meist keine Installations- oder Beschaffungsdokumentation vorhanden ist, wächst das Risiko unbemerkt, bis jemand gezielt danach sucht.
Wie lassen sich Schatten-KI in der Praxis erkennen und eliminieren?
Die Erkennung basiert auf drei zusammenwirkenden Signalen (Netzwerk- und Proxy-Protokolle, Identitäts- und Zugriffssignale sowie Code/pipelineDie Ermittlung und Eliminierung von Assets auf Ebene - ist ein vierstufiger Prozess: Aufbau eines einheitlichen Inventars, Klassifizierung der Daten vor dem Schreiben von Richtlinien, Bereitstellung eines schnelleren Genehmigungsprozesses für die Teams und Durchsetzung der Richtlinien zum Zeitpunkt der Installation oder des API-Aufrufs anstatt in einem Dokument.
Ist Schatten-KI dasselbe wie Schatten-IT?
Verwandt, aber nicht identisch. Schatten-IT hinterlässt üblicherweise Spuren (eine Installation, eine Lizenz, eine Netzwerksignatur). Schatten-KI hinterlässt oft nichts davon: einen Browser-Tab und ein persönliches Profil. login sind ausreichend, und KI-Funktionen werden jetzt in bereits zugelassene Plattformen integriert ausgeliefert.
Kann ein CASB- oder DLP-Tool das Risiko von Schatten-KI selbstständig erkennen?
Nur teilweise. Diese Tools wurden entwickelt, um nicht genehmigte Software mit Spuren aufzuspüren. Ein direkt aus dem Code aufgerufenes Modell oder eine in einer genehmigten Plattform aktivierte KI-Funktion erzeugt keine der Signale, die ein CASB erkennen soll. Um das Risiko von Schatten-KI vollständig zu managen, sind Identitäts-, Netzwerk- und Codeanalysen erforderlich.pipeline-Level-Sichtbarkeit zusammen.
Wo genau tritt Schatten-KI am häufigsten in der Softwareentwicklung auf?
Abgesehen von browserbasierten Chatbots zeigt es sich auch in Form von fest im Quellcode codierten API-Schlüsseln, Open-Source-Modellen, die ohne Sicherheitsprüfung in ein Projekt übernommen werden, und Agenten-Skill-Dateien oder MCP-Serververbindungen, die ohne Überprüfung zu einem Repository hinzugefügt werden – genau die Ebene, die generische Schatten-IT-Tools nicht untersuchen.
