AutoSynthData mejora los agentes de IA con datos sintéticos

Por Redacción Pangea IA · 2 de octubre de 2026

ServiceNow ha presentado AutoSynthData, un sistema que fabrica y valida tareas sintéticas a partir de los fallos reales de un agente de inteligencia artificial. En sus pruebas controladas, el ajuste con esos datos elevó un 35 % relativo la tasa de éxito de un modelo Gemma en flujos empresariales híbridos y mejoró de forma notable su rendimiento en gestión de servicios de TI. El resultado es prometedor, pero todavía no demuestra que el método funcione igual en una empresa real.

La novedad, publicada el 2 de octubre por el equipo CoreAI de ServiceNow, apunta a uno de los problemas menos vistosos y más difíciles de los agentes empresariales: no basta con que un modelo razone bien en general. También debe respetar reglas, manejar herramientas, modificar el estado correcto de una aplicación y saber cuándo una petición es imposible. AutoSynthData intenta convertir precisamente esos errores concretos en un programa de entrenamiento que cambia a medida que mejora el modelo.

Qué es AutoSynthData y qué cambia

Los datos sintéticos son ejemplos generados artificialmente para entrenar o evaluar un sistema. La idea no es nueva. Lo diferente aquí es que ServiceNow no propone producir miles de instrucciones genéricas al azar, sino buscar la frontera de capacidad de un agente: tareas que todavía resuelve mal, que un modelo profesor sí puede completar y cuyo resultado se puede comprobar dentro de un entorno empresarial simulado.

Cada tarea se define con tres piezas: una especificación del sistema, la petición que recibe el agente y un verificador. La especificación recoge las herramientas, las políticas y el estado inicial; la petición describe el objetivo; y el verificador determina si el estado final es correcto. Esta última pieza es crucial. Un agente puede redactar una respuesta convincente y, aun así, haber actualizado el ticket equivocado, omitido una dependencia o ejecutado una acción prohibida.

El sistema parte de ejecuciones de diagnóstico del modelo objetivo y de un modelo profesor más capaz. Compara dónde falla el primero, cómo actúa el segundo y qué condiciones debe cumplir una solución válida. Después resume esas carencias en fichas de capacidad saneadas. Según ServiceNow, el generador no recibe las preguntas originales del conjunto de evaluación, sus entidades ni sus verificadores, una separación diseñada para reducir la contaminación del examen.

Un ciclo de generación, prueba y reparación

Detectar la carencia. El sistema identifica un patrón de fallo real del agente, no una categoría elegida de antemano.
Crear tareas nuevas. Varía las entidades, el estado inicial, las herramientas y la redacción sin copiar la prueba original.
Ejecutar la solución. El modelo profesor aporta una trayectoria que se reproduce dentro del entorno.
Validar en positivo y en negativo. La solución prevista debe pasar; resultados incorrectos o mutados deben fallar.
Reparar o descartar. Un crítico diagnostica inconsistencias y permite un número limitado de correcciones antes de aceptar la muestra.
Volver a medir. Tras el ajuste, los errores que persisten orientan la siguiente ronda de datos.

Este enfoque importa porque la calidad de un conjunto sintético no depende solo de que los ejemplos suenen plausibles. Una tarea imposible, una solución que no se puede ejecutar o un verificador demasiado permisivo pueden enseñar justo el comportamiento equivocado. AutoSynthData intenta poner controles automáticos en los tres puntos.

Los resultados: una mejora medible, no una victoria definitiva

ServiceNow probó el método en EnterpriseOps Gym, un banco de pruebas que simula herramientas de correo, calendario, archivos, atención al cliente, recursos humanos y gestión de servicios de TI. El entorno contiene 164 tablas, 512 herramientas y 1.150 tareas revisadas por expertos. En el trabajo que presentó el benchmark en marzo, el mejor de 14 modelos de frontera solo completaba el 37,4 % de las tareas, una señal de que estos flujos siguen siendo difíciles incluso para sistemas avanzados.

Prueba	Modelo objetivo	Profesor	Datos generados	Resultado comunicado
Flujos híbridos	Gemma 4 26B A4B	Qwen 3.8 27B	2.000 tareas en unas 18 horas	Pass@1 sube 7,2 puntos; mejora relativa del 35 %
Gestión de servicios de TI	Gemma 4 26B A4B	DeepSeek V4.1 Flash	1.994 tareas en 66 horas	Pass@1 pasa del 18,77 % al 27,18 %

En la prueba híbrida, la tasa de éxito del verificador también pasó del 63,01 % al 68,55 %. El equipo afirma que el modelo ajustado cerró el 59 % de la distancia que lo separaba del modelo de referencia. Son resultados relevantes porque proceden de acciones con estado y herramientas, no de preguntas de respuesta única.

Conviene leer las cifras con precisión. El 35 % es una mejora relativa, mientras que el avance absoluto fue de 7,2 puntos porcentuales. En ITSM, la subida fue de 8,41 puntos. Tampoco se trata de una comparación comercial entre asistentes listos para usar: es un experimento de ajuste supervisado sobre un modelo objetivo concreto dentro de un entorno controlado.

Por qué puede interesar a empresas y pymes

Para una empresa, el atractivo no está en generar datos por generar, sino en entrenar sobre sus propias reglas de operación sin necesitar que una persona escriba manualmente cada variación. Un equipo que despliegue un agente para tramitar incidencias, preparar altas de empleados o coordinar citas podría registrar fallos repetidos y transformarlos en familias de ejercicios verificables.

Eso abre una vía para modelos más pequeños y especializados. Si un agente de 26.000 millones de parámetros aprende mejor un proceso delimitado, una organización podría reservar modelos de frontera más caros para generar o revisar ejemplos y utilizar el modelo ajustado en el trabajo rutinario. No hay datos en la publicación que permitan calcular el ahorro real, pero la arquitectura separa de forma clara el coste ocasional del profesor y el uso recurrente del modelo objetivo.

También encaja con la tendencia hacia modelos especializados, como analizamos al explicar Koa, la IA de Salesforce para CRM. El valor ya no depende únicamente de tener el modelo más general, sino de combinarlo con contexto, herramientas, verificadores y datos de un dominio.

Qué debería exigir un piloto serio

Un inventario de tareas acotadas y reversibles, con permisos mínimos.
Registros de errores que separen fallos de razonamiento, uso de herramientas, políticas y datos.
Verificadores deterministas cuando sea posible, no solo otra valoración generada por IA.
Un conjunto de evaluación reservado que nunca alimente al generador.
Revisión humana de muestras aceptadas y rechazadas.
Métricas de efectos secundarios, coste, latencia y escalados a una persona, además de la tasa de éxito.

La necesidad de limitar acciones no es teórica. En ámbitos sensibles, un agente puede completar el objetivo principal y causar un perjuicio colateral. Ya vimos este problema al analizar los riesgos de fraude y error al comprar con agentes de IA. Un benchmark de estado final ayuda, pero la producción exige controles de identidad, autorización, auditoría y recuperación.

Los límites que no resuelve AutoSynthData

El primer límite es la evidencia. Los incrementos han sido comunicados por el equipo que desarrolló el método y todavía no hay una réplica independiente de esos experimentos de entrenamiento. Artificial Analysis mantiene una implementación independiente de EnterpriseOps Gym, lo que ayuda a comparar agentes en el mismo tipo de flujos, pero no valida por sí sola las mejoras atribuidas a AutoSynthData.

El segundo es la distancia entre simulación y producción. Un entorno reiniciable permite comprobar si un ticket o una base de datos terminan en el estado previsto. Una empresa real añade datos incompletos, sistemas heredados, excepciones, usuarios contradictorios y consecuencias que no siempre caben en un verificador automático.

El tercero es la dependencia del profesor. Si el modelo más potente interpreta mal una política o introduce un sesgo, puede propagarlo a miles de ejemplos. Las comprobaciones positivas y negativas reducen ese riesgo, pero solo dentro de las reglas que alguien haya formalizado. Lo que no está en la especificación puede quedar fuera de la evaluación.

Por último, «sintético» no significa automáticamente libre de problemas jurídicos o de privacidad. Las fichas de capacidad deben eliminar nombres, instrucciones internas y datos personales, y la organización necesita conocer la procedencia de cualquier contenido usado por el profesor. La reciente sentencia estadounidense sobre copyright y entrenamiento de IA recuerda que sustituir datos humanos por ejemplos generados no borra las obligaciones sobre las fuentes de partida.

Un paso hacia agentes que aprenden de sus propios fallos

AutoSynthData no convierte a los agentes empresariales en sistemas autónomos fiables de un día para otro. Su aportación es más concreta: propone un circuito para observar errores, crear ejercicios nuevos alrededor de ellos, comprobar que las soluciones son ejecutables y mover el entrenamiento hacia las carencias que todavía quedan.

Si otros equipos reproducen los resultados, el método puede reducir una de las barreras más caras de la IA especializada: construir datos útiles y verificables para procesos que cambian constantemente. La señal importante no es solo la mejora del 35 %, sino el cambio de enfoque. En lugar de alimentar al agente con más ejemplos genéricos, se le enseña justo aquello que aún no sabe hacer y se comprueba en el sistema donde tendrá que actuar.

Lecturas relacionadas

Fuentes consultadas

ServiceNow CoreAI: AutoSynthData, publicación técnica y resultados (2 de octubre de 2026).
Repositorio de EnterpriseOps Gym (consulta: 2 de octubre de 2026).
Artículo original de EnterpriseOps Gym en arXiv (consulta: 2 de octubre de 2026).
Implementación independiente EnterpriseOps-Gym-AA de Artificial Analysis (consulta: 2 de octubre de 2026).