El equipo CoreAI de ServiceNow publicó el 2 de octubre de 2026 AutoSynthData, un método para crear datos de entrenamiento a partir de las tareas que un agente de IA tiene dificultades para realizar. En lugar de añadir más ejemplos de forma general, el sistema utiliza los fallos del modelo objetivo y los aciertos de un modelo más potente para decidir dónde concentrarse. Los resultados publicados corresponden a experimentos en el entorno EnterpriseOps-Gym, no a una implantación demostrada en cualquier organización.
En un experimento del ámbito Hybrid se generaron 2,000 ejemplos en unas 18 horas. Según los investigadores, el entrenamiento elevó el promedio de Pass@1 en 7.2 puntos porcentuales, una mejora relativa del 35%. En un experimento de ITSM se generaron 1,994 ejemplos en 66 horas y el promedio de Pass@1 pasó del 18.77% al 27.18%. Las cifras describen las configuraciones experimentales publicadas; no se deben comparar sus tiempos de generación de datos sin tener en cuenta las diferencias entre ellas.
Por qué un agente puede explicar bien y aun así fallar
Un agente empresarial no se evalúa únicamente por la última frase que escribe. Si se le pide actualizar una solicitud de servicio, debe encontrar la solicitud correcta, comprender los permisos y realizar el cambio adecuado. Un mensaje de finalización convincente no corrige una situación en la que se ha actualizado otro registro.
La ficha del conjunto de datos EnterpriseOps-Gym describe un entorno de simulación con bases de datos sintéticas, herramientas operativas y la posibilidad de restablecer el entorno entre experimentos. La medición examina el estado del sistema después de las acciones del agente mediante comprobaciones ejecutables. El énfasis está en el resultado conseguido, no en exigir que todos los agentes elijan exactamente la misma secuencia de acciones.
El conjunto incluye 1,150 tareas creadas por expertos en 8 ámbitos empresariales, con 512 herramientas y 164 tablas de datos. Estas cifras explican por qué no es una prueba convencional de preguntas y respuestas: una acción puede afectar a información de la que dependa una tarea posterior.
Por ejemplo, en un entorno de prueba se podría solicitar un cambio en el calendario manteniendo a determinados participantes. Un resultado correcto debe incluir tanto la actualización solicitada como los detalles que no debían cambiar. No basta con que exista un registro nuevo. El ejemplo ilustra la naturaleza de la prueba; no es un nuevo resultado comunicado por los investigadores.
El fallo se convierte en materia de aprendizaje
Según la publicación sobre AutoSynthData, las tareas de diagnóstico se transforman en descripciones de capacidades y, a partir de ellas, se generan ejercicios nuevos. El generador no recibe los enunciados ni las trayectorias originales de las tareas de evaluación. Antes de aceptar un ejemplo para entrenar, se comprueban tanto su solución como el mecanismo de verificación. Con ello se intenta evitar el entrenamiento con una tarea que parece razonable pero no puede realizarse.
La distinción entre identificar una debilidad y copiar un examen importa. Si un modelo vio la misma pregunta durante el entrenamiento, acertar después puede reflejar que ha memorizado el ejemplo. Para comprobar si ha aprendido una capacidad hay que cambiar la situación, los nombres y los detalles de la solicitud, y ver si la misma habilidad funciona también en las nuevas condiciones.
También hay una cuestión relativa al propio verificador. Si un ejercicio pide transferir una tarea a un equipo concreto, un verificador que solo compruebe el cambio de estado puede aprobar un resultado incorrecto. En cambio, uno que exija una redacción específica puede rechazar un resultado válido. La calidad de los datos de entrenamiento incluye, por tanto, la calidad de la definición del éxito.
Este punto distingue la producción de grandes cantidades de texto de la construcción de material de aprendizaje útil. El número de ejemplos importa, pero no revela si son variados, viables y precisos. Una colección enorme de ejercicios casi idénticos puede dejar sin evaluar la misma debilidad.
La selección de los casos de prueba también puede cambiar el panorama. Si el conjunto de validación solo contiene tareas en las que está permitido actuar, no evaluará bien la capacidad de detenerse cuando falta autorización. Si únicamente contiene peticiones claras, no revelará cómo afronta el agente una instrucción que admite dos interpretaciones.
Por eso, un equipo que adopte el entrenamiento basado en fallos también debería documentar qué quedó fuera del conjunto: qué tipos de tareas se excluyeron, qué herramientas no estaban disponibles y qué condiciones no se comprobaron. Esa información permite interpretar la puntuación de éxito dentro de sus límites, en lugar de convertir un resultado local en una afirmación general.
La investigación anterior explica el problema, no el estado actual de todos los modelos
El artículo original sobre EnterpriseOps-Gym se presentó en marzo de 2026. Sus autores evaluaron 14 modelos y detectaron carencias en la planificación y el uso de herramientas. Según el resumen, proporcionar planes de acción humanos ideales mejoró los resultados entre 14 y 35 puntos porcentuales. Los investigadores lo interpretaron como una señal de que la planificación era un factor limitante importante en el entorno estudiado.
También observaron que a los agentes les costaba rechazar tareas imposibles de completar. Es otro tipo de fallo: un sistema que no sabe cuándo detenerse puede ejecutar acciones que no lo acercan a una solución. Sin embargo, los resultados de marzo no son una clasificación actualizada de los modelos lanzados desde entonces y no deben utilizarse para determinar su rendimiento actual.
Ese contexto ayuda a entender la nueva pregunta de investigación. Si una debilidad está en la planificación de acciones, añadir conocimientos generales al modelo no necesariamente la resolverá. Pueden hacer falta ejercicios en los que existan dependencias entre pasos, falte información o no deba ejecutarse una acción. Es una interpretación de la estructura del problema, no una prueba de que el mismo método resuelva todas las debilidades.
Una mejora en una prueba debe seguir siendo verificable
En otro artículo de contexto, de enero de 2026, Anthropic distingue entre evaluaciones de capacidades, que examinan lo que un agente todavía no hace bien, y evaluaciones de regresión, destinadas a comprobar que se conservan las capacidades que ya funcionaban. La diferencia ayuda a interpretar el entrenamiento adicional: mejorar en una tarea concreta no elimina la necesidad de comprobar que el modelo no haya empeorado en otras.
Ese artículo describe también la combinación de comprobaciones mediante código, evaluación con modelos y revisión humana. Cada enfoque tiene limitaciones: una prueba rígida puede pasar por alto una solución válida expresada de otra manera y un evaluador basado en modelos necesita calibración. No es una validación independiente de AutoSynthData, sino contexto técnico para abordar cómo se evalúa un sistema de este tipo.
Para un equipo israelí que construya un agente para trabajar en hebreo, la conclusión práctica es comenzar con un conjunto real de fallos bien definidos. Se puede comprobar, por ejemplo, la confusión entre nombres parecidos, la identificación de una fecha o una acción ejecutada en el documento equivocado. Después hace falta un conjunto de pruebas separado que no se haya utilizado para generar los ejemplos de entrenamiento.
La nueva publicación no incluye pruebas específicas de mejora en hebreo ni un compromiso de ahorro empresarial. Propone una forma sistemática de elegir qué debe aprender el agente y comunica mejoras en dos ámbitos experimentales. El siguiente paso importante será comprobar si esas mejoras se mantienen ante tareas nuevas, en entornos distintos y con pruebas que midan también errores que no se pretendía introducir inicialmente.