Trend

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).

Alle

Abgrenzung: Governance vs Detection vs KI-Angriffe

Diese Seite behandelt AI Governance als organisatorisch-regulatorisches Rahmenwerk: Richtlinien, Rollen, Freigaben, Nachweise. Wie man nicht genehmigte KI-Nutzung im Netz erkennt und stoppt, steht auf Schatten-KI-Detection. Wie Angreifer KI zur Skalierung von Attacken nutzen, steht auf KI-getriebene Cyberangriffe. Wie das SOC KI defensiv einsetzt, steht auf KI im SOC. Für die Grundfrage, warum ein SOC überhaupt gebraucht wird, siehe SOC as a Service Schweiz.

Kurzform

Governance definiert, was erlaubt ist und wer es freigeben darf. Detection prüft, ob es eingehalten wird. Ohne Detection bleibt jede Richtlinie eine Absichtserklärung.

Regulatorischer Rahmen

  • revDSG: KI-Nutzung, die Personendaten verarbeitet, unterliegt den Grundsätzen (Zweckbindung, Verhältnismässigkeit, Transparenz); automatisierte Einzelentscheidungen erfordern Information der betroffenen Person und ggf. eine menschliche Überprüfung. Siehe revDSG und SOC.
  • FINMA: Beaufsichtigte Institute müssen KI-gestützte Prozesse in ihr Operational-Risk- und Outsourcing-Management einbinden; Modell-Governance, Bias-Kontrolle und Nachvollziehbarkeit sind erwartete Praktiken. Siehe SOC & FINMA-Anforderungen.
  • ISG: Betreiberinnen kritischer Infrastrukturen bleiben für KI-gestützte Prozesse voll verantwortlich; Cyber-Vorfälle mit KI-Bezug fallen unter die 24-Stunden-Meldepflicht ans BACS (Bundesamt für Cybersicherheit). Siehe SOC & ISG-Meldepflicht.
  • EU AI Act: Wer KI-Systeme in der EU anbietet oder deren Ausgaben in der EU nutzt, unterliegt gestaffelten Pflichten je Risikoklasse (verboten, hochrisiko, transparenzpflichtig, minimal). Für Schweizer Unternehmen mit EU-Kundschaft oder EU-Tochter besteht Anwendungsbezug; Hochrisiko-Systeme brauchen Risiko-Management, Datenqualität, Logging, menschliche Aufsicht und Konformitätsbewertung.
  • Vertragsrecht: Nutzung von Cloud-KI (OpenAI, Anthropic, Google, Mistral, Azure OpenAI) erzeugt Auftragsbearbeitungsverhältnisse; Datenklassifikation, geografischer Verarbeitungsort und Retention müssen vertraglich geregelt sein.

Bausteine eines verlässlichen Governance-Rahmens

BausteinWas er regeltNachweis für den Auditor
AI-RichtlinieZugelassene Modelle, Datenklassen, verbotene Use-Cases, Freigabeprozess.Signierte Richtlinie mit Version und Reviewer, Schulungsnachweis der Mitarbeitenden.
Rollen und VerantwortlichkeitenAI-Owner, Data-Owner, Security-Owner, Rechtsverantwortliche pro System.RACI-Matrix pro produktivem KI-System.
Modell- und Use-Case-RegisterWelche Modelle in welcher Version wo im Einsatz sind, mit Risikoklasse.Aktuelles Register, verlinkt mit Verträgen und Datenschutz-Folgenabschätzung.
Datenschutz-FolgenabschätzungPflicht bei hohem Risiko (revDSG Art. 22); dokumentiert Zweck, Datenkategorien, Massnahmen.Unterzeichnete DSFA, Konsultation EDÖB wenn Restrisiko hoch bleibt.
Technische KontrollenDLP für Prompts, sanktionierte KI-Gateways, Prompt- und Output-Logging, Rate-Limits.Log-Auszüge, Konfigurations-Baseline, Detection-Regeln im SIEM.
Monitoring und DetectionSOC erkennt nicht genehmigte KI-Endpunkte, ungewöhnliche Datenmengen und sensitive Inhalte in Prompts.Use-Cases, Alerts, Playbooks; siehe Schatten-KI-Detection.

Vom Governance-Beschluss zur SOC-Detection

  1. Richtlinie definiert erlaubte KI-Endpunkte und Datenklassen. Jede Freigabe entsteht mit einem Owner und einer Klassifikation.
  2. Identity-Provider erzwingt Zugriff auf sanktionierte KI-Gateways nur über verwaltete Konten und Geräte. Personal Accounts werden blockiert.
  3. DLP-Regeln filtern Prompts auf sensitive Muster (Kundendaten, Kreditkarten, Quellcode-Signaturen, Vertrauensklassifikationen).
  4. Netzwerk-Telemetrie und Proxy-Logs fliessen ins SIEM; SOC hat Use-Cases für nicht sanktionierte Domains und Datenexfiltration über HTTPS. Siehe ITDR für die Identity-Seite.
  5. Incident-Response-Playbook für KI-Vorfälle ist Teil des Incident-Response-Plans: Wer isoliert die Session, wer entscheidet über Meldepflicht, wer kommuniziert an den EDÖB.
  6. Quartalsweises Review von Modell-Register, Auditlogs und Detection-Regeln. Änderungen werden versioniert.
Der teure Fehler

Eine Richtlinie ohne Detection ist keine Governance, sondern ein Wunsch. Ohne Log der Prompts, ohne Netz-Sichtbarkeit auf KI-Endpunkte und ohne SIEM-Use-Cases bleibt die Frage, ob sich Mitarbeitende an die Regeln halten, unbeantwortet und unbelegbar.

Rechtsgrundlagen und Quellen

Häufige Fragen

Gilt der EU AI Act auch für reine Schweizer Unternehmen?

Direkt nicht, aber über die Marktzugangs-Brücke oft doch. Wer KI-Systeme in der EU anbietet, sie für EU-Kundschaft nutzt oder deren Ergebnisse in der EU verwertet, fällt in den Anwendungsbereich. Für Schweizer Konzerne mit EU-Töchtern ist die Konformität regelmässig relevant; für rein binnenschweizerische Nutzung greifen primär revDSG und sektorale Vorgaben.

Wo hört AI Governance auf und wo beginnt Schatten-KI-Detection?

Governance definiert Regeln, Rollen und Nachweise. Detection erkennt und stoppt Regelverstösse in der Praxis. Beides gehört zusammen; ohne Detection bleibt Governance unbelegbar, ohne Governance ist Detection ziellos. Siehe [Schatten-KI-Detection](/de/soc/schatten-ki-detection).

Ist ChatGPT Enterprise oder Copilot for M365 rechtlich unproblematisch?

Sie sind besser abgesichert als Consumer-Varianten, aber nicht automatisch konform. Verarbeitungsort, Retention, Trainings-Opt-out, Rollen unter revDSG und Vertragswerk mit dem Anbieter müssen individuell geprüft werden. Für FINMA-beaufsichtigte Institute sind zusätzlich Outsourcing-Regeln zu erfüllen.

Welche Rolle spielt das SOC in AI Governance?

Das SOC ist der operative Nachweis, dass Regeln eingehalten werden. Es liefert Detection auf nicht sanktionierte KI-Nutzung, Auditlogs für Prompts und Outputs, sowie Playbooks für KI-Vorfälle. Für die Anbindung an Meldepflichten siehe [Incident-Response-Plan](/de/soc/incident-response-plan-erstellen) und die Grundpflicht via [SOC as a Service Schweiz](/de/soc/soc-as-a-service-schweiz).

Wie oft muss der Governance-Rahmen überprüft werden?

Mindestens jährlich und bei jeder wesentlichen Änderung (neues Modell, neue Datenkategorie, neuer Anbieter, neue Regulierung). Modell-Register und Detection-Regeln sollten quartalsweise angeschaut werden, weil sich die Anbieterlandschaft und die Angriffsfläche schnell ändern.

Weiterlesen im Cluster
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).
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.
revDSG und SOC: Was das revidierte Datenschutzgesetz vom Sicherheitsbetrieb verlangt
Das revidierte Datenschutzgesetz (revDSG, in Kraft seit 1.9.2023) verlangt angemessene technische und organisatorische Massnahmen und einen Nachweis darüber. Führt eine Verletzung der Datensicherheit voraussichtlich zu einem hohen Risiko für die betroffenen Personen, ist sie dem EDÖB so rasch als möglich zu melden. Ein SOC liefert die Detection, die dokumentierte Reaktion und die Beweisspur, die für eine verlässliche Meldung an den EDÖB und die Information Betroffener nötig sind.
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

Verwandte Begriffe