Trend

Schatten-KI-Detection: Wenn Mitarbeitende KI unerlaubt nutzen

Schatten-KI beschreibt KI-Nutzung ausserhalb genehmigter Freigaben: private ChatGPT-Konten am Arbeitsplatz, Browser-Erweiterungen mit LLM-Anbindung, KI-Features in SaaS-Produkten, die niemand freigegeben hat. Das Risiko ist der unkontrollierte Abfluss von Kundendaten, Quellcode oder vertraulichen Dokumenten an einen Anbieter, der weder vertraglich gebunden noch dokumentiert ist. Schweizer Unternehmen brauchen technische Detection auf Netz-, Endpoint- und Identity-Ebene, um Schatten-KI sichtbar zu machen und dann in die Governance zurückzuführen. Für das Regelwerk siehe [AI Governance](/de/soc/ai-governance-security).

SOC as a ServiceAlleSchatten-KI-Detection: Wenn Mitarbeitende KI unerlaubt nutzen

Abgrenzung: Detection vs Governance vs DLP

Diese Seite behandelt Schatten-KI als Detection-Problem: Wie sieht man, dass Mitarbeitende KI ausserhalb der Freigabe nutzen? Was überhaupt erlaubt sein soll, wer freigibt und welche Nachweise nötig sind, gehört in den Governance-Rahmen; siehe AI Governance. Reine Data-Loss-Prevention ohne KI-Fokus zielt auf Daten-Exfiltration allgemein; Schatten-KI-Detection kombiniert DLP mit Netzwerk- und Identity-Signalen speziell auf KI-Endpunkte. Für die Grundpflicht eines SOC siehe SOC as a Service Schweiz.

Kurzform

Governance sagt was erlaubt ist. Detection zeigt, was tatsächlich passiert. Ohne Detection bleibt jede AI-Richtlinie eine Vermutung.

Typologie: Vier Wege, wie Schatten-KI entsteht

Weg	Beispiel	Was das Risiko ausmacht
Persönliches Web-Konto	Mitarbeitende öffnen ChatGPT, Claude oder Gemini mit privatem Login am Arbeitsgerät.	Prompt-Inhalte fliessen an einen Anbieter ohne Vertrag, ohne Verarbeitungsverzeichnis, oft mit Training auf Ausgaben.
Browser-Erweiterung mit LLM	Sidebars, Zusammenfassungs-Tools, KI-Assistenten in unmanaged Browsern.	Erweiterungen lesen Seiteninhalte automatisch mit; Berechtigungen sind meist zu breit.
KI-Feature in SaaS ohne Freigabe	Meeting-Recorder, CRM-Assistenten, Notion-KI, das ohne Datenschutz-Check aktiviert wurde.	Neue Sub-Prozessoren, veränderte Datenflüsse, ohne Update der Verarbeitungsverzeichnisse.
Entwickler-Tools mit LLM	IDE-Plugins, Code-Assistenten mit direktem API-Zugriff auf externe Modelle.	Quellcode, Secrets und Konfigurationen fliessen an externe Modelle; Lizenz- und Vertragsfragen offen.

Warum das in der Schweiz besonders zählt

revDSG: Wird Personendatenzugriff durch einen nicht sanktionierten KI-Anbieter wahrscheinlich, ist die Verletzung dem EDÖB so rasch als möglich zu melden, wenn sie voraussichtlich zu einem hohen Risiko für die betroffenen Personen führt. Die Verantwortung bleibt beim Verantwortlichen, auch wenn ein Mitarbeitender die Nutzung eigenmächtig gestartet hat. Siehe revDSG und SOC.
ISG: Betreiberinnen kritischer Infrastrukturen melden Cybervorfälle innert 24 Stunden ans BACS (Bundesamt für Cybersicherheit); ein Datenabfluss über Schatten-KI mit Wirkung auf die geschützte Funktion zählt genauso. Siehe SOC & ISG-Meldepflicht.
FINMA: Beaufsichtigte Institute melden wesentliche Cyber-Attacken nach Art. 29 Abs. 2 FINMAG (AM 05/2020, präzisiert durch AM 03/2024): Erstmeldung innert 24 Stunden ab Entdeckung, vollständige Meldung innert 72 Stunden. Die Nutzung eines nicht freigegebenen Cloud-KI-Dienstes für Kundendaten kann als Outsourcing- und Sicherheitsvorfall qualifizieren. Siehe SOC & FINMA-Anforderungen.
Berufsgeheimnisse: Anwaltsgeheimnis (StGB Art. 321), Bankkundengeheimnis (BankG Art. 47) und ärztliches Berufsgeheimnis werden durch Übermittlung an einen nicht sanktionierten KI-Anbieter potentiell verletzt, unabhängig von Datenschutzrecht.

Wirksame Detection auf drei Ebenen

Netzwerk: Proxy- und DNS-Logs auf bekannte KI-Endpunkte (openai.com, anthropic.com, mistral.ai, generativelanguage.googleapis.com, xai.com und weitere) plus Upload-Grössen. Ein Alert auf Traffic zu diesen Domains von nicht sanktionierten Konten liefert die erste Sicht. Kombination mit Attack-Surface-Management macht auch externe Angriffsflächen sichtbar.
Endpoint: EDR-Telemetrie erkennt neue Browser-Extensions, unbekannte Desktop-Assistenten und ungewöhnliche Prozesse mit Netzverbindungen zu KI-APIs. Managed-Browser-Policy schränkt Extensions ein.
Identity: SSO- und OAuth-Logs zeigen, welche KI-Apps in Google Workspace, Microsoft 365 oder Slack Berechtigungen bekommen haben. Persönliche Logins auf KI-Diensten fallen in ITDR auf; siehe ITDR.
DLP-Content-Regeln prüfen Prompts auf Kundendaten, Kreditkarten, AHV-Nummern, Quellcode-Signaturen und interne Klassifikationen. Blockade oder Warnhinweis je nach Kritikalität.
SIEM-Korrelation: Netz-Signal plus Identity-Signal plus DLP-Treffer wird zu einem Fall aggregiert; Threat-Hunting sucht nach neuen Endpunkten und veränderten TLS-SNI-Mustern. Siehe Threat Hunting Schweiz.
Response-Playbook: Case-Owner benachrichtigt Mitarbeitenden, Data-Owner beurteilt Datenklasse, DPO entscheidet über Meldung, IT sperrt Endpunkt oder Konto. Aufnahme in den Incident-Response-Plan.

Warum reine Blockade nicht reicht

Wer KI-Endpunkte pauschal sperrt, verschiebt die Nutzung auf private Geräte und Netze. Die Datenabflüsse werden unsichtbar, das Problem bleibt. Wirksam ist die Kombination aus sanktionierten Alternativen, klarer Kommunikation und lückenloser Detection.

Rechtsgrundlagen und Quellen

FINMA-Aufsichtsmitteilung 05/2020 «Meldepflicht bei Cyber-Attacken» (Art. 29 Abs. 2 FINMAG): finma.ch
FINMA-Aufsichtsmitteilung 03/2024, Präzisierung der Meldepflicht: finma.ch
ISG (SR 128), Art. 74a-74f: Fedlex
ISG-Meldepflicht beim BACS inklusive Wegeleitung: bacs.admin.ch
Meldung von Datensicherheitsverletzungen an den EDÖB: edoeb.admin.ch

Häufige Fragen

Wie unterscheidet sich Schatten-KI von klassischer Schatten-IT?

Der Mechanismus ist verwandt, aber die Datenflussrichtung ist heikler. Schatten-IT nutzt oft unbekannte Tools mit begrenztem Datenkontakt; Schatten-KI erzeugt hochvolumige Übermittlungen an lernende Systeme, oft mit Ausgabewiederverwendung. Das erhöht das Risiko von Geheimnis- und Datenschutzverstössen erheblich.

Reicht ein DLP-Produkt allein aus?

Nein. DLP allein sieht Inhalte, aber nicht immer den KI-Kontext, und wird durch verschlüsselte Verbindungen und personal accounts umgangen. Wirksam wird es erst mit Netz- und Identity-Telemetrie im SIEM und mit einem SOC, das die Signale korreliert. Siehe [SOC as a Service Schweiz](/de/soc/soc-as-a-service-schweiz).

Wie geht man mit KI-Features in bestehender SaaS um?

Jede Aktivierung eines KI-Features durch den Anbieter braucht einen Change-Check: neuer Sub-Prozessor, veränderter Datenfluss, ggf. neue Datenschutz-Folgenabschätzung. Ein Vendor-Alert-Prozess ist Teil der Governance; die Detection erkennt zusätzlich, ob das Feature bereits Traffic erzeugt. Siehe [AI Governance](/de/soc/ai-governance-security).

Was tun bei einem konkreten Verdachtsfall?

Case im SOC eröffnen, Session isolieren, Prompt-Inhalte und Übermittlungsvolumen sichern, Data-Owner und DPO einbinden, Meldepflicht prüfen. Wenn der Vorfall unter revDSG, FINMA oder ISG fällt, gelten die dortigen Fristen. Ablauf im [Incident-Response-Plan](/de/soc/incident-response-plan-erstellen).

Wie oft werden neue KI-Endpunkte publik?

Faktisch monatlich. Neue Anbieter, neue Modelle, neue Sub-Domains: eine statische Blockliste veraltet schnell. Detection muss auf Verhalten setzen (grosse Uploads an unbekannte APIs, TLS-SNI-Muster typischer LLM-Gateways) und den Endpunkt-Katalog laufend pflegen.

Weiterlesen im Cluster

AI Governance: Wie Schweizer Unternehmen KI-Nutzung sicher steuern

AI Governance ist das Rahmenwerk aus Richtlinien, Rollen, Kontrollen und Nachweisen, mit dem ein Unternehmen KI-Nutzung sicher, rechtskonform und überprüfbar betreibt. In der Schweiz treffen revDSG, sektorale Regelungen (FINMA, ISG) und der EU AI Act (für Anbieter mit EU-Bezug) aufeinander. Diese Seite beschreibt, wie Governance-Entscheide (welche Modelle, welche Datenklassen, welche Freigaben) in technische Kontrollen und SOC-Detection übersetzt werden. Für die operative Erkennung nicht genehmigter KI-Nutzung siehe [Schatten-KI-Detection](/de/soc/schatten-ki-detection).

KI-getriebene Cyberangriffe: Was sich real verändert, und was Marketing ist

Generative KI verändert Cyberangriffe nicht in der Technik, sondern in Skalierung, Sprachqualität und Personalisierung. Phishing in fehlerfreiem Schweizerdeutsch, Deepfake-Vishing gegen die Finanzabteilung, automatisch generierter Malware-Code und LLM-gesteuerte Reconnaissance sind heute Realität. Was gleich bleibt: die Kill-Chain, die Detection-Logik und die Bedeutung schneller Response. Was sich ändert: Volumen, Qualität und die Fähigkeit, Sicherheitskontrollen zu umgehen, die auf sprachliche oder verhaltensbezogene Auffälligkeiten setzen.

KI im SOC: Wo sie hilft, wo sie schadet, und wo die Grenze zum Marketing liegt

KI im SOC ersetzt keine Analysten, sie entlastet sie. Der reale Nutzen liegt in Alert-Triage, Korrelation über Datenquellen, Zusammenfassung forensischer Rohdaten und Vorschlägen für Response-Schritte. Wo KI schadet: unbeaufsichtigte Auto-Response ohne Analyst-Freigabe, halluzinierte Zusammenhänge in Reports und die Illusion, dass ein KI-Modul einen Detection-Engineering-Prozess ersetzt. ANOMAL setzt KI dort ein, wo sie deterministisch prüfbar ist, und behält den Analysten als Entscheidungsträger.

ITDR: Identity Threat Detection and Response für die Schweiz

ITDR (Identity Threat Detection and Response) erkennt Angriffe auf Identitäten selbst, nicht nur auf Endpoints oder Netzwerke. Ziel sind Konten, Tokens, Sessions, Berechtigungen und Identity-Provider wie Entra ID oder Okta. ITDR erweitert EDR und SIEM um Signale, die nur im Identity-Layer sichtbar sind: Impossible Travel, Consent-Phishing, Refresh-Token-Missbrauch, Rollen-Missbrauch, Angriffe auf Federation und Directory-Objekte. Für Schweizer Unternehmen mit M365, Entra ID und regulierten Prozessen ist ITDR heute so wichtig wie EDR vor fünf Jahren.

Incident-Response-Plan erstellen: Vorlage, Rollen, Meldeketten

Ein Incident-Response-Plan legt vor dem Ernstfall fest, wer entscheidet, wer benachrichtigt wird und in welcher Reihenfolge Systeme abgeschaltet, isoliert und wiederhergestellt werden. Er referenziert die fünf Kern-Kontrollen der Cyberversicherer (MFA, EDR, getrennte Backups, Patch-Prozess, dokumentierter IR-Plan selbst). Ausserdem bindet er die Meldefristen aus revDSG, ISG, FINMA und DORA verbindlich in Rollen und Zeiten ein. Ohne diesen Plan wird die 72-Stunden-Reaktion improvisiert und die Versicherungsleistung angreifbar.

Kurzdefinitionen im Glossar nachschlagen