AI agent evaluation: qué métricas importan

La evaluación de agentes de IA mide si un agente de IA resuelve de forma fiable la tarea prevista. Las métricas clave son la tasa de éxito de tareas, la corrección de la trayectoria y de las llamadas a herramientas, la fundamentación (groundedness) o tasa de alucinaciones, la latencia, el coste y la tasa de escalado HITL. Se mide offline, contra un dataset de evaluación, y online, en producción. La evaluación es la disciplina que decide si un agente puede salir del laboratorio y, con el Reglamento de IA de la UE, la ISO/IEC 42001 y las expectativas de BaFin y FINMA sobre el riesgo de los modelos, ha pasado de ser una práctica de investigación a un artefacto de cumplimiento.

Lo más importante, de entrada: una sola métrica en un leaderboard ya no demuestra que un agente funcione. El equipo de Princeton que está detrás del Holistic Agent Leaderboard (HAL) muestra que 18 meses de avances en capacidad solo trajeron pequeñas mejoras en fiabilidad, mientras la precisión pura no dejaba de subir. Si quieres operar agentes en producción y cumpliendo la normativa, necesitas un conjunto de métricas multidimensional.

Respuestas rápidas:

• La tasa de éxito de tareas es el indicador individual más importante, pero nunca basta: la calidad, la corrección en el uso de herramientas, el coste y la fiabilidad también cuentan.
• Las evaluaciones offline (dataset fijo, LLM-as-Judge) aportan pruebas antes del despliegue; la monitorización online detecta la deriva y los errores reales. Ambas son necesarias.
• Los benchmarks de agentes demuestran capacidad, no idoneidad para tu caso de uso: la prueba es un dataset de evaluación propio en tu idioma.

Las seis familias de métricas para agentes de IA

Un programa de evaluación completo genera en cada versión al menos una cifra de cada categoría relevante y representa el triángulo de tensión entre coste, calidad y seguridad en una frontera de Pareto, en lugar de reducirlo a una sola puntuación.

Dos puntos merecen destacarse. Primero, la tasa de escalado no es una señal puramente negativa: un escalado a una persona bien ajustado es una funcionalidad, no un defecto; lo decisivo es que el agente derive los casos adecuados. Segundo, la fiabilidad suele importar más que la precisión. Un agente que acierta en el 90 % de los casos pero falla de forma impredecible en el 10 % restante suele ser peor en producción que uno con un 80 % de éxito y un comportamiento ante errores previsible y recuperable. El τ-bench de Sierra muestra que pass^k (las k ejecuciones con éxito) cae claramente en muchos modelos hasta k=8: el mismo agente, la misma tarea y resultados materialmente distintos de una ejecución a otra. Quien solo informa de una ejecución con una única semilla oculta esa varianza. Estándar mínimo: media más error estándar en 3-5 ejecuciones.

Evaluación offline frente a monitorización online

La dicotomía fundamental de la disciplina es offline frente a online, y los programas maduros usan ambos lados.

La evaluación offline se ejecuta por lotes contra un dataset fijo y versionado. Es determinista, repetible y aporta las pruebas previas que el art. 15 del Reglamento de IA de la UE exige para los sistemas de alto riesgo: la precisión debe medirse y declararse, no afirmarse como aspiración. Las evaluaciones offline son el lugar para LLM-as-Judge frente a respuestas de referencia y para recorrer de forma sistemática los casos límite conocidos.

La evaluación online valora el tráfico real de producción. Es el puente entre «lo hemos desplegado» y «podemos demostrar que el sistema sigue funcionando dentro de las tolerancias». En los sistemas de IA de alto riesgo, el art. 72 del Reglamento de IA de la UE exige al proveedor precisamente esta vigilancia continua tras la introducción en el mercado (vigilancia poscomercialización). Patrones de despliegue probados:

• Shadow mode: el nuevo sistema funciona en paralelo con las mismas entradas, pero sus salidas no se entregan, sino que se registran y se comparan. Es el estándar de facto antes de cualquier despliegue de alto riesgo.
• Canary deployment: un 1-5 % del tráfico va al nuevo sistema y el resto del despliegue depende de métricas en tiempo real. Importante: las métricas de los gates deben incluir puntuaciones de evaluación, no solo latencia y tasa de errores.
• Eval gates: umbrales automáticos que detienen el despliegue (p. ej., «detener la promoción si la faithfulness cae por debajo de 0,85 en una ventana de 4 horas»).

Como pasar cada traza por jueces LLM resulta prohibitivamente caro, se trabaja con muestreo. Una configuración inicial razonable para pymes: un 1-5 % de muestreo aleatorio estratificado más un 100 % de muestreo basado en anomalías (sesiones largas, muchos reintentos, feedback negativo explícito). Las heurísticas baratas (comprobación de PII, validación de formato, detección de rechazos) se ejecutan de forma síncrona e inline; las evaluaciones caras con jueces, de forma asíncrona sobre la muestra. Esta división síncrono/asíncrono es la palanca de costes más importante: sin ella, el gasto en evaluación puede llegar a ser de 2 a 5 veces el coste de la inferencia.

Además, la evaluación online debería anclarse en el comportamiento real de los usuarios, no solo en las puntuaciones de los jueces: la tasa de copiar y pegar, las ediciones después de pegar, la tasa de reintentos y la tasa de abandono son señales de ground truth lentas pero fiables. En la región DACH (Alemania, Austria y Suiza), la tasa de clics en el pulgar arriba/abajo es culturalmente más baja que en EE. UU., lo que reduce el valor informativo de las señales de feedback explícito.

LLM-as-Judge: útil, pero no funciona solo

La referencia canónica (Zheng et al., 2023) muestra que los modelos juez potentes alcanzan más de un 80 % de coincidencia con valoraciones humanas controladas, el mismo nivel que la coincidencia entre personas. Pero eso vale para tareas basadas en opiniones; en contenidos en tu idioma donde la exactitud de los hechos es crítica (derecho, medicina, finanzas), la referencia humana sigue siendo el estándar.

Pautas sacadas de la práctica:

• Binario en lugar de Likert. Un pass/fail con una crítica redactada funciona mejor que las escalas de 1-5, porque la frontera entre el 3 y el 4 es inestable entre jueces y entre ejecuciones.
• Mitigar los sesgos conocidos. El sesgo de posición, intercambiando el orden y promediando ambos resultados; el sesgo de verbosidad, con control de longitud; el sesgo de autopreferencia, con jueces de otra familia de modelos o con un ensemble de jueces.
• Calibrar. Informar de la coincidencia entre juez y humanos como kappa de Cohen o alfa de Krippendorff antes de confiar en un juez en producción.
• Limitar los costes. Regla general: presupuestar un 10-30 % del coste de inferencia para la evaluación; con jueces de razonamiento puede superar el 50 %. Patrón: jueces de razonamiento para el conjunto de validación y jueces especializados baratos (por ejemplo, modelos del tipo MiniCheck) para el muestreo en producción.

Lo decisivo: LLM-as-Judge no sustituye al análisis de errores. El consenso entre profesionales es que el 60-80 % del esfuerzo de evaluación debería seguir dedicándose a mirar datos, encontrar modos de fallo y traducirlos en asserts de pass/fail.

Cómo crear el dataset de evaluación y el bucle de evaluación

Un golden set sólido tiene una procedencia documentada, una rúbrica de etiquetado, acuerdo entre anotadores y una cobertura explícita de los casos de uso reales. Receta práctica:

1. Muestrear 200-500 trazas reales de usuarios; enmascarar la PII conforme al art. 32 del RGPD.
2. Dos expertos en la materia etiquetan cada traza con resultado y crítica; calcular el kappa de Cohen y resolver los conflictos.
3. Añadir 50-100 casos límite adversariales escritos por expertos en los límites de las políticas.
4. Incorporar 100-200 casos sintéticos según dimensiones documentadas (funcionalidades × escenarios × personas).
5. Separar un 30 % como conjunto de prueba congelado que nunca se usa para el ajuste; el 70 % restante, para iterar.
6. Versionar, documentar la dataset card y actualizarlo cada trimestre.

Para un piloto en una pyme, un golden set de 500 ítems requiere al principio unas 3-6 semanas de tiempo de expertos y después alrededor de una semana por trimestre. Es la palanca más potente de todo el programa de evaluación.

El bucle de evaluación continua une ambos mundos: consulta del usuario → ejecución del agente → emisión de spans de traza (OpenTelemetry) → capa de muestreo → capa de evaluación (jueces LLM más heurísticas más jueces basados en modelos pequeños) → almacén de evaluaciones → dashboard → alerta al superarse un umbral → retroalimentación al golden set. Los programas maduros lo convierten en un gate de CI/CD: cada pull request que cambia el prompt, la elección de modelo, la configuración del retrieval o la definición de herramientas lanza la suite de evaluación; el merge falla si la tasa de aprobación cae por debajo del umbral. También un cambio de versión del modelo por parte del proveedor debería activar una reevaluación automática antes de que el nuevo modelo entre en el enrutamiento de producción. Un golden set congelado debería reevaluarse contra el sistema en vivo al menos una vez por semana, y a diario en agentes críticos para la producción, para distinguir la regresión del modelo o del prompt de la simple deriva del entorno.

Para una residencia de datos conforme al RGPD son adecuadas herramientas autoalojables como Langfuse, fundada en Alemania (self-hosting con ClickHouse y Postgres), o Arize Phoenix, nativa de OTel; RAGAS es la biblioteca de facto para métricas de RAG (Faithfulness, Context Precision, Answer Relevancy), y DeepEval e Inspect AI cubren evaluaciones cercanas al CI/CD y relevantes para la seguridad. (Datos de 2026; el mercado de herramientas de evaluación se está consolidando ahora mismo mediante operaciones de M&A como Cisco/Galileo.)

Diferencias con los benchmarks de modelos

Un error de razonamiento frecuente y caro es confundir las puntuaciones de benchmarks con una prueba de idoneidad. Una evaluación de model card es el artefacto de marketing o de investigación del proveedor del modelo: una instantánea de su capacidad en benchmarks públicos. Una evaluación de cumplimiento es el artefacto regulatorio de la empresa que desarrolla o despliega el agente: medición previa y continua frente al caso de uso real, el dataset y el perfil de riesgo, con metodología documentada, scorers versionados y pista de auditoría. Son artefactos distintos con destinatarios distintos, y la mayoría de los reguladores no aceptan una model card como sustituto.

Tres razones por las que las puntuaciones de benchmarks solo aportan contexto:

• Contaminación. Cualquier benchmark cuyo dataset fuera público antes de 2024 está presumiblemente en los datos de entrenamiento. Ejemplo: según Anthropic, Claude Opus 4.5 alcanza un 80,9 % en SWE-bench Verified, un subconjunto seleccionado en 2024 del SWE-bench publicado en 2023. En cambio, en SWE-bench Pro, más resistente a la contaminación, se queda en un 45,9 % en el leaderboard público de Scale AI (datos de octubre de 2026). La diferencia no se debe solo a la contaminación: SWE-bench Pro también está diseñado para ser más difícil (las soluciones de referencia modifican de media 107 líneas de código en 4,1 archivos), y ambos valores proceden de configuraciones de medición distintas (dato del fabricante frente a leaderboard). Aun así, muestra hasta qué punto las puntuaciones dependen del diseño del benchmark y de una posible contaminación.
• Dependencia del scaffold. Ser «líder del leaderboard de GAIA» no significa nada si no se indica el scaffold: entre las puntuaciones con scaffold (Princeton HAL con Claude Sonnet 4.5: 74,6 %) y las puntuaciones bare hay unos 30 puntos porcentuales.
• Reward hacking. Un trabajo del UC Berkeley RDI (abril de 2026) mostró que un agente de escaneo automatizado podía hackear los ocho grandes benchmarks de agentes hasta obtener puntuaciones casi perfectas sin resolver ninguna tarea.

La posición defendible para un dossier de cumplimiento: citar varios benchmarks de distintas familias, informar de costes y varianza, complementarlos con golden sets privados del cliente y reconocer sus límites por escrito. Los benchmarks de agentes en inglés (SWE-bench, GAIA, τ-bench, BFCL, OSWorld) sirven para establecer una línea base de capacidad; la prueba real sigue siendo el dataset de evaluación en tu idioma, idealmente mapeado a los catálogos de criterios de la BSI.

Para agencias y decisores B2B

Si planificas u operas agentes de IA para clientes en Europa, conviene que entiendas la evaluación no como una prueba posterior, sino como una disciplina continua: un golden set en el idioma de tus clientes como base, gates offline antes de la puesta en producción, monitorización online con detección de deriva después y un conjunto de métricas que se tome la fiabilidad y el coste tan en serio como la tasa de éxito a secas. En los sistemas de IA de alto riesgo, esta base de evaluación es también un fundamento para la vigilancia poscomercialización. Sin embargo, el art. 15 y el art. 72 del Reglamento de IA de la UE solo obligan a los proveedores de esos sistemas. Para la mayoría de los agentes de marketing, un programa de evaluación bien hecho es una buena práctica, no una obligación legal. Desde Viena, Blck Alpaca ayuda a agencias y empresas B2B a poner en marcha un programa de evaluación así, desde el golden set y la selección de herramientas hasta un dossier de cumplimiento preparado para auditorías. Escríbenos si quieres que tus agentes entren en producción de forma medible y conforme a la normativa.