Shadow-AI-Erkennung: Wie Sie unautorisierte KI-Nutzung finden, bewerten und steuern

Ihre Mitarbeitenden nutzen bereits KI. Die Frage ist, ob Sie davon wissen.

Ein Entwickler fuegt proprietaeren Quellcode in ChatGPT ein. Ein Marketing-Analyst laedt Kundendaten in ein Bildgenerierungstool hoch. Ein Mitglied des Finanzteams leitet sensible Anfragen ueber einen nicht genehmigten LLM-Endpunkt. Keine dieser Interaktionen erscheint in einem genehmigten Softwareverzeichnis.

Das ist Shadow AI: die Nutzung von KI-Tools innerhalb einer Organisation ohne Genehmigung von IT, Sicherheit oder Compliance. Sie taucht nicht in Software-Inventaren auf, sondern in Netzwerk-Logs. Und die Kluft zwischen Einfuehrung und Governance wird immer groesser. Bis eine Organisation ein nicht genehmigtes Tool entdeckt, wurden moeglicherweise bereits sensible Daten an einen Anbieter mit unbekannten Aufbewahrungs- und Trainingsrichtlinien gesendet.

Die Konsequenzen sind konkret. An KI-Anbieter gesendete Daten koennen gespeichert, fuer das Training verwendet oder durch Sicherheitsverletzungen offengelegt werden. Dies erzeugt Compliance-Risiken unter DSGVO, HIPAA, SOC 2 und branchenspezifischen Vorschriften, die Datenverarbeitungskontrollen erfordern. Lieferantenbeziehungen werden nicht nachverfolgt: keine Datenverarbeitungsvertraege, keine Sicherheitsbewertungen, keine vertraglichen Schutzklauseln.

Und wenn eine Aufsichtsbehoerde fragt, welche KI-Tools die Organisation einsetzt, wer sie nutzt und welche Daten sie verarbeiten, koennen die meisten Organisationen keine Antwort geben.

Warum traditionelle Sicherheitstools nicht ausreichen

Firewalls koennen Domains blockieren, aber sie koennen Traffic nicht als KI-bezogen kategorisieren oder das Risikoprofil eines KI-Anbieters bewerten. DLP-Systeme erkennen Muster in ausgehenden Daten, fuehren aber kein Register von KI-Tools. SIEM-Plattformen sammeln die Roh-Logs, die Hinweise auf KI-Nutzung enthalten, verfuegen jedoch nicht ueber die Erkennungslogik, um diese zu finden und zu klassifizieren.

Was benoetigt wird, ist ein System, das vorhandene Log-Daten aufnimmt, die Nutzung von KI-Tools identifiziert, das Risiko bewertet und einen Weg von der Erkennung zur Governance bietet.

Wie die Shadow-AI-Erkennung von VerifyWise funktioniert

Die Shadow-AI-Erkennung in VerifyWise ist passiv. Keine Agenten auf Endpunkten, keine Browser-Erweiterungen. Sie nimmt Log-Daten auf, die Organisationen bereits aus ihrer Sicherheitsinfrastruktur sammeln.

Log-Aufnahme

Zwei Aufnahmemethoden stehen zur Verfuegung. Eine REST-API akzeptiert JSON-formatierte Events und funktioniert mit SIEM-Systemen, benutzerdefinierten Log-Pipelines und Orchestrierungstools. Ein Syslog-Empfaenger auf TCP-Port 5514 akzeptiert Standard-Syslog-Nachrichten von Web-Proxys, Firewalls und Netzwerkgeraeten.

Parsing und Normalisierung

Roh-Logs kommen in verschiedenen Formaten an, abhaengig von der Quelle. Vier integrierte Parser verarbeiten die gaengigsten Unternehmensquellen: Zscaler Internet Access, Netskope Cloud Security, Squid-Proxy und ein generischer Key-Value-Parser fuer Systeme, die strukturierte key=value-Paare ausgeben. Jeder Parser extrahiert Zeitstempel, Quell-IP, Benutzername, Ziel-Domain, URL-Pfad, HTTP-Methode, uebertragene Bytes und ausgefuehrte Aktion und normalisiert sie dann in ein gemeinsames Event-Schema.

KI-Tool-Identifikation

Normalisierte Events werden mit einem kuratierten Register von ueber 50 KI-Tools und -Diensten abgeglichen, die nach Kategorie organisiert sind: LLM-Chatbots (ChatGPT, Claude, Gemini, Perplexity), Coding-Assistenten (GitHub Copilot, Cursor, Tabnine), Bildgeneratoren (Midjourney, DALL-E, Stable Diffusion), Schreibtools (Notion AI, Jasper, Grammarly) und Low-Code-KI-Plattformen (v0.dev, Bolt, Replit). Jeder Registereintrag enthaelt den Toolnamen, den Anbieter, zugehoerige Domains, die Standard-Risikoklassifizierung und Kategorie-Metadaten.

Die Erkennung geht ueber den Domain-Abgleich hinaus. Regex-Muster, die auf URI-Pfade angewendet werden, extrahieren spezifische Modellkennungen aus API-Traffic. Wenn eine Anfrage den AWS-Bedrock-Endpunkt mit einem Pfad erreicht, der anthropic.claude-3-opus enthaelt, oder wenn Traffic zu Azure OpenAI gpt-4-turbo im Deployment-Pfad referenziert, erfasst das System das spezifische aufgerufene Modell. Diese Extraktion auf Modellebene deckt AWS Bedrock, Azure OpenAI, Google Vertex AI und direkte API-Endpunkte der wichtigsten Anbieter ab.

Event-Anreicherung

Jedes erkannte Event wird mit organisatorischem Kontext angereichert. Der Benutzername wird mit Abteilung, Berufsbezeichnung und Vorgesetztem aus den SIEM-Daten korreliert. Dies ist fuer die Risikobewertung relevant: Ein Finanzanalyst, der auf ein nicht genehmigtes KI-Tool zugreift, birgt ein anderes Risiko als ein Entwickler, der dasselbe Tool nutzt.

Risikobewertung: vier gewichtete Faktoren

Jedes erkannte KI-Tool erhaelt einen zusammengesetzten Risiko-Score von 0 bis 100, der aus vier gewichteten Faktoren berechnet wird.

Genehmigungsstatus (40 %) ist der groesste Faktor. Ein nicht genehmigtes Tool ohne Governance-Eintrag erhaelt die maximale Strafe. Ein formell ueberprueftes und genehmigtes Tool erhaelt das Minimum. Tools in aktiver Ueberpruefung liegen dazwischen.

Datenrichtlinien-Compliance (25 %) bewertet die Sicherheitslage des KI-Anbieters. Verfuegt der Anbieter ueber SOC 2 Type II? Ist der Dienst DSGVO-konform mit einem veroeffentlichten Datenverarbeitungsvertrag? Verschluesselt der Anbieter Daten im Ruhezustand und waehrend der Uebertragung? Verwendet er Kundendaten fuer das Modelltraining? Anbieter mit Opt-out-Trainingsrichtlinien oder ohne veroeffentlichte Aufbewahrungsrichtlinie erhalten eine hoehere Risikobewertung.

Abteilungssensibilitaet (20 %) gewichtet die Nutzung aus den Bereichen Finanzen, Recht, Personalwesen und Unternehmensfuehrung hoeher als aus Marketing, Vertrieb oder Technik. Diese Abteilungen verarbeiten regulierte Daten (Finanzdaten, anwaltliche Privilegien, Mitarbeiter-PII, strategische Plaene), bei denen die Weitergabe an ein nicht ueberprueftes KI-Tool ueberproportionale Konsequenzen hat.

Nutzungsvolumen (15 %) normalisiert die Rohzahlen der Events gegenueber den organisatorischen Durchschnittswerten, um Ausreisser zu finden. Ein Tool, das das 10-fache des durchschnittlichen Verkehrsvolumens generiert, hat ein erhoehtes Risiko unabhaengig vom Genehmigungsstatus, da ein hohes Volumen auf eine tiefere Workflow-Integration und groessere Datenexposition hindeutet.

Risiko-Scores sind nicht statisch. Sie werden neu berechnet, wenn neue Events eintreffen, sich Nutzungsmuster verschieben und der Tool-Status sich im Governance-Prozess weiterentwickelt.

Alarmierung durch eine konfigurierbare Regel-Engine

Das Alarmierungssystem verfuegt ueber sechs konfigurierbare Ausloesertypen:

1. Neues KI-Tool erkannt - wird ausgeloest, wenn das System ein Tool erkennt, das noch nie im Verkehr der Organisation aufgetaucht ist
2. Nutzungsschwelle ueberschritten - wird ausgeloest, wenn die Event-Anzahl eines Tools ein konfigurierbares Limit innerhalb eines Zeitraums ueberschreitet
3. Zugriff aus sensibler Abteilung - wird ausgeloest, wenn Benutzer aus Abteilungen mit hoher Sensibilitaet auf ein Tool oder eine Tool-Kategorie zugreifen
4. Blockierte Zugriffsversuche - wird ausgeloest, wenn Logs zeigen, dass ein Proxy oder eine Firewall den Zugriff auf ein KI-Tool blockiert hat, was auf eine Absicht hinweist, selbst wenn der Zugriff verweigert wurde
5. Risiko-Score ueberschritten - wird ausgeloest, wenn der zusammengesetzte Risiko-Score eines Tools eine konfigurierbare Grenze ueberschreitet
6. Neuer Benutzer erkannt - wird ausgeloest, wenn ein bisher unbekannter Benutzer beginnt, auf ein bekanntes KI-Tool zuzugreifen

Jede Regel kann eine oder mehrere Aktionen ausloesen: Alarmbenachrichtigungen senden, Governance-Aufgaben mit Verantwortlichen und Fristen erstellen, eine Governance-Ueberpruefung starten oder Risikoeintraege erstellen. Abklingzeiten verhindern Alarm-Muedigkeit, indem sie wiederholte Benachrichtigungen fuer ein konfigurierbares Intervall unterdruecken. Empfaengerlisten werden pro Regel festgelegt, sodass eine Neues-Tool-Warnung das Sicherheitsteam erreicht, waehrend eine Warnung ueber eine sensible Abteilung an den Compliance-Beauftragten geht.

Von der Erkennung zur Governance in vier Schritten

Die meisten Organisationen, die sich mit Shadow AI befassen, hoeren bei der Erkennung auf. Sie identifizieren, welche Tools im Einsatz sind, erstellen einen Bericht und ueberlassen es manuellen Prozessen, ueber die naechsten Schritte zu entscheiden. VerifyWise schliesst diese Luecke mit einem Governance-Assistenten, der ein erkanntes Tool in ein verwaltetes, nachverfolgbares Asset umwandelt.

• Schritt 1: Zum Modell-Inventar hinzufuegen. Das erkannte Tool wird dem Modell-Inventar der Organisation hinzugefuegt. Felder werden mit Erkennungsdaten vorbefuellt: Toolname, Anbieter, primaere Domain, Kategorie, initialer Risiko-Score. Der Governance-Verantwortliche ueberprueft und ergaenzt diese Informationen.

• Schritt 2: Governance-Verantwortlichkeit zuweisen. Ein Verantwortlicher, ein Pruefer und ein Faelligkeitsdatum werden zugewiesen. Der Verantwortliche treibt die Bewertung voran; der Pruefer bietet eine zweite Kontrollebene; das Faelligkeitsdatum schafft Verbindlichkeit.

• Schritt 3: Risikobewertung. Eine strukturierte Bewertung erfasst die Datensensibilitaetsklassifizierung (welche Datentypen offengelegt werden), die Benutzeranzahl (wie viele Personen es nutzen) und die Abteilungsexposition (welche Funktionen betroffen sind). Dies fliesst in das VerifyWise-Risikoregister ein.

• Schritt 4: Modell-Lebenszyklus initiieren (optional). Das Tool kann in einen vollstaendigen Lebenszyklusprozess aufgenommen werden, der eine Sicherheitsueberpruefung des Anbieters, eine rechtliche Ueberpruefung der Nutzungsbedingungen und die Aushandlung eines Datenverarbeitungsvertrags ausloest.

Wenn ein Tool den Governance-Prozess durchlaeuft, aendert sich sein Status: Erkannt (keine Massnahme ergriffen), In Ueberpruefung (Governance gestartet), dann einer von vier Endzustaenden: Genehmigt (freigegeben), Eingeschraenkt (mit Bedingungen erlaubt), Blockiert (verboten) oder Verworfen (irrelevant oder Fehlalarm).

Dies erzeugt eine auditierbare Kette von "unbekanntes Tool im Netzwerkverkehr" ueber "Governance-Ueberpruefung mit zugewiesenem Verantwortlichen" bis hin zu "formal verwaltetes KI-Asset mit dokumentierter Genehmigungsentscheidung". Diese Kette ist das, wonach Regulierungsbehoerden und Pruefer suchen.

Analysen und Berichterstattung

Das Insights-Dashboard beginnt mit vier KPI-Karten: eindeutige entdeckte KI-Anwendungen, Gesamtzahl der KI-Nutzer ueber alle Tools, das Tool mit dem hoechsten Risiko, das derzeit erkannt wird, und die aktivste Abteilung nach Event-Volumen. Diese bieten eine Uebersicht auf Fuehrungsebene vor jeder detaillierten Analyse.

Vier Diagrammtypen bieten tiefere Einblicke. Ein Balkendiagramm der Tools nach Event-Volumen ordnet erkannte Tools nach Gesamtverkehr und zeigt, welche Tools die groesste Datenexpositionsflaeche haben. Ein Balkendiagramm der Tools nach eindeutigen Benutzern ordnet nach der Anzahl unterschiedlicher Benutzer und zeigt, welche Tools die breiteste Akzeptanz haben. Ein Kreisdiagramm der Benutzer nach Abteilung zeigt, wo sich die KI-Nutzung konzentriert. Ein Trendanalyse-Liniendiagramm verfolgt Gesamtereignisse, eindeutige Benutzer und neue Tool-Entdeckungen ueber konfigurierbare Zeitraeume von 30 Tagen bis zu einem Jahr.

Benutzeraktivitaetsdaten sind auf zwei Ebenen verfuegbar. Auf individueller Ebene: die Event-Zahlen jedes Benutzers, genutzte Tools, Risiko-Scores und Abteilung. Auf Abteilungsebene: aggregierte Nutzung, Top-Tools und maximale Risikoexposition, geeignet fuer Berichte an Abteilungsleiter und Compliance-Ausschuesse.

Datenaufbewahrung

Ein dreistufiges Aufbewahrungsmodell balanciert Detailtiefe mit Speicherplatz:

• Rohereignisse werden 30 Tage lang mit vollem Detail fuer forensische Untersuchungen und Detailanalysen aufbewahrt
• Taegliche Zusammenfassungen werden ein Jahr lang aufbewahrt und bieten aggregierte Uebersichten fuer Trendanalysen und Quartalsberichte
• Monatliche Zusammenfassungen werden dauerhaft aufbewahrt fuer Jahresvergleiche und regulatorische Anfragen, die mehrere Jahre umfassen

Alle Daten sind durchsuchbar, sortierbar und filterbar. Exporte stehen fuer Compliance-Workflows zur Verfuegung, die eine Datenextraktion fuer Pruefer oder regulatorische Einreichungen erfordern.

Was die Shadow-AI-Erkennung kann und was nicht

Es ist wichtig, den Umfang klar zu benennen. Die Shadow-AI-Erkennung arbeitet mit Netzwerk-Metadaten. Hier ist, was sie abdeckt und wo ihre Grenzen liegen.

Was sie leistet:

• Entdeckt die Nutzung von Cloud- und SaaS-KI-Tools aus Netzwerk-Logs ohne Endpunkt-Agenten oder Browser-Erweiterungen
• Identifiziert ueber 50 KI-Tools in fuenf Kategorien und extrahiert spezifische Modellnamen aus API-Traffic ueber AWS Bedrock, Azure OpenAI, Google Vertex AI und direkte Anbieter-Endpunkte
• Bewertet Risiken auf einer Skala von 0 bis 100 anhand vier gewichteter Faktoren: Genehmigungsstatus, Compliance-Haltung des Anbieters, Nutzungsvolumen und Abteilungssensibilitaet
• Alarmiert Teams ueber 6 Ausloesertypen mit 4 Aktionstypen (Benachrichtigungen, Aufgaben, Governance-Ueberpruefungen, Risikoeintraege)
• Wandelt erkannte Tools in verwaltete Assets um durch einen vierstufigen Assistenten, der Modell-Inventar-Eintraege erstellt, Verantwortliche zuweist und Risikobewertungen startet
• Parst 4 Log-Formate standardmaessig (Zscaler, Netskope, Squid, generisches Key-Value)

Was sie nicht leistet:

• Verschluesselten HTTPS-Inhalt inspizieren. Sie arbeitet mit Metadaten: Domains, URL-Pfade, Zeitstempel, Benutzerkennungen. Die Extraktion dieser Daten aus verschluesseltem Traffic erfordert einen TLS-abfangenden Proxy oder ein API-Gateway vorgeschaltet
• Lokal gehostete KI-Modelle erkennen (Ollama, lokale Llama-Instanzen, private Inferenz-Server). Diese erzeugen keinen externen Netzwerkverkehr
• Tatsaechliche Prompts, Antworten oder Konversationen erfassen. Sie arbeitet ausschliesslich mit Zugriffs-Metadaten: wer hat worauf zugegriffen, wann, aus welcher Abteilung, wie oft
• Traffic blockieren. Sie ist ausschliesslich beratend. Das Blockieren von Zugriffen erfordert die Konfiguration auf Proxy-, Firewall- oder DNS-Ebene
• Verhaltensbasierte Anomalieerkennung durchfuehren. Die Alarmierung ist regelbasiert mit expliziten Schwellenwerten, keine ML-gesteuerte Musteranalyse

Erste Schritte

Die Shadow-AI-Erkennung ist ein Modul in der VerifyWise KI-Governance-Plattform, neben Modell-Inventar, Risikomanagement, Compliance-Framework-Tracking und LLM-Evaluierungen. Wenn Ihre Organisation bereits Web-Proxy- oder Firewall-Logs sammelt, haben Sie die benoetigten Daten. Die Frage ist, ob Sie sie nutzen, um KI-Tools zu finden, bevor sie zu Compliance-Vorfaellen werden.

Entdecken Sie unsere Shadow-AI-Erkennung-Funktion, um zu sehen, wie passive logbasierte Erkennung, Risikobewertung und Governance-Workflows in einer einzigen Plattform zusammenkommen.

Buchen Sie eine Demo, um zu sehen, wie die Shadow-AI-Erkennung mit Ihrer bestehenden Log-Infrastruktur funktioniert, oder erkunden Sie die vollstaendige VerifyWise-Plattform, um zu sehen, wie Erkennung mit Governance verbunden ist.