Shadow AI erkennen: Beispiele, Risiken und konkrete Maßnahmen

Was ist Shadow AI – und was unterscheidet sie von Shadow IT?

Ein KI-Werkzeug wird zur Schatten-KI, wenn sein beruflicher Einsatz an der vorgesehenen Prüfung vorbeigeht. Das kann eine einzelne Person betreffen oder eine selbst gebaute Integration im Team. Eine bezahlte Lizenz, bekannte Marke oder lokale Installation beantwortet die Freigabefrage noch nicht.

Auch erlaubte Software kann einen ungeprüften Datenweg bekommen: etwa wenn jemand eine neue KI-Zusammenfassung aktiviert oder einen Connector mit zusätzlichen Leserechten verbindet. Prüfe deshalb immer Werkzeug und Verwendung. „Supportentwürfe mit synthetischen Beispielen“ ist eine andere Verwendung als „vollständige Kundentickets in ein Privatkonto laden“.

Der Begriff ist keine eigene gesetzliche Risikoklasse und bedeutet nicht automatisch Datenleck oder Rechtsverstoß. Ob ein konkreter Einsatz zulässig ist, muss anhand der tatsächlichen Daten und Bedingungen beurteilt werden.

Shadow-AI-Selbstcheck: Was ist als Nächstes zu klären?

Beschreibe eine konkrete KI-Aufgabe und beantworte fünf Fragen. Die Prüfliste bündelt alle ausgelösten Schritte. Anschließend kannst du eine Alternative vergleichen und dieselben Angaben in einen offenen Freigabeantrag übernehmen.

Warum entsteht Schatten-KI im Arbeitsalltag?

Hinter einer ungeprüften Nutzung kann eine ungelöste Aufgabe stehen: ein langes Dokument, eine fehlende Suchfunktion oder ein zu langsamer Freigabeweg. Privat vertraute Werkzeuge sind schnell verfügbar; eine neue KI-Funktion sieht möglicherweise wie ein normales Softwareupdate aus. Das erklärt den möglichen Einstieg, beweist aber keine bestimmte Ursache in deinem Betrieb.

Frage deshalb konkret: „Was möchtest du erledigen, welcher erlaubte Weg fehlt und welche Daten brauchst du?“ Eine erreichbare Ansprechperson und eine brauchbare Alternative machen die Antwort auf diese Fragen leichter.

Eine deutsche Erhebung – mit erkennbaren Grenzen

In einer Bitkom-Befragung von 2025 berichteten 8 Prozent der Unternehmen von verbreiteter Nutzung privater KI-Zugänge für die Arbeit, 17 Prozent von Einzelfällen. Weitere 17 Prozent vermuteten eine Nutzung, wussten es aber nicht sicher.

Diese Angaben beschreiben Antworten von Unternehmen im Jahr 2025. Sie sind weder eine Messung der heutigen Tokenwerk-Leserschaft noch ein Nachweis für einen einzelnen Betrieb. Auch vermutete und bestätigte Nutzung bleiben getrennt.

Fünf Beispiele: Wo ungeprüfte KI-Nutzung beginnt

Die Kontotypen und Datenregeln bei Claude zeigen, warum „kostenpflichtig“ keine ausreichende Beschreibung ist. Bei Integrationen hilft der Guide Datenschutz bei n8n, auch Ausführungsdaten und nachgelagerte Dienste einzubeziehen.

Welche Risiken musst du getrennt prüfen?

Prüfe vier Bereiche: Daten und Empfänger, Ergebnisqualität, Zugriff und Aktionen sowie Verantwortung und Nachweis. Halte jeweils fest, was schiefgehen könnte, wer betroffen wäre und welche Begrenzung tatsächlich hilft.

Bei personenbezogenen Daten gehören insbesondere Zweck, Rechtsgrundlage, notwendiger Umfang, sichere Verarbeitung und Aufbewahrung zur Prüfung. Der Europäische Datenschutzausschuss erläutert diese Grundlagen. Das ist keine pauschale Freigabe eines Produkts und kein Ersatz für die Beurteilung deines Falls.

Shadow AI erkennen: Was zeigt welche Methode?

Beginne mit einer verständlichen Abfrage im Team und vorhandenen Freigabelisten. Technische Hinweise können diese Übersicht ergänzen. Sie erklären aber nicht von selbst, welche Aufgabe hinter einer Verbindung steckt oder ob eine Nutzung erlaubt ist.

Ein konkretes Herstellerbeispiel: Microsoft trennt App-Erkennung und GenAI Insights. Die App-Erkennung ordnet Netzwerkverkehr Anwendungen zu; die gesonderte Inhaltsfunktion nutzt laut Dokumentation TLS-Inspektion und Deep Packet Inspection für Prompts und MCP-Vorgänge. Aus dem Erkennen eines Dienstes folgt daher nicht, dass der Inhalt jeder Eingabe sichtbar ist.

Mehr Datensammlung ist nicht automatisch die bessere Bestandsaufnahme. Zweck, Umfang, Rechtsgrundlage, Transparenz, Zugriffsrechte und Aufbewahrung einer Überwachung müssen selbst geprüft werden. Für den ersten Überblick reichen häufig Aufgabenbeschreibungen und Datenkategorien statt kompletter Promptverläufe. Die Herstellerbeschreibung ist kein unabhängiger Wirksamkeitstest und keine Empfehlung, eine Inhaltsüberwachung einzuschalten.

Eigener Praxistest: Was sieht ein vorgeschalteter Prüfweg?

Ein Prüfpunkt sieht nur die Anfragen, die ihn durchlaufen. Wir haben diese Grenze an einem eigenen lokalen Aufbau überprüft: sieben festgelegte Fälle, jeweils drei Wiederholungen. Von 21 Anfragen wurden zwölf durch die vorgeschalteten Regeln gestoppt; neun erreichten das Modell. Die drei direkten Modellaufrufe fehlten im Gateway-Protokoll. Drei Eingaben mit einem synthetischen Kontakttext passierten ebenfalls; ihr Inhalt wurde durch diese Regeln nicht geprüft.

Was wir tatsächlich aufgebaut haben

Ein Python-Gateway prüfte vier übermittelte Angaben: Anwendung, Kontotyp, Datenkategorie und gewünschte Aktion. Erlaubt war ausschließlich eine registrierte Testanwendung mit Arbeitszugang, synthetischen Daten und Entwurf als Aktion. Ein separater Mess-Proxy zählte die wirklichen Weiterleitungen an Ollama 0.40.8 mit qwen3.5:4b (Q4_K_M). Die Modelloptionen waren Temperatur 0, Seed 42, Kontext 4.096 und höchstens 128 Ausgabetokens; Thinking und Streaming waren deaktiviert.

Alle Eingaben waren künstlich, alle drei Dienste an die Loopback-Adresse gebunden, die Ollama-Cloudfunktionen abgeschaltet. Es wurden keine Kundenunterlagen, Konten oder Nachrichten verwendet. Der Ablauf und die erwarteten Ergebnisse wurden vor dem Versuch fixiert.

Was die Ergebnisse für deine Prüfung bedeuten

• Regeln wirkten auf ihrem Weg: Privatkonto, deklarierter Personenbezug, Versandwunsch und unbekannte Anwendung wurden je dreimal mit HTTP 403 abgewiesen, ohne das Modell zu erreichen.
• Der direkte Weg blieb außerhalb: Drei Aufrufe erreichten den Modellweg, ohne einen Gateway-Eintrag zu erzeugen. Ein Protokoll dieses Gateways allein hätte sie nicht gezeigt.
• Eine Angabe ist noch kein Nachweis: Fall G enthielt einen vollständig erfundenen Testkontakt unter .invalid und war als synthetisch deklariert. Das Gateway akzeptierte die Anfrage, ohne den Prompt zu klassifizieren. Das beweist keine Fehlklassifizierung echter personenbezogener Daten.

Was dieser Versuch nicht belegt

Das ist ein eigener kontrollierter Softwareversuch, kein Test eines kommerziellen DLP- oder Shadow-AI-Produkts. Wir haben keine echte Anmeldung, OAuth-Berechtigung, CRM-Änderung, MCP-Aktion oder E-Mail ausgeführt. Die angefragte Versandaktion war nur ein Testfeld. Ebenso wurde weder der gesamte Rechnerverkehr aufgezeichnet noch eine Beschäftigtennutzung untersucht. Drei Wiederholungen derselben Fälle ergeben keine allgemeine Schutzwahrscheinlichkeit.

Für den betrieblichen Aufbau folgt daraus eine Prüffrage: Sind die relevanten Zugangswege erfasst, werden Identität und Rechte tatsächlich verifiziert, und welche Information liefert die eingesetzte Prüfung wirklich? Nutze die Ergebnisse als begrenzten Anschauungsfall, nicht als Freigabe für eine Überwachung.

Präzisierung zu Fall G: Im vorab gespeicherten Plan heißt der Fall „Falsche Datendeklaration“. Diese Bezeichnung war ungenau, weil der Kontakttext selbst künstlich ist. Wir bewahren den Originalplan unverändert und beschreiben das Ergebnis deshalb als Kontakttext ohne Inhaltsregel. Die Zähler ändern sich dadurch nicht.

Rohbelege und Nachbau

Den veröffentlichten Python-Nachbaucode haben wir anschließend in einem separaten Durchlauf mit weiteren 21 künstlichen Anfragen geprüft. Er reproduzierte dieselben Zähler. Die Tabelle und Grafik oben zeigen weiterhin den ersten Durchlauf; wir addieren die Wiederholung nicht zu einer größeren Stichprobe.

• Geprüfter Python-Nachbaucode · PY
• Separater Nachbautest · JSON
• Vorab festgelegter Versuchsplan · JSON
• Alle 21 HTTP-Ergebnisse und Modellantworten · JSON
• Gateway-Metadaten ohne Prompttexte · JSON
• Beobachtete Modellweiterleitungen · JSON
• Modellkennung, Digest und Quantisierung · JSON
• Aufbau und Nachbaukriterien · TXT

Die Ollama-API-Dokumentation beschreibt den verwendeten Generate-Aufruf. Die Hersteller-FAQ erläutert die Bind-Adresse und das Abschalten der Cloudfunktionen. Das sind Dokumentationsbelege; die obigen Zähler stammen aus unserem eigenen Versuch.

$env:OLLAMA_HOST="127.0.0.1:11438"
$env:OLLAMA_NO_CLOUD="1"
ollama serve

python reproduce.py --design frozen-design.json --output eigener-test --ollama-port 11438

Unser zweiter Versuch: Rechte und echte Testaktionen

Ein erlaubter Lesezugriff ist kein Senderecht. Um diese Grenze tatsächlich auszuführen, haben wir einen zweiten lokalen Aufbau mit zwei getrennten HTTP-Diensten getestet. Zehn vorab festgelegte Fälle wurden je dreimal mit zurückgesetztem Zustand ausgeführt. Unter den 54 protokollierten HTTP-Anfragen waren 30 Versandversuche: Sechs erzeugten je eine neue lokale Outboxzeile; 24 abgelehnte Versuche erzeugten keine.

Was wirklich geprüft wurde

Lesen, Entwürfe und Versand hatten getrennte Zugänge. Das Backend verlangte für den Versand zusätzlich eine einmalige Freigabe für genau das Objekt aus Ticketkennung, Empfänger und Text. Die Freigabe kam von einem separaten, skriptgesteuerten Reviewer-Endpunkt. Nach jeder Anfrage wurden HTTP-Antwort und tatsächlicher SQLite-Zustand vor und nach der Aktion verglichen.

Welche Grenze daran sichtbar wird

Ein Read-Zugang konnte lesen, aber nicht senden. Senderecht allein genügte ebenfalls nicht. Der exakt freigegebene Inhalt erzeugte eine Outboxzeile; eine Wiederverwendung wurde mit HTTP 409 abgewiesen. Geänderter Text wurde mit HTTP 403 abgelehnt, während das ursprünglich freigegebene Objekt danach noch einmalig zulässig war. Ein formulierter Befehl im künstlichen Ticket veränderte die serverseitigen Rechte nicht.

Ein separater Nachbau mit neuen Ports und flüchtigen Testzugängen reproduzierte dieselben Zähler. Wir addieren ihn nicht zur ersten Stichprobe. In beiden Läufen wurden die eigenen Listener und Threads anschließend beendet; die SQLite-Integritätsprüfung bestand.

Was offen bleibt

Hier lief kein Sprachmodell und kein MCP. Es gab keine echte Person am Freigabepunkt und keine Zustellung per E-Mail. Der Anweisungstext prüft die Serverrechte, keine Reaktion eines Modells und keine Prompt-Injection-Abwehrrate. Parallele Replays, Ablaufzeiten, gestohlene Zugangswerte, TLS, Abstürze und Produktionsbetrieb wurden nicht geprüft. Der Aufbau ist ein Anschauungsversuch, keine einsatzfertige Sicherheitslösung.

python reproduce.py --output eigener-neuer-lauf

Inventarvorlage: vom Produktnamen zum konkreten Datenweg

Ein brauchbarer Eintrag beantwortet: Wer möchte was erreichen, mit welchem Zugang, welchen Daten und welchen Rechten? Notiere offene Fragen ausdrücklich. „Noch ungeprüft“ ist hilfreicher als ein unbegründetes Häkchen bei „sicher“.

Ausgefülltes Beispiel: Supportentwürfe

Vollständig fiktiv: Ein Supportteam möchte aus einer Anfrage einen Antwortentwurf erstellen. Es hat noch keine Freigabe für den vorgesehenen KI-Zugang. Das Beispiel enthält weder echte Kundendaten noch eine Anbieterbewertung.

Leere Inventarvorlage herunterladen (CSV) · Ausgefülltes fiktives Beispiel herunterladen (CSV). Beide Dateien lassen sich lokal in einer Tabellenkalkulation öffnen. Ein Download übermittelt keine ausgefüllten Einträge an Tokenwerk.

Bereich / verantwortliche Rolle:
Aufgabe und gewünschtes Ergebnis:
Produkt / Konto / konkrete Version:
Eingabedaten / Empfänger / Aufbewahrung:
Lese- und Schreibrechte / Ergebnisprüfung:
Freigabestatus / offene Fragen:
Erlaubte Alternative / nächster Prüfanlass:

Beschränke den Zugriff auf ausgefüllte Inventare passend zum Inhalt. Die Vorlagen verlangen keine Zugangsschlüssel, vollständigen Chats oder Dokumentkopien. Trage solche Inhalte dort auch nicht vorsorglich ein.

Vom Inventar zur Freigabe: dein Starterpaket

Die Werkstatt führt durch drei Aufgaben: Verwendung erfassen, Antrag vorbereiten, echte Entscheidung dokumentieren. Die fünf Prüffragen mit Variantenvergleich übernehmen deine Angaben in einen Antragsentwurf. Eine Datei oder Prüfliste ersetzt keine Prüfung durch die tatsächlich zuständige Rolle.

Ohne JavaScript kannst du den leeren Freigabeantrag als TXT herunterladen und die sieben Starterdateien als ZIP herunterladen. Die Dateien enthalten Inventar, fiktives Beispiel, Antrag, Entscheidungsvorlage, Musterentscheidung, Protokoll und Anleitung.

Vom Antrag zur tatsächlichen Entscheidung

1. Eine Verwendung mit Aufgabe, Zugang, Datenkategorien und Rechten erfassen.
2. Offene Fragen, einen begrenzten Test mit künstlichen Daten und eine erlaubte Alternative festhalten.
3. Den Entwurf über den vorgesehenen internen Abstimmungsweg der zuständigen Rolle vorlegen.
4. Nur echte Nachweise und die tatsächlich getroffene Entscheidung dokumentieren. Bei geänderten Daten oder Rechten erneut prüfen.

Das durchgehende Beispiel TW-SHA-001 ist vollständig erfunden. Es enthält keine reale Anbieterprüfung. Komplette Chats, Dokumentkopien und Schlüssel gehören nicht in die Vorlagen.

So nutzt du Selbstcheck und Starterpaket

Die Videoanleitung führt in 2:23 Minuten durch einen vollständig fiktiven Fall: Angaben einordnen, die Prüfliste lesen, eine Alternative vergleichen und einen offenen Antragsentwurf vorbereiten. Mit deutscher Sprachspur, zuschaltbaren Untertiteln und Textfassung.

1. Eine konkrete Aufgabe beschreiben und fünf Fragen beantworten; keine echten Dokumentinhalte oder Zugangsdaten eintragen.
2. Die vollständige Prüfliste einschließlich weiterer Befunde und nächster Schritte lesen.
3. Eine geplante Alternative vergleichen. Ein unbekannter Freigabestatus bleibt offen.
4. Ausgangslage oder Alternative ausdrücklich für den Antragsentwurf wählen, offene Angaben ergänzen und die Vorschau prüfen.
5. Den Entwurf bewusst exportieren. Ein JSON-Arbeitsstand lässt sich später lokal wieder öffnen.

Sprechertext herunterladen · TXT · Deutsche Untertitel · VTT

Drei Situationen selbst einordnen

Prüfe zuerst Daten und Rechte, dann die gewünschte Wirkung. Die folgenden Fälle sind redaktionelle Übungen, keine gesetzliche Risikoklassifizierung. Überlege jeweils: Was darf jetzt weitergehen, was muss zuerst geklärt werden?

Priorisiere ungeklärte vertrauliche Eingaben und weitreichende Aktionsrechte. Danach folgen wiederkehrende Abläufe mit vielen Datensätzen oder Beteiligten. Biete für Erprobung einen begrenzten Weg mit Testmaterial an, statt jede Aufgabe ungeklärt liegenzulassen.

Was tun, wenn bereits Daten übertragen wurden?

Stoppe weitere Übermittlungen und informiere den vorgesehenen internen Kontakt. Notiere Zeitpunkt, Kontotyp, vermutete Datenkategorien und betroffene Verbindung, ohne den Inhalt unnötig erneut zu verteilen. Ein möglicherweise offengelegter Zugangsschlüssel gehört in den betrieblichen Sicherheitsprozess.

Ob eine Meldung, Benachrichtigung oder weitere Maßnahme erforderlich ist, hängt vom konkreten Sachverhalt ab. Versuche nicht, das durch das bloße Löschen eines sichtbaren Chats abschließend zu beurteilen. Datenschutz- und Sicherheitsverantwortliche brauchen die relevanten Fakten.

Aus der Bestandsaufnahme wird ein erlaubter Arbeitsweg

1. Aufgabe aufnehmen: gewünschtes Ergebnis, benötigte Daten und fehlende Alternative festhalten.
2. Einsatz prüfen: Zugang, Empfänger, Aufbewahrung, Rechte und Ergebnisprüfung durch die zuständigen Rollen klären.
3. Verständlich entscheiden: erlaubten Umfang dokumentieren oder einen begründeten Ersatz anbieten. Eine Ablehnung ohne Arbeitsweg löst die ursprüngliche Aufgabe nicht.
4. Änderungen nachprüfen: bei neuem Kontotyp, Modell, Connector oder Aktionsrecht den Eintrag erneut prüfen; verantwortliche Rolle und nächsten Anlass festhalten.

Eine praktische KI-Richtlinie hält fest, welcher Zugang für welche Daten und Aufgaben vorgesehen ist. Der Prozess braucht eine erreichbare Person, einen überschaubaren Antrag und eine Antwort, mit der das Team weiterarbeiten kann.

Dein erster Schritt: Wähle eine wiederkehrende Aufgabe und fülle dafür einen Inventareintrag aus. Wenn Datenweg oder Verantwortung offen sind, ist genau das das Ergebnis der ersten Prüfung – kein Anlass, eine Freigabe zu behaupten.