Was passiert
Forschende von SAP haben einen neuen Ansatz zur Generierung synthetischer Unternehmensdaten veröffentlicht, der eines der größten Probleme bei der Entwicklung von KI-Agenten löst: die Verfügbarkeit realistische Trainingsdaten unter Beachtung von Datenschutz und Geschäftsgeheimnis.
Der neue Ansatz heißt Synthesis Through Simulation (STS) und funktioniert grundlegend anders als bisherige Verfahren. Statt Daten aus tabellarischen Quelldaten zu synthetisieren oder komplexe manuelle Prozessmodelle zu programmieren, setzt STS ein LLM-Agenten in eine simulierte Enterprise-Umgebung mit Policy-durchsetzenden APIs ein. Der Agent führt Operationen aus, als würde er mit echten Systemen interagieren – aber alles innerhalb einer kontrollierten Simulation. Dadurch entsteht Konsistenz von selbst: Die Daten sind strukturell valide, weil sie nur durch jene Operationen entstehen, die das System als gültig definiert.
Das Herzstück ist der Generalist Populator (GP), ein domänen-unabhängiger Agent, der ohne Zugriff auf Datenbankschemas arbeitet. In Tests über zehn verschiedene Enterprise-Szenarien erreichte GP im Durchschnitt eine Marginal Fidelity von 0,88 und erfüllte 100% aller Constraints – unabhängig vom Einsatzbereich.
Zum Vergleich: Statistische Synthesizer konnten sieben der zehn Umgebungen gar nicht bearbeiten, weil ihnen Seed-Daten fehlten. Schema-privilegierte Agenten scheiterten in 82% der Workflows beim Airline-Szenario, weil die Geschäftsprozesse eng gekoppelt sind und harte Task-Abhängigkeiten zu Bruchstellen führten.
Die Forschenden haben das komplette Framework, alle zehn Testumgebungen und die generierten Datensätze als Open Source verfügbar gemacht. Der Ansatz adressiert ein echtes Schmerz-Punkt in der Enterprise-KI: Während Tool-calling Agents längst produktiv im Einsatz sind, bleibt ihre systematische Evaluierung und das Finetuning auf neue Aufgaben schwierig, weil echte Enterprise-Daten selten zugänglich sind und strikte Compliance-Anforderungen gelten.
Einordnung
Tool-calling Agents haben in Enterprise-Umgebungen Realität gewonnen – sie rufen APIs auf, orchestrieren Prozesse, führen Abfragen durch und treffen Entscheidungen basierend auf strukturierten Daten. Das Problem: Um solche Agenten zu trainieren, zu evaluieren und auszuprobieren, brauchen Entwickler realistische Testdaten. Diese zu beschaffen ist in Unternehmen ein hochgradig restritktives Unterfangen. Datenschutzverordnungen, IP-Schutz, und Haftungsrisiken führen dazu, dass echte Produktionsdaten für Entwicklung kaum freigegeben werden.
Bisherige Synthese-Ansätze hatten fundamentale Schwächen: Tabellarische Synthesizer (etwa Generative Adversarial Networks für strukturierte Daten) erzeugen statistisch plausible Datensätze, können aber nicht garantieren, dass diese auch wirtschaftlich-logisch korrekt sind – etwa dass eine Flugbuchung nur mit gültigen Flugzeugen, Zeiten und Passagierdaten möglich ist. Procedure-basierte Ansätze wiederum erfordern, dass jemand die Geschäftslogik manuell kodiert. Das ist zeitaufwendig, fehleranfällig und nur für gut verstandene, repetitive Prozesse praktikabel.
STS dreht das Problem um: Statt Daten zu synthetisieren und danach zu hoffen, dass sie valide sind, lässt es den Agent nur das tun, was valide ist. Die simulierte Umgebung erzwingt Regeln durch ihre APIs – ähnlich wie eine echte Datenbank Constraints durch Fremdschlüssel und Überprüfungen sicherstellt. Das bedeutet: Strukturelle Validität ist eine Nebenfolge des Daten-Generierungsprozesses, nicht ein separates Problem, das man lösen muss.
Der Agent selbst (GP) ist domänen-agnostisch programmiert – er versteht keine Airline-spezifischen Regeln, keine HR-Workflows, keine Finanzprozesse. Stattdessen lernt er, indem er mit der Umgebung interagiert: Er stellt Anfragen, beobachtet Reaktionen, versucht Operationen und passt sein Verhalten an, wenn Fehler auftreten. Dadurch funktioniert derselbe Agent über völlig unterschiedliche Domänen hinweg.
Die 100% Constraint-Erfüllung zeigt, dass dieser Mechanismus tatsächlich robust ist. Kein fehlender Fremdschlüssel, keine ungültigen Zustandsübergänge, keine broken references – alles, was die simulierte Umgebung als ungültig einstuft, wird erst gar nicht generiert.
Was das bedeutet
Der praktische Gewinn liegt in der Entlastung von Enterprise-AI-Teams. Statt auf echte Daten zu kämpfen, auf Juristen zu warten oder manuelle Testszenararios zu schreiben, können Teams nun Simulations-Umgebungen für ihre Kernprozesse aufbauen und sofort mit dem Training beginnen. Das skaliert auch: Ein Generalist Populator funktioniert ohne Re-Training über verschiedene Domänen, was die Time-to-Evaluation deutlich senkt.
Das hat auch Implikationen für die Qualität von Tool-calling Agents selbst. Wer seine Agenten auf synthetischen Daten trainiert, die garantiert strukturell valid sind, hat weniger stille Fehler im Produktivbetrieb. Der Agent lernt nicht, mit ungültigen oder widersprüchlichen Zuständen umzugehen, weil er diesen nie begegnet – aber das ist kein Nachteil, sondern Feature. Die Umgebung ist sein Korrektor.
Der Open-Source-Release ist ein zweites Signal: Das Problem ist erkannt, die Lösung ist dokumentiert, und andere Organisationen können sie adaptieren. Das dürfte die Verfügbarkeit qualitativ guter Testdaten in diesem Bereich erheblich verbesdern und den Standard senken, auf den Teams hinarbeiten müssen, um ihre Agenten ernsthaft zu evaluieren.
