Suche

Wonach suchen Sie?

Durchsuchen Sie Leistungen, Anwendungsfälle und unser Praxiswissen.

Mindestens 2 Zeichen eingeben

Beliebte Einstiege

Daten & Governance

Wie behandelt man einen KI-bezogenen Datenschutzvorfall?

Ein KI-Datenvorfall kann aus einer falschen Freigabe, einem Prompt, einer RAG-Quelle, einem Agenten-Tool oder einem Anbieterereignis entstehen. Die Reaktion muss Datenschutz, Sicherheit, Fachprozess und Anbieterkoordination verbinden.

Die kurze Antwort

Ein KI-bezogener Datenschutzvorfall wird wie jede mögliche Datensicherheitsverletzung sofort eingedämmt, dokumentiert und nach betroffenen Daten, Personen und Folgen bewertet. Nach Schweizer Recht muss der Verantwortliche eine Verletzung, die voraussichtlich zu einem hohen Risiko für Persönlichkeit oder Grundrechte führt, dem EDÖB so rasch wie möglich melden; die Information Betroffener ist separat zu prüfen.

Kurz zusammengefasst

  • Fehlausgaben und Sicherheitsvorfälle sind nicht dasselbe, können sich aber überschneiden.
  • Prompts, Antworten, Tool-Aufrufe und Berechtigungen sind wichtige Beweismittel.
  • Der Auftragsbearbeiter informiert den Verantwortlichen so rasch wie möglich; der Verantwortliche bewertet das Risiko und trifft den gesetzlichen Meldeentscheid.
  • Die gesetzliche Meldeentscheidung folgt dem Risiko für betroffene Personen, nicht der medialen Sichtbarkeit.
  • Auch nicht meldepflichtige Ereignisse sollten dokumentiert und zur Verbesserung genutzt werden.

Zuerst klären, was geschehen ist

Eine Datensicherheitsverletzung liegt nach Schweizer Recht vor, wenn Personendaten unbeabsichtigt oder widerrechtlich verlorengehen, gelöscht, vernichtet oder verändert werden oder Unbefugten offengelegt oder zugänglich gemacht werden. Eine falsche fachliche Antwort ohne Personendaten kann ein Qualitätsvorfall sein, aber kein Datenschutzvorfall.

  • RAG zeigt Dokumente oder Passagen an unberechtigte Nutzer.
  • Ein Prompt oder Log enthält Personendaten und gelangt an einen falschen Empfänger.
  • Ein Agent schreibt oder löscht personenbezogene Datensätze ausserhalb seiner Befugnis.
  • Ein Anbieter oder Unterauftragnehmer meldet unbefugten Zugriff.
  • Ein manipuliertes Dokument löst eine Offenlegung über ein Tool aus.

Eindämmen, ohne wichtige Spuren zu verlieren

Die ersten Massnahmen sollen weitere Auswirkungen stoppen und gleichzeitig eine verlässliche Untersuchung ermöglichen. Das Vorfallteam muss Fachbereich, IT-Sicherheit, Datenschutz, Betrieb und gegebenenfalls Anbieter zusammenbringen.

  1. Schritt 1

    Eindämmen

    Berechtigungen der betroffenen Funktion oder des Connectors einschränken beziehungsweise Schlüssel sperren.

  2. Schritt 2

    Spuren sichern

    Zeitstempel, Prompts, Antworten, Tool-Aufrufe, Rollen und Änderungen unverändert sichern.

  3. Schritt 3

    Umfang bestimmen

    Betroffene Daten, Personen, Empfänger, Systeme und Zeiträume eingrenzen.

  4. Schritt 4

    Anbieter koordinieren

    Vertragliche Vorfallkanäle nutzen und belastbare Fakten sowie Massnahmen anfordern.

Der Auftragsbearbeiter meldet, der Verantwortliche bewertet

Nach Artikel 24 Absatz 3 DSG muss ein Auftragsbearbeiter eine Verletzung der Datensicherheit dem Verantwortlichen so rasch wie möglich melden. Er sollte bekannte Fakten weitergeben und laufend ergänzen, statt auf eine vollständige Ursachenanalyse zu warten.

Der Verantwortliche bleibt zuständig, das Risiko für Betroffene zu bewerten, bei voraussichtlich hohem Risiko den EDÖB zu informieren und über die Information Betroffener zu entscheiden. Verträge sollten deshalb einen sofortigen Vorfallkanal, Zugriff auf Nachweise und Nachmeldepflichten festlegen, ohne die Erstmeldung des Auftragsbearbeiters von der rechtlichen Meldeschwelle des Verantwortlichen abhängig zu machen.

  • Auftragsbearbeiter: im eigenen Bereich eindämmen, Spuren sichern, Verantwortlichen alarmieren und verifizierte Updates liefern.
  • Verantwortlicher: gesamten Datenfluss koordinieren, Folgen und Schutzmassnahmen bewerten, Entscheid dokumentieren und erforderliche Meldungen vornehmen.
  • Gemeinsam: Unterauftragnehmer, Empfänger und betroffene Funktionen ermitteln und eine belastbare Zeitlinie führen.

Risiko und Meldepflicht getrennt von der Technik bewerten

Die Bewertung betrachtet Art und Sensitivität der Daten, Zahl und Verwundbarkeit betroffener Personen, mögliche Folgen, tatsächlichen Zugriff und Wirksamkeit von Schutzmassnahmen. Unter dem Schweizer DSG ist die Schwelle für die Meldung an den EDÖB das voraussichtlich hohe Risiko.

  • Meldung an den EDÖB so rasch wie möglich, wenn die gesetzliche Schwelle erreicht ist.
  • Betroffene informieren, wenn dies zu ihrem Schutz erforderlich ist oder der EDÖB es verlangt.
  • Weitere anwendbare Fristen und Stellen, etwa nach DSGVO oder Sektorrecht, separat prüfen.
  • Entscheid, verfügbare Fakten, Unsicherheiten und Nachmeldungen dokumentieren.
  • Keine pauschale 72-Stunden-Regel aus der DSGVO auf jeden Schweizer Fall übertragen.

Den Entscheid dokumentieren und dem EDÖB die nötigen Angaben liefern

Jede bewertete Verletzung braucht einen internen Entscheidungsnachweis, auch wenn das Ergebnis lautet, dass keine Meldung erforderlich ist. Er sollte den damaligen Informationsstand, die Risikobegründung und spätere Korrekturen nachvollziehbar machen.

Interner Entscheidungsnachweis
Erfassungszeit und Ereignisablauf, betroffene Systeme, Daten und Personen, bekannte oder mögliche Empfänger, wahrscheinliche Folgen, vorhandene Schutzmassnahmen, Unsicherheiten, Eindämmung und Behebung, Melde- und Informationsentscheid, verantwortliche Personen sowie spätere Updates festhalten.
Meldung an den EDÖB
Eine erforderliche Meldung enthält die Art der Verletzung; soweit möglich Zeitpunkt und Dauer; Kategorien und ungefähre Anzahl betroffener Personen sowie betroffener Personendatensätze; Folgen; getroffene oder vorgesehene Massnahmen; sowie Name und Kontaktdaten einer Ansprechperson. Noch nicht verfügbare Angaben sind bei neuen Erkenntnissen so rasch wie möglich nachzureichen.
Gesetzliche Aufbewahrung nach einer Meldung
Wird eine Verletzung nach Artikel 24 DSG gemeldet, müssen Sachverhalt, Auswirkungen und getroffene Massnahmen ab der Meldung mindestens zwei Jahre dokumentiert bleiben. Eine längere interne Incident-Aufbewahrung kann sinnvoll sein, sollte aber separat festgelegt und mit Zweck sowie anwendbaren Pflichten begründet werden.

Nach dem Vorfall System und Governance verbessern

Die Behebung endet nicht mit einem Patch. Ursachen können in Rechten, Datenklassifikation, fehlenden Tests, unklarer Verantwortung oder einer Produktänderung liegen. Korrekturen müssen deshalb technische und organisatorische Ebenen abdecken.

  • Zugriffs- und RAG-Tests um den Vorfall erweitern.
  • Agentenrechte, Freigaben und Stop-Bedingungen verschärfen.
  • Datenregeln, Schulung und Meldekanäle präzisieren.
  • Anbieter- und Unterauftragnehmerkontrollen aktualisieren.
  • AI-Inventar, DSFA, Runbook und Risikobewertung nachführen.
  • Wirksamkeit der Massnahmen durch einen Wiederholungstest belegen.
Beispiel aus dem Unternehmensalltag

Beispiel: Falsche Berechtigungsvererbung im Wissensassistenten

Nach einer Änderung zeigt der Assistent einer kleinen Nutzergruppe Auszüge aus vertraulichen Personaldokumenten. Das Team deaktiviert die betroffene Quelle, sichert Such- und Antwortprotokolle und ermittelt Nutzer, Dokumente und Abrufe. Datenschutz und Sicherheit bewerten mögliche Folgen und Meldepflichten. Danach wird die Berechtigungsprüfung korrigiert, mit negativen Testfällen ergänzt und vor Wiederaktivierung unabhängig geprüft.

Was Sie mitnehmen sollten

Erweitern Sie das bestehende Incident-Response-Verfahren um KI-Artefakte, Anbieterkanäle und fachliche Folgen. Üben Sie den Ablauf, bevor ein echter Vorfall Zeitdruck erzeugt.

Quellen und Vertiefung

Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.

Inhaltlich geprüft

Stand: 17. Juli 2026. Allgemeine Einordnung, keine Rechtsberatung. Die konkrete Rechtslage und der anwendbare Geltungsbereich sind für den jeweiligen Einsatz zu prüfen.

Sie möchten das auf Ihre Situation übertragen?

Wir klären gemeinsam, was für Ihren Prozess, Ihre Daten und Ihre Systeme sinnvoll ist – verständlich und ohne unnötige Komplexität.

Projekt besprechen