Wenn freigegebene KI zu Shadow AI wird

Die Freigabe einer Anwendung verschafft einem Unternehmen einen wertvollen Kontrollpunkt: Sicherheit, Recht, Datenschutz, Beschaffung und IT bewerten einen Dienst gemeinsam, handeln Vertragsbedingungen aus, konfigurieren unternehmensweite Kontrollen und definieren, was als angemessene Nutzung gelten soll.

Diese Entscheidung beschreibt allerdings nur einen Zustand – nämlich den zum Zeitpunkt der Prüfung. Sie bildet die Konten, Funktionen, Integrationen, Datenflüsse und Geschäftszwecke ab, die vor dem Zeitpunkt der Freigabe erfasst wurden. KI-Dienste entwickeln sich jedoch erheblich schneller weiter als die Zyklen, in denen sie geprüft werden: Software-as-a-Service-(SaaS)-Anwendungen werden um Copiloten und Agenten erweitert, Browser-Erweiterungen erhalten Konnektoren bzw. Plug-Ins, private und geschäftliche Editionen desselben Dienstes unterscheiden sich in Funktionsumfang und Datenschutzzusagen – und die Beschäftigten erschließen Anwendungsfälle, die in der ursprünglichen Bewertung niemand vorgesehen hatte.

Workflows lassen sich deshalb nicht zuverlässig in «freigegeben» und «unkontrolliert» (Shadow-AI) sortieren. Auch ein freigegebener Dienst kann einen unkontrollierten Datenpfad eröffnen – etwa wenn jemand die Identität wechselt, eine Funktion außerhalb der freigegebenen Konfiguration aktiviert, einen weiteren Dienst anbindet oder sensible Daten auf neue Weise einbringt (siehe Abbildung 1).

Shadow AI ist ein Zustand, keine Kategorie

Betrachtet man Shadow AI nicht als feste Kategorie, sondern als Zustand, wird das Problem greifbarer. Eine Interaktion kann den Rahmen der Governance verlassen, sobald sich eine der folgenden Bedingungen ändert:

• Identität: Die Beschäftigten wechseln vom Unternehmenskonto zu privaten oder nicht verwalteten Anmeldedaten
• Funktion: Eine freigegebene SaaS-Plattform führt einen Assistenten für generative KI (GenAI), einen autonomen Workflow oder agentische Funktionen ein
• Integration: Ein Plug-in, eine Browser-Erweiterung, ein Konnektor, ein Model-Context-Protocol-(MCP)-Server oder ein externer Agent erhält Zugriff auf den Workflow
• Daten: Die Interaktion umfasst nun Kundeninformationen, Quellcode, Anmeldedaten, Verträge oder andere geschützte Inhalte (RAG – Retrieval Augmented Generation)
• Zweck: Ein für die allgemeine Texterstellung freigegebener Dienst wird zur Analyse regulierter Daten oder zur Entscheidungsvorbereitung in geschäftskritischen Fragen genutzt
• Aktion: Ein Assistent, der zunächst nur Texte erzeugte, darf nun Datensätze abrufen, Nachrichten versenden, Systeme aktualisieren oder nachgelagerte Arbeitsschritte auslösen

Jeder dieser Wechsel verändert das Risiko, und innerhalb einer einzigen Browser-Sitzung können mehrere davon eintreten. Besonders anschaulich ist die Identität: Ein Unternehmen hat für einen KI-Dienst vielleicht Schutzmaßnahmen, Aufbewahrungsfristen, administrative Kontrollen und Nachvollziehbarkeit ausgehandelt – eine private Anmeldung bei demselben Dienst fällt jedoch nicht unter diese Vereinbarung. Für die Nutzenden sieht die Oberfläche dabei nahezu identisch aus, während die Sicherheitseigenschaften weit auseinanderliegen. Ein solcher Kontowechsel bleibt unbemerkt, wenn die Erkennung bei der Domain oder dem Anwendungsnamen endet.

Das Asset-Inventar bleibt die Grundlage – genügt aber nicht mehr

Sicherheitsteams müssen wissen, welche KI-Anwendungen und -Agenten im Einsatz sind, wer sie nutzt und mit welchen Systemen sie kommunizieren. Mit KI wird dieses Inventar jedoch zum Ausgangspunkt der Bewertung und nicht mehr zu ihrem Ergebnis.

Ein Eintrag im Anwendungsinventar belegt, dass ein Dienst die Prüfung bestanden hat. Er sagt für sich genommen nichts darüber aus, ob die Anmeldung im verwalteten Mandanten erfolgt, welche KI-Funktion aktiv ist, welche Informationen in den Prompt einfließen, ob ein neu hinzugekommener Konnektor Daten abrufen darf oder wohin die Ausgabe anschließend weitergereicht wird. Diese Angaben stecken in der Interaktion selbst.

Deshalb kann selbst der alltägliche, ausdrücklich erlaubte KI-Einsatz zu erheblichen Risiken führen. Der «AI Security Report 2026» von Check Point Research weist aus, dass sich der Anteil risikoreicher GenAI-Prompts binnen eines Jahres von zwei auf vier Prozent verdoppelt hat; im Mittel nutzen Unternehmen zehn KI-Anwendungen pro Monat, viele davon ohne formale Freigabe. Den Großteil der beobachteten Datenexposition führt der Bericht ausdrücklich nicht auf Angriffe zurück, sondern auf die genehmigte Alltagsnutzung – weil Beschäftigte mehr Kontext bereitstellen, als ihnen bewusst ist, um eine brauchbare Antwort zu erhalten.

Dieses Verhalten ist nachvollziehbar, denn nützliche KI lebt vom Kontext: Eine allgemeine Anfrage erzeugt eine allgemeine Antwort. Also kommen der Vertrag, die Kundenhistorie, der Quellcode, das Besprechungsprotokoll und der interne Diskussionsstrang hinzu, damit das Modell versteht, worum es tatsächlich geht. Die Antwort wird besser – und Data Leakage Prevention und die Bewertung der betroffenen Elemente entsprechend schwierig.

Vertraute Werkzeuge, unbekannte Datenpfade

Mit der Einbettung von KI in bestehende Produkte wächst der blinde Fleck genau dort, wo die Freigabe eigentlich greifen sollte. Früher mussten Beschäftigte eine erkennbare KI-Anwendung aufrufen, um generative KI zu nutzen; heute steckt diese Funktion in Produktivitätssuiten, Kundenplattformen, Entwicklungswerkzeugen, Konferenzsystemen, Browsern und Desktop-Software. Microsofts «Work Trend Index 2026» beziffert das Tempo dieser Einbettung: Die Zahl aktiver Agenten im Microsoft-365-Ökosystem wuchs binnen eines Jahres um den Faktor 15, in großen Unternehmen um den Faktor 18. Zugleich nennen 67 Prozent der befragten Beschäftigten die organisatorische Reife – Kultur, klare Nutzungsregeln, Führungsunterstützung – und nicht die Technik als entscheidenden Faktor für den Erfolg von KI-Vorhaben.

Auch eine vertraute Anwendung kann Informationen auf ungewohnte Weise zusammenführen. Eine Nutzerin darf möglicherweise mehrere Kundendatensätze einzeln einsehen; ein eingebetteter Assistent fasst sie zusammen, verknüpft sie mit dem E-Mail-Verlauf und schickt das Ergebnis an einen angebundenen Workflow. Das Risiko entsteht dabei nicht aus dem einzelnen Zugriff, sondern aus dem zusammengestellten Kontext und aus dem Zielsystem.

Kennzeichnungen auf Anwendungsebene verlieren dadurch an Aussagekraft. «Freigegeben» beschreibt die Produktbeziehung – über die aktuelle KI-Interaktion sagt es deutlich weniger aus.

Die Regulierung folgt der Nutzung, nicht dem Katalog

Diese Unschärfe hat auch eine regulatorische Seite. Betreiber im Sinne von Art. 3 Nr. 4 der KI-Verordnung (EU) 2024/1689 ist, wer ein KI-System in eigener Verantwortung verwendet – die Rolle entsteht also aus der tatsächlichen Nutzung und nicht aus dem Beschaffungsvorgang. Wer nicht sieht, welche KI-Funktion in welchem Kontext mit welchen Daten arbeitet, kann die daran hängenden Pflichten weder erfüllen noch nachweisen. Das gilt schon heute: Die Pflicht zur KI-Kompetenz nach Art. 4 gilt seit dem 2. Februar 2025 und richtet sich ausdrücklich auch an Betreiber – Schulung und Sensibilisierung lassen sich aber nur für Werkzeuge organisieren, von deren Einsatz das Unternehmen überhaupt weiß.

Dass die Betreiberpflichten für eigenständige Hochrisiko-Systeme nach Anhang III mit dem Digital Omnibus vom Mai 2026 auf den 2. Dezember 2027 verschoben wurden, verschafft dabei nur scheinbar Luft. Denn die Einordnung eines Anwendungsfalls in eine Risikoklasse setzt voraus, dass der Anwendungsfall bekannt ist – und genau das ist bei einem Assistenten, der über ein privates Konto Bewerbungsunterlagen oder Bonitätsdaten verarbeitet, nicht mehr gegeben. Die Frist verschiebt den Stichtag, allerdings nicht die Notwendigkeit der Bestandsaufnahme.

Bestandsaufnahme braucht Kontext der Interaktion

Zielführend ist daher eine fortlaufende Klassifizierung, die erkennt, wann eine KI-Interaktion ihren Sicherheitszustand ändert – und zwar während der Arbeit, nicht im Nachhinein. Entscheidend ist, wer die KI nutzt, über welches Konto und welches Gerät, welche Erweiterungen oder Agenten aktiv sind, welche Daten eingegeben oder abgerufen werden und wohin Informationen oder Aktionen anschließend gelangen können. Erst dieser Kontext unterscheidet den Beschäftigten, der mit einem regulierten Unternehmensassistenten einen Pressetext überarbeitet, von demselben Beschäftigten, der über sein privates Konto unveröffentlichte Finanzzahlen analysiert.

Zugleich erlaubt er eine abgestufte Reaktion: Aktivitäten mit geringem Risiko laufen weiter. Eine private Anmeldung löst einen Hinweis aus oder erzwingt den Wechsel in den Unternehmens-Mandanten. Sensible Inhalte werden maskiert. Eine unzulässige Integration wird blockiert. Und eine KI-Aktion benötigt eine Freigabe, bevor sie ein weiteres System erreicht.

Richtlinien und Listen freigegebener Werkzeuge bleiben die Grundlage – ihr Wert steigt aber erst, wenn die Sicherheitsabteilung sieht, wie KI tatsächlich genutzt wird: über Browser, SaaS-Anwendungen, Desktop-Werkzeuge, Copiloten, Erweiterungen und selbst gebaute Workflows der Fachbereiche hinweg. Die Richtlinie muss der Interaktion folgen, während sich deren Zustand ändert.

Fazit

Das Unternehmenskonto für KI ist verwaltet, das private Konto derselben Person liegt außerhalb der ausgehandelten Schutzmaßnahmen. Der neue Assistent im CRM-System ist noch nicht geprüft, und die Browser-Erweiterung bringt womöglich ein weiteres Modell und einen weiteren Datenpfad mit. Die Arbeit bleibt dabei durchweg legitim – der Sicherheitszustand kann sich trotzdem mehrfach ändern, bevor beispielsweise die Mittagspause beginnt.

Shadow AI existiert daher auch in Organisationen, die eine KI-Richtlinie, eine Liste zugelassener Anbieter und Unternehmenslizenzen besitzen. Sie sitzt in den Lücken zwischen diesen Kontrollen: im Kontowechsel, in der neu aktivierten Funktion, in der stillen Integration, im zusätzlichen Kontext und in der Aktion, die niemand vom Assistenten erwartet hätte. «Freigegeben» und «Schatten-KI» sind in der KI-gestützten Arbeitswelt keine Kategorien mehr, sondern vorübergehende Sicherheitszustände.

Autor: Thomas Boele, Global Director Solutions Engineering – AI Security bei Check Point Software.