Evals: cómo medir si un agente hace bien su trabajo antes de que lo note tu cliente
Evals de agentes de IA en producción: define tareas, mide resultados, analiza fallos y mejora con datos antes de que un error llegue a tu cliente.
El problemaCambias algo en tu agente y no sabes si lo mejoraste o lo rompiste hasta que se queja un cliente.
Lunes, 8:05. Marta, gerente de atención al cliente de una tienda en línea de refacciones, encuentra once quejas nuevas en la bandeja. Todas dicen lo mismo: el asistente les negó una devolución que sí procedía. El jueves anterior, el equipo había ajustado las instrucciones del agente para que sonara "más cercano". El tono mejoró. La política de devoluciones, sin que nadie lo notara, dejó de aplicarse bien. El problema no fue el cambio. Fue no tener evals de agentes de IA que lo detectaran antes de publicarlo.
Cualquier persona que haya puesto un agente en producción conoce esta sensación: cada ajuste es una apuesta. Este artículo explica cómo dejar de apostar y empezar a medir.
Por qué "lo probé y funcionó" no es suficiente
Cuando un equipo ajusta un agente, normalmente lo prueba con tres o cuatro preguntas, ve que responde bien y lo publica. El problema es que un agente atiende cientos de situaciones distintas. Un cambio que mejora un caso puede empeorar otro que nadie revisó.
Además, el agente cambia aunque tú no lo toques. Los proveedores actualizan sus modelos, los datos del negocio se mueven, se agregan productos nuevos. Sin una forma sistemática de medir, solo te enteras de que algo se rompió cuando un cliente te lo dice.
Por eso tantos pilotos se quedan en piloto. Una encuesta de marzo de 2026 a 650 líderes tecnológicos encontró que 78% tiene al menos un piloto de agentes, pero solo 14% lo ha escalado a toda la organización. Sin evidencia de calidad, nadie se atreve a escalar; lo analizamos a fondo en por qué tu piloto de IA nunca llegó a producción.
Qué son los evals de agentes de IA, en simple
Un eval es un examen. Tiene preguntas (tareas reales que el agente debe resolver), una forma de calificar (qué cuenta como bien, regular o mal) y un resultado que puedes comparar en el tiempo.
Piensa en cómo se certifica a un piloto de avión. No basta con que haya volado bien una vez. Pasa por un simulador con escenarios definidos, incluidos los difíciles: tormenta, falla de motor, pista mojada. Si un día cambian el avión, vuelve al simulador. Los evals son el simulador de tu agente.
El ciclo de mejora en cinco pasos
Los evals no son una auditoría que haces una vez. Son el motor del ciclo de mejora del agente.
1. Define las tareas
Reúne casos reales que representen el trabajo del agente. En el caso de Marta: solicitudes de devolución dentro y fuera de plazo, productos con garantía, clientes molestos, preguntas ambiguas. Incluye los casos difíciles y los que ya fallaron alguna vez. Este conjunto se llama benchmark: tu batería fija de pruebas.
2. Ejecuta
Corre el agente sobre todo el benchmark, en las mismas condiciones en que trabaja en producción: mismas herramientas, mismas reglas, misma memoria del negocio.
3. Califica
Cada respuesta se compara con lo esperado. Algunas cosas se verifican de forma automática (¿aplicó la política correcta?, ¿citó el número de pedido?). Otras requieren criterio, y ahí puede intervenir un agente evaluador independiente, con reglas escritas por tu equipo. La regla de oro: quien genera no se califica a sí mismo, como explicamos en generador y evaluador.
4. Analiza los fallos
Aquí está el valor real. No basta con saber que el agente acertó en una proporción de casos. Hay que agrupar los errores: ¿falla por falta de información?, ¿por una instrucción ambigua?, ¿por una herramienta que devuelve datos incompletos?, ¿por el modelo?
5. Mejora y vuelve a medir
Según la causa, el arreglo es distinto:
- Instrucciones: aclarar una regla o un ejemplo en el prompt.
- Herramientas: que el agente pueda consultar la fecha real de compra en lugar de preguntarla.
- Políticas: agregar una regla dura, por ejemplo "nunca negar una devolución sin revisar la fecha de entrega".
- Modelo: cambiar a otro modelo para un paso específico si el actual no da el nivel requerido.
Después de cada arreglo, vuelves a correr el benchmark completo. Si el resultado mejora y nada se rompe, publicas. Si algo empeora, lo sabes antes que tu cliente.
Un marco práctico: qué medir según el proceso
| Proceso | Qué cuenta como éxito | Qué es un error grave |
|---|---|---|
| Atención al cliente | Resuelve aplicando la política correcta | Promete algo que la empresa no cumple |
| Propuestas comerciales | Precios y condiciones vigentes | Descuento no autorizado |
| Revisión de contratos | Detecta las cláusulas de riesgo definidas | Omite una cláusula crítica |
| Calificación de leads | Clasifica según los criterios del equipo | Descarta un lead calificado |
Fíjate en la tercera columna. Un buen benchmark no trata todos los errores igual. Un error de tono no pesa lo mismo que una promesa falsa.
Ejemplo ilustrativo: el asistente de devoluciones, antes y después
Ejemplo ilustrativo. Antes, el equipo de Marta ajustaba el agente cada semana y lo probaba "a ojo". Los problemas aparecían como quejas.
Después, armaron un benchmark con 60 casos reales de los últimos meses, incluidos los once que fallaron ese lunes. Cada cambio pasa por el benchmark antes de publicarse. El día que alguien vuelve a ajustar el tono, el eval marca de inmediato que los casos de devolución dentro de plazo empezaron a fallar. El cambio no se publica hasta que se corrige.
Lo interesante es que los datos de los fallos alimentan el siguiente ciclo. Cada ejecución real que se marca como problemática en las trazas se convierte en un caso nuevo del benchmark. Sin observabilidad, no tendrías de dónde sacar esos casos.
Errores comunes
- Un benchmark solo con casos fáciles. Si todo pasa siempre, la prueba no está midiendo nada.
- Que lo diseñe solo el equipo técnico. Los criterios de calidad son del negocio.
- Medir una sola vez. Un eval que no se repite tras cada cambio es una foto, no un control.
- Mirar solo el promedio. Un agente puede mejorar en promedio y empeorar justo en los casos que más importan.
- No actualizar el benchmark. Tu negocio cambia; tus pruebas también deben cambiar.
Qué hacer el lunes
Pide a la persona responsable del proceso que reúna veinte casos reales que el agente debería resolver, incluyendo cinco difíciles y los errores que ya conoces. Para cada uno, que escriba en una línea qué sería una respuesta correcta. Esa lista es tu primer benchmark.
En Addabra los evals son parte del método, no un añadido: definimos el benchmark con tu equipo durante el diseño, lo corremos antes de cada cambio y usamos los fallos para mejorar instrucciones, herramientas, políticas o modelo. Así cada versión del sistema llega a producción con evidencia de que funciona.
Preguntas frecuentes
¿Qué es un eval en un agente de IA?
Es una prueba controlada: le das al agente una tarea con una respuesta esperada conocida y mides qué tan bien la resuelve. Un conjunto de evals funciona como el examen que el agente debe aprobar antes de cada cambio importante.
¿Quién define qué es una buena respuesta?
Las personas que conocen el negocio, no el equipo técnico. El gerente de atención, el abogado o el director comercial describen qué resultado es aceptable, qué es un error grave y qué es tolerable. El equipo técnico convierte esos criterios en pruebas automáticas.
¿Cada cuánto hay que correr los evals?
Siempre que cambie algo que afecte al agente: sus instrucciones, sus herramientas, sus reglas o el modelo que usa. Además conviene correrlos de forma periódica, porque los modelos de los proveedores también cambian y el comportamiento puede moverse sin que tú toques nada.
