DatenTrainings-, Kontext- und Eingabedaten schützen.
Bei KI-Systemen prägen Daten das Verhalten, nicht nur den Inhalt. Diese Seite zeigt den Datenlebenszyklus, Herkunft und Rechtsgrundlage, Zugriffskontrolle entlang des Datenflusses, Integrität, Schutz neuer Artefakte, Datenqualität und Bias-Erkennung, Privacy-Enhancing Technologies sowie Löschung im Modellkontext.
Rechtsstand: 11. Oktober 2026. AI Act in der Fassung der Verordnung (EU) 2026/1744. AI Act und DSGVO sind EU-Recht und für Schweizer Unternehmen nur bei EU-Bezug anwendbar (Art. 2 AI Act, Art. 3 DSGVO). Das revDSG gilt direkt.
Daten formen
das Verhalten.
Ein klassisches System führt aus, was programmiert wurde. Ein KI-System verhält sich so, wie es seine Daten geprägt haben. Das gilt für Trainings- und Feinabstimmungsdaten, für Wissensbasen im Abruf (Retrieval-Augmented Generation, RAG) und für die Eingaben im Betrieb.
Bausteine und Vertrauensgrenzen der Anwendung stehen in der Architektur-Referenz. Schutzklassen und Inventar behandelt Inventar und Klassifizierung, die Datenschutz-Folgenabschätzung die Seite Folgenabschätzungen.
Das gemeinsame Informationsblatt «AI Data Security» der NSA, der CISA, des FBI und von Behörden aus Australien, Neuseeland und dem Vereinigten Königreich (22.05.2025) ordnet drei Risikobereiche den Phasen des Lebenszyklus zu: Datenlieferkette, böswillig veränderte Daten und Datendrift. Es nennt zehn Massnahmen bis zur sicheren Löschung. Das Blatt ist eine Empfehlung, kein Gesetz.
Sieben Stationen,
sieben Risiken.
| Station | Daten | Hauptrisiko |
|---|---|---|
| 1 · Beschaffung | Rohdaten, Fremddatensätze, Lieferantendaten | Unklare Herkunft, fehlende Rechtsgrundlage, Vergiftung |
| 2 · Aufbereitung | Bereinigte, annotierte, pseudonymisierte Kopien | Neue Datensammlung ohne Schutz |
| 3 · Training und Feinabstimmung | Trainings-, Validierungs-, Testdaten | Manipulation, Abfluss über die Gewichte |
| 4 · Wissensbasis | Dokumente, Chunks, Embeddings | Rechte der Quelle gehen verloren |
| 5 · Betrieb | Prompts, Dateien, Antworten | Vertrauliche Eingaben, Übernahme in Training |
| 6 · Protokolle | Anfragen, Antworten, Aktionen | Protokoll als Zweitkopie sensibler Inhalte |
| 7 · Löschung | Alle obigen | Daten bleiben im Modell oder in Sicherungen |
Erst klären,
dann verwenden.
Nach DSGVO braucht jede Verarbeitung von Personendaten eine Rechtsgrundlage, auch jeder Schritt mit einer KI-Anwendung (DSK-Orientierungshilfe KI und Datenschutz, 06.05.2024, Ziff. 1.5). Das gilt für Trainingsdaten ebenso wie für Referenzdokumente in der Vektordatenbank (DSK-Orientierungshilfe zu RAG, Oktober 2025, Ziff. 3.6). Das revDSG kennt für private Verantwortliche keinen Erlaubnisvorbehalt: Massgebend sind die Grundsätze nach Art. 6 und, bei einer Persönlichkeitsverletzung, ein Rechtfertigungsgrund nach Art. 31; Bundesorgane brauchen eine gesetzliche Grundlage (Art. 34).
| Grundsatz | Schweiz (revDSG, SR 235.1) | EU/Deutschland (DSGVO) |
|---|---|---|
| Rechtmässigkeit, Einwilligung | Art. 6 Abs. 1; Einwilligung gültig nur bei Freiwilligkeit und Information (Abs. 6), ausdrücklich bei besonders schützenswerten Daten (Abs. 7 Bst. a) | Art. 5 Abs. 1 Bst. a, Art. 6; besondere Kategorien Art. 9 |
| Zweckbindung | Art. 6 Abs. 3 | Art. 5 Abs. 1 Bst. b |
| Verhältnismässigkeit, Datenminimierung, Vernichtung | Art. 6 Abs. 2 und 4 | Art. 5 Abs. 1 Bst. c und e |
| Technik und Voreinstellungen | Art. 7 | Art. 25 |
| Datensicherheit | Art. 8 | Art. 32 |
Bei öffentlich zugänglichen Daten reicht eine Rechtsgrundlage für das Training allein nicht. Die DSK-Orientierungshilfe zu technischen und organisatorischen Massnahmen (Juni 2025, Ziff. 2.1) nennt als Voraussetzung zusätzlich, dass der Datensatz nicht offensichtlich rechtswidrig entstanden ist, etwa durch eine Datenpanne, und verweist dazu auf die Stellungnahme 28/2024 des Europäischen Datenschutzausschusses. Als Dokumentation empfiehlt sie «Datasheets for datasets».
- Datenblatt je Datensatz: Inhalt, Quelle mit Version und Datum, Erhebungskontext, ursprünglicher Zweck, Rechtsgrundlage.
- Prüffrage Personenbezug: Lässt sich das Ziel mit synthetischen oder anonymisierten Daten erreichen? Nicht benötigter Personenbezug wird spätestens bei der Aufbereitung entfernt.
Rechte müssen
mitwandern.
Ein Sprachmodell kennt keine Zugriffsrechte. Im Modell lässt sich nicht steuern, welcher Nutzer welche Information sehen darf, in der Datenbank davor schon (DSK-Orientierungshilfe zu RAG, Ziff. 3.3). Die Kontrolle muss an jeder Station gelten.
| Station | Gefahr | Kontrolle |
|---|---|---|
| Quellsystem | Export ohne Rechteprüfung | Export nur über freigegebene Konnektoren, Rechte der Quelle als Metadaten mitführen |
| Zwischenspeicher, Pipeline | Kopien mit weiterem Leserkreis | Schutzklasse der Quelle, Verschlüsselung, kurze Aufbewahrung |
| Trainingsumgebung | Zwischenversionen und Zwischenergebnisse mit Personenbezug | Need-to-know, Zugriffsprotokoll, keine langfristige Speicherung von Zwischenergebnissen (DSK-Orientierungshilfe TOM, Ziff. 2.2.7) |
| Vektordatenbank | Treffer über Rechtegrenzen hinweg | Rechte- und Rollenkonzept, Mandanten- oder funktionale Trennung, Rechteprüfung beim Abruf (DSK-Orientierungshilfe zu RAG, Ziff. 3.3, 3.4) |
| Quellenwechsel | Neue Daten, alter Leserkreis | Bei jeder neuen Datenquelle prüfen, ob alle Nutzer des Systems die Daten sehen dürfen (DSK-Orientierungshilfe TOM, Ziff. 2.4.7) |
| Modellgewichte | Daten sind für alle Nutzer des Modells potenziell abrufbar | Gewichte nur mit Daten einer Schutzklasse und eines Leserkreises trainieren |
Die letzte Zeile ist eine Folgerung dieser Seite: Was in die Gewichte eingeht, trägt keine Rechte mehr. Membership Inference (NISTAML.033) und Reconstruction (NISTAML.032) beschreibt NIST AI 100-2 E2025 als Privatsphäre-Angriffe, die Trainingsdaten aus dem Modell ableiten. Datenflüsse von Agenten behandelt Agenten und MCP.
Veränderung
erkennbar machen.
- Prüfsummen: Hash-Werte über Rohdatensätze oder einzelne Datenpunkte speichern, um Veränderungen zu erkennen (DSK-Orientierungshilfe TOM, Ziff. 2.1.6). Das Informationsblatt der Behörden ergänzt digitale Signaturen für freigegebene Datenversionen.
- Quellenprüfung und Datenvalidierung: Vertrauenswürdigkeit der Quelle prüfen, Daten statistisch untersuchen. Beides wirkt gegen Data Poisoning (NISTAML.013).
- Vortrainierte Modelle: Vertrauenswürdigkeit vor dem Weitertrainieren prüfen, wegen Backdoor Poisoning (NISTAML.023). Siehe Lieferanten und Modelle.
- Trennung der Datensätze: Trainingsdaten dürfen im selben Lauf nicht zugleich für Validierung oder Test dienen (DSK-Orientierungshilfe TOM, Ziff. 2.2.6).
- Trennung der Umgebungen: Training und Produktion getrennt betreiben, mit eigenen Identitäten. Das ist eine Empfehlung dieser Seite.
Abgeleitetes erbt
die Schutzklasse.
Jede Aufbereitung erzeugt neue Bestände. Sie sind so schutzbedürftig wie ihre Quelle, auch wenn sie anders aussehen. Empfehlung dieser Seite: Die Schutzklasse der Quelle gilt, bis eine dokumentierte Prüfung etwas anderes ergibt.
| Artefakt | Schutz |
|---|---|
| Aufbereitete Datensätze | Klassifizierung erben, Hash und Version, Verschlüsselung |
| Chunks und Embeddings | Wie die Quelldokumente behandeln; Chunks enthalten Personendaten |
| Gewichte und Checkpoints | Signieren, Zugriff beschränken; Zwischenversionen können noch anfällig sein |
| Systemprompt, Konfiguration | Versionieren, Änderungen freigeben |
Art. 10 und
Art. 4a.
Gilt für Hochrisiko-KI-Systeme, die mit Daten trainiert werden. Abs. 2 verlangt Daten-Governance, unter anderem zu Herkunft (bei Personendaten auch zum ursprünglichen Erhebungszweck, Bst. b), Aufbereitung, Datenlücken und zur Untersuchung möglicher Verzerrungen (Bst. f) samt Gegenmassnahmen (Bst. g). Abs. 3 verlangt relevante, hinreichend repräsentative und so weit wie möglich fehlerfreie und vollständige Datensätze. Fristen: Fristenkalender.
Eingefügt durch Art. 1 Nr. 6 der Verordnung (EU) 2026/1744. Der bisherige Art. 10 Abs. 5 ist gestrichen. Anbieter von Hochrisiko-KI-Systemen dürfen besondere Kategorien von Personendaten ausnahmsweise verarbeiten, wenn dies zur Erkennung und Korrektur von Verzerrungen unbedingt erforderlich ist. Abs. 2 erweitert das auf Anbieter und Betreiber anderer KI-Systeme und -Modelle sowie auf Betreiber von Hochrisiko-KI-Systemen; er begründet keine Pflicht zur Bias-Erkennung und -Korrektur.
Die Ausnahme ist eng. Nach Art. 4a Abs. 1 müssen alle folgenden Bedingungen erfüllt sein:
- Das Ziel lässt sich mit anderen, auch synthetischen oder anonymisierten Daten nicht wirksam erreichen.
- Technische Beschränkung der Weiterverwendung, modernste Sicherheitsmassnahmen, einschliesslich Pseudonymisierung.
- Strenge, dokumentierte Zugriffskontrolle; Zugang nur für befugte Personen mit Vertraulichkeitspflicht.
- Keine Übermittlung an Dritte und kein Zugang Dritter.
- Löschung, sobald die Verzerrung korrigiert ist oder die Speicherfrist endet.
- Begründung im Verzeichnis der Verarbeitungstätigkeiten, warum die Verarbeitung unbedingt erforderlich war.
Die Bedingungen gelten zusätzlich zur DSGVO. Erwägungsgrund 9 der Verordnung (EU) 2026/1744 bezeichnet Art. 4a als Rechtsgrundlage, die DSGVO-Pflichten bleiben bestehen. Für Schweizer Verantwortliche ausserhalb des AI-Act-Anwendungsbereichs gelten die allgemeinen Regeln des revDSG; Art. 4a hilft ihnen nicht.
Unabhängig von der Risikoeinstufung bietet das BSI mit QUAIDAL einen Entwurf eines Kriterienkatalogs für Trainingsdaten im KI-Lebenszyklus an: zehn Qualitätskriterien, 143 Metriken und Methoden, von der Datenakquise über Bias-Erkennung bis zu Datenschutz und Audit.
Weniger Personenbezug,
gleicher Zweck.
| Technik | Wirkung | Einsatz und Quelle |
|---|---|---|
| Pseudonymisierung, Maskierung | Entfernt direkte Identifikatoren | Aufbereitung und Betrieb; für Art. 4a Abs. 1 Bst. b genannt |
| Anonymisierung, synthetische Daten | Kein Personenbezug im Datensatz | Vorrangig zu prüfen (Art. 4a Abs. 1 Bst. a; DSK-Orientierungshilfe TOM, Ziff. 2.1.1) |
| Differential Privacy | Begrenzt, was sich aus dem Modell über Einzelne ableiten lässt | Gegenmassnahme gegen die Preisgabe von Trainingsdaten (DSK-Orientierungshilfe TOM, Ziff. 2.1.7) |
| Federated Learning | Training ohne Zusammenführung der lokalen Daten | Beispiel für Datenminimierung (DSK-Orientierungshilfe TOM, Ziff. 2.1.2) |
| Tokenisierung | Ersetzt Werte durch Platzhalter | Vor dem Modellaufruf; Zuordnung bleibt in der Anwendung |
Jede Technik schützt nur gegen bestimmte Angriffe und kostet Genauigkeit oder Aufwand. Restrisiko gehört in die Risikobeurteilung. Werkzeugkategorie: Privacy Enhancing Technologies, Tokenisierung.
Löschen heisst:
auch im Modell.
Wird eine Einwilligung widerrufen (Art. 7 Abs. 3 DSGVO) und fehlt eine andere Rechtsgrundlage, besteht ein Löschanspruch (Art. 17 Abs. 1 Bst. b DSGVO). Das revDSG sieht Vernichtung oder Anonymisierung vor, sobald Daten nicht mehr erforderlich sind (Art. 6 Abs. 4), und die Klage auf Löschung (Art. 32 Abs. 2 Bst. c). Ausnahmen regelt Art. 17 Abs. 3 DSGVO.
| Ort | Löschweg | Nachweis |
|---|---|---|
| Quell- und Trainingsdatensätze, Ein- und Ausgaben | Vollständige Löschung, auch wenn sie als Trainingsdaten weiterverwendet werden | Löschprotokoll, Datensatzversion |
| Referenzdokumente und Vektordatenbank | Einträge sind direkt adressierbar und gezielt löschbar (DSK-Orientierungshilfe zu RAG, Ziff. 3.5) | Löschlauf im Index, Stichprobenabfrage |
| Protokolle, Zwischenergebnisse | Aufbewahrungsfrist, automatische Löschung | Konfiguration |
| Trainiertes Modell | Neutraining ohne die Daten oder Nachtraining (Machine Unlearning). Filter sind nur Übergangslösung und keine Löschung (DSK-Orientierungshilfe TOM, Ziff. 2.4.4) | Betroffene Daten sind aus dem Modell nicht mehr als Trainingsdaten identifizierbar |
| Sicherungen | Löschkonzept schliesst Sicherungen ein | Ablauf der Sicherungsfrist |
Die DSK stellt fest, dass die Umsetzung von Betroffenenrechten in Sprachmodellen weitgehend ungelöst ist (Orientierungshilfe zu RAG, Ziff. 3.7). Daraus folgt eine Entwurfsregel: Personendaten nicht in Gewichte trainieren, wenn eine Wissensbasis genügt. Sie lässt sich aktualisieren und löschen, die Probleme im Sprachmodell selbst bleiben aber bestehen.
Acht Prüfpunkte
vor der Freigabe.
- Datenblatt mit Herkunft, Zweck und Rechtsgrundlage liegt für jeden Datensatz vor.
- Personenbezug ist begründet oder entfernt.
- Rechte der Quelle gelten in Pipeline, Trainingsumgebung und Vektordatenbank.
- Hash und Version sind für Datensätze und Gewichte hinterlegt, Änderungen werden freigegeben.
- Abgeleitete Artefakte tragen die Schutzklasse ihrer Quelle.
- Bei Hochrisiko-KI-Systemen: Daten-Governance nach Art. 10 AI Act dokumentiert; Nutzung von Art. 4a nur mit allen sechs Bedingungen.
- Anbieterverträge schliessen Training auf eigenen Daten aus oder regeln es ausdrücklich (Lieferanten und Modelle).
- Löschkonzept deckt Datensätze, Index, Protokolle, Modell und Sicherungen ab.
Werkzeugkategorien: Data Discovery, Data Classification, DLP, DSPM, Encryption, Key Management. Siehe auch Kontrollkatalog und Lebenszyklus-Kontrollen.
- AI Data Security: Best Practices for Securing Data Used to Train and Operate AI Systems (NSA, CISA, FBI u. a., 22.05.2025)
- Verordnung (EU) 2024/1689 (AI Act), Art. 2, 10 (EU, 13.06.2024)
- Verordnung (EU) 2026/1744 (Digital-Omnibus KI), Art. 1 Nr. 6 und 9, Erwägungsgrund 9 (EU, 08.07.2026)
- Orientierungshilfe Künstliche Intelligenz und Datenschutz, Version 1.0 (DSK, 06.05.2024)
- Orientierungshilfe zu empfohlenen technischen und organisatorischen Massnahmen bei der Entwicklung und beim Betrieb von KI-Systemen, Version 1.0 (DSK, Juni 2025)
- Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode, Version 1.0 (DSK, Oktober 2025)
- Adversarial Machine Learning, NIST AI 100-2 E2025 (NIST, März 2025)
- Bundesgesetz über den Datenschutz (DSG, SR 235.1), Art. 5, 6, 7, 8, 31, 32, 34 (Fedlex)
- Verordnung (EU) 2016/679 (DSGVO), Art. 3, 5, 6, 7, 9, 17, 25, 32 (EU, 27.04.2016)
- QUAIDAL, Qualitätskriterien für Trainingsdaten im KI-Lebenszyklus, Entwurf (BSI, abgerufen 11.10.2026)
Zitierte Fremdinhalte unterliegen der Lizenz ihrer Herausgeber. Die Seite ist eine Orientierung, keine Rechtsberatung.
© 2026 4T2 Solutions GmbH. Text und eigene Diagramme stehen unter CC BY 4.0.