Evals: el sistema operativo que separa el piloto de IA del sistema en producción

Evaluación de agentes de IA: de último filtro a sistema operativo

Un agente que resuelve una tarea aislada en una demo impecable no es garantía de nada. La pregunta que de verdad importa para una empresa no es si un modelo puede completar un paso bien definido, sino si puede sostener una cadena de decisiones —veinte, cincuenta, cien pasos— sin desviarse, sin alucinar un estado que no existe y sin propagar un error temprano hasta el final del flujo. Esa distancia entre "funciona en la demo" y "funciona en producción" fue uno de los temas centrales del Agentic AI Summit 2026, celebrado el 1 y 2 de agosto en UC Berkeley. Según la asistencia reportada por la organización y las 25 charlas que WATR documentó de primera mano, participaron organizaciones como Amazon, OpenAI, Google DeepMind, NVIDIA, Databricks, Microsoft y el propio MIT.

La tesis que emergió de forma consistente entre esas charlas es incómoda para cualquier equipo que trate la evaluación como un trámite de control de calidad al final del ciclo de desarrollo: la evaluación de agentes de IA no es el último chequeo antes de lanzar. Es el sistema operativo sobre el que corre todo lo demás. Determina qué se construye, qué se corrige y qué se descarta —no después del hecho, sino durante todo el ciclo de vida del agente.

De 88-97% a 44-73%: lo que revela encadenar veinte pasos

El dato más citado del summit vino acompañado de una gráfica comparativa que vale más que cualquier discurso sobre capacidades de modelos. Al evaluar 19 modelos de frontera en subtareas de un solo paso ("solo subtasks"), 18 de ellos puntúan entre 88% y 97%. Prácticamente empatados. Cualquiera de esos modelos, visto de forma aislada, parece capaz de ejecutar trabajo real.

Pero cuando esas mismas capacidades se evalúan encadenadas en secuencias de 20 pasos, el rango se desploma a 44%-73%. Las tareas individuales no se volvieron más difíciles: lo que se volvió difícil fue sostener la dependencia entre un paso y el siguiente. Un error de 3% en el paso uno, compuesto veinte veces, no es un error de 3%. Es la diferencia entre un agente confiable y uno que hay que supervisar paso a paso —lo cual anula buena parte del valor de automatizar en primer lugar.

Esta es la brecha que los benchmarks de un solo paso, por diseño, no pueden ver. Miden la competencia atómica de un modelo, no su capacidad de actuar como sistema.

Benchmarks saturados frente a la brecha real

El segundo dato refuerza el primero desde otro ángulo. En benchmarks ya saturados como HumanEval, los modelos rinden de forma casi indistinguible entre sí, alrededor de 95%-97%. Todos aprueban. Todos parecen igual de capaces. El benchmark, en la práctica, dejó de discriminar.

El contraste aparece en evaluaciones diseñadas para simular trabajo real y exigente, no ejercicios de práctica. En Senior SWE-Bench —pensado para replicar el tipo de tarea que resolvería un ingeniero de software senior, no un ejercicio de examen— el rendimiento cae a apenas 30%-35%, y la diferencia entre los modelos "de menor puntaje" y "de mayor puntaje" se reduce a casi nada. Ahí, y no en HumanEval, es donde se revela la verdadera capacidad de un modelo para operar en un flujo de trabajo completo.

Replit lo resumió en el summit con una frase que funciona como declaración de principios para cualquier equipo que construya agentes:

"La evaluación deja de ser el último chequeo antes de lanzar. Se convierte en el motor que envía mejores agentes." — Replit, Agentic AI Summit 2026

Esa distinción es exactamente lo que separa a un equipo que evalúa como control de calidad de uno que evalúa como arquitectura: en el primer caso, la evaluación certifica el producto al final. En el segundo, la evaluación es la señal que decide qué versión del agente avanza, qué prompt se descarta, qué herramienta se retira del set y qué patrón de fallo se corrige antes de que llegue a producción.

La lectura correcta del 95% de fracaso en pilotos corporativos

El dato del MIT sobre el fracaso de los pilotos de IA generativa en el entorno corporativo —95% no logra generar valor medible— ya es ampliamente conocido. Lo que el summit aportó no fue el dato, sino una lente distinta para interpretarlo: ese fracaso masivo es exactamente lo que predice la brecha entre benchmarks saturados y evaluaciones realistas.

Un equipo que valida su agente contra un benchmark estándar —o, peor, contra una demo interna con datos curados a mano— está midiendo lo mismo que HumanEval: una competencia que ya no distingue nada, porque todos los modelos la superan con holgura. La pregunta de negocio nunca fue si el modelo puede resolver una tarea de práctica. Fue siempre si puede sostener un flujo de trabajo de principio a fin, con las dependencias, las excepciones y los datos ruidosos de un proceso real. Esa es precisamente la pregunta que Senior SWE-Bench, las cadenas de 20 pasos y las evaluaciones de trayectoria están diseñadas para responder —y que la mayoría de los pilotos corporativos nunca se hizo antes de comprometer presupuesto y reputación interna al proyecto.

Qué debe exigir una empresa antes de delegar un flujo completo

La capa de evaluación que se consolidó en el summit —con herramientas y enfoques como ViBench, Senior SWE-Bench y las evaluaciones de trayectoria ("trajectory evals")— apunta a un cambio de pregunta. En lugar de "¿el resultado final fue correcto?", la pregunta relevante es "¿el camino que tomó el agente para llegar ahí fue razonable, auditable y repetible?". Un agente puede llegar a la respuesta correcta por el motivo equivocado, con una herramienta mal invocada o un supuesto erróneo que esta vez no rompió nada, pero que romperá algo la próxima vez, con datos distintos.

Para una empresa que evalúa si un agente está listo para operar sin supervisión constante, esto tiene implicaciones directas sobre qué exigir antes de aprobar el paso de piloto a producción:

• Que la evaluación cubra cadenas de pasos representativas del proceso real, no tareas aisladas de un solo paso.
• Que exista trazabilidad de la trayectoria completa del agente, no solo del resultado final —para poder diagnosticar por qué falla, no solo que falló.
• Que los benchmarks usados para decidir no estén saturados: si todos los modelos candidatos puntúan igual de alto, el benchmark ya no informa la decisión.
• Que el criterio de éxito se defina en términos del caso de negocio específico, no de una métrica genérica reportada por el proveedor del modelo.

Recomendaciones: construir la evaluación como sistema operativo

Tratar la evaluación como infraestructura, no como checklist final, exige decisiones concretas de arquitectura e ingeniería:

• Diseñar evals de trayectoria propias, alineadas al proceso de negocio real —no adoptar un benchmark público sin verificar primero si sigue discriminando entre las opciones que la empresa realmente está evaluando.
• Medir el rendimiento en cadenas largas, no en pasos aislados. Si el flujo de producción encadena diez o veinte decisiones, la evaluación debe encadenar diez o veinte decisiones. Cualquier cosa menos es una métrica de vanidad.
• Instrumentar la evaluación como parte del pipeline continuo, no como una fase previa al lanzamiento. Cada cambio de prompt, herramienta o modelo base debería correr contra el mismo conjunto de evals antes de tocar producción.
• Exigir trazabilidad completa del camino que toma el agente, no solo del resultado, para poder diagnosticar fallos sin necesidad de reproducir el incidente desde cero.
• Descartar benchmarks saturados como criterio de decisión entre modelos o proveedores, y priorizar evaluaciones donde todavía exista dispersión real de resultados —ahí es donde vive la información útil.

El mensaje del summit, condensado, es que la brecha entre lo que un agente parece poder hacer y lo que puede hacer de forma confiable en producción no se cierra con un modelo mejor. Se cierra con una capa de evaluación que funcione como sistema nervioso del desarrollo, no como su certificado de defunción o aprobación final.