ServiceNows AutoSynthData beschreibt, wie aus Fehlern eines Agenten ausführbare synthetische Trainingsaufgaben entstehen. Entscheidend ist nicht allein die Menge: Jede Aufgabe umfasst eine Umgebung und eine Prüflogik. Bevor Sie den Ansatz übernehmen, prüfen Sie, ob diese Logik falsche Ergebnisse zurückweist und ob die Verbesserung auf einem unangetasteten Abnahmedatensatz bestehen bleibt.
Was ServiceNow veröffentlicht hat
Am 2. Oktober 2026 veröffentlichte ServiceNow CoreAI AutoSynthData: Generating Training Data for Enterprise Agents. Der Ansatz evaluiert ein Zielmodell und ein stärkeres Lehrermodell, identifiziert fehlende Fähigkeiten, erzeugt dazu neue Aufgaben und validiert sie vor dem überwachten Fine-Tuning. Die Veröffentlichung berichtet über Experimente in EnterpriseOps Gym, nicht über einen unabhängig bestätigten Produktiveinsatz.
Eine Aufgabe besteht dabei nicht nur aus einem Prompt und einer Musterantwort. ServiceNow definiert sie als Systemspezifikation, Nutzerauftrag und Verifikator. Die Spezifikation beschreibt Regeln und Ausgangsbedingungen; der Auftrag definiert die Arbeit; der Verifikator prüft den Erfolg. Damit ist der Ansatz für Unternehmen relevant, deren Agenten Tickets, Kalender oder andere persistente Geschäftsdaten verändern sollen.
Das zugrunde liegende EnterpriseOps-Gym-Paper wurde bereits am 13. März 2026 eingereicht. Es ist Hintergrundmaterial, keine heutige Neuveröffentlichung. Neu sind die beschriebene Pipeline zur fehlerbasierten Trainingsdatenerzeugung und die berichteten Ergebnisse nach dem Training. Ein bestehender Benchmark wird nicht zum neuen Produkt, weil ein neuer Artikel auf ihn verweist.
Was den Ansatz von generischen synthetischen Beispielen unterscheidet
AutoSynthData überführt beobachtete Schwächen zunächst in bereinigte Fähigkeitsspezifikationen. Nach Angaben von ServiceNow erhält der Generator weder die ursprünglichen Evaluationsprompts und Entitäten noch deren Ausführungsverläufe oder Verifikator-Details. Er bekommt Fähigkeitsbeschreibungen und erzeugt Aufgaben mit anderen Zuständen und Lösungswegen.
Die Erzeugung hat zwei Phasen. „Target“ erstellt und validiert die Kernbeispiele. „Multiply“ erzeugt Varianten akzeptierter Target-Beispiele. Eine solche Variante darf jedoch nicht selbst Ausgangspunkt weiterer Multiply-Varianten werden. Das begrenzt Ableitungsketten, die sich vom geprüften Ursprung entfernen. Die Regel allein beweist weder Vielfalt noch die Abwesenheit von Informationsübertragung aus der Evaluation.
Wichtiger sind die beiden Prüfrichtungen. Die positive Verifikation führt die Referenzlösung aus und prüft, ob sie besteht. Die negative Verifikation verändert relevante Teile des erwarteten Ergebnisses und prüft, ob dieses falsche Ergebnis durchfällt. Fehlerhafte Kandidaten werden mit begrenzten Korrekturversuchen überarbeitet und erneut geprüft. Eine zusätzliche Bewertung ganzer Batches adressiert Abdeckung und Wiederholungen: Einzeln gültige Beispiele ergeben nicht automatisch einen sinnvollen Trainingsplan.
In der berichteten Konfiguration werden Aufgaben bevorzugt, die das Zielmodell in höchstens einem von drei Versuchen löst, während der stärkere Solver mindestens zwei von drei Versuchen besteht. Dies sind ServiceNows experimentelle Auswahlregeln, keine allgemeingültigen Abnahmeschwellen. Drei Durchläufe können Hinweise auf den Schwierigkeitsgrad geben; für eine präzise Zuverlässigkeitsschätzung reichen sie nicht.
Was die berichtete Verbesserung belegt – und was nicht
ServiceNow berichtet über 2.000 synthetische Hybrid-Trainingsbeispiele, erzeugt in rund 18 Stunden. Das Zielmodell war Gemma-4-26B-A4B-it, das Lehrermodell Qwen3.8-27B. Der beste Checkpoint nach Epoche fünf verbesserte den mittleren Pass@1-Wert um 7,2 Prozentpunkte. Die separat ausgewiesene Verifikator-Erfolgsrate stieg von 63,01 auf 68,55 Prozent. Dies sind vom Anbieter berichtete Versuchsergebnisse, keine hier reproduzierten Messungen. Die beiden Kennzahlen sind nicht austauschbar.
Das ITSM-Experiment nutzte ein anderes Lehrermodell und erzeugte 1.994 Beispiele in 66 Stunden. Als wesentliche Gründe für die längere Laufzeit nennen die Autoren das größere Lehrermodell und eine frühere Pipeline-Implementierung. Keine der Laufzeiten ist ein Preisangebot oder ein hardwarebereinigter Effizienzvergleich. Die Veröffentlichung belegt weder einen Qualitätsgewinn für deutsche Anfragen noch eine unternehmensweite Automatisierungsquote oder eine Einsparung im Produktivbetrieb.
Auch das Evaluationsdesign setzt Grenzen. Bereinigte Spezifikationen reduzieren direktes Kopieren. Der Trainingsplan lernt aber weiterhin aus Fehlern, die während der Evaluation sichtbar wurden. Wiederholte Auswahl von Fähigkeiten und Checkpoints anhand derselben Evaluationsumgebung kann den Entwicklungsprozess an diese Umgebung anpassen. Unsere technische Empfehlung: Halten Sie eine separate Abnahmesuite zurück, die weder Erzeugung und Reparatur noch die Checkpoint-Auswahl steuert. Nutzen Sie segmentbezogene Freigabekriterien für Modelländerungen, statt den besten Gesamtwert automatisch freizugeben.
Was ist verfügbar, und welche Kosten entstehen?
Die Veröffentlichung ist öffentlich lesbar. Das verlinkte EnterpriseOps-Gym-Repository enthält Benchmark-Code, Konfigurationshinweise und Anleitungen für domänenspezifische MCP-Server und Ausgangsdatenbanken. Seine Repository-Lizenz ist Apache 2.0. Der öffentliche Datensatz enthält Aufgabendefinitionen und Material zur Ergebnisprüfung.
Übertragen Sie diese Repository-Lizenz nicht pauschal auf alle in der Ankündigung genannten Bestandteile. Der geprüfte AutoSynthData-Artikel belegt weder eine separat herunterladbare AutoSynthData-Implementierung noch einen Preis für einen gehosteten Dienst, regionale Leistungszusagen oder kommerzielle Supportbedingungen. Verfügbarer Benchmark-Code beweist nicht, dass die vollständige Erzeugungspipeline als einsatzfertiges Paket vorliegt. Prüfen Sie die Bedingungen für Datensätze, Container, Ziel- und Lehrermodelle getrennt. Einkauf und Rechtsberatung müssen den vorgesehenen Einsatz bewerten.
Ein realistisches Pilotbudget umfasst Inferenz des Lehrer- und Zielmodells, verworfene Kandidaten, Korrekturversuche, Umgebungsresets, Trainingsrechenleistung, Abnahme und Wartung des Umgebungsadapters. Aussagekräftiger als erzeugte Beispiele pro Stunde sind intern die gesamten Erzeugungs- und Validierungskosten pro akzeptiertem Beispiel, ergänzt um Ablehnungsgründe. Messen Sie anschließend die Kosten pro erfolgreich abgeschlossener, zurückgehaltener Geschäftsaufgabe vor und nach dem Training. Aus den veröffentlichten Erzeugungszeiten allein lässt sich kein numerischer Kostenvorteil ableiten.
Das Betriebsrisiko: richtiger Endzustand, unzulässiger Weg
Betrachten Sie eine illustrative ITSM-Aufgabe: Ein Incident soll der autorisierten Supportgruppe zugewiesen werden, ohne seine Priorität zu ändern oder seine Beschreibung einem anderen Mandanten zugänglich zu machen. Ein schwacher Verifikator prüft nur die endgültige Zuweisung. Er könnte einen Agenten akzeptieren, der zwischenzeitlich unberechtigten Zugriff gewährt und ihn vor dem abschließenden Zustand wieder entzieht.
Dieses Beispiel ist eine technische Bedrohungsbetrachtung, kein berichteter AutoSynthData-Vorfall. Es zeigt, warum Endzustandsprüfung und Durchsetzung von Ausführungsregeln unterschiedliche Fragen beantworten. Prüfen Sie das Geschäftsergebnis in einer zurücksetzbaren Umgebung, erfassen Sie zusätzlich relevante Werkzeugereignisse und verhindern Sie verbotene Aktionen während der Ausführung. Eine SQL-Abfrage des Endzustands belegt nicht, dass keine unzulässige Zwischenaktion stattfand – es sei denn, die erforderliche Historie ist ebenfalls verfügbar und wird geprüft.
Umgekehrt kann eine Prüflogik, die genau eine Werkzeugaufrufsequenz verlangt, eine gültige Alternativlösung zurückweisen. Trennen Sie Ergebnisbedingungen von tatsächlich notwendigen Vorgaben für den Ausführungsweg. Das Ziel lautet weder „den Lehrer kopieren“ noch „irgendeinen bestandenen Datenbankzustand erreichen“, sondern die autorisierte Aufgabe ohne Verletzung geschützter Bedingungen abschließen. Der Leitfaden zur Evaluation produktiver KI-Agenten ergänzt diese engere Trainingsdatenprüfung um betriebliche Kennzahlen.
Fünf Prüfungen vor der Pilotfreigabe
1. Prüfen Sie, ob Training den tatsächlichen Fehler adressiert
Beginnen Sie mit einem wiederkehrenden Fehler, dessen Vermeidung das Zielmodell plausibel lernen kann. Fehlende aktuelle Dokumentation, ein defekter Konnektor oder unzureichende Berechtigungen werden durch synthetisches Training nicht repariert. Nutzen Sie den Entscheidungsrahmen für Prompting, RAG und Fine-Tuning. Dokumentieren Sie Fehlerklasse und Ausgangsmessung, bevor Sie Beispiele erzeugen.
2. Fixieren Sie die Umgebung und begrenzen Sie ihre Auswirkungen
Hinterlegen Sie Werkzeugschemata, Regelversion, Digest des Ausgangszustands und erlaubte Übergänge bei jeder Aufgabe. Setzen Sie den Zustand zwischen Versuchen zurück und prüfen Sie den Reset. Trennen Sie Sandbox-Zugangsdaten vom Produktivbetrieb, unterbinden Sie unnötigen ausgehenden Zugriff und prüfen Sie generierten Verifikator-Code vor der Ausführung. Synthetische Prompts machen beliebige SQL-Abfragen, Programme oder MCP-Aktionen nicht vertrauenswürdig.
3. Testen Sie die Prüflogik mit gezielten Gegenbeispielen
Eine gültige Lösung muss bestehen. Ändern Sie danach Objekt, Mandant, Pflichtfeld oder eine geschützte Nebenwirkung und verlangen Sie Ablehnung. Testen Sie auch einen gültigen alternativen Lösungsweg. Bewahren Sie Mutation, erwartetes Urteil und beobachtetes Urteil als Nachweis auf. Eine Prüfung, die diese Fälle nicht unterscheiden kann, muss vor Nutzung ihrer Beispiele als Trainingssignal repariert werden. Auch das Bestehen einer endlichen Menge solcher Tests beweist noch keine vollständige Korrektheit.
4. Trennen Sie Trainingsfeedback von Abnahmenachweisen
Versionieren Sie Fähigkeitsspezifikationen, Elternbeispiele, Lehrermodellkonfiguration und Reparaturhistorie. Halten Sie Multiply-Beispiele bis zu ihrem akzeptierten Target-Ursprung nachvollziehbar. Prüfen Sie Ähnlichkeit und Aufgabenfamilien über den gesamten Batch. Evaluieren Sie das trainierte Modell anschließend mit zurückgehaltenen Fällen – einschließlich deutscher Anfragen und lokaler Prozessregeln, soweit dies Einsatzanforderungen sind. Sobald Sie diese Fälle zur Reparatur des nächsten Batches verwenden, sind sie nicht mehr unangetastet.
5. Vereinbaren Sie Abbruchkriterien und eine vollständige Kostenrechnung
Legen Sie geschützte Fehlerklassen, Erzeugungsbudget, Reparaturlimit und Verantwortlichkeit für unklare Ergebnisse fest. Stoppen Sie, wenn Verifikatorfehler, geringe Vielfalt oder wiederholt unlösbare Aufgaben weitere Erzeugung wenig aussagekräftig machen. Geben Sie das Modell erst frei, wenn es den vereinbarten Qualitäts- und Betriebsanforderungen genügt. Andernfalls behalten Sie die Fehlernachweise, statt die Größe des Datensatzes als Fortschritt auszugeben.
Die nächste Entscheidung betrifft Nachweise, nicht Datenmenge
AutoSynthData liefert einen konkreten Entwurf für gezieltes synthetisches Agententraining. Seine wichtigste technische Aussage: Aufgabenerzeugung, Umgebungsausführung und Verifikation müssen gemeinsam entwickelt werden. Für Unternehmen ist der nächste Schritt eine begrenzte Machbarkeitsprüfung mit einem Workflow, einer diagnostizierten Schwäche, geprüften Verifikatoren und einer unabhängigen Abnahme – keine unmittelbare Produktivfreigabe aufgrund eines Anbieter-Benchmarks.
Die Beratung zur KI-Automatisierung kann diesen Trainingsdatenvertrag mit vorhandenen Werkzeugen, Datengrenzen und Freigabenachweisen verbinden. Bringen Sie einen repräsentativen Fehlerfall und die Bedingungen mit, die niemals verletzt werden dürfen. Davon hängt ab, ob zusätzliche Trainingsdaten die richtige Investition sind.
