Testdaten für AI-Features: Golden Sets, synthetische Daten und DSGVO

Das AI-Feature ist gebaut, die Evals sind aufgesetzt, und dann stellt sich die Frage, die viele Teams unterschätzen: Womit testen wir eigentlich. Testdaten für AI-Features sind ein eigenes Problem, denn anders als bei klassischer Software reicht es nicht, ein paar Eingabefelder mit Beispielwerten zu füllen. Das Feature soll mit echter Sprache umgehen, mit echten Dokumenten, echten Tippfehlern und echten Missverständnissen. Ausgedachte Beispiele vom Schreibtisch bilden davon fast nichts ab.

Der Reflex vieler Teams ist deshalb der kurze Dienstweg: eine Kopie der Produktionsdatenbank in die Testumgebung, fertig. Damit liegen plötzlich echte Kundendaten in einer Umgebung mit lockereren Zugriffsregeln, wandern in Prompts, Logs und Eval-Berichte und werden womöglich an externe Modellanbieter geschickt. Das ist datenschutzrechtlich heikel und praktisch unnötig, denn es gibt einen besseren Weg. Er besteht aus vier Bausteinen: einem kuratierten Golden Set, gezielt eingesetzten synthetischen Daten, sauberer Anonymisierung und einem Prozess, der die Sammlung am Leben hält.

Golden Sets: wenige Fälle, aber die richtigen

Ein Golden Set ist eine kuratierte Sammlung von Eingaben mit geprüften Soll-Ausgaben, der Goldstandard, an dem jede Änderung gemessen wird. Kuratiert ist das entscheidende Wort. Nicht die Menge macht das Set wertvoll, sondern die Auswahl: Jeder Fall ist von einem Menschen angesehen, die Erwartung ist fachlich abgesichert, und der Fall steht stellvertretend für eine ganze Klasse von Eingaben.

Gute Quellen sind reale Fälle aus dem eigenen Umfeld: typische Anfragen aus dem Tagesgeschäft, Dokumente in den tatsächlich vorkommenden Formaten und Qualitätsstufen, Grenzfälle, bei denen sich auch erfahrene Mitarbeiter abstimmen müssen, und bewusste Negativfälle, bei denen die korrekte Antwort eine Ablehnung oder ein Eingeständnis von Nichtwissen ist. Einige Dutzend solcher Fälle, sauber dokumentiert, schlagen tausende ungeprüfte Datensätze. Wichtig ist die Balance: Wer nur die schwierigen Fälle sammelt, bekommt ein verzerrtes Bild, denn das Set soll die reale Verteilung grob widerspiegeln, mit einem bewussten Übergewicht an Randfällen.

Synthetische Daten und ihre Fallstricke

Wo reale Daten fehlen oder nicht verwendet werden dürfen, helfen synthetische Daten: Eingaben, die ein Sprachmodell nach Vorgaben erzeugt. Das funktioniert erstaunlich gut, um Volumen aufzubauen, Varianten eines Musters durchzuspielen oder seltene Konstellationen gezielt herzustellen, die in echten Daten kaum vorkommen.

Die Fallstricke sind allerdings real. Generierte Texte sind zu glatt: korrekt formuliert, vollständig, höflich, während echte Nutzereingaben abgebrochen, mehrdeutig und fehlerhaft sind. Die Verteilung spiegelt das erzeugende Modell, nicht die Nutzerschaft. Und es droht Zirkularität: Wer Testfälle mit derselben Modellfamilie generiert, die sie später lösen soll, testet das Modell an seinen eigenen Mustern und misst zu optimistisch. Drei Regeln entschärfen das:

• Echte Vorlagen: Muster aus einer Handvoll realer, bereinigter Fälle ableiten und das Modell Varianten erzeugen lassen, statt frei zu erfinden.
• Gezielte Verschmutzung: Tippfehler, Abkürzungen, gemischte Sprachen und fehlende Angaben bewusst hineingenerieren.
• Menschliche Stichprobe: einen Teil jeder generierten Charge prüfen, bevor sie ins Set wandert. Ungeprüfte synthetische Daten sind keine Testdaten, sondern Ballast.

Anonymisierung: was die DSGVO für Testdaten bedeutet

Sobald echte Fälle als Testdaten dienen, sind Datenschutzfragen zu klären, denn personenbezogene Daten bleiben auch in einer Testumgebung personenbezogene Daten. Die Grundsätze der DSGVO, etwa Zweckbindung und Datenminimierung, gelten dort genauso. Der sichere Weg ist echte Anonymisierung: Die Angaben werden so entfernt oder ersetzt, dass kein Rückbezug auf Personen mehr möglich ist. Erst dann fällt der Datensatz aus dem Anwendungsbereich des Datenschutzrechts heraus.

In der Praxis ist das anspruchsvoller, als es klingt, besonders bei Freitext. Namen und Adressen zu ersetzen reicht oft nicht, wenn die Kombination aus Ort, Beruf und Sachverhalt eine Person erkennbar macht. Bewährt hat sich ein zweistufiges Vorgehen: automatisierte Erkennung und Ersetzung personenbezogener Angaben durch realistische Platzhalter, danach eine menschliche Durchsicht genau der Fälle, die ins Golden Set übernommen werden. Da das Set klein ist, bleibt dieser Aufwand überschaubar. Wichtig ist außerdem, die Ersetzungen konsistent zu halten, damit fachliche Zusammenhänge im Fall erhalten bleiben. Bei Unsicherheit über die Zulässigkeit einer Nutzung gehört die Frage zu den Datenschutzverantwortlichen, bevor die Daten fließen, nicht danach.

Edge Cases aus dem Betrieb sammeln

Die wertvollsten Testfälle entstehen nach dem Go-live, denn der Betrieb produziert genau die Fälle, an die vorher niemand gedacht hat. Damit sie nicht verloren gehen, braucht es einen definierten Weg: Jede Nutzerbeschwerde über eine falsche Antwort, jedes negative Feedback, jeder manuell korrigierte Vorschlag wird als Kandidat erfasst, anonymisiert, mit einer Soll-Ausgabe versehen und ins Set übernommen. Aus einem Vorfall wird so ein dauerhafter Regressionstest.

Hilfreich ist eine feste Routine statt guter Vorsätze: ein wiederkehrender Termin, in dem das Team die auffälligen Fälle der letzten Wochen sichtet und die besten übernimmt. So wächst das Set dort, wo das System tatsächlich schwach ist, und nicht dort, wo das Team Schwächen vermutet hat.

Pflege über Modellwechsel hinweg

Testdaten sind kein Einmalprojekt. Damit sie Modellwechsel überleben, sollten Erwartungen eigenschaftsbasiert formuliert sein statt wortlautbasiert: geprüft wird, ob die Antwort die relevanten Punkte enthält, die richtige Quelle nennt und das Format einhält, nicht ob sie einem gespeicherten Text gleicht. Wortlaut-Erwartungen brechen bei jedem neuen Modell flächendeckend, obwohl die Qualität gleich oder besser ist, und trainieren dem Team an, rote Ergebnisse zu ignorieren.

Dazu gehört Versionierung: Das Set liegt im Repository, Änderungen laufen über Review, und jedes Eval-Ergebnis referenziert den Stand des Sets, gegen den es gemessen wurde. Und es gehört Ausmisten dazu. Fälle, die seit langem trivial bestanden werden, dürfen in einen Archivbestand wandern, damit das aktive Set schnell läuft und die Aufmerksamkeit auf den Fällen bleibt, die noch etwas aussagen.

Fazit

Gute Testdaten für AI-Features entstehen nicht durch Kopieren der Produktionsdatenbank, sondern durch Kuratieren: ein Golden Set aus wenigen, fachlich geprüften realen Fällen, ergänzt um synthetische Daten mit echten Vorlagen und bewusster Verschmutzung. Echte Fälle werden vor der Übernahme sauber anonymisiert, im Zweifel mit den Datenschutzverantwortlichen abgestimmt. Der Betrieb liefert laufend neue Randfälle, die über eine feste Routine ins Set wandern, und eigenschaftsbasierte Erwartungen plus Versionierung halten die Sammlung über Modellwechsel hinweg brauchbar. Der Aufwand ist überschaubar, und er verzinst sich bei jeder einzelnen Änderung am System.