Garrett Lord refundó Handshake como empresa de evals después de pasar meses hablando con cientos de ejecutivos. El diagnóstico que encontró en casi todas las conversaciones era el mismo: el programa de IA está atascado en el piloto, el equipo lleva semanas o meses sin poder escalar a producción, y nadie tiene claro por qué.

La razón que encontró, refrendada esta semana por Aaron Levie en Box: las empresas no tienen definido qué es un output de calidad para sus propios procesos. Y sin eso, no hay forma de saber si el agente está mejorando, si está peor que el proceso manual que reemplazó, o si sus errores son sistemáticos.

Aaron Levie lo dijo sin rodeos: “casi todo el progreso en agentes depende de los evals”. Los avances en modelos, en arquitecturas de agentes, en capacidades de herramientas: todo eso mide contra evals. Y las empresas que ganen en IA no serán las que tengan acceso al mejor modelo. Serán las que tengan los mejores evals para sus propios flujos de trabajo.

Por qué los programas de IA se atascan

El mecanismo de atasco que Lord describe es uno que reconozco de haber conversado con equipos que llevan tiempo intentando escalar IA. No es falta de tecnología. No falta acceso a buenos modelos; falta que la empresa pueda articular qué se ve bien.

Un piloto de IA que “funciona” sin criterio de evaluación definido es un piloto donde alguien miró el output y dijo “parece bueno”. Eso funciona para la demo. No funciona para escalar. En producción, los casos borde aparecen, los errores se acumulan, y si no tienes un criterio explícito que diga qué es aceptable y qué no, el equipo no puede ni siquiera ponerse de acuerdo en si hay un problema o no.

Lo que Lord llama evals efectivos no es una revisión de pulgar arriba o pulgar abajo ni una encuesta a los usuarios. Es un sistema de criterios que captura los matices de juicio, tono y criterio de negocio que importan en cada proceso, y los convierte en algo evaluable de forma consistente. Verificación determinista para lo objetivo: ¿el output cumple con el alcance?, ¿los datos son correctos?, ¿el formato es el que corresponde? Criterio de LLM como juez para lo subjetivo: ¿el tono es apropiado para el cliente?, ¿la recomendación es relevante para el contexto específico?

El error de confundir benchmarks con evals de negocio

Hay una trampa en la que cae casi todo equipo técnico al evaluar modelos: usar benchmarks externos como sustituto de evals de negocio. MMLU, GPQA, HumanEval, los que sean. Los benchmarks son útiles para comparar capacidades generales de modelos. Son un sustituto pobre para saber si el agente está ejecutando bien en tu proceso de ventas o en tu proceso de atención al cliente.

Un modelo puede puntuar alto en todos los benchmarks externos y entregar mal en tu proceso específico, porque lo que importa en tu proceso es el criterio particular de tu empresa, no la capacidad general del modelo. Como argumenté en la IA como activo compuesto y los evals: el eval que importa es el tuyo, no el del proveedor.

Y aquí está la parte que Levie señala con más fuerza: los evals como propiedad intelectual. Una empresa que ha construido un sistema de evals sólido para sus procesos tiene algo que ningún proveedor puede darle: el criterio de éxito codificado para su negocio específico. Ese criterio es portable. Funciona con cualquier modelo. Escala con el agente. Y se compone con el tiempo a medida que los estándares se refinan.

El prerequisito que nadie menciona

Hay un paso antes de los evals que casi todo el debate omite: necesitas saber qué quieres evaluar antes de poder evaluarlo.

Suena obvio. En la práctica, la mayoría de las empresas no puede articular sus propios criterios de calidad hasta que alguien les hace las preguntas correctas. ¿Qué hace que una respuesta de atención al cliente sea excelente versus apenas aceptable en tu empresa? ¿Qué señales indican que un lead debería pasar a ventas hoy versus la próxima semana? ¿Qué criterios usa tu equipo de operaciones para decidir escalar un problema?

Esas respuestas viven en las personas más experimentadas del equipo. Raramente están escritas. Y hasta que estén escritas, no pueden convertirse en evals.

Eso es exactamente el trabajo que hacemos en la primera fase de AI Maestro: mapear los procesos reales, articular los criterios de calidad que el equipo usa implícitamente, y convertirlos en el Score de Oportunidad que prioriza dónde construir primero. Ese Score es un pre-eval: define en qué procesos el criterio de éxito está suficientemente articulado para que un eval tenga sentido, y en cuáles el trabajo de articulación todavía falta.

Sin ese diagnóstico previo, los evals que construyes miden el proceso tal como está descrito en papel, que rara vez coincide con el proceso tal como ocurre en la realidad.

Articulemos el criterio de éxito de tu operación