Synthetische Testdaten mit KI — DSGVO-frei testen und entwickeln

Jedes Entwicklerteam kennt die Versuchung: Ein realistisches Staging-System braucht realistische Daten, also zieht man eben schnell einen Dump der Produktiv-Datenbank, spielt ihn lokal ein und testet damit. Solange niemand hinschaut, geht das auch. Aber dieser „Mirror” ist datenschutzrechtlich eine tickende Zeitbombe: Echte Kundennamen, echte E-Mail-Adressen, echte Bestellhistorien liegen plötzlich auf Entwickler-Laptops, in Cloud-Backups, in alten Snapshots, die niemand mehr kennt. Wenn einer dieser Laptops verloren geht oder ein Backup falsch konfiguriert ist, hast Du einen meldepflichtigen Datenschutzvorfall.

Wir sind MOLOTOW Web Development aus Lahr im Schwarzwald, geführt vom zertifizierten KI-Manager Thorsten Heß. In diesem Beitrag zeigen wir Dir, warum synthetische Testdaten der saubere Weg sind, welche Tools funktionieren und wo die Grenzen liegen.

Was synthetische Testdaten eigentlich sind

Synthetische Daten sind Datensätze, die nicht aus realen Beobachtungen stammen, sondern kuenstlich erzeugt wurden — aber dieselbe Struktur, Verteilung und Semantik wie echte Daten haben. Eine synthetische Kundentabelle enthält erfundene Namen, die aber wie echte deutsche Namen aussehen, plausible Postleitzahlen zu plausiblen Stadtteilen, Kaufdaten in einem realistischen Zeitrahmen und Warenkorbgroessen mit derselben Verteilung wie die echten.

Der entscheidende Unterschied: Keine Person aus Deiner realen Kundschaft taucht darin auf, auch nicht indirekt. Die DSGVO hat mit synthetischen Daten nichts zu tun, weil sie überhaupt keine personenbezogenen Daten sind.

Warum kein Echt-Daten-Mirror in Staging gehört

Der Reflex „wir anonymisieren das dann schon” klingt gut, funktioniert aber in der Praxis schlecht. Echte Anonymisierung bedeutet, dass aus keinem Attribut-Set der Person auf ein Individuum zurückgeschlossen werden kann. Das ist bei Tabellen mit mehreren Merkmalen (Alter, Postleitzahl, Beruf, Kaufhistorie) verblueffend schwer — drei Attribute reichen oft, um eine Einzelperson zu identifizieren.

Pseudonymisierung („wir tauschen die Namen gegen Hashes”) ist keine Anonymisierung. Pseudonymisierte Daten sind weiter personenbezogen und unterliegen der DSGVO. Das heißt: Zugriffsbeschränkungen, Löschpflichten, Meldepflichten bei Vorfällen — alles wie beim Echt-Datensatz.

Die Konsequenz ist unbequem, aber klar: Eine Staging-Datenbank mit Echt-Daten (auch pseudonymisiert) braucht dieselben Sicherheitsmaßnahmen wie Produktion. In den meisten Teams fehlen die dort. Synthetische Daten umgehen das Problem komplett.

Tools, die wir tatsächlich einsetzen

Faker (Python, PHP, JavaScript). Die Open-Source-Bibliothek, die seit Jahren den Standard setzt. Faker kann deutsche Namen, Adressen, Telefonnummern, Firmennamen, IBANs — alles lokalisiert. Für strukturell einfache Tests (Unit-Tests, E-Mail-Format-Checks) reicht Faker völlig. Nachteil: Die Daten sind plausibel, aber nicht immer in sich konsistent (die Postleitzahl passt nicht zur Stadt, das Geburtsdatum nicht zum Alter).

Mockaroo. Ein Webdienst, der große Datensätze als CSV, JSON oder SQL generiert. Mockaroo beherrscht Abhängigkeiten zwischen Feldern (PLZ zur Stadt, realistische Kaufdaten) deutlich besser als Faker und liefert bis zu einer Million Zeilen pro Export. Die kostenlose Variante reicht für die meisten Projekte. Bei sensiblen Datensätzen solltest Du darauf achten, keine echten Strukturbeschreibungen in einen externen Dienst zu kippen.

Claude und GPT-4.5 für kontextreiche Daten. Wenn Du nicht 10.000 Zeilen brauchst, sondern 50 sehr realistische Datensätze mit konsistenten Beziehungen, ist ein Sprachmodell die beste Wahl. „Erzeuge 20 fiktive Kundendatensätze für einen Schwarzwälder Handwerksbetrieb, mit realistischen Namen, passenden PLZ und Kaufhistorie über zwei Jahre” liefert Output, der wie echte Kundendaten aussieht — nur dass keiner davon real ist.

Synthea und Synth. Spezialisiert auf strukturierte, relationale Datensätze mit starkem Realismus. Synthea stammt aus dem Healthcare-Bereich und generiert komplette synthetische Patientenakten, Synth (Rust) ist generischer und beherrscht JSON-Schema-Vorgaben. Für einfache Webprojekte ist beides overkill, für große Systeme mit vielen Entitäten aber ausgesprochen gut.

Ein typischer Workflow

Unser Standard-Vorgehen für einen neuen Kunden sieht so aus: Wir erstellen einen Seeder, der bei jedem Staging-Deployment die Datenbank leert und mit synthetischen Daten neu befuellt. Der Seeder nutzt Faker für die Masse (Nutzer, Produkte, Bestellungen) und gezielte KI-Anfragen für die „Showcase”-Daten, die in Demos gezeigt werden — schöne Beispielkunden mit plausiblen Geschichten, die für Screenshots und Videos taugen.

Die Struktur spiegelt die echte Datenbank exakt, inklusive Fremdschlüsseln und Constraints. Was fehlt, sind die echten Menschen. Jeder Entwickler kann mit der Staging-Datenbank machen, was er will, kein Screenshot verraet einen echten Kunden, kein verlorener Laptop löst eine Meldepflicht aus.

Grenzen, die Du kennen musst

Realismus ist relativ. Synthetische Daten sehen plausibel aus, decken aber nicht alle Edge-Cases echter Daten ab — die eine Bestellung mit dreizehn Artikeln und einem Rabattcode, der zweimal falsch eingegeben wurde, findest Du nur in echten Logs. Wenn Du Performance-Tests unter realen Lastbedingungen fahren willst, brauchst Du entweder sehr aufwändige synthetische Daten oder echte Daten unter sehr strikter Zugriffskontrolle.

Bugs, die nur bei bestimmten Datenkonstellationen auftreten. Die klassische Geschichte: Im Staging alles gruen, in Produktion crasht es bei einem Kunden mit Umlaut im Nachnamen und einer Adresse ohne Hausnummer. Synthetische Daten helfen dagegen nur, wenn Du die Edge-Cases explizit modellierst. Wir empfehlen, eine „Problem-Kunden-Sammlung” synthetisch zu pflegen: Sonderzeichen, extreme Werte, leere optionale Felder. Das sind die Tests, die in Produktion wirklich etwas abfangen.

KI-generierte Daten brauchen Review. Sprachmodelle sind kreativ, erfinden aber manchmal Dinge, die in Deiner Datenbank nicht existieren dürfen (etwa Produkte, die Du nicht verkaufst, oder Preise, die es nicht gibt). Ein Validierungsschritt, der synthetische Daten gegen Dein echtes Schema prüft, ist Pflicht.

Use Cases außerhalb der Entwicklung

• Demo-Shops für Sales. Ein Vertriebsteam braucht Beispiel-Shops, die echt aussehen, aber keine Kundendaten zeigen. Synthetisch füllen, fertig.
• Schulungen. Mitarbeiter lernen das neue CRM oder ERP an einem Test-System, das mit realistischen, aber fiktiven Daten bestückt ist. Keine Gefahr, dass jemand aus Versehen eine echte Kundenakte ändert.
• Automatisierte Screenshots für Marketing und Dokumentation. Wenn Du auf einer Website Screenshots von Deinem eigenen Tool zeigst, will kein Kunde darin auftauchen. Synthetische Accounts lösen das elegant.
• Sicherheitstests und Penetration-Testing. Red-Team-Tests laufen gegen das synthetische Abbild der Produktion, ohne echte Daten zu gefährden.

Häufige Fragen

Brauche ich für synthetische Daten überhaupt eine KI?

Nein, für die meisten Fälle reicht Faker oder Mockaroo komplett aus. KI ist dann sinnvoll, wenn die Daten in sich sehr stimmig und kontextreich sein sollen — für Demos, Sales-Vorführungen, Dokumentation.

Wie stelle ich sicher, dass keine echten Namen in den synthetischen Daten stehen?

Faker zieht aus Namenslisten, die veröffentlicht sind. Dass der zufällig erzeugte „Peter Müller” irgendwo real existiert, lässt sich nicht ausschließen — aber das ist kein DSGVO-Problem, solange er nicht mit einem echten Merkmal (Geburtsdatum, Adresse, Kundennummer) Deines Unternehmens verknüpft ist. Entscheidend ist, dass keine reale Person aus Deinem Datensatz identifizierbar ist.

Kann ich die echten Daten nicht einfach anonymisieren?

Echte Anonymisierung ist so schwer, dass die Aufsichtsbehörden synthetische Daten als die sauberere Lösung empfehlen. Wenn Du es trotzdem versuchst, brauchst Du eine sorgfältige Risikoanalyse und technische Maßnahmen, die „Reidentifikation” praktisch ausschließen. Das ist in der Regel teurer als ein Seeder.

Funktioniert das auch für Bild- und Videodaten?

Prinzipiell ja — Stable Diffusion und verwandte Modelle erzeugen synthetische Gesichter und Szenen, die nicht existieren. Für Testzwecke (Avatare, Demo-Produktbilder) ist das eine saubere Lösung, solange Du die Lizenzbedingungen der Modelle einhaeltst.

Fazit

Synthetische Testdaten sind kein exotischer Luxus, sondern die Standardantwort auf eine DSGVO-Realität, die sich nicht wegdiskutieren lässt. Sie kosten einmal Einrichtungsaufwand, sparen dafür laufend Kopfschmerzen — beim Datenschutzbeauftragten, beim Backup, bei verlorenen Laptops. Die Tools sind reif, der Workflow ist erprobt, und die Rechenzeit kostet wenig. Wenn Du Deine Staging-Umgebung mal sauber aufsetzen willst, reden wir gern darüber — unverbindlich über unser Kontaktformular oder direkt in der Webentwicklung.