Ein anschauliches Szenario. Das Team, das deinen Kundenservice-Agenten baut, bittet völlig nachvollziehbar um „eine Stichprobe echter Tickets zum Feintuning“. Zweitausend Gespräche werden aus dem CRM exportiert, in einen geteilten Ordner gelegt, und der Agent wird besser. Niemand hat etwas entschieden: Es ist einfach passiert. Und in diesem Ordner liegen jetzt Namen, Adressen und Vorfälle von Menschen, die nie ahnten, dass ihre Nachrichten zum Testen von Software dienen.
Die These in einer Zeile: Einen Agenten mit echten Daten zu testen ist keine technische Abkürzung, sondern eine Verarbeitung personenbezogener Daten mit eigenem Risiko und eigenem Verantwortlichen – und fast immer lässt sie sich vermeiden oder eingrenzen, zum Preis eines Qualitätsverlusts, den man besser misst, statt ihn zu ignorieren.
Testdaten für KI-Agenten: Warum „einfach mit echten Daten testen“ schon Datenverarbeitung ist
Die spanische Datenschutzbehörde (AEPD) sagt es in ihrem Blogbeitrag zu Entwicklungs- und Vorproduktionsumgebungen (April 2022) ohne Umschweife: Softwaretests mit personenbezogenen Daten „sind oder sind Teil von Verarbeitungen personenbezogener Daten“, mit allen DSGVO-Pflichten, und personenbezogene Daten sollten in Entwicklung, Vorproduktion oder jeder anderen Testumgebung möglichst vermieden werden. Dazu kommt etwas Unbequemes: Das Risiko in diesen Umgebungen kann so hoch sein wie in der Produktion oder höher, weil es mehr Dienstleister, mehr Kopien und weniger Kontrollen gibt.
Bei einem Agenten ist die Exposition schwerer zu erkennen als bei einer klassischen Anwendung. Testdaten bleiben nicht in einer Datenbank: Sie wandern in Prompts zu einem Drittmodell, landen in Observability-Traces und enden in Evaluierungssets, die versioniert und geteilt werden. Jede Kopie ist ein weiterer Ort, an dem die Daten deiner Kunden existieren, ohne dass sie jemand gezählt hat – dasselbe Problem wie in was bei jedem Aufruf deinen Perimeter verlässt. Die Grundregel ist europäisch; wie die einzelnen nationalen Behörden sie auslegen, kann abweichen.
Welche Alternativen gibt es zu echten Daten – und was kostet jede?
Keine Option ist gratis. Jede Alternative schützt etwas und kostet etwas; gut wählen heißt zu wissen, welchen Test man mit welcher verliert.
| Alternative | Was sie tut | Was verloren geht | Wann sie passt |
|---|---|---|---|
| Echt anonymisieren | Entfernt oder verändert Daten, bis niemand die Person identifizieren kann – auch nicht mit Zusatzinformationen | Die Details, die den Fall echt machten: die Vorgeschichte, der Faden zwischen zwei Nachrichten. Sauber ist das schwer, und was sich umkehren lässt, ist keine Anonymisierung | Kurze, strukturierte Daten; fast nie langer Freitext |
| Pseudonymisieren | Ersetzt Kennungen durch Codes und verwahrt den Schlüssel getrennt | Kaum Realismus. Aber es bleiben personenbezogene Daten: Die Leitlinien 01/2025 des Europäischen Datenschutzausschusses erinnern daran, dass pseudonymisierte Daten personenbezogen bleiben, wenn Zusatzinformationen eine Re-Identifizierung erlauben | Wenn du Kontinuität zwischen Fällen brauchst und kontrollierst, wer den Schlüssel hat |
| Synthetische Daten | Erzeugt Daten in der Form echter Daten, die zu niemandem gehören | Die Eigenheiten, die keiner simuliert hat: der Tippfehler, der Kunde, der zwei Sprachen mischt, das Feld, das nur dienstags leer ist | Ablauf, Format, Berechtigungen und Integrationen testen |
| Handgebaute Fälle | Geschrieben von jemandem, der den Prozess kennt, nach echten Mustern | Menge und Überraschung: Du findest nur, was du schon zu suchen wusstest | Grenzfälle und Tests, die wiederholbar sein müssen |
| Eingegrenzte echte Daten | Eine minimale Teilmenge mit dokumentierter Entscheidung, beschränktem Zugriff und Löschdatum | Kein Realismus verloren, aber das ganze Risiko, verringert | Nur wenn das Übrige nicht reicht und es einen konkreten Grund gibt |
Die AEPD nennt diese Rangfolge: Synthetische Daten vermeiden in vielen Fällen die Verarbeitung personenbezogener Daten in Tests, und aus echten Daten abgeleitete Testdaten sollen die Struktur behalten, ohne echte personenbezogene Daten zu enthalten. Reicht das nicht, verlangt sie eine dokumentierte Entscheidung, die die verwendeten echten Daten so weit wie möglich begrenzt.
Was lässt sich mit falschen Daten nicht testen?
Was in der Produktion kaputtgeht, ist selten das, was du dir vorgestellt hast. Ein Agent, der nur mit sauberen Daten getestet wurde, besteht Prüfungen, die die Produktion nie stellt: dreizeilige Nachrichten ohne Kontext, schief gescannte Anhänge, der Kunde, der etwas ganz anderes beantwortet. Es ist der Mechanismus von der Demo, die deine besten Fälle nutzte, auf Tests übertragen.
Die Antwort lautet deshalb nicht „nie echte Daten“, sondern: trennen, was wo getestet wird. Logik, Formate, Integrationen und Berechtigungen testest du mit synthetischen Daten und handgebauten Fällen. Die Qualität gegenüber der echten Vielfalt misst du danach in einem Schattenlauf, in dem der Agent echte Eingaben liest, aber in falsche Ziele schreibt – so, wie es der Leitfaden zum Testen von Änderungen, ohne die Automatisierung zu brechen beschreibt. Vorsicht: Diese Kopie liest echte Daten, ist also weiterhin eine Verarbeitung und braucht ihre eigene Begründung und eigene Grenzen.
Welche praktische Regel verhindert das Problem von Anfang an?
- Fang synthetisch an und geh nur bei Bedarf höher. Jede Stufe Richtung echt braucht einen schriftlichen Grund: welchen konkreten Test du sonst nicht durchführen kannst.
- Gib der Testumgebung die Berechtigungen einer Testumgebung. Eigene Zugangsdaten, kein Zugriff auf Produktion oder echten Versand, wie in welche Berechtigungen ein KI-Agent bekommen sollte beschrieben.
- Verfolge den Weg der Daten. Prompts, Traces, Evaluierungssets und Kopien beim Anbieter zählen mit. Speichert dein Anbieter deine Testeingaben, gehört die Testumgebung nicht mehr nur dir.
- Gib dem Testset ein Löschdatum. Ein Evaluierungsset aus echten Daten, das niemand prüft, ist ein Archiv personenbezogener Daten ohne Verantwortlichen.
- Eine benannte Person entscheidet. Wer die Nutzung echter Daten freigibt und wer regelmäßig prüft, ob sie noch nötig ist.
Was tun, wenn der Anbieter eine echte Stichprobe verlangt?
Das kommt häufiger vor, als man denkt: Der Anbieter muss „eure Fälle sehen“, um den Agenten zu konfigurieren. Bevor du etwas schickst, vier Fragen – schriftlich:
- Wofür genau? Eine Stichprobe, um das Format zu verstehen, ist keine Stichprobe zum Trainieren oder Evaluieren.
- Was macht der Anbieter damit? Dient sie dazu, seine eigenen Modelle zu verbessern oder etwas anderes als dein Projekt, ist es ein anderes Gespräch.
- Wo wird sie gespeichert und wer hat Zugriff? Land, Unterauftragsverarbeiter, Aufbewahrungsdauer. Das ist die Kernfrage aus was dein Anbieter dir zu KI und DSGVO nicht sagt.
- Reichen synthetische Daten? Meist genügen zehn handgeschriebene Fälle und ein Feldschema zur Konfiguration; die echte Stichprobe kommt später, eingegrenzt und nur bei Bedarf.
Wann sind echte Daten sinnvoll?
Wenn die Messung echter Qualität das Ziel ist und Synthetisches sie nicht abbildet. Eine kontinuierliche Evaluierung auf einer kleinen, eingegrenzten Stichprobe mit beschränktem Zugriff ist vertretbar, und genau diese Messung beschreiben wir in die Qualität deiner KI-Agenten bewerten und in Evals: ohne Messen weißt du nicht, ob es funktioniert. Nicht vertretbar ist, es aus Gewohnheit zu tun.
Dann verlangt die AEPD eine Erforderlichkeits- und Verhältnismäßigkeitsprüfung und Sicherheitsmaßnahmen nach Artikel 32 DSGVO. In der Praxis passt das auf eine Seite: warum, wie viele Daten, wer Zugriff hat und bis wann. Und muss ein Fehler ohne Alternative an echten Daten debuggt werden, nennt dieselbe AEPD, was gilt: Genehmigung des Verantwortlichen, protokollierte und auditierte Genehmigung samt Handlungen, minimale Daten und Zugriff nur für die, die ihn brauchen.
Der Satz zum Mitnehmen: Frag nicht, ob dein Agent seine Tests bestanden hat, frag, mit wessen Daten. Lautet die Antwort „mit den echten“ und hat das niemand entschieden, hast du keinen Agenten getestet, sondern ein Archiv eröffnet.
Quellen (abgerufen am 20. Oktober 2026): AEPD, „Brechas de datos personales: entornos de desarrollo y preproducción“ (18. April 2022, auf Spanisch); Verordnung (EU) 2016/679, Art. 4 Nr. 5 und Art. 32; und eine Zusammenfassung der EDSA-Leitlinien 01/2025 zur Pseudonymisierung (angenommen am 16. Januar 2025). Allgemeine Information, keine Rechtsberatung.