Was ist Schatten-KI?

Schatten-KI bezeichnet jedes KI-System, das innerhalb einer Organisation ohne formale Genehmigung, Transparenz oder Governance eingeführt und genutzt wird: der Copilot, den ein Entwickler letzte Woche in seiner IDE aktiviert hat, das Modell, das aus einem öffentlichen Hub in ein Nebenprojekt übernommen wurde, der MCP-Server, der auf einem Laptop läuft, von dem niemand im Sicherheitsteam weiß. Es handelt sich dabei nicht um einen Sonderfall. Laut einer Umfrage unter Sicherheitsverantwortlichen aus dem Jahr 2026 gaben nur 19 % der Unternehmen an, vollständige Transparenz darüber zu haben, wo und wie KI in ihrer IT-Umgebung eingesetzt wird.

Das Verständnis von Schatten-KI (und ihrer praktischen Bedeutung) ist wichtig, da es sich nicht nur um ein Problem der Datenverwaltung handelt. Schatten-KI ist der Nachfolger der Schatten-IT im KI-Zeitalter, mit einem entscheidenden Unterschied: Ein unkontrolliertes SaaS-Tool verursacht Compliance-Probleme, aber … Ein bösartiger KI-Agent mit Zugriff auf Ihre Daten pipelineDas Vorhandensein von Daten, Repositories und Geheimnissen schafft eine Angriffsfläche. Dieser Leitfaden erklärt, was Schatten-KI ist, warum sie sich schneller ausbreitet, als die Regierung folgen kann, welche Risiken sie birgt und wie Organisationen sie erkennen und bewältigen können, bevor es zu einem Zwischenfall kommt. 

Bedeutung von Schatten-KI: Ausführliche Definition #

Unter Schatten-KI versteht man die nicht genehmigte Nutzung von Werkzeugen, Modellen, Agenten oder Integrationen künstlicher Intelligenz innerhalb der Arbeitsabläufe oder Infrastruktur einer Organisation ohne Wissen, Zustimmung oder Aufsicht der IT- oder Sicherheitsteams.

Der Begriff erweitert das Konzept der Schatten-IT (nicht autorisierte Software und Dienste) auf die spezifischen Eigenschaften von KI-Systemen. Während Schatten-IT typischerweise ein Produktivitätstool beschreibt, das jemand ohne Genehmigung installiert hat, umfasst Schatten-KI ein deutlich breiteres und gefährlicheres Feld: große Sprachmodelle, die sensible Daten ohne Datenschutzkontrollen verarbeiten, KI-Programmierassistenten, die Code generieren, und commitCode ohne Sicherheitsprüfung, autonome Agenten, die auf pipelines und Repositories mit Berechtigungen, die niemand formell erteilt hat, und MCP-Server, die KI-Assistenten mit internen Tools verbinden, ohne eine Zulassungsliste oder Überwachungsebene zu haben.

Der Begriff „Schatten-KI“ bedeutet in der Praxis Folgendes: KI, von der Ihr Unternehmen operativ abhängig ist, die Sie aber weder einsehen, prüfen noch steuern können. In den meisten Fällen handelt es sich nicht um bewusste Umgehung. Vielmehr ist sie die Folge davon, dass KI-Tools so zugänglich und produktiv geworden sind, dass ihre Einführung die üblicherweise damit verbundenen Steuerungsprozesse überholt.

Schatten-KI vs. Schatten-IT: Was ist der Unterschied? #

Schatten IT Schatten-KI und Schatten-KI haben zwar dieselbe Ursache (Mitarbeiter und Teams nutzen Tools, die ihre Produktivität steigern, ohne auf eine formelle Genehmigung zu warten), aber ihre Risikoprofile sind kategorisch unterschiedlich.

Schatten-IT birgt typischerweise Risiken für Daten-Governance und Compliance: Ein nicht autorisierter Cloud-Speicherdienst kann Dateien offenlegen, und ein nicht genehmigtes Projektmanagement-Tool kann personenbezogene Daten ohne DSGVO-konforme Kontrollen verarbeiten. Diese Risiken sind real, aber in der Regel begrenzt und von Sicherheitsteams gut verstanden.

Schatten-KI birgt all diese Risiken und darüber hinaus weitere, die Schatten-IT nicht birgt. Ein nicht autorisiertes KI-Modell, das proprietäre Codebasen oder Kundendaten verarbeitet, kann diese Daten ohne bestehende Datenverarbeitungsvereinbarung an externe Infrastrukturen senden. Ein KI-Codierungsassistent, der Code ohne Sicherheitskontrollen generiert, kann Schwachstellen in einem Ausmaß und einer Häufigkeit einführen, die kein menschlicher Prüfer erfassen kann. Ein autonomer Agent, der innerhalb von CI/CD pipelineBenutzer ohne formale Berechtigungen können Aktionen durchführen (Abhängigkeiten installieren, Dateien öffnen). pull requests(Änderung von Konfigurationsdateien), die weder für das Sicherheitsteam noch für den Entwickler, der dies aktiviert hat, unsichtbar sind.

Der größte Unterschied liegt in der Handlungsfähigkeit. Schatten-IT ist passiv: Sie speichert, überträgt und verarbeitet Daten. Schatten-KI hingegen kann agieren und in agentenbasierten Workflows autonom, in Maschinengeschwindigkeit und über die gesamte Entwicklerumgebung hinweg. Dieser Wandel von passiven Werkzeugen zu aktiver Handlungsfähigkeit macht Schatten-KI zu einem Problem der Lieferkettensicherheit und nicht nur zu einem Problem der Datenverwaltung.

Warum verbreitet es sich? #

Schatten-KI breitet sich aus dem gleichen Grund aus wie Schatten-IT schon immer: Der Produktivitätsgewinn durch die Nutzung des Tools ist unmittelbar und individuell, während der Governance-Prozess, der es offiziell machen würde, langsam und organisatorisch ist.

Die Verfügbarkeit von KI-Tools hat diese Entwicklung dramatisch beschleunigt. KI-Programmierassistenten sind als kostenlose oder kostengünstige IDE-Erweiterungen verfügbar, die jeder Entwickler innerhalb von Sekunden aktivieren kann. Modelle lassen sich direkt von öffentlichen Plattformen in die Abhängigkeitsstruktur eines Projekts einbinden. MCP Server können lokal mit wenigen Zeilen JSON konfiguriert werden. Keine dieser Aktionen erfordert eine Genehmigung der IT-Abteilung, eine Freigabe durch den Einkauf oder eine Sicherheitsprüfung, und keine davon wird in einer Cloud-Konsole angezeigt.

Drei spezifische Faktoren treiben die Verbreitung von Schatten-KI voran: #

• Produktivität. KI-Tools beschleunigen nachweislich die Arbeit von Entwicklern, Analysten und Sicherheitsingenieuren. Ein KI-Programmierassistent, der eine Lösung für eine Sicherheitslücke vorschlägt, eine Testsuite generiert oder wiederkehrende Aufgaben automatisiert. pipeline Eine Aufgabe liefert unmittelbaren Nutzen. Auf einen Genehmigungsprozess zu warten, bis dieser Nutzen sichtbar wird, stellt eine Hürde dar, die die meisten Menschen nicht freiwillig akzeptieren werden.
• BarierrefreiheitDie meisten KI-Tools, die 2026 aktiv im Einsatz sein werden, benötigen weder Infrastruktur noch einen Beschaffungsprozess oder IT-Unterstützung. Es handelt sich um SaaS-Produkte, IDE-Plugins, npm-Pakete und CLI-Tools. Die einzige Hürde für die Nutzung ist ein Browser-Tab oder ein Terminalbefehl.
• UnsichtbarkeitSchatten-KI ist unter anderem deshalb schwer zu kontrollieren, weil sie schwer zu erkennen ist. Ein lokal laufendes Modell, ein in einer Konfigurationsdatei eingerichteter MCP-Server, ein in einen CI-Workflow eingebetteter Agent: Nichts davon taucht in einem Cloud-Asset-Inventar auf. Sicherheitsteams, die sich ausschließlich auf die Cloud-basierte Erkennung verlassen, übersehen daher regelmäßig den Großteil der im Unternehmen aktiv genutzten KI.

Risiken durch Schatten-KI #

Schatten-KI birgt Risiken in vier Dimensionen, wobei jede dieser Dimensionen die anderen verstärkt.

• Datenfreigabe: KI-Tools verarbeiten alle ihnen zur Verfügung gestellten Daten. Ein Entwickler, der proprietären Quellcode in ein nicht genehmigtes LLM einfügt, oder ein Agent, der eine geheime Datei liest, um eine Aufgabe zu erledigen, kann sensible Daten ohne Datenverarbeitungsvereinbarung, Datenspeicherung oder Prüfprotokoll an externe Infrastrukturen übertragen. Laut einer Studie von IBM gibt über ein Drittel der Beschäftigten zu, sensible Arbeitsinformationen ohne Zustimmung des Arbeitgebers mit KI-Tools zu teilen – und in vielen Fällen sind sich beide Parteien der Konsequenzen für die weitere Datenverarbeitung nicht bewusst.
• Angriffsfläche der Lieferkette: Schatten-KI ist ein Vektor, nicht nur eine Lücke in der Governance. Schadsoftware, die auf KI-Tools abzielt (die Cluster ollama-helpers und openai-agents-helpers), SkillLeak Muster, das GhostTracker Diese Kampagnen sind speziell darauf ausgelegt, Entwickler zu erreichen, die KI-Tools ohne formale Aufsicht einsetzen. Ein nicht autorisierter KI-Programmierassistent, der selbstständig eine Abhängigkeit installiert, durchläuft keine Sicherheitsprüfung zwischen dem schädlichen Paket und seiner Ausführung. Scanner suchen genau dort, wo die Installation stattfindet: im Skill-Verzeichnis, bei transitiven Abhängigkeiten und auf dem MCP-Server – dort lauern die Bedrohungen.
• Compliance-Risiko: Die EU-KI-Gesetzgebung, die DSGVO, das NIST AI RMF und ISO/IEC 42001 begründen Verpflichtungen, die Unternehmen nur erfüllen können, wenn sie wissen, welche KI sie einsetzen. Schatten-KI fällt definitionsgemäß nicht in den Geltungsbereich von Compliance-Programmen, die auf einem Verzeichnis zugelassener Tools basieren. Allein die Bußgelder für Verstöße gegen die DSGVO können bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes betragen, und die Verwendung eines nicht genehmigten Modells zur Verarbeitung personenbezogener Daten stellt unabhängig von der Absicht einen eindeutigen Compliance-Verstoß dar.
• Governance und Qualitätsrisiko: KI-Modelle erzeugen Ausgaben, die ihre Trainingsdaten, ihre Konfiguration und die erhaltenen Eingaben widerspiegeln. Ein nicht autorisiertes Modell, das ohne Qualitätskontrollen, Bias-Bewertung oder Ausgabevalidierung eingesetzt wird, birgt Risiken.cisEs entstehen Risiken, die für die Organisation unsichtbar sind. Modellabweichungen, Fehlinterpretationen und verzerrte Ergebnisse in einem Schatten-KI-System bleiben so lange verborgen, bis sie sich in Form einer Kundenbeschwerde, einer behördlichen Anfrage oder eines Sicherheitsvorfalls bemerkbar machen.

Wo es sich versteckt #

Die am schwersten zu findende Schatten-KI ist die KI innerhalb des Softwareentwicklungszyklus, vor dercisEs liegt wahrscheinlich daran, dass es nie dafür konzipiert wurde, an Orten aufzutauchen, an denen Sicherheitsteams suchen.

Schatten-KI in der SDLC Lebt typischerweise an vier Orten:

• Lokale MCP-Server. MCP-Server, die in den lokalen IDE-Einstellungen konfiguriert sind (eine JSON-Datei in einem Punktordner), bilden die unsichtbarste Ebene von allen. Sie verbinden KI-Assistenten direkt mit Dateien, APIs, Repositories und Geheimnissen, ohne dass ein Netzwerkperimeter sie erkennen oder ein Genehmigungsprozess sie einschränken könnte.

• Entwicklerendpunkte. KI-Codierungsassistenten, die pro Entwickler und IDE (Copilot, Cursor, Windsurf oder einem beliebigen MCP-fähigen Client) konfiguriert sind, laufen auf dem Rechner des Entwicklers und sind in Cloud-Asset-Inventaren nicht sichtbar. Die Modelle, mit denen sie sich verbinden, die MCP-Server, die sie einbinden, und die Daten, die sie verarbeiten, erscheinen niemals in einem zentralen Protokoll, es sei denn, die Organisation hat Einblick auf Endpunktebene.

• Code-Repositories. KI-Modelle und Bibliotheken, die als npm-, PyPI- oder andere Ökosystem-Abhängigkeiten eingebunden werden, gelangen wie jedes andere Paket in die Codebasis. Ohne SCA Tools, die KI-spezifische Asset-Typen verstehen (nicht nur CVE-Scores), sind von jeder anderen Abhängigkeit nicht zu unterscheiden, bis etwas schiefgeht.

• CI/CD pipelines. Agentische Workflows, die öffnen pull requests, Abhängigkeiten installieren oder Konfigurationsdateien ändern, funktionieren innerhalb pipeline Die Infrastruktur wurde für die von Menschen erstellte Automatisierung entwickelt. Ein in einen GitHub Actions-Workflow oder einen Jenkins-Job eingebetteter KI-Agent verfügt über dieselben Berechtigungen wie jeder andere Schritt im Workflow. pipeline und standardmäßig keine Sichtbarkeitsebene.

Wie man Schatten-KI entdeckt und verwaltet #

Die Entdeckung von Schatten-KI erfordert einen anderen Ansatz als die traditionelle Asset-Erkennung, da Schatten-KI nicht dort auftaucht, wo die traditionelle Erkennung sucht.

1. Greifen Sie in die SDLC, nicht nur die Cloud. Die reine Cloud-basierte Asset-Erkennung erfasst die meisten Schatten-KI-Funktionen nicht. Eine effektive Erkennung muss innerhalb von Code-Repositories erfolgen und entsprechende Prozesse implementieren. pipelineund Entwickler-Endpunkte, um KI-Codierungswerkzeuge, MCP-Server und Modellabhängigkeiten an denselben Stellen zu finden, an denen Entwickler sie platzieren, und nicht in den Cloud-Konsolen, wo sie nie erscheinen.
2. Behandeln Sie Abhängigkeiten von KI wie jedes andere Lieferkettenrisiko. KI-Bibliotheken, -Modelle und MCP-Pakete, die in eine Codebasis integriert werden, sind Bestandteile der Lieferkette. Sie sollten daher genauso sorgfältig geprüft werden wie jede andere Open-Source-Abhängigkeit: Herkunft, Versionsverlauf, Verhaltensanalyse und Echtzeitüberwachung auf neu veröffentlichte, schädliche Versionen.
3. Inventarisieren Sie MCP-Server als erstklassige Assets. MCP-Server sind keine Entwicklerhilfen; sie sind privilegierte Integrationen mit Zugriff auf Dateien und APIs. pipelineund Geheimnisse. Jeder MCP-Server sollte inventarisiert, bewertet und entweder genehmigt oder gesperrt werden, wobei die Durchsetzung am Entwicklerendpunkt und nicht auf Richtliniendokumenten beruhen sollte.
4. Setzen Sie AI-SPM als Governance-Ebene ein. AI Security Posture Management (AI-SPM) ist ein speziell entwickeltes Verfahren zur Bekämpfung von Schatten-KI in großem Umfang. Es erfasst kontinuierlich alle KI-Ressourcen im Unternehmen, bewertet deren Risiko anhand KI-spezifischer Angriffsvektoren, ordnet sie regulatorischen Verpflichtungen zu und setzt Richtlinien durch, bevor unkontrollierte KI zu einem Sicherheitsvorfall wird. Ein KI-Inventar ist das erste Ergebnis; eine KI-Stückliste (AI BOM) ist das auditfähige Dokument, das für die Einhaltung der Vorschriften erforderlich ist.

Schatten-KI mit Xygeni sichern #

Schatten-KI lässt sich nicht allein durch Richtlinien kontrollieren. Eine Richtlinie, die besagt, dass „Entwickler keine nicht genehmigten KI-Tools verwenden dürfen“, erkennt weder den auf dem Laptop eines Entwicklers laufenden MCP-Server, noch kennzeichnet sie das KI-Modell, das letzten Dienstag in einen Abhängigkeitsbaum eingebunden wurde, und blockiert auch nicht das schädliche Paket, das ein KI-Agent selbstständig installiert hat.

Xygenis Die KI-Sicherheitsplattform begegnet Schatten-KI als kontinuierliches Erkennungs- und Durchsetzungsproblem: AI-SPM erkennt jedes Modell, jeden Agenten, jeden MCP-Server und jedes KI-Codierungstool im gesamten System. SDLC (einschließlich auf Entwicklerendpunkten, in Code-Repositories und innerhalb von CI/CD pipelines) die Herstellung eines KI-BOM das jedes Asset seinem Risikoniveau und seiner regulatorischen Klassifizierung zuordnet. Shield Setzt Richtlinien am Entwicklerendpunkt durch und blockiert nicht genehmigte MCP-Server und schädliche Abhängigkeiten, bevor diese den Benutzer erreichen. pipeline. Frühwarnung vor Malware Erkennt bösartige Pakete, die auf KI-Tools abzielen, bereits zum Zeitpunkt der Veröffentlichung, noch bevor eine CVE existiert.

Wenn Ihre Teams KI-gestützte Programmierassistenten einsetzen, ist das Problem der Schatten-KI bereits vorhanden. Die Frage ist, ob Sie es erkennen können.

FAQ #