Shadow AI: Wenn KI zur Schatten-IT wird – und wie SASE/SSE sie einhegt

Generative KI ist längst im Arbeitsalltag angekommen. Texte zusammenfassen, Code erklären, E-Mails formulieren – und weil es so praktisch ist, geschieht es oft an der IT vorbei. Genau hier entsteht ein neues Risiko: Shadow AI, die inoffizielle Nutzung nicht freigegebener KI-Dienste. Der Kollege, der schnell einen Kundenvertrag in ein öffentliches Chatmodell kopiert, um ihn zusammenzufassen, meint es gut – und schickt damit vertrauliche Daten aus dem Unternehmen hinaus.

Das ist kein Randphänomen. Erhebungen zeigen, dass generative KI in vielen Unternehmen längst in einzelnen Abteilungen im Einsatz ist, häufig ohne Freigabe, ohne Richtlinie, ohne dass die IT davon weiß. Schatten-IT gab es immer; durch KI wird sie nur schwerer zu erkennen und riskanter.

Warum Shadow AI gefährlich ist

Das Kernproblem ist der Datenabfluss. Was einmal in einem externen Dienst gelandet ist, ist außerhalb der eigenen Kontrolle – im Zweifel gespeichert, verarbeitet, vielleicht sogar zum Training verwendet. Bei Kundendaten, Verträgen oder internem Wissen ist das nicht nur ärgerlich, sondern ein handfestes Datenschutz- und Geheimnisschutzproblem.

Dazu kommt der regulatorische Druck. Der EU AI Act ist seit 2024 in Kraft und verlangt von Unternehmen, den Einsatz von KI zu kennen, einzuordnen und zu dokumentieren – bei Verstößen drohen empfindliche Bußgelder. Wer nicht einmal weiß, welche KI-Dienste im Haus genutzt werden, kann diese Pflichten nicht erfüllen. Sichtbarkeit ist damit nicht mehr nur eine Sicherheits-, sondern eine Compliance-Frage.

Warum klassische Kontrollen nicht greifen

Der Reflex, das mit Firewall und VPN zu lösen, geht ins Leere. Diese Werkzeuge wurden für ein Modell gebaut, in dem der Verkehr durch ein zentrales Rechenzentrum floss und Anwendungen bekannt waren. KI-Dienste laufen in der Cloud, der Verkehr ist verschlüsselt, und der Zugriff geschieht direkt vom Endgerät aus – oft am zentralen Gateway vorbei. Eine Firewall, die nur Ports und Adressen sieht, erkennt nicht, dass in einem TLS-verschlüsselten Datenstrom gerade ein Vertrag in ein Chatmodell wandert.

So entsteht die eigentliche Lücke: Man kann nicht kontrollieren, was man nicht sieht. Zero Trust ist als Prinzip verstanden, aber ohne die passende Architektur bleibt es Theorie.

Wie SASE/SSE Shadow AI einhegt

Genau diese Sichtbarkeit und Durchsetzung liefert SASE/SSE : eine cloudbasierte Schicht, die den Verkehr nah an Nutzer und Standorten prüft, statt ihn durch ein fernes Rechenzentrum zu zwingen. Vier Bausteine greifen dabei gegen Shadow AI ineinander:

• CASB ( Cloud Access Security Broker ) macht sichtbar, welche Cloud- und KI-Dienste überhaupt genutzt werden – auch die, die niemand offiziell eingeführt hat – und erlaubt, sie gezielt freizugeben oder zu sperren.
• DLP (Data Loss Prevention) erkennt sensible Inhalte – Kundendaten, Vertragsklauseln, Quellcode – und blockiert, dass sie in einen nicht freigegebenen Dienst hochgeladen werden, bevor sie das Haus verlassen.
• SWG (Secure Web Gateway) inspiziert den Web- und TLS-Verkehr inline und setzt die Regeln in Echtzeit durch, statt nur zu protokollieren.
• ZTNA ( Zero Trust Network Access ) ersetzt das pauschale VPN-Vertrauen: Zugriff gibt es nur für geprüfte Identität und Kontext, nicht für jeden, der im Netz ist.

Der entscheidende Punkt ist die Kombination. Erst zusammen entsteht ein durchgängiges Bild: Wer nutzt welchen KI-Dienst, mit welchen Daten, von welchem Gerät? Aus diesem Bild werden Richtlinien, die nicht pauschal verbieten, sondern differenzieren – etwa: freigegebenes KI-Werkzeug ja, aber keine als vertraulich klassifizierten Daten hinein.

Technik allein reicht nicht

So wichtig die Plattform ist – ohne Regeln bleibt sie stumpf. Es braucht eine klare KI-Richtlinie: Welche Werkzeuge sind freigegeben, welche Datenklassen dürfen hinein, wer entscheidet über neue Dienste? Und es braucht die Menschen: Die meisten Shadow-AI-Vorfälle entstehen nicht aus böser Absicht, sondern aus Bequemlichkeit und Unwissen. Wer den sicheren Weg – ein freigegebenes, integriertes KI-Werkzeug – zum einfachsten Weg macht, muss weniger verbieten.

Ein pragmatischer Einstieg sieht so aus: erst sichtbar machen, welche KI-Dienste tatsächlich im Einsatz sind (der Shadow-AI-Bestand überrascht fast immer). Dann Datenklassen und eine KI-Richtlinie definieren. Dann die Regeln über SASE/SSE durchsetzen – zunächst beobachtend, dann blockierend, damit die Produktivität nicht leidet. Und schließlich laufend nachschärfen, weil ständig neue KI-Dienste dazukommen.

Genau diesen Zyklus managen wir bei KAEMI als Service: Sichtbarkeit herstellen, Richtlinien mit dem Unternehmen definieren, sie über die SASE/SSE-Plattform durchsetzen und im laufenden Betrieb pflegen. Wie eine solche Architektur über viele Standorte und Länder hinweg aussieht, zeigt unser Praxisbeispiel zu Cloudflare One in Europa .

Shadow AI verschwindet nicht, indem man KI verbietet – die Werkzeuge sind zu nützlich, die Nutzer finden ohnehin einen Weg. Es verschwindet, indem man den unkontrollierten Gebrauch in einen kontrollierten überführt: sichtbar, geregelt, abgesichert. SASE/SSE ist die Schicht, die das möglich macht.