# Evaluación de agentes de IA: cómo medir si un agente hace bien su trabajo

> Evaluación de agentes de IA: casos de prueba con respuesta conocida, métricas por tarea y evaluación continua para separar una demo de un sistema fiable.

- Canonical: https://arkatai.com/evaluacion-de-agentes-de-ia/
- Site: Arkatai (https://arkatai.com) — agentic operations as a service
- Language: es
- Published: 2026-07-19

---


Evaluar un agente de IA es medir, con casos de prueba de respuesta conocida y métricas por tarea, si ejecuta su trabajo con calidad suficiente para producción, y volver a medirlo cada vez que cambia el modelo o el proceso. No es probar el caso feliz en una demo. Es la pieza que separa un sistema que parece funcionar de uno que funciona, y la primera que reviso antes de dejar a un agente tocar una operación real.

Lo digo así de directo porque el mercado enseña demos y las demos siempre salen bien: se elige el caso limpio, se lanza una vez y se aplaude. La operación real no es eso. Es el caso número trescientos, el que llega con un dato mal escrito, una excepción que nadie documentó y un plazo encima. Sin una evaluación seria, no tienes forma de saber qué hace tu agente en ese caso hasta que lo hace mal con un cliente delante.

## Qué es evaluar un agente y qué no es

Evaluar es responder a una pregunta que un comité puede firmar: sobre un conjunto representativo de casos, ¿con qué frecuencia el agente hace lo correcto, y qué pasa cuando no está seguro? Todo lo demás son matices de esa pregunta.

No es lo mismo que la [observabilidad y trazabilidad de agentes](/observabilidad-y-trazabilidad-de-agentes/), que mira el sistema mientras opera en vivo. La evaluación se hace contra un conjunto controlado de casos con respuesta conocida, la mayoría antes de que el agente vea trabajo real; la observabilidad vigila lo que ocurre después, con el tráfico de verdad. Las dos son necesarias y se alimentan: los fallos que detecta la observabilidad se convierten en casos nuevos del conjunto de evaluación.

## El conjunto de evaluación: casos con respuesta conocida

La base de todo es un conjunto de casos de prueba donde ya sabes cuál es la respuesta correcta. Para un agente que concilia facturas, eso significa un lote de facturas reales anonimizadas con el resultado que un buen contable daría a cada una: esta cuadra, esta tiene una desviación de portes, esta hay que escalar porque el pedido no aparece. El agente procesa el lote y comparas su salida con la respuesta esperada, caso por caso.

Ese conjunto se construye con criterio, no a voleo. Tiene que incluir:

- **Casos normales**, los del día a día, que deben salir bien casi siempre.
- **Excepciones conocidas**, las que el proceso ya sabe manejar y el agente debe reconocer.
- **Casos límite y ambiguos**, donde la respuesta correcta muchas veces es «esto no lo decido yo, lo escalo».
- **Casos trampa**, entradas malformadas o incompletas que en producción llegan más de lo que nadie admite.

Un conjunto que solo tiene casos fáciles miente: da una nota alta y no dice nada del riesgo real. La calidad de la evaluación depende de que los casos difíciles estén dentro. Y ese conjunto sale de tu operación, no de un catálogo genérico: es parte de la arquitectura operativa que se codifica al mapear el proceso, un activo del cliente y no de la plataforma.

## Métricas por tarea, no una nota global

«El agente acierta un 90%» no significa nada hasta que dices en qué. Un 90% de acierto con un 10% de errores silenciosos que llegan al cliente es inaceptable. Un 90% con el 10% restante escalado a una persona puede ser excelente. La métrica útil se define por tarea y por lo que cuesta cada tipo de error.

| Métrica | Qué mide | Por qué importa |
|---|---|---|
| Exactitud por tipo de caso | Con qué frecuencia la salida coincide con la respuesta correcta, desglosada por categoría | Una media global esconde que falla justo en los casos caros |
| Cobertura de excepciones | Qué proporción de las excepciones conocidas reconoce y trata bien | Mide si el agente aguanta la operación real, que vive de excepciones |
| Tasa de escalado correcto | Cuántas veces escala cuando debía escalar, y cuántas escala de más | Un agente que no escala nunca es peligroso; uno que escala todo es inútil |
| Falsos positivos con impacto | Acciones erróneas que llegan al sistema o al cliente sin filtro | Es el error que un comité no perdona; se vigila aparte |

La distinción entre un error que se queda dentro y uno que sale fuera es la que gobierna el riesgo. Por eso separo siempre el escalado. Prefiero un agente que ante la duda para y pasa el caso a una persona, con el contexto preparado, a uno que decide por decidir. Dónde se pone ese límite es una decisión de negocio, y la desarrollo en [human in the loop](/human-in-the-loop/); la mecánica de a quién y cómo se escala, en [excepciones y escalado a humanos](/excepciones-y-escalado-a-humanos/).

## Antes de producción y de forma continua

La evaluación tiene dos momentos y los dos son obligatorios. Antes de dar trabajo real, el agente pasa el conjunto completo y tiene que superar unos umbrales pactados. Por debajo de esa calidad no entra en producción, punto. Es la puerta que convierte una prueba de concepto en un sistema del que respondes ante un comité. Muchos pilotos mueren precisamente aquí, porque nunca hubo umbral. La demo bastó para ilusionar y nadie midió si aguantaba el volumen. He escrito sobre ese patrón en [por qué fracasan los pilotos de IA](/por-que-fracasan-los-pilotos-de-ia/).

El segundo momento no termina nunca. Un agente en producción no es una máquina que instalas y olvidas: el modelo por debajo se actualiza, tu proceso cambia, aparece un tipo de caso que antes no existía. Cada uno de esos cambios puede degradar el rendimiento sin que nadie lo note, y la única forma de saberlo es volver a pasar la evaluación. En Arkatai eso forma parte del ciclo de operar y actualizar: cuando cambia una pieza, las evaluaciones se vuelven a correr antes de confiar en el resultado.

## Qué pasa cuando cambias de modelo

Este punto merece párrafo propio porque es donde más gente se confía. Cambiar el modelo por debajo de un agente —porque salió uno mejor, más barato o más rápido— parece un cambio técnico menor. No lo es. Un modelo distinto puede acertar más en los casos normales y, a la vez, tratar peor una excepción concreta que el anterior clavaba. Sin evaluación, ese retroceso se descubre en producción, con un caso real.

Por eso trato los modelos como una utility intercambiable, pero nunca sustituyo uno sin volver a pasar el conjunto de evaluación completo. La capacidad de cambiar de modelo sin rehacer el proceso es una ventaja. Ejercerla sin medir es imprudencia. El criterio para elegir modelo por tarea lo desarrollo en el [hub de arquitectura de agentes de IA](/arquitectura-de-agentes-de-ia/), donde encaja la evaluación dentro del sistema completo.

## Evaluación, observabilidad y auditoría: tres cosas distintas

Se confunden a menudo, así que las separo. La **evaluación** mide la calidad contra casos conocidos, sobre todo antes de producción. La observabilidad vigila el sistema mientras opera. La **auditoría** reconstruye a posteriori qué decidió el agente y por qué, como evidencia ante un tercero. La trato en [auditar decisiones de agentes](/auditar-decisiones-de-agentes/), y el marco de control que las engloba, en [gobernanza de agentes](/gobernanza-de-agentes/). Las tres se apoyan en la misma traza, pero responden a preguntas diferentes: ¿es bueno?, ¿va bien ahora?, ¿puedo demostrar qué hizo? Un sistema serio necesita las tres.

Si tuviera que quedarme con una idea para un comité, es esta: no preguntéis si el agente es bueno, pedid ver cómo se mide que lo es, sobre qué casos y con qué umbral. La respuesta a esa pregunta distingue a quien tiene un sistema de quien tiene una demo con suerte. Este artículo pertenece al cluster de [agentes de IA para empresas](/agentes-de-ia-para-empresas/), donde encaja el resto de decisiones de adopción.

## Preguntas frecuentes

### ¿Qué es la evaluación de un agente de IA?

Es medir, con un conjunto de casos de prueba cuya respuesta correcta ya conoces, si el agente ejecuta su tarea con la calidad suficiente para operar. Se hace antes de darle trabajo real, para decidir si entra en producción, y de forma continua después, cada vez que cambia el modelo o el proceso.

### ¿Qué métricas se usan para evaluar un agente?

No una nota global, sino métricas por tarea: exactitud desglosada por tipo de caso, cobertura de las excepciones conocidas, tasa de escalado correcto y falsos positivos con impacto real. La clave es separar los errores que se quedan dentro del sistema de los que llegan al cliente, porque cuestan cosas muy distintas.

### ¿Por qué hay que reevaluar al cambiar de modelo?

Porque un modelo nuevo puede mejorar en los casos normales y, a la vez, tratar peor una excepción que el anterior resolvía bien. Ese retroceso no se ve sin volver a pasar el conjunto de evaluación completo. Descubrirlo en producción significa descubrirlo con un caso real y un cliente delante.

### ¿En qué se diferencia la evaluación de la observabilidad?

La evaluación mide la calidad contra casos con respuesta conocida, sobre todo antes de producción. La observabilidad vigila el sistema mientras opera en vivo, con el tráfico real. Se complementan: los fallos que detecta la observabilidad se convierten en casos nuevos del conjunto de evaluación.