Erzeugung synthetischer Daten (Datenschutz & Trainingsdaten)

Echte Daten sind oft durch die DSGVO, das Bankgeheimnis oder schlicht Knappheit gesperrt. Das blockiert Softwaretests, den Austausch von Analysedaten und das Training von ML-Modellen. Generative Modelle lernen die Struktur eines Quelldatensatzes und erzeugen neue Datensätze, die dessen Statistik erhalten, aber keiner realen Person zugeordnet werden können. Gut gemacht, öffnet das den Datenzugang in Tagen statt Monaten; nachlässig umgesetzt, erzeugt es nur ein falsches Gefühl von Anonymität.

Problem & Nutzen

• Heute: Entwickler testen mit Kopien von Produktionsdaten (ein Compliance-Risiko) oder mit von Hand erstellten Dummy-Daten (unrealistisch). Der Datenaustausch mit Partnern, Hochschulen oder Cloud-Teams erfordert langwierige Freigaben. ML-Teams haben zu wenige Beispiele für seltene Ereignisse (Betrug, Defekte, seltene Krankheiten).
• KI-Nutzen: schnellerer, risikoärmerer Zugang zu realistischen Daten; Ausgleich seltener Klassen; reproduzierbare Testdatensätze in beliebiger Größe; Daten für Demos und Schulungen.
• Belegbasis: Anbieter nennen große Beschleunigungen bei der Datenbereitstellung, aber es gibt keinen unabhängigen, einheitlichen Vergleichstest. Behandeln Sie genannte ROI-Zahlen als Herstellerangaben und messen Sie Ihre eigene Ausgangslage (Zeit bis zum Datenzugang, Testabdeckung, Modellverbesserung).
• Wichtiger Vorbehalt: Synthetisch heißt nicht automatisch anonym. Ähnlichkeitsbasierte Datenschutzmaße können Angriffe auf „wirklich anonyme“ synthetische Datensätze übersehen [6], und die Kriterien der Artikel-29-Datenschutzgruppe (Herausgreifen, Verknüpfbarkeit, Inferenz) gelten weiterhin [1].

Varianten

• Tabellarisch / relational (Kern): Kunden-, Transaktions- oder Patiententabellen mit referenzieller Integrität über mehrere Tabellen hinweg.
• Software-Testdaten: regel- und modellbasierte Generatoren für Datenbanken, APIs und CI-Pipelines (Maskierung plus Erzeugung).
• Zeitreihen und Sequenzen: Sensordaten, EKG oder Zahlungsverläufe.
• Text: per LLM erzeugte synthetische Dokumente, Dialoge, Support-Tickets oder klinische Notizen, oft aus Personas abgeleitet und anschließend auf personenbezogene Daten (PII) geprüft; außerdem Instruktionsdaten für das Feintuning (siehe DATA-023, LANG-027).
• Bilder und Video: Simulation und generative Bilder für das Training von Bildverarbeitung (zur Anonymisierungsseite siehe VIS-030).
• Privat: selten; vor allem Hobbyanwender, die Dummy-Daten für Lernzwecke und Demos erzeugen.

So funktioniert es

1. Quelldaten (geschützte Umgebung)
2. Profiling + Erfassung von Schema/Randbedingungen
3. Training des Generators (GAN / VAE / Diffusion / Transformer / Copula / LLM, optional mit Differential Privacy)
4. Stichprobenziehung (+ Durchsetzung von Geschäftsregeln und Randbedingungen)
5. Bewertung: Treue (Verteilungen, Korrelationen), Nutzbarkeit (auf synthetischen Daten trainieren, auf realen testen), Datenschutz (nächster Nachbar, Membership Inference, Attribute Inference)
6. Freigabeentscheidung durch Mensch / Datenschutzbeauftragte
7. synthetischer Datensatz wird an die gesamte Organisation ausgeliefert

• Generatoren: statistische Modelle (Gaußsche Copula, CTGAN, TVAE in der SDV-Bibliothek), autoregressive Transformer-Modelle für relationale Daten (MOSTLY AI), differentiell private Feintunings für Text- und Tabellendaten sowie per Prompt gesteuerte LLMs für Text.
• Datenschutzkontrollen: Differential Privacy (DP) gibt eine formale Garantie, die Nutzbarkeit kostet; empirische Tests (Membership Inference, Abstand zum nächsten Datensatz) ergänzen sie, ersetzen sie aber nicht.
• Mensch-in-der-Schleife (Human-in-the-Loop): Eine Datenschutzbeauftragte bzw. ein Datenschutzbeauftragter oder ein Data Steward gibt den Datenschutzbericht vor der Freigabe ab; Fachexperten prüfen Realitätsnähe und Grenzfälle.

Datenaufbereitung

Die Quelle sind typischerweise relationale Daten aus ERP-, CRM-, HR- oder Kernsystemen sowie Exporte auf Dateiablagen und in Excel-Tabellen. Textkorpora (Tickets, Mails) liegen auf Mailservern und in Dokumentenmanagementsystemen. Typische Lücken: nicht dokumentierte Schemata, fehlende Fremdschlüssel zwischen Exporten, uneinheitliche Codes und Dubletten, Freitextfelder mit versteckten personenbezogenen Daten und kein klarer Verantwortlicher, der die Daten freigeben darf.

Aufbereitungsschritte: 1. Kandidatentabellen erfassen und je Quelle einen Verantwortlichen festlegen (PREP-001, PREP-004). 2. Einen konsistenten Stand über Exporte oder Konnektoren ziehen (PREP-005) und in saubere Tabellen überführen (PREP-011). 3. Schema, Randbedingungen und Geschäftsregeln dokumentieren (gültige Wertebereiche, referenzielle Integrität); sie werden zu Randbedingungen des Generators. 4. Zweck und Rechtsgrundlage für die Nutzung echter Daten zum Training des Generators prüfen (PREP-025) und direkte Identifikatoren zuerst pseudonymisieren (PREP-022). 5. Einen zurückgehaltenen echten Testdatensatz für die Prüfung der Nutzbarkeit aufbewahren.

Werkzeuge: pandas oder dbt für die Bereinigung, SDV oder MOSTLY AI für die Erzeugung. Grober Aufwandsanteil: etwa 40 bis 50 Prozent, denn der Generator ist nur so gut wie die bereinigten, mit Randbedingungen versehenen Eingangsdaten. Siehe auch DATA-003 und DATA-023.

Umsetzungswege

Welcher Weg für wen

• smb: Weg C. Die Quelldaten sind meist personenbezogen oder vertraulich, und Open-Source-Generatoren wie SDV laufen auf HW2, sodass echte Datensätze das Unternehmen nie verlassen; ziehen Sie für den ersten Durchlauf einen externen Partner hinzu.
• enterprise: Weg C. Daten aus Banken, Versicherungen und dem Gesundheitswesen sind sensibel, und eine gemeinsame interne Plattform verteilt den Aufwand; kommerzielle Generatoren (Weg A) passen, sobald ein Anbieter freigegeben ist.
• developer: Weg C. Open-Source-Bibliotheken geben volle Kontrolle über Randbedingungen und Datenschutztests und kosten nichts pro Datensatz.
• public: Weg C. Bürgerdaten müssen in souveräner Infrastruktur bleiben, und die Beschaffung bevorzugt offene, prüfbare Werkzeuge.

Weg A — Kaufen (Standardsoftware)

• EU: MOSTLY AI (Wien; kommerzielle Plattform plus Open-Source-SDK), Syntheticus (Schweiz), Aindo (Italien), Statice (Deutschland; von Anonos übernommen, aktuelle Verfügbarkeit prüfen), Clearbox AI (Italien).
• Nicht-EU: Tonic.ai, Hazy (Software-Assets von SAS übernommen, Nov. 2024), NVIDIA (das Berichten zufolge im März 2025 Gretel übernommen hat; der eigenständige Gretel-Dienst ging in NVIDIA-Angebote über, aktuellen Stand prüfen) [4], Synthesis AI für Bilder, K2view für entitätsbasierte Testdaten.
• Wählen Sie A, wenn: regulierte Daten (Banken, Gesundheit) vorliegen, kein internes ML-Team vorhanden ist und Sie auditfähige Datenschutzberichte sowie Konnektoren zu Datenbanken und Data Warehouses brauchen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Text: Frontier-LLMs (Claude, Gemini, GPT, Mistral über EU-Regionen), per Prompt mit Schemata und Personas gesteuert; nutzen Sie strukturierte Ausgaben für konsistentes JSON und führen Sie stets eine PII-/Leck-Prüfung durch. Senden Sie echte personenbezogene Datensätze niemals ohne Rechtsgrundlage an Nicht-EU-APIs.
• Tabellarisch: verwaltete ML-Plattformen (Azure ML, Vertex AI, SageMaker in EU-Regionen), auf denen SDV oder ähnliche Bibliotheken laufen; Microsoft Presidio und Cloud-DLP-Dienste erkennen verbleibende PII [5].
• Wählen Sie B, wenn: Sie individuelle Logik oder Texterzeugung brauchen und bereits in einem Cloud-Mandanten arbeiten.

Weg C — Selbst betreiben (Open Source)

• Tabellarisch: SDV (MIT-Lizenz; CTGAN, TVAE, Copulas, mehrere Tabellen, Zeitreihen) [2], MOSTLY AI SDK (Apache-2.0) [3], ydata-synthetic, synthcity, SmartNoise (OpenDP) für DP-Synthese.
• Text: Open-Weight-LLMs (Llama-, Qwen-, Mistral-, Gemma-Familien) über vLLM oder Ollama; DP-Feintuning mit Opacus; Auswertung mit offenen Bibliotheken wie dem Paket SDMetrics.
• Testdaten: Faker, Mimesis und regelbasierte Generatoren im Stil von Synth für die Software-Qualitätssicherung.
• Hardware: Tabellarische Modelle laufen für moderate Tabellen auf HW1 (CPU), für große relationale Daten oder Textmodelle mit 7-8 Mrd. Parametern auf HW2 (eine GPU mit 24 GB); HW3 für Textgenerierung mit 30 Mrd. Parametern und mehr.

Weg D — Eigenes Training

Lohnt sich für Nischenmodalitäten (medizinische Zeitreihen, industrielle Sensoren) oder wenn formale DP-Garantien nötig sind. Erfordert die vollständigen Quelldaten in einer gesicherten Enklave, ein Privacy-Engineering-Team und eine Evaluierungsumgebung; planen Sie Monate ein.

Stand der Technik (2026)

• Tabellarisch: Transformer- und diffusionsbasierte Generatoren übertreffen GANs inzwischen bei der Datentreue für Tabellen mit gemischten Datentypen; die Erzeugung mehrerer Tabellen mit referenzieller Integrität ist in kommerziellen Werkzeugen Standard.
• Text: LLM-basierte synthetische Korpora werden häufig für Feintuning und Evaluierung genutzt, doch die Qualität hängt von der Vielfalt der Prompts ab; wiederholtes Training auf synthetischen Ausgaben riskiert Modellkollaps und den Verlust seltener Ausprägungen.
• Evaluierung: Frameworks kombinieren statistische, strukturelle und graphbasierte Treueprüfungen [7]; keine einzelne Kennzahl gilt als Beleg für Anonymität.
• Konsolidierung: Der Markt hat sich 2024-2025 bewegt (Hazy zu SAS, Gretel zu NVIDIA); die Kontinuität des Anbieters ist daher ein Auswahlkriterium [4].
• Grenzen: Seltene Kombinationen können auswendig gelernt werden und durchsickern; Ausreißer sind am schwersten zu schützen; synthetische Daten bilden Korrelationen, die in der Quelle fehlen, selten ab; Verzerrungen (Bias) der Quelle werden übernommen oder verstärkt; DP mit strengen Einstellungen verschlechtert die Nutzbarkeit.

Gemeinsame Bausteine & Kombinationen

• Gemeinsamer Stack: die Fähigkeiten tabular-ml und llm-general, eine gesicherte Daten-Enklave sowie PII-Detektoren, die mit DOC-018 (Dokumentenanonymisierung) und VIS-030 (Bildanonymisierung) geteilt werden.
• Vorgelagert: DATA-003 (Bereinigung und Stammdaten) liefert saubere Quelltabellen; DATA-008 (Qualitätsüberwachung) kann synthetische Ausgaben validieren.
• Nachgelagert: DATA-023 (Annotation) und Feintuning von Modellen; CODE-001 (Coding-Assistenten) nutzen synthetische Testdaten; LANG-027 (synthetische Befragte) ist der verwandte Fall der Persona-Simulation.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen für einen ersten Datensatz; Lizenz typischerweise nach Datenvolumen oder Nutzerzahl.
• Weg B: 1-2 Monate einschließlich Datenschutzbewertung.
• Weg C: 1-3 Monate; vor allem Entwicklungs- und Evaluierungsaufwand, wenig Rechenleistung.
• Weg D: Quartale.
• Kostentreiber: Aufwand für die Datenschutzbewertung und die Prüfung durch Experten, nicht GPU-Zeit.
• Kennzahlen: Zeit bis zum Datenzugang, Treue-Wert (Abstand von Verteilungen und Korrelationen), Nutzbarkeitsverhältnis Training auf synthetischen / Test auf echten Daten, Erfolgsquote von Datenschutzangriffen, Anzahl der aus Testumgebungen entfernten Kopien von Produktionsdaten, Audit-Feststellungen.

Menschen & Veränderung

Binden Sie die Geschäftsleitung für das Mandat und die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten früh ein: Sie bzw. er entscheidet, ob die synthetische Ausgabe als anonym gilt, und zeichnet den Datenschutzbericht ab; eine Datenschutz-Folgenabschätzung (DSFA) ist wahrscheinlich, wenn der Generator mit besonderen Kategorien personenbezogener Daten trainiert wird (Art. 35 DSGVO). Die Datenverantwortlichen geben die Quellen frei, IT und Informationssicherheit richten eine isolierte Umgebung ein, und die Abteilungsleitung legt die Testszenarien fest. Die Testteams sind die Endanwender.

Betriebsrat: meist nein, da das System Geschäftsdaten verarbeitet, nicht das Verhalten von Beschäftigten. Werden HR- oder Zeiterfassungsdaten als Quelle genutzt, ist das System unter Umständen zur Überwachung der Beschäftigten geeignet, und § 87 Abs. 1 Nr. 6 BetrVG greift; informieren Sie den Betriebsrat dennoch nach § 90 Abs. 1 Nr. 3, wo sich Arbeitsabläufe ändern.

KI-Kompetenz: Unterstützen Sie die Mitarbeitenden mit einer kurzen Schulung dazu, was synthetische Daten garantieren können und was nicht (Art. 4 KI-Verordnung (AI Act), Maßnahmen zur Förderung der KI-Kompetenz). Starten Sie einen Pilot mit einem Testdaten-Anwendungsfall, messen Sie die eingesparte Wartezeit beim Datenzugang und zeigen Sie Skeptikern den Datenschutzbericht. Typische Sorge: „Ist es wirklich anonym?“ Antworten Sie mit Membership-Inference-Tests und einer menschlichen Freigabeentscheidung. Leitfäden: GUIDE-005, GUIDE-003, GUIDE-009.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise minimales Risiko; die KI-Kompetenz (Art. 4) ist zu beachten. Werden synthetische Texte, Bilder oder Audio als realistische Inhalte veröffentlicht, kann die Transparenzpflicht nach Art. 50 gelten (maschinenlesbare Kennzeichnung synthetischer Ausgaben). Synthetische Daten, die zum Training eines Hochrisiko-Systems dienen, unterliegen den Daten-Governance-Pflichten nach Art. 10 (Prüfung auf Verzerrungen, Relevanz, Repräsentativität) [8].
• DSGVO: Der Trainingsschritt verarbeitet echte personenbezogene Daten und braucht eine Rechtsgrundlage sowie Zweckvereinbarkeit; Daten fallen nur dann nicht unter die DSGVO, wenn sie wirklich anonym sind, was im Einzelfall anhand der WP29-Kriterien zu beurteilen ist [1]. Die Stellungnahme 28/2024 des EDSA betont, dass die Anonymität von KI-Modellen und Ausgaben nachgewiesen und nicht vorausgesetzt werden muss [9]. Führen Sie eine DSFA durch, wenn die Quelldaten sensibel sind (Daten nach Art. 9, etwa Gesundheitsdaten).
• Branchenregeln: Bankgeheimnis, ärztliche Schweigepflicht und aufsichtsrechtliche Erwartungen (z. B. EBA/BaFin zu Modelldaten) können weitere Einschränkungen mit sich bringen.
• Risiken und Gegenmaßnahmen: Auswendiglernen und Re-Identifizierung (DP, Nächster-Nachbar-Tests, Weitergabe nur an kontrollierte Empfänger unter Vertrag); Verzerrungsübertragung (Datentreue in Untergruppen vergleichen); übertriebene Werbung mit „anonym“ (Bewertung des Restrisikos dokumentieren); Modellkollaps (mit echten Daten mischen).

Erste Schritte

1. Wählen Sie einen konkreten Bedarf (Testdaten für eine Anwendung oder einen teilbaren Datensatz) und halten Sie die Datenschutzanforderung gemeinsam mit Ihrer bzw. Ihrem Datenschutzbeauftragten fest.
2. Erstellen Sie einen Prototyp mit SDV oder dem MOSTLY AI SDK auf einer nicht sensiblen Tabelle, um die Treuekennzahlen kennenzulernen.
3. Legen Sie das Prüftor fest: Schwellenwerte für die Datentreue, Nutzbarkeit Training auf synthetischen / Test auf echten Daten, Membership-Inference-Test.
4. Führen Sie die echte Pipeline in einer gesicherten Umgebung aus, dokumentieren Sie die Anonymisierungsbewertung und halten Sie die Freigabe durch die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten fest.
5. Vergleichen Sie vor der Skalierung mit einem kommerziellen Werkzeug auf demselben Datensatz.

Quellen

1. Article 29 Working Party, Opinion 05/2014 on Anonymisation Techniques — https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf
2. Synthetic Data Vault (SDV) — https://github.com/sdv-dev/SDV
3. MOSTLY AI open-source SDK — https://github.com/mostly-ai/mostlyai
4. Overview of synthetic data tools 2026 (Gretel/NVIDIA, MOSTLY AI, SDV) — https://www.k2view.com/blog/best-synthetic-data-generation-tools/
5. Microsoft Presidio (PII detection and anonymisation) — https://github.com/microsoft/presidio
6. Ganev & De Cristofaro, The Inadequacy of Similarity-based Privacy Metrics: Privacy Attacks against "Truly Anonymous" Synthetic Datasets — https://arxiv.org/pdf/2312.05114
7. Synthetic Data Blueprint (SDB): evaluation framework for synthetic tabular data — https://arxiv.org/pdf/2512.19718
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
9. EDPB Opinion 28/2024 on data protection aspects of AI models — https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en