AutoSynthData: cómo generar datos de entrenamiento para agentes empresariales

El reto: agentes que funcionen en su propio entorno

Los modelos grandes pueden ser competentes en términos generales pero fallar frente a escenarios empresariales concretos: un flujo de trabajo que no comprenden bien, una combinación de herramientas que usan incorrectamente o restricciones de política que no respetan. Para las organizaciones esto no es solo una curiosidad técnica: son fallas que afectan procesos, cumplimiento y productividad.

El problema clave no es solo detectar esas debilidades, sino convertirlas en datos de entrenamiento útiles. Un incidente puntual aporta información, pero el aprendizaje exige muchas tareas nuevas que ejerciten la misma habilidad en contextos diversos, que sean posibles dentro del entorno, realistas desde la perspectiva del usuario y verificables de forma automática.

Qué es AutoSynthData y cómo aborda el problema

AutoSynthData es una metodología y pipeline diseñada para convertir brechas de capacidad de un modelo en ejemplos de entrenamiento prácticos. Parte de las ejecuciones del modelo objetivo en el entorno empresarial, identifica patrones de fallo y usa un “teacher” más capaz para caracterizar soluciones correctas. A partir de allí genera tareas nuevas, las valida en el entorno y selecciona las que pasan verificación para el entrenamiento posterior. El sistema adapta el currículum a medida que el modelo mejora, concentrándose en las dificultades remanentes.

En el trabajo de referencia se ilustra el enfoque con EnterpriseOps Gym (Malay et al., 2026) y su dataset liberado, lo que sirve como caso de estudio para entornos de operaciones empresariales.

La abstracción de una tarea agente-centrada

Para generar ejemplos útiles, AutoSynthData define una tarea como la combinación: (especificación del sistema, prompt del usuario, verificador). Esta estructura garantiza que las tareas estén enraizadas en el entorno y tengan un criterio claro de éxito.

• Especificación del sistema: describe las reglas y restricciones bajo las que opera el agente: instrucciones del sistema, políticas, y cuando sea necesario, el estado inicial específico (por ejemplo, una base de datos con ciertos registros o un conjunto de artículos de conocimiento). Debe ser compatible con las herramientas y acciones soportadas por el entorno y evitar limitaciones artificiales destinadas solo a aumentar la dificultad.

• Prompt del usuario (tarea dirigida al agente): especifica qué se espera que haga el agente y cualquier restricción a nivel de usuario. Las tareas generadas deben cumplir tres propiedades:

  • Viabilidad: debe existir al menos una trayectoria posible en el entorno que permita completar la tarea respetando la especificación del sistema. Esto descarta tareas que requieren herramientas inexistentes o cambios de estado imposibles.
  • Realismo: la solicitud debe parecer algo que un usuario realmente pediría en ese entorno. El universo de acciones ejecutables suele ser mucho mayor que las solicitudes realistas; la generación debe privilegiar estas últimas.
  • Dificultad: la tarea debe exponer una debilidad del modelo objetivo. Las tareas ya resueltas sistemáticamente aportan poco al entrenamiento.

• Verificador: determina si la trayectoria ejecutada cumple la tarea. Un buen verificador debe ser consistente (con las instrucciones y el estado), sound (rechazar soluciones incorrectas o violaciones de políticas) y completo (aceptar soluciones válidas aunque no sigan una única trayectoria de referencia). Un verificador laxo puede premiar comportamiento erróneo; uno demasiado estricto puede castigar soluciones válidas.

De las fallas a una currícula eficaz

El motor de AutoSynthData comienza con ejecuciones de evaluación del modelo objetivo en un conjunto diagnóstico. Paralelamente, un teacher más capaz también realiza esas tareas. Comparando ambos resultados, el sistema identifica: la capacidad concreta que se evalúa, las herramientas y la estructura del flujo de trabajo involucradas, dónde falla el modelo objetivo y cómo lo resuelve el teacher, las propiedades del estado final correcto y las dimensiones que se pueden variar sin perder la esencia de la capacidad.

Estas observaciones se condensan en “cartas de especificación de capacidad” (capability specification cards), que describen qué hay que enseñar sin revelar prompts, entidades o rutas exactas usadas en la evaluación. Las cartas guían al generador para crear nuevas tareas que mantengan el foco en la habilidad identificada pero cambien detalles como redacción, entidades y condiciones iniciales.

Generación, validación y escalado de tareas

Saber qué enseñar no es suficiente: el entrenamiento requiere muchos ejemplos variados que ejerciten la misma habilidad. El generador toma la carta de especificación y crea una colección de tareas que varían en entidades, estado inicial, combinación de herramientas, composición del flujo y nivel de dificultad. A continuación, el teacher demuestra soluciones exitosas en esas tareas, lo que ayuda a especificar patrones de comportamiento correctos.

Cada tarea generada se ejecuta en el entorno real o simulado y se verifica mediante los verificadores definidos. Solo las muestras que pasan las comprobaciones automáticas se aceptan para el conjunto de entrenamiento. Tras el reentrenamiento del modelo, se evalúa nuevamente para identificar las brechas restantes y cerrar el ciclo.

Beneficios para organizaciones (incluyendo contextos latinoamericanos)

El enfoque tiene ventajas prácticas para empresas que requieren agentes adaptados a sus procesos:

• Entrenamiento dirigido: en lugar de depender sólo de datos generales, se concentra en las debilidades reales del modelo en el entorno productivo.
• Realismo y factibilidad: las tareas son ejecutables y representativas de solicitudes de usuarios, lo que aumenta la relevancia operativa del aprendizaje.
• Verificación automática: reduce la necesidad de etiquetado humano extensivo al aceptar solo las muestras que cumplen criterios claros.
• Iteración continua: a medida que el modelo mejora, la currícula se ajusta hacia problemas más difíciles.

Para organizaciones en América Latina, donde la heterogeneidad de sistemas y la necesidad de cumplir regulaciones locales pueden complicar la adopción de agentes genéricos, un pipeline como AutoSynthData facilita crear agentes que respeten políticas internas, integren herramientas específicas y funcionen con datos y workflows propios.

Limitaciones y consideraciones prácticas

AutoSynthData depende de contar con un teacher suficientemente capaz para caracterizar soluciones correctas y de entornos donde la ejecución y verificación automáticas sean posibles. Además, la calidad de las cartas de especificación y de los verificadores determina en gran medida la utilidad de los ejemplos generados. Un verificador mal diseñado puede introducir ruido en el entrenamiento.

Conclusión

Generar datos de entrenamiento útiles para agentes empresariales exige más que sintetizar prompts: requiere comprender las fallas del modelo en un entorno concreto, describir qué enseñar en términos precisos, crear variedad de tareas realistas y verificables, y cerrar el ciclo con reentrenamiento y reevaluación. AutoSynthData ofrece un flujo práctico para hacer justamente eso, transformando errores en un currículum adaptativo que prioriza las brechas más relevantes. El caso de EnterpriseOps Gym muestra cómo la metodología puede aplicarse y escalarse usando datasets liberados como punto de referencia.

Para equipos de producto y responsables de IA en empresas, el enfoque invita a pensar en el ciclo de mejora no solo como ajuste de modelos sino como diseño de tareas y verificadores alineados con sus procesos y políticas internas.