AutoSynthData: la generación de datos de entrenamiento para agentes empresariales convierte los fallos en un plan de aprendizaje

ServiceNow CoreAI lanzó AutoSynthData el 2 de octubre e informó de mejoras obtenidas a partir de casi 4.000 tareas sintéticas en dos experimentos con agentes empresariales. AutoSynthData: la generación de datos de entrenamiento para agentes empresariales parte de los fallos de los modelos y transforma esas debilidades en ejemplos de entrenamiento ejecutables y verificables. El conflicto es claro: los datos sintéticos pueden escalar rápidamente, pero las tareas generadas también pueden enseñar comportamientos equivocados.

Esto hace que AutoSynthData sea más que otro sistema para pedirle a un modelo que invente prompts. Intenta construir un ciclo cerrado de entrenamiento en torno al agente objetivo, su entorno operativo y un modelo docente más potente. Cada tarea aceptada incluye un estado inicial del sistema, una solicitud del usuario, una trayectoria exitosa y un verificador que evalúa el estado final.

ServiceNow afirma que el enfoque mejoró un modelo Gemma objetivo en dos dominios de EnterpriseOps Gym. Sin embargo, esas mejoras proceden de experimentos controlados dentro de la misma familia de benchmarks que dio forma al plan de aprendizaje. El resultado presiona a los equipos que dependen de conjuntos de datos estáticos escritos por humanos, al tiempo que deja sin resolver la transferencia externa y la fiabilidad en producción.

AutoSynthData: la generación de datos de entrenamiento para agentes empresariales comienza con el fallo

El cambio importante es que ServiceNow trata los fallos de los agentes como indicaciones sobre qué datos de entrenamiento generar a continuación.

Las canalizaciones tradicionales de datos sintéticos suelen partir de temas, plantillas o ejemplos semilla. Amplían esas entradas en colecciones mayores, filtran los resultados y utilizan las muestras supervivientes para el entrenamiento. Ese proceso puede generar volumen sin demostrar que los nuevos datos aborden las debilidades reales de un modelo.

AutoSynthData invierte ese orden. Primero evalúa un modelo objetivo dentro de un entorno operativo y estudia dónde falla. Un modelo docente más potente intenta resolver las mismas tareas de diagnóstico, proporcionando una comparación entre comportamientos fallidos y exitosos.

El sistema analiza la capacidad implicada, las herramientas necesarias, la estructura del flujo de trabajo y el estado final que cuenta como éxito. También identifica detalles que pueden cambiar sin eliminar la capacidad subyacente. Estas observaciones se convierten en lo que ServiceNow denomina tarjetas de especificación de capacidades depuradas.

Estas tarjetas guían la generación sin revelar los prompts de evaluación originales, las entidades, las trayectorias ni los detalles del verificador. Esta separación busca reducir la filtración directa del benchmark. También obliga al generador a crear situaciones nuevas, en lugar de limitarse a parafrasear preguntas de prueba.

El formato de tarea tiene tres partes conectadas. Una especificación del sistema define las políticas, las acciones disponibles y el estado inicial del entorno. Un prompt de usuario indica el resultado solicitado, mientras que un verificador determina si el agente alcanzó un estado final aceptable.

Esta estructura importa porque el trabajo empresarial rara vez termina con una respuesta de texto. Un agente de servicios de TI podría tener que inspeccionar un incidente, comprobar una autorización, actualizar un registro y conservar un historial de auditoría. Una respuesta fluida no demuestra que ninguna de esas acciones se haya realizado correctamente.

El lanzamiento de AutoSynthData describe dos etapas de generación. La etapa objetivo crea y valida ejemplos centrales basados en carencias de capacidades identificadas. La etapa de multiplicación produce nuevas variantes a partir de muestras objetivo aceptadas.

Cada variante recibe su propia solicitud, entidades, estado inicial, trayectoria de referencia y verificador. Una muestra multiplicada no puede convertirse en semilla de otra muestra multiplicada. Este límite está diseñado para evitar que varias generaciones de expansión sintética se alejen del núcleo validado.

La canalización separa el control central de generación de la ejecución específica del entorno. Un controlador gestiona la cobertura, las comprobaciones de calidad y la construcción del conjunto de datos. Un adaptador ejecuta herramientas, gestiona el estado, reproduce soluciones de referencia, evalúa agentes y aplica una verificación determinista.

Esta separación ofrece al enfoque una vía más allá de un único benchmark. En teoría, una empresa podría mantener el controlador compartido mientras escribe un adaptador para sus propios sistemas. Sin embargo, cada nuevo adaptador necesitaría herramientas precisas, transiciones de estado realistas y criterios de éxito fiables.

Por tanto, la noticia no es simplemente que ServiceNow haya generado tareas sintéticas. La empresa ha construido un proceso que elige tareas según las debilidades del modelo actual. Después, desplaza el objetivo de entrenamiento a medida que cambian esas debilidades.

Este ciclo adaptativo desafía el desarrollo de conjuntos de datos estáticos. Una colección fija pierde valor una vez que un modelo resuelve la mayor parte de ella. AutoSynthData, en cambio, busca cerca del límite actual de capacidades del modelo, donde los ejemplos siguen siendo difíciles pero aún enseñables.

La idea también cambia lo que representa un fallo de evaluación. En lugar de convertirse únicamente en una puntuación o un informe de errores, el fallo se convierte en materia prima para el posentrenamiento. El mismo entorno puede diagnosticar debilidades, generar prácticas específicas y probar el modelo actualizado.

Ese ciclo es la afirmación central de AutoSynthData: la generación de datos de entrenamiento para agentes empresariales. ServiceNow aún no ha demostrado que funcione en entornos empresariales no relacionados. Aun así, ha definido una alternativa concreta al escalado indiscriminado de datos sintéticos.

Los conjuntos de datos estáticos para agentes se enfrentan ahora a un objetivo móvil

AutoSynthData presiona a los equipos que recopilan datos de entrenamiento amplios sin medir si cada muestra enseña una capacidad ausente.

Los desarrolladores de agentes empresariales afrontan un difícil problema de datos. Los registros de producción contienen patrones útiles de flujo de trabajo, pero también pueden incluir información personal, datos empresariales confidenciales y resultados incoherentes. Las tareas escritas por humanos evitan algunas preocupaciones de privacidad, pero crear suficientes ejemplos variados y verificables resulta costoso.

Los datos sintéticos ofrecen escala, pero la escala por sí sola no selecciona la lección adecuada. Un modelo que ya gestiona solicitudes de restablecimiento de contraseñas obtiene poco de miles de ejemplos similares. Necesita tareas que expongan problemas no resueltos, como comprobaciones de políticas, planificación multisistema y rechazos seguros.

EnterpriseOps Gym proporciona el entorno controlado utilizado para los experimentos de ServiceNow. Su artículo sobre el benchmark describe tareas con estado en las que un agente debe razonar entre herramientas y dejar el sistema subyacente en la condición correcta. Esto difiere de los benchmarks que solo califican una respuesta de texto final.

ServiceNow describe EnterpriseOps Gym como una plataforma que cubre ocho dominios empresariales. El entorno asociado incluye 512 herramientas funcionales y 164 tablas de bases de datos interconectadas. Estos recursos sustentan flujos de trabajo en áreas como la gestión de servicios de TI, la atención al cliente y los recursos humanos.

Según ServiceNow, el benchmark más amplio contiene 1.150 tareas empresariales. Evalúan planificación, cumplimiento de políticas y cambios de estado en sistemas conectados. El conjunto de datos publicado también brinda a investigadores externos acceso a los materiales del benchmark.

Estas cifras explican por qué importa la generación dirigida. Un solo flujo de trabajo puede combinar varias herramientas, registros, políticas y dependencias. Pequeños cambios en el estado inicial pueden alterar qué secuencia es válida o si la acción solicitada debería realizarse siquiera.

ServiceNow informó previamente de que proporcionar planes de tareas de expertos elevó el rendimiento entre un 15 % y un 35 % en dominios empresariales difíciles. Ese hallazgo sugiere que la planificación sigue siendo una limitación importante, incluso cuando un agente puede llamar correctamente a herramientas individuales. AutoSynthData intenta transformar esas carencias de planificación en oportunidades repetidas de entrenamiento.

La presión recae primero sobre los equipos de evaluación estática. Un conjunto de pruebas fijo puede identificar una debilidad, pero no crea automáticamente un plan de aprendizaje que la aborde. Los investigadores aún deben traducir los fallos en ejemplos diversos, soluciones válidas y una lógica de calificación fiable.

La segunda presión recae sobre los proveedores de modelos de propósito general. Los promedios sólidos en benchmarks pueden ocultar fallos causados por políticas locales, estructuras de tablas o reglas de flujo de trabajo. Las empresas necesitan pruebas de que un modelo puede operar dentro de sus sistemas concretos, no solo responder preguntas sobre ellos.

La tercera presión recae sobre las empresas que construyen plataformas de agentes. Si el entrenamiento adaptativo demuestra ser útil, la infraestructura de evaluación pasa a formar parte del desarrollo de modelos en lugar de ser una puerta final de control de calidad. Las plataformas necesitarán entornos reproducibles, generación de tareas, registros de ejecución y verificación basada en el estado.

Este requisito favorece a las organizaciones que cuentan con simuladores operativos o gemelos digitales. Salesforce ha seguido una dirección relacionada con CRMArena-Pro, que utiliza entornos empresariales simulados para evaluar agentes en flujos de trabajo de negocio. La coincidencia señala un movimiento más amplio hacia las pruebas de agentes ejecutables y fundamentadas en el entorno.

Las vías no son idénticas. Un benchmark puede comparar modelos sin modificarlos, mientras que AutoSynthData usa los fallos del benchmark para generar datos de posentrenamiento. Uno mide la capacidad y el otro intenta desplazarla.

Esta distinción importa para los compradores empresariales. Una clasificación identifica el modelo más potente bajo condiciones declaradas. Un plan de aprendizaje adaptativo pregunta si un modelo objetivo más barato o pequeño puede mejorar en las tareas recurrentes propias de la organización.

Los resultados comunicados por ServiceNow hacen concreta esa posibilidad, pero no la resuelven. Tras el entrenamiento, el modelo objetivo aún completaba solo una minoría de las tareas de servicios de TI. Mejor que la referencia no significa preparado para acceder a producción sin supervisión.

La calidad del conocimiento también sigue siendo una limitación práctica. Un agente no puede seguir una política que falta, es contradictoria o resulta inaccesible. Los equipos que construyen una base de conocimiento consultable siguen necesitando material fuente claro antes de que las tareas de entrenamiento generadas puedan reflejar el trabajo real.

Por tanto, AutoSynthData desplaza el cuello de botella en vez de eliminarlo. Los equipos necesitan menos variaciones elaboradas manualmente, pero necesitan un entorno fiable y una verificación precisa. Ese intercambio se vuelve decisivo cuando un agente puede modificar registros de clientes, empleados o infraestructuras.

El mecanismo depende de tareas ejecutables y verificadores estrictos

AutoSynthData solo funciona cuando las solicitudes generadas, las soluciones de referencia y los verificadores coinciden sobre qué significa el éxito.

La canalización comienza identificando tareas que diferencian al modelo objetivo de un docente más potente. En la configuración comunicada, ServiceNow favorece candidatos que el objetivo resuelve como máximo una vez en tres intentos. El solucionador más potente debe completarlas al menos dos veces en tres intentos.

Este filtro busca una banda de dificultad útil. Las tareas que derrotan a ambos modelos no ofrecen una demostración fiable. Las tareas que ambos resuelven sistemáticamente consumen capacidad de entrenamiento sin abordar una debilidad clara.

Una vez que un candidato entra en la canalización, AutoSynthData ejecuta su trayectoria de referencia. Una trayectoria es la secuencia de llamadas a herramientas y acciones utilizada para alcanzar el estado solicitado. Después, el verificador inspecciona el resultado frente a las condiciones de éxito de la tarea.

Esta comprobación positiva pregunta si la solución prevista funciona realmente. Puede revelar un estado inicial no válido, una herramienta no disponible, una secuencia de acciones rota o una inconsistencia entre la solicitud y el verificador. Un ejemplo de apariencia plausible falla si no puede superar la ejecución.

El pipeline también realiza verificación negativa. Modifica los resultados esperados y confirma que los estados incorrectos no superen la validación. Este paso es importante porque un verificador débil puede recompensar a un agente que omite acciones obligatorias o incumple una restricción importante.

Consideremos una solicitud para cerrar un incidente de TI solo después de confirmar la resolución con el empleado afectado. Un verificador que revise únicamente el estado del incidente aceptaría un atajo inseguro. Un verificador más sólido también exigiría el registro de confirmación y las notas obligatorias.

El mismo problema aparece cuando varias soluciones son válidas. Un verificador debería reconocer resultados aceptables sin exigir una única secuencia de referencia exacta. ServiceNow lo plantea como integridad, junto con la coherencia con la solicitud y el rechazo adecuado de comportamientos incorrectos.

Estos requisitos crean un equilibrio difícil. Un verificador demasiado permisivo recompensa el trabajo incompleto. Uno demasiado restrictivo penaliza estrategias legítimas y entrena al modelo para imitar una secuencia arbitraria.

Los candidatos fallidos entran en un ciclo acotado de crítica y reparación. Un crítico examina la construcción de la tarea, el estado inicial, la solución y la lógica de verificación. El sistema aplica correcciones específicas, vuelve a ejecutar los controles pertinentes y acepta o rechaza el candidato revisado.

Reparar un candidato existente puede preservar trabajo útil. También evita reiniciar la generación cada vez que un componente contiene un defecto corregible. El límite de reintentos impide que el sistema dedique recursos ilimitados a una familia de tareas de bajo rendimiento.

AutoSynthData revisa después la calidad de todo el lote. Los ejemplos válidos de forma individual aún pueden formar un conjunto de datos repetitivo. Un generador podría producir en exceso flujos de trabajo conocidos mientras ignora combinaciones difíciles de políticas, herramientas o estados del sistema.

El controlador rastrea muestras aceptadas y rechazadas, patrones repetidos, cobertura de capacidades y hallazgos recurrentes de las críticas. Reduce la generación en áreas sobrerrepresentadas y redirige el esfuerzo hacia las brechas. Esto crea retroalimentación por encima del nivel de las tareas individuales.

Las etapas target y multiply respaldan esa estrategia. Las muestras target establecen familias de tareas validadas en torno a brechas específicas de capacidad. Las muestras multiply varían redacción, entidades, combinaciones de herramientas y estados del entorno sin ampliar recursivamente las variantes anteriores.

Este diseño reduce un riesgo común de los datos sintéticos. La generación recursiva puede amplificar pequeños errores, ya que cada nueva muestra hereda supuestos de otra muestra generada. Anclar todas las variantes a ejemplos target evaluados limita esa cadena.

El enfoque también ofrece a las empresas una trazabilidad de auditoría más defendible. Cada ejemplo de entrenamiento puede asociarse con su estado inicial, secuencia de acciones prevista, verificador y resultado de validación. Esto resulta más útil que una carpeta que contiene prompts sin contexto ejecutable.

Sin embargo, las comprobaciones deterministas no pueden codificar todas las dimensiones significativas de calidad. Un estado final de base de datos puede parecer correcto incluso cuando un agente expuso información sensible durante el proceso. Otra trayectoria puede generar cambios innecesarios antes de restaurar el estado esperado.

Siguen siendo necesarios los registros de ejecución y las comprobaciones conscientes de las políticas. La propia herramienta de evaluación de agentes de ServiceNow pone énfasis en conjuntos de datos, registros de ejecución y múltiples dimensiones de calidad. AutoSynthData extiende esa filosofía a la producción de datos de entrenamiento.

El mecanismo también depende del docente. Un modelo más potente puede demostrar comportamientos exitosos, pero sus acciones siguen reflejando las herramientas disponibles y las políticas codificadas. Un docente que elige un atajo arriesgado puede propagar ese comportamiento al ajuste fino supervisado.

Esto plantea una cuestión de gobernanza. Las empresas deben saber quién define el comportamiento válido, qué políticas implementa el entorno y cómo se revisan los cambios en los verificadores. De lo contrario, la generación automatizada puede escalar un error de especificación inadvertido.

AutoSynthData: Generating Training Data for Enterprise Agents resulta más sólido como argumento a favor de los datos ejecutables. El generador recibe atención, pero el entorno y el verificador sostienen gran parte de la credibilidad del sistema. Sin ellos, las tareas sintéticas siguen siendo relatos convincentes en lugar de ejemplos de entrenamiento comprobados.

Las mejoras reportadas son significativas, pero siguen siendo limitadas

ServiceNow informa mejoras claras en los benchmarks, pero los experimentos no demuestran fiabilidad en producción ni transferencia amplia.

El primer experimento utilizó Gemma-4-26B-A4B-it como modelo objetivo en el dominio Hybrid de EnterpriseOps Gym. Qwen3.8-27B actuó como docente. AutoSynthData generó 2.000 ejemplos sintéticos de entrenamiento en aproximadamente 18 horas.

ServiceNow ajustó Gemma mediante ajuste fino supervisado, que entrena a un modelo para imitar ejemplos exitosos. El mejor checkpoint reportado correspondió a la quinta época. Una época representa una pasada completa por el conjunto de datos de entrenamiento.

El Pass@1 medio mejoró en 7,2 puntos porcentuales, según la empresa. ServiceNow caracteriza ese cambio como una mejora relativa del 35%. El éxito del verificador también aumentó del 63,01% al 68,55%.

La empresa afirma que el checkpoint resultante cerró el 59% de la brecha original de Pass@1 entre Gemma y su modelo de referencia. Estos resultados indican que los ejemplos sintéticos dirigidos influyeron en más de una medición. No revelan cómo se comportó el modelo fuera del entorno probado.

El segundo experimento se centró en la gestión de servicios de TI. Volvió a usar Gemma-4-26B-A4B-it como objetivo, mientras que DeepSeek-V4.1-Flash actuó como docente. El pipeline produjo 1.994 muestras aceptadas durante 66 horas.

El Pass@1 medio pasó del 18,77% al 27,18% en la evaluación ITSM. Esto supone un aumento de 8,41 puntos porcentuales. También deja al modelo entrenado fallando en la mayoría de los primeros intentos según el método de puntuación del benchmark.

Esa brecha restante es un contexto esencial. El experimento respalda la afirmación de que el ajuste fino sintético dirigido puede mejorar un modelo. No respalda que el agente resultante esté listo para operar de forma independiente en sistemas empresariales.

ServiceNow afirma que el generador Hybrid nunca recibió los prompts, entidades, trayectorias ni detalles del verificador de la evaluación original. Recibió especificaciones de capacidades destiladas del comportamiento de evaluación. Esta separación reduce una forma evidente de contaminación del conjunto de prueba.

Sin embargo, el currículo seguía procediendo de fallos observados dentro de EnterpriseOps Gym. Por tanto, el entrenamiento y la evaluación compartieron un entorno, una estructura de herramientas y una distribución general de tareas. La mejora dentro de ese entorno no demuestra transferencia a software no relacionado ni a configuraciones empresariales privadas.

Las cifras reportadas también proceden del equipo que diseñó el sistema. La replicación independiente reforzaría el resultado. Los investigadores necesitarían suficiente código, configuraciones de generación, muestras aceptadas y detalles de evaluación para reproducir el pipeline.

Artificial Analysis opera ahora una clasificación independiente basada en EnterpriseOps Gym. Su evaluación también pone énfasis en el trabajo con estado, de varios pasos, y en las condiciones finales de la base de datos. Ese entorno externo crea una posible vía para probar checkpoints entrenados de forma más independiente.

La evaluación entre entornos sería aún más informativa. Un modelo entrenado en una configuración ITSM podría probarse frente a políticas modificadas, herramientas renombradas, esquemas alterados y distribuciones de registros desconocidas. El rendimiento ante esos cambios mostraría si el modelo aprendió una capacidad o memorizó un patrón del entorno.

La seguridad también necesita una medición independiente. ServiceNow describió anteriormente 30 tareas de benchmark inviables que implicaban recursos no disponibles, permisos ausentes o infracciones de políticas. Según los informes, su modelo probado más potente reconoció solo alrededor de la mitad como inviables.

AutoSynthData podría centrarse en esos fallos, pero la versión actual no presenta un resultado específico de abstención segura. Mejorar la finalización de tareas puede crear nuevos riesgos si el modelo también se vuelve más dispuesto a actuar cuando lo correcto es negarse.

La relación entre docente y objetivo merece escrutinio. El experimento Hybrid utilizó una pareja de modelos de tamaño relativamente cercano, mientras que la ejecución ITSM utilizó un docente mucho mayor. La duración de la generación difirió sustancialmente, en parte porque ServiceNow afirma que la ejecución ITSM anterior precedió a las optimizaciones de rendimiento.

Estas diferencias dificultan las comparaciones directas. Los dos dominios involucraron docentes, tiempos de procesamiento y probablemente distribuciones de capacidades distintas. La evidencia muestra repetibilidad en dos configuraciones, no un estudio controlado de cada componente del sistema.

La ausencia de un estudio de ablación también limita la interpretación. Los resultados públicos no aíslan cuánto de la mejora provino de la orientación basada en fallos, las demostraciones del docente, el filtrado del verificador, la multiplicación de tareas o el equilibrio a nivel de lote. Cada componente parece plausible, pero sus contribuciones por separado siguen sin estar claras.

El coste y el uso de recursos son otra cuestión abierta, incluso sin asignar cifras comerciales. Generar miles de tareas exige llamadas repetidas al modelo, ejecución del entorno, pruebas del solucionador, crítica, reparación y verificación. El conjunto de datos aceptado representa únicamente la salida, no toda la carga de trabajo intentada.

Las empresas deben comparar esa carga de trabajo con las alternativas. Los ejemplos redactados por humanos pueden ser más lentos, pero más fáciles de revisar. Los cambios en recuperación y orquestación podrían corregir algunos fallos sin actualizar los pesos del modelo.

Un flujo de trabajo también puede fallar porque su conocimiento es incompleto, y no porque el modelo carezca de capacidad de razonamiento. Una mejor combinación de conocimiento puede abordar algunas brechas de forma más directa. El entrenamiento no debería convertirse en la respuesta predeterminada a cada ejecución fallida de un agente.

La lectura prudente sigue siendo alentadora. AutoSynthData produjo mejoras medibles a partir de tareas seleccionadas en torno a debilidades observadas. La afirmación más fuerte —que los currículos sintéticos adaptativos se generalizan en agentes de producción más seguros— sigue sin demostrarse.

Tres señales decidirán si AutoSynthData importa más allá del benchmark

La próxima evidencia debería demostrar reproducibilidad, transferencia y un comportamiento más seguro, no solo otra puntuación más alta dentro del entorno original.

La primera señal es una publicación reproducible de forma independiente. ServiceNow ha publicado materiales de EnterpriseOps Gym, pero los investigadores necesitan la implementación de AutoSynthData y la receta experimental completa. Ese paquete debería incluir la construcción de tarjetas de capacidades, configuraciones de generación, pruebas de verificadores, criterios de rechazo y evaluación de checkpoints.

Los equipos independientes deberían poder regenerar conjuntos de datos comparables a partir de los mismos fallos de diagnóstico. Mejoras similares en múltiples ejecuciones reducirían las preocupaciones sobre un muestreo favorable. Publicar estadísticas de tareas rechazadas también revelaría cuánto filtrado requirió el conjunto de datos final.

La versión más sólida de esta señal incluiría ablaciones. Los investigadores podrían eliminar la verificación negativa, el equilibrio por lotes, la multiplicación o la orientación basada en fallos, un componente cada vez. Las diferencias de rendimiento resultantes identificarían qué mecanismos producen la mejora.

Si la replicación independiente tiene éxito, reforzaría la principal afirmación técnica de ServiceNow. Si las ganancias varían drásticamente entre ejecuciones, el resultado sugeriría que el pipeline sigue siendo sensible a los generadores, los docentes o las decisiones de selección.

La segunda señal es la transferencia entre entornos. Un modelo entrenado debería enfrentarse a flujos de trabajo que preserven la capacidad subyacente mientras cambian herramientas, entidades, políticas y esquemas. Esa prueba distinguiría el aprendizaje general de la familiaridad con la estructura de EnterpriseOps Gym.

Un experimento útil podría entrenar en un entorno ITSM y evaluar en otro sin ajuste fino adicional. Otro podría pasar de un flujo de trabajo de un solo dominio a una tarea entre dominios que requiera datos de clientes, empleados y activos.

Las empresas también deberían prestar atención a los adaptadores más allá de los sistemas orientados a ServiceNow. La arquitectura de controlador-adaptador de AutoSynthData sugiere portabilidad, pero el diseño de software no garantiza la compatibilidad práctica. Cada nuevo entorno necesita acciones ejecutables y una verificación fiable.

Los resultados satisfactorios entre plataformas harían que el método fuera relevante para un mercado de agentes mucho más amplio. Una transferencia débil limitaría su función a una eficiente canalización de personalización para entornos estrechamente definidos.

La tercera señal es si la finalización de tareas mejora sin debilitar la negativa a actuar ni el cumplimiento de políticas. Un agente empresarial debe saber cuándo no actuar. Unas puntuaciones Pass@1 más altas son insuficientes si el entrenamiento fomenta una ejecución confiada ante permisos ausentes o instrucciones contradictorias.

Las evaluaciones futuras deberían informar sobre la detección de tareas inviables, cambios de estado no autorizados, infracciones de políticas y llamadas a herramientas innecesarias. También deberían inspeccionar las acciones intermedias, no solo los estados finales de la base de datos. Un estado final restaurado puede ocultar una secuencia insegura.

La revisión humana sigue siendo importante para los flujos de trabajo de alto impacto. Los revisores deberían examinar muestras que involucren registros de empleados, controles de acceso, derechos de clientes, incidentes de seguridad y cambios irreversibles. Los verificadores automatizados pueden respaldar ese proceso, pero no deberían definir políticas sin una supervisión responsable.

Por tanto, los próximos uno a tres meses deberían aportar tres formas concretas de evidencia: código de canalización ejecutable, pruebas entre entornos y resultados específicos de seguridad. Cada una abordaría una incertidumbre distinta de la publicación actual.

AutoSynthData: Generating Training Data for Enterprise Agents presenta un mecanismo creíble para convertir los fallos de evaluación en prácticas dirigidas. Las mejoras que informa muestran que la idea merece atención, especialmente para equipos que cuentan con entornos de flujos de trabajo ejecutables.

La decisión más importante ahora corresponde a quienes desarrollan IA empresarial. Deberían preguntarse si los fallos de sus propios agentes pueden expresarse como estados reproducibles, trayectorias válidas y resultados comprobables. De no ser así, generar más tareas solo ampliará la ambigüedad.

Si esas bases existen, un currículo adaptativo puede hacer que la evaluación sea mucho más útil. Puede mostrar qué falló, generar entrenamiento específico y medir si persiste la misma debilidad. La próxima prueba debe demostrar que este ciclo funciona fuera del entorno que lo creó.