En los comités de dirección con los que trabajamos, la conversación sobre agentes suele arrancar con una cifra leída en un titular: un modelo resuelve tal porcentaje de las tareas de un banco de pruebas de ingeniería o de asistencia. La pregunta que llega después es siempre parecida. Si el modelo acierta en tres de cada cuatro casos, ¿por qué el piloto interno lleva cinco meses sin salir del entorno de pruebas?
La respuesta rara vez está en la calidad del modelo. Está en la diferencia entre lo que mide un benchmark y lo que exige un proceso de negocio real.
Qué mide realmente un benchmark agéntico
Conviene entender el diseño de las tres referencias que más se citan en las presentaciones de proveedores.
- SWE-bench Verified trabaja sobre incidencias reales de repositorios públicos de Python, con un conjunto de tareas revisado por personas para asegurar que son resolubles y que las pruebas asociadas discriminan bien. El entorno está congelado: el código, las dependencias y el criterio de éxito no cambian mientras el agente trabaja.
- τ-bench simula conversaciones de atención al cliente en dominios acotados, con un catálogo de herramientas definido y una política escrita que el agente debe respetar. Su aportación más útil no es la tasa de acierto, sino la métrica de consistencia: repetir la misma tarea varias veces y contar cuántas veces sale bien todas las veces. Esa cifra cae con rapidez conforme aumentan los intentos.
- GAIA plantea preguntas de asistente general organizadas por niveles de dificultad, diseñadas expresamente para que una persona con navegador las resuelva sin gran esfuerzo y un sistema automático tropiece.
Los tres comparten una característica que casi nunca se traslada a la empresa: el conjunto de herramientas disponibles está documentado, es estable y está pensado para la tarea. En un proceso interno, esa condición no se cumple prácticamente nunca.
La aritmética de las cadenas largas
El primer factor de degradación no tiene nada que ver con la IA. Es multiplicación.
Un agente que ejecuta un proceso de diez pasos encadenados, y que acierta el 95% de las veces en cada paso, completa el proceso entero sin intervención humana en el 59,9% de los casos (0,95 elevado a 10). Con cinco pasos, la cifra sube al 77,4%. Con el 99% por paso, esos diez pasos dan un 90,4%. Nada de esto es una crítica al modelo: es lo que ocurre cuando se encadenan sucesos independientes.
La consecuencia práctica es que la tasa por paso, que es la que suelen enseñar los proveedores en la prueba de concepto, no informa del resultado del proceso. Y en cuanto un error temprano contamina el contexto de los pasos siguientes, la independencia deja de cumplirse y el resultado empeora todavía más, porque el agente sigue razonando sobre una premisa equivocada durante el resto de la cadena.
Tres razones por las que el número baja al salir del laboratorio
Herramientas internas mal documentadas
En los benchmarks, cada función expuesta al agente tiene una descripción precisa de qué hace, qué parámetros admite y qué devuelve. En un ERP con quince años encima, la mitad de los campos tiene un nombre heredado que no significa lo que parece, hay tres maneras de dar de alta el mismo tipo de registro y la documentación fiable vive en la cabeza de dos personas. Un agente no puede inferir esa semántica; elige la opción que mejor encaja con el nombre del campo, que suele ser la equivocada.
Ausencia de estado
Los procesos de empresa son largos, se interrumpen y se retoman. Una reclamación puede quedar bloqueada tres días esperando a un tercero. La mayoría de las implantaciones que revisamos guardan ese estado en el historial de la conversación, lo que significa que se pierde, se trunca o se degrada. Sin un almacén de estado explícito, externo al modelo, y sin idempotencia en las operaciones que escriben, un reintento genera un duplicado en lugar de continuar donde se quedó.
El entorno no está congelado
Los precios cambian, se añaden campos obligatorios, un proveedor modifica su interfaz. El agente que funcionaba en marzo empieza a fallar en junio sin que nadie haya tocado nada del agente. Los bancos de pruebas, por definición, no capturan esta clase de deriva.
Qué procesos son candidatos honestos hoy
Nuestro criterio de selección se apoya en tres condiciones que deben darse a la vez.
- Volumen alto. Suficientes ejecuciones al mes para que el ahorro compense el coste de construir el andamiaje y para que se pueda medir la tasa de acierto con muestras que signifiquen algo.
- Reversible. Un error debe poder deshacerse sin coste material ni daño reputacional. Redactar un borrador es reversible; emitir un abono contra la cuenta de un cliente no lo es.
- Verificable de forma barata. Tiene que existir una comprobación automática, o una revisión humana de segundos, que distinga un resultado bueno de uno malo sin rehacer el trabajo.
Encajan bien la clasificación y el enrutado de correo entrante, la extracción estructurada de datos de documentos con validación posterior contra un maestro, la preparación de borradores de respuesta que revisa un agente humano, la conciliación de discrepancias entre dos sistemas señalando candidatos, y las tareas de mantenimiento de código con una batería de pruebas que dictamine el resultado.
No encajan hoy los procesos que mueven dinero sin punto de control, los que exigen criterio con información fuera de sistema, los que tienen un volumen de una decena de casos al mes y aquellos en los que un fallo tarda semanas en detectarse. Tampoco los que atraviesan seis aplicaciones distintas, ninguna de ellas con una interfaz programática decente.
Recomendación
Antes de aprobar un despliegue, pida dos cifras que ningún benchmark público le va a dar: la tasa de acierto del proceso completo, de extremo a extremo, medida sobre casos históricos reales de su empresa; y la misma tarea repetida cinco veces, contando cuántas salen bien las cinco. La segunda cifra es la que determina si puede quitar la supervisión humana o si lo que va a construir es un asistente con un revisor detrás, que también tiene su valor, pero cuyo retorno se calcula de otra manera.