Synthetische Daten für KI-Training und -Tests: Leitfaden 2026

Ein Versicherungsunternehmen möchte ein Modell zur Betrugserkennung trainieren. Es verfügt über hunderttausend Transaktionsdatensätze. Davon sind dreihundert Betrugsfälle. Ein auf diesem Datensatz trainierter Klassifikator lernt, in 99,7 % der Fälle „kein Betrug“ vorherzusagen, und erreicht eine Genauigkeit von 99,7 %, ohne etwas Nützliches zu erkennen. Das Problem liegt nicht im Algorithmus. Es liegt in den Daten.

Synthetische Daten sind eine Antwort auf dieses Problem. Nicht die einzige und nicht immer die richtige, aber im Jahr 2026 sind sie zu einem Standardwerkzeug im Arsenal jedes Teams geworden, das KI-Systeme für Unternehmen aufbaut. Im Folgenden beschreibe ich, wann dieses Werkzeug sinnvoll ist, wie man es sicher einsetzt und wo die Grenzen liegen, die man nicht überschreiten sollte.

Synthetische Daten sind Daten, die von einem Modell oder Algorithmus auf Basis von Mustern generiert werden, die aus Quelldaten gelernt wurden. Entscheidend: Sie sind weder eine Kopie noch eine anonymisierte Version der Originaldaten. Sie sind eine neue Population von Datensätzen, die die Struktur und Verteilung des Originals nachahmen.

Drei Klassen synthetischer Daten, die in Projekten auftauchen:

Synthetische Tabellendaten — Tabellenzeilen, die reale Transaktionen, Patienten, Kunden oder Ereignisse nachahmen, generiert durch Modelle wie CTGAN, TVAE oder Gaussian Copula. Jede Zeile ist neu. Keine entspricht einer konkreten Person.

Synthetische Texte und Dokumente — Inhalte, die von LLM auf Basis von Schemata generiert werden (z. B. synthetische Rechnungen, Beschwerde-E-Mails, Inspektionsberichte) zum Training und Testen von Systemen, die auf RAG oder Datenextraktion basieren.

Synthetische Bilder und unstrukturierte Daten — Fotos, Scans, Aufnahmen, die von generativen Modellen erzeugt werden, eingesetzt bei Datenmangel in Computervision- oder OCR-Systemen.

Synthetische Daten sind nicht dasselbe wie anonymisierte Daten. Anonymisierung entfernt oder maskiert PII aus realen Datensätzen. Synthetische Daten enthalten überhaupt keine realen Datensätze als Quelle einzelner Zeilen, obwohl das generierende Modell mit realen Daten trainiert wurde. Dieser Unterschied hat rechtliche und architektonische Bedeutung.

Nicht jedes Datenproblem lässt sich durch Synthese lösen. Die folgende Tabelle vergleicht Signale, die für synthetische Daten sprechen, mit Signalen, die dagegen sprechen.

Entscheidungskriterium: Synthetische Daten eignen sich bei statistischen Problemen (Klassenungleichgewicht, fehlende Umgebungsdaten, Datenschutz). Sie eignen sich nicht bei Problemen, die reale Variabilität von Mustern erfordern, die das generierende Modell in den Quelldaten nicht gesehen hat.

Bei tabellarischen Daten (häufigster Fall in Unternehmen) hängt die Wahl der Methode von der Komplexität der Abhängigkeiten in den Daten ab.

Gaussian Copula modelliert Abhängigkeiten zwischen Spalten durch eine multivariate Normalverteilung. Schnell, interpretierbar, gut für einfache Korrelationen. Versagt bei stark nichtlinearen oder kategorialen Daten mit seltenen Kombinationen.

CTGAN (Conditional Tabular GAN) lernt bedingte Verteilungen durch ein generativ-adversariales Netzwerk. Besser bei Daten mit vielen Spaltentypen und nichtlinearen Abhängigkeiten. Erfordert mehr Quelldaten zum Training (orientierungsweise einige tausend Zeilen minimum) und ist schwieriger zu kalibrieren.

TVAE (Tabular Variational Autoencoder) ähnlich wie CTGAN, basiert aber auf einem variationalen Autoencoder. Oft stabiler im Training, schlechter bei sehr seltenen Wertkombinationen.

LLM-basierte Methoden — neuerer Ansatz, bei dem ein LLM synthetische Zeilen auf Basis einer Schemabeschreibung und Beispiele generiert. Funktioniert bei kleinen Datensätzen (Few-Shot), ist langsamer und teurer bei Millionen von Datensätzen, bietet aber hohe Realitätsnähe für textuelle oder gemischte Daten.

Die Methodenwahl sollte durch eine Evaluation am Validierungsdatensatz erfolgen: Trainieren Sie das Zielmodell einmal mit synthetischen Daten, einmal mit realen Daten und vergleichen Sie die Metriken. Ein Unterschied unter 5 % auf demselben Testdatensatz ist ein gutes Signal. Ein Unterschied über 15 % deutet darauf hin, dass die Synthese wichtige Muster verliert.

Die Generierung von Daten ist nur die halbe Arbeit. Die andere Hälfte besteht darin, zu bestätigen, dass sie nützlich und sicher sind. Drei Validierungsdimensionen:

Statistische Treue. Vergleichen Sie die Verteilungen jeder Spalte: Mittelwert, Standardabweichung, Quantile, Modus für kategoriale Daten. Überprüfen Sie die Korrelationsmatrix (Pearson für numerische, Cramér's V für kategoriale Daten) zwischen realen und synthetischen Daten. Bibliotheken wie sdmetrics oder ydata-profiling generieren solche Berichte automatisch.

Nützlichkeit (Train on Synthetic, Test on Real — TSTR). Trainieren Sie ein Modell mit synthetischen Daten. Testen Sie es mit realen Daten. Vergleichen Sie es mit einem Modell, das mit realen Daten trainiert wurde (TRTR). Ein Verhältnis der Metriken TSTR/TRTR nahe 1,0 bedeutet, dass die Synthese Muster bewahrt, die für das Modell relevant sind. Fällt es unter 0,85, kehren Sie zu den Parametern des Generators zurück.

Datenschutz (Privacy Metrics). Am wichtigsten: Distance to Closest Record (DCR) und Nearest Neighbor Adversarial Accuracy (NNAA). DCR misst, wie nah jeder synthetische Datensatz zu seinem nächsten Gegenstück in den realen Daten ist. Zu nahe an den Originalen liegende Datensätze können die Privatsphäre durch Membership-Inference-Angriffe gefährden — also die Erkennung, dass eine bestimmte Person im Trainingsdatensatz enthalten war.

Die Observability des Generierungsprozesses ist genauso wichtig wie die Observability des Produktionsmodells. Loggen Sie Generatorparameter, Version der Quelldaten und Validierungsmetriken bei jeder Generierung.

Synthetische Daten fallen nicht automatisch aus dem Anwendungsbereich der DSGVO. Der Europäische Datenschutzbeauftragte (EDPS) und der Ausschuss (EDPB) stellen klar, dass wenn das generierende Modell mit personenbezogenen Daten trainiert wurde und die generierten Datensätze eine Re-Identifizierung ermöglichen (z. B. durch Kombination seltener Merkmale), synthetische Daten weiterhin als personenbezogene Daten im Sinne von Art. 4(1) DSGVO gelten können.

Die Anforderungen hängen von der Risikobewertung der Re-Identifizierung ab:

Wenn DCR und NNAA auf ein geringes Re-Identifizierungsrisiko hinweisen und die Daten aus Aggregaten (nicht aus konkreten Datensätzen) generiert wurden, sind die rechtlichen Grundlagen für die Verarbeitung synthetischer Daten analog zu anonymisierten Daten.

Wenn synthetische Daten im Kontext eines Hochrisikosystems gemäß AI Act generiert werden (z. B. Kreditscoring-Systeme, Rekrutierung, medizinische Systeme), muss die Dokumentation des Trainingsdatenpfads eine Beschreibung der Generierungsmethode, Datenschutzmetriken und das Ergebnis einer DPIA umfassen. Dies ist eine Anforderung von Art. 10 AI Act zum Datenmanagement.

Praktische Regel: Generieren Sie vor jedem Einsatz synthetischer Daten in der Produktion oder in Systemen, die dem AI Act unterliegen, einen Validierungsbericht. Speichern Sie den Bericht zusammen mit dem Modell. Bei Human-Oversight in Hochrisikosystemen muss der Auditor Zugang zur Historie der Trainingsdaten, einschließlich synthetischer Daten, haben.

Ein separates Anwendungsgebiet, das weder Modelltraining noch vollständige statistische Validierung erfordert, sind synthetische Daten für Testumgebungen und KI-Agenten.

Ein Agent, der Bestellungen bearbeitet, muss auf Szenarien getestet werden, die in der Produktion selten vorkommen: Bestellung mit fehlender Adresse, zwanzig Positionen im Warenkorb derselben Kategorie, andere Währung als PLN, Lieferdatum in der Vergangenheit. Solche Fälle kommen in Produktionsdaten fünfmal pro Million Transaktionen vor. In der Testdatenbank können sie in beliebiger Anzahl generiert werden.

Diese Art von synthetischen Daten wird durch einfache Skripte oder durch LLM mit Anweisungen zur Erstellung von Edge-Cases generiert. CTGAN oder TVAE sind nicht erforderlich. Was erforderlich ist, sind gut dokumentierte Edge-Cases, die in der Regel während der Anforderungsanalyse erfasst werden.

Beim Aufbau von Guardrails für den Agenten ermöglichen synthetische Testdaten automatisierte Regressionstests: Jede Änderung am System-Prompt oder an der Guardrail-Logik durchläuft einen Satz synthetischer Testszenarien. Dies ist das gleiche Schema wie Unit-Tests in der Softwareentwicklung, aber angepasst an nicht-deterministische KI-Systeme. Mehr über die Überwachung der Agentenqualität beschreibt der Artikel Monitoring der Qualität von KI-Agenten.

Synthetische Daten fließen an zwei Stellen in den KI-Prozess ein: als Trainingsdaten (Fine-Tuning) und als Dokumente zur Erweiterung der Wissensbasis in RAG.

Beim Fine-Tuning ermöglichen synthetische Frage-Antwort-Paare auf Basis von Unternehmensdokumenten die Spezialisierung des Modells, ohne sensible Dokumente an externe Anbieter weiterzugeben. Schema: Ein lokales LLM generiert Fragen und Antworten aus Dokumenten (die verarbeitet werden dürfen). Diese synthetischen Paare bilden die Grundlage des Trainingsdatensatzes für das Fine-Tuning. Die Originaldokumente verlassen niemals die Umgebung. Wann dieser Ansatz sinnvoll ist und wann RAG allein besser bleibt, beschreibt der Artikel Wann Fine-Tuning sinnvoll ist.

Bei RAG ergänzen synthetische Daten die Wissensbasis um Szenarien, die reale Dokumentation nicht abdeckt: Beispiel-Dialoge mit Kunden, Beispiel-Anfragen, Beispiel-Inspektionsberichte. Dies gibt dem Modell Kontext für präzisere Antworten, ohne reale Kundendaten preiszugeben.

Wichtige Einschränkung: Synthetische Dokumente für RAG müssen in den Metadaten des Vektors klar als synthetisch gekennzeichnet sein. Das Mischen synthetischer und realer Daten ohne Kennzeichnung erschwert Audits und das Debugging von Halluzinationen. Mehr über das Management der RAG-Wissensbasis im Artikel Aktualisierung von RAG-Wissen und Versionsverwaltung.

Nein. Synthetische Daten können weiterhin personenbezogene Daten sein, wenn das generierende Modell mit personenbezogenen Daten trainiert wurde und die generierten Datensätze eine Re-Identifizierung konkreter Personen durch Kombination seltener Merkmale ermöglichen. Die Risikobewertung der Re-Identifizierung durch Metriken wie DCR und NNAA sollte jedem Einsatz synthetischer Daten in Systemen, die Informationen über natürliche Personen verarbeiten, vorausgehen. Bei Hochrisikosystemen gemäß AI Act ist eine vollständige DPIA erforderlich.

Das hängt von der Methode ab. Gaussian Copula funktioniert mit einigen hundert Zeilen und einfachen Abhängigkeiten. CTGAN und TVAE benötigen orientierungsweise einige tausend Zeilen für ein stabiles Training des Generators, bei vielen kategorialen Spalten mit seltenen Werten sogar mehr. Die Generierung durch LLM (Few-Shot) funktioniert mit einigen Dutzend Beispielen, aber die statistische Qualität ist geringer als bei generativen Methoden. Bei sehr kleinen Datensätzen (unter 500 Datensätzen) können synthetische Daten paradoxerweise das Modell nicht verbessern, weil der Generator Rauschen statt Muster lernt.

Berechnen Sie die Distance to Closest Record (DCR) für jeden synthetischen Datensatz im Vergleich zum Quelldatensatz. Wenn der Median der DCR nahe null liegt, kopiert der Generator Originalzeilen, statt neue zu erstellen. Ergänzen Sie dies mit dem Nearest Neighbor Adversarial Accuracy (NNAA)-Test: Ein auf einer Stichprobe „real vs. synthetisch“ trainierter Klassifikator sollte eine Genauigkeit nahe 0,5 (zufällig) haben, nicht nahe 1,0 (kann unterscheiden). Die Bibliothek sdmetrics implementiert beide Tests als fertige Funktionen.

Nicht vollständig. Synthetische Daten sind ein wertvolles ergänzendes Werkzeug, kein Ersatz. Das generierende Modell lernt Muster aus realen Daten — es gibt keine Quelle, um Phänomene zu generieren, die in realen Daten nicht existierten. Bei einem neuen Produkt ohne Historie, einem neuen Markt oder einem neuen Ereignistyp können synthetische Daten den Prozess der Pilotdatensammlung nicht ersetzen. Deshalb lohnt es sich vor jedem KI-Projekt, den Datenstatus mit dem Tool Bewertung der Einsatzbereitschaft und dem ROI-Rechner zu bewerten.

Der Arbeitsumfang hängt von der Komplexität des Datenschemas, der Anzahl der Spalten mit PII, dem erforderlichen Validierungsniveau (statistisch vs. TSTR vs. vollständiger Datenschutz) und davon ab, ob die Daten in ein Hochrisikosystem nach AI Act einfließen. Orientierung: Pilotprojekte mit Methodenevaluation auf einem bestehenden Datensatz und Implementierung eines Synthese-Pipelines umfassen einige bis mehrere Wochen Arbeit. Eine vollständige Bewertung erstellen wir nach der Analyse durch den ROI-Rechner oder direktem Kontakt. }