Claude Code im Unternehmen: Was der CISO jetzt ­regeln muss

Generative KI ist längst im Arbeitsalltag angekommen — meistens ohne dass jemand es kontrolliert. Fünf Kontrollen, die ein Informationssicherheits-Management-System dafür braucht.

Die unbequeme Realität

Eine Mitarbeiterin schickt das Sitzungsprotokoll an ChatGPT, weil die KI eine bessere Zusammenfassung macht als sie selbst. Ein Entwickler kopiert den Code-­Auszug eines Kunden in Claude Code, um einen Bug schneller zu finden. Ein Sachbearbeiter lädt einen vertraulichen Vertrag in Gemini, das Verträge analysiert. Drei Beispiele, drei verschiedene Tools, drei Datenabflüsse — wahrscheinlich an einem einzigen Vormittag in einem mittelgrossen Schweizer Unternehmen.

Wer heute als CISO oder Informationssicherheitsbeauftragter behauptet, sein ISMS adressiere generative KI ausreichend, sollte kurz innehalten und überlegen, ob er die Frage tatsächlich beantworten kann: Wer in der Organisation nutzt welche AI-Tools mit welchen Daten? In den meisten Fällen lautet die ehrliche Antwort: keine Ahnung.


Hinzu kommt der Schweizer Rechtsrahmen. Das revidierte Datenschutzgesetz verlangt für jede Bearbeitung von Personendaten durch Auftragsbearbeiter (ein generatives KI-Tool kann genau das) eine vertragliche Grundlage und angemessene Schutzmassnahmen. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) hat in seinem Leitfaden zu KI-Modellen klargestellt, dass keine separate KI-Sondergesetzgebung nötig ist, weil das DSG bereits greift. Wer Personendaten unkontrolliert in öffentliche Modelle kippt, riskiert nicht nur einen Datenabfluss, sondern eine DSG-Verletzung.

Die gute Nachricht: Ein bestehendes ISMS hat alle nötigen Hebel, um generative KI zu adressieren, sie müssen nur konsequent gezogen werden. Fünf Kontrollen sind in der Praxis entscheidend.

Erstens: Eine AI-Nutzungsrichtlinie, die etwas regelt

Eine AI-Policy, die nur sagt «bitte vorsichtig sein», ist keine Policy. Brauchbare Richtlinien beantworten drei Fragen explizit: Welche Tools sind erlaubt? Welche Datenkategorien dürfen in welche Tools? Was tun, wenn der Verdacht besteht, dass Daten ungewollt geteilt wurden?

In der Praxis bewährt sich eine Drei-Listen-Struktur. Die grüne Liste enthält freigegebene Tools mit Enterprise-Vertrag und vertraglich zugesicherter Datenverarbeitung in der EU oder der Schweiz. Die gelbe Liste umfasst Tools, die für nicht-vertrauliche Inhalte erlaubt sind — etwa öffentliche Recherche, Übersetzung allgemein verfügbarer Texte. Die rote Liste benennt Tools, die nicht genutzt werden dürfen, sowie Datenkategorien, die generell nicht in Drittsysteme gelangen dürfen.


Wichtig: Die Listen müssen gepflegt werden. Eine AI-Policy von 2024 ist 2026 nicht mehr aktuell, neue Modelle, neue Anbieter, neue Funktionen kommen quartalsweise dazu.

Zweitens: Datenklassifizierung, die zu AI passt

Klassische Klassifizierungsmodelle unterscheiden öffentlich, intern, vertraulich, streng vertraulich. Für AI-Nutzung braucht es eine ergänzende Dimension: AI-Eignung. Welche Datenkategorien dürfen in welche Tool-Klassen? Eine Kundennummer in Klartext gehört auch in ein Enterprise-LLM nicht hinein. Ein anonymisierter Projektbericht hingegen kann durchaus in einem freigegebenen Tool zusammengefasst werden.


Wer die Klassifizierung nicht anpasst, schafft eine paradoxe Lage: Mitarbeitende halten sich an die ISMS-Regeln und verstossen gleichzeitig gegen jede Datenschutz-Praxis, weil die Regeln den AI-Anwendungsfall nicht abbilden.

Drittens: Lieferanten-Assessment für AI-Dienste

Ein AI-Anbieter ist ein Lieferant und gehört in das Lieferantenmanagement. Das klingt trivial, wird in der Praxis aber regelmässig übersprungen, weil die Tools so einfach beschafft werden können. Eine Kreditkarte, eine E-Mail-Adresse, ein Klick auf «Akzeptieren», und schon hat ein Marketing-Team ein neues Werkzeug, ohne Lieferanten-Assessment, ohne Datenschutz-Folgenabschätzung, ohne dass die IT etwas davon weiss.


Drei Fragen gehören in jedes Assessment: Wo werden die Daten verarbeitet und gespeichert? Werden Eingaben für Modell-Training verwendet, und gibt es vertraglich verlässliche Opt-out-Mechanismen? Welche Sub-Dienstleister sind beteiligt und kennt der Anbieter sie selbst? Die dritte Frage ist meist die aufschlussreichste.

Viertens: Logging und Erkennung

Es muss möglich sein, mindestens grobe Aussagen über die AI-Nutzung im Unternehmen zu treffen. Welche Domänen werden vom Firmennetz aufgerufen? Welche Cloud-Anwendungen tauchen in den DLP-Logs auf? Welche Browser-Erweiterungen sind installiert? Eine vollständige Überwachung ist weder realistisch noch verhältnismässig, aber ein Blindflug ist es auch nicht.

In den meisten Unternehmen gibt es bereits die nötigen Werkzeuge: ein modernes Endpoint-Tool, ein DNS-Filter, ein Cloud-Security-Modul. Sie müssen nur konfiguriert und ausgewertet werden. Wer das einmal macht, ist oft überrascht, welche AI-Dienste tatsächlich genutzt werden und welche nicht.

Fünftens: Awareness, die den Anwendungsfall trifft

Eine Schulung «Phishing erkennen» hilft nicht gegen unbedachte AI-Nutzung. Es braucht eigene Inhalte: konkrete Beispiele, was passiert, wenn ein Vertrag in ein öffentliches Tool gelangt; eine Demonstration, wie schnell ein Modell sensible Inhalte aus einem Prompt rekonstruiert; eine ehrliche Diskussion darüber, dass AI das Arbeitsleben tatsächlich erleichtert und dass es darum geht, die Nutzung in geordnete Bahnen zu lenken, nicht zu verbieten.


Das letzte Wort ist entscheidend. Eine Awareness, die mit der Realität der Mitarbeitenden bricht und ein generelles Verbot kommuniziert, wird ignoriert. Eine Awareness, die einen sicheren Pfad aufzeigt und vorgeführt wird, wird genutzt.

Was nicht funktioniert

Drei Ansätze, die ich in den letzten Monaten gesehen habe und die regelmässig scheitern: ein generelles Verbot von AI-Tools, das niemand prüft. Eine alleinige technische Sperre auf Netzwerkebene, die Mitarbeitende mit dem mobilen Hotspot des privaten Smartphones umgehen kann. Und die Vorstellung, eine einmal verfasste AI-Policy reiche für die nächsten zwei Jahre. Generative KI bewegt sich zu schnell für statische Regelwerke.

Fazit

Ein ISMS, das generative KI ignoriert, ist 2026 nicht mehr glaubwürdig. Die Werkzeuge sind vorhanden: Datenklassifizierung, Lieferantenmanagement, Logging, Awareness. Sie müssen auf den AI-Anwendungsfall geschärft und konsequent angewendet werden. Wer jetzt eine AI-Nutzungsrichtlinie erlässt, eine Tool-Liste pflegt und einmal im Quartal überprüft, was die Mitarbeitenden tatsächlich nutzen, hat den Grossteil des Risikos im Griff. Die Alternative ist nicht ein KI-freies Unternehmen. Die Alternative ist ein Unternehmen, in dem KI längst genutzt wird, nur ohne, dass es jemand mitbekommt.