Da igual si vas a lanzar un agente que construyó tu equipo o a dar el visto bueno al de un proveedor: necesitas responder una sola pregunta. ¿Esto aguanta en producción, o solo en la demo? Los agentes fallan menos por límites del modelo que por la fragilidad de la plataforma que los rodea, así que evaluarlos consiste sobre todo en evaluar esa plataforma. Esta es la checklist que aplicamos, y que puedes pedirle a cualquier proveedor que recorra contigo.
1. ¿Existe un arnés de evaluación, y decide los releases?
Pide verlo. No un «lo probamos», sino el conjunto real: preguntas reales, respuestas reales y umbrales explícitos, con un set bloqueante que detiene el release cuando falla. Si la respuesta es «se veía bien en las pruebas», no hay eval, y el modelo más barato que pasa nunca llegó a elegirse: se eligió el favorito del proveedor. Sin eval en verde, no se lanza.
2. ¿Puedes seguir una sola petición de punta a punta?
Abre una interacción real que haya fallado y síguela. Un sistema multiagente que devuelve una respuesta segura y equivocada mientras cada componente «tuvo éxito» es el modo de fallo habitual, y solo se depura con un trace —spans tipados, IDs compartidos, el razonamiento adjunto—, nunca con un log plano. Si nadie puede enseñarte por qué una petición hizo lo que hizo, nadie va a poder operarlo una vez esté en vivo.
3. ¿Hay un verificador entre el modelo y todo lo irreversible?
Para cualquier acción que el agente no pueda deshacer —enviar, pagar, agendar, borrar— tiene que haber una comprobación antes de que se consume: un gate de verificación, un checkpoint humano, o los dos. «El modelo casi siempre acierta» no es un mecanismo de seguridad. Pregunta qué ocurre con la salida equivocada pero convincente, cuatro pasos más adentro.
4. ¿Hay un mapa de permisos?
Todo agente que llama a tools necesita un mapa explícito de qué puede leer, escribir, mutar, escalar y nunca tocar: el límite trazado antes de la primera tool call, no atornillado después del primer incidente. Si el agente «puede hacer cualquier cosa que permita la API», eso no es un modelo de permisos: es el incidente esperando su turno.
5. ¿Sabe cuándo se está equivocando?
Un sistema con un único modo —responder— va a inventarse cosas con aplomo justo cuando debería rechazar o escalar. Rechazar y escalar son comportamientos que se diseñan y se miden, no que se esperan. Comprueba que el eval los puntúe.
6. ¿Cuánto cuesta bajo carga real, y alguien lo mide?
El tráfico de una demo es indulgente; el de producción se acumula. Pide latencia p95 y dólares por petición bajo carga realista, y pregunta si el loop aprovecha el cache. Un sistema que va bien en la demo puede volverse lento y ruinosamente caro a escala si nadie lo presupuestó.
7. ¿Hay runbook y hay rollback?
Cuando derive o se rompa a las 3 a.m. —y va a pasar—, ¿existe un documento de operación de verdad, con alertas, modos degradados, criterios para despertar a un humano y cómo revertir? «Lo vamos a monitorear» no es un runbook.
Cómo usar esto
Si el build es tuyo, esto es la definición de terminado. Si estás evaluando a un proveedor, pídele que recorra los siete puntos con tu equipo técnico sobre un proyecto anterior. Una firma seria puede hacerlo. Una que vive de las demos se escapará hacia el roadmap. La distancia entre esas dos respuestas es exactamente la distancia entre un sistema y una diapositiva.
Evaluar un agente de IA no va de lo impresionante que se ve, sino de si esas siete cosas existen. Son la diferencia entre «funciona» y «sobrevive». Si quieres un segundo par de ojos sobre un sistema antes de lanzarlo o comprarlo, en eso consiste nuestra auditoría.