Ya sea que estés por lanzar un agente de IA que construyó tu equipo o por dar el visto bueno a uno que construyó un proveedor, necesitas una forma de responder una pregunta: ¿esto va a aguantar en producción, o solo en la demo? Los agentes fallan menos por limitaciones del modelo que por la falta de confiabilidad de la plataforma que los rodea — así que la evaluación es mayormente sobre esa plataforma. Aquí está la checklist que corremos, y que puedes pedirle a cualquier proveedor que te recorra.
1. ¿Hay un harness de evaluación — y controla los releases?
Pide verlo. No "lo probamos", sino el conjunto real de preguntas reales, respuestas reales y umbrales explícitos, con un set bloqueante que detiene un release cuando falla. Si la respuesta es "se veía bien en las pruebas", no hay evaluación, y el modelo más barato que pasa nunca se eligió de verdad — se eligió el favorito del proveedor. Sin evaluación en verde, no se lanza.
2. ¿Puedes trazar una sola solicitud de punta a punta?
Abre una interacción real (fallida) y síguela. Un sistema multi-agente que devuelve una respuesta segura y equivocada mientras cada componente "tuvo éxito" es el modo de fallo normal, y solo puedes depurarlo con un trace — spans tipados, IDs compartidos, el razonamiento adjunto — no con un log plano. Si nadie puede mostrarte por qué una solicitud hizo lo que hizo, nadie puede operarlo una vez que está en vivo.
3. ¿Hay un verificador entre el modelo y cualquier cosa irreversible?
Para cualquier acción que el agente no pueda deshacer — enviar, pagar, agendar, borrar — debería haber una verificación antes de que se comprometa: una compuerta de verificación, un checkpoint humano, o ambos. "El modelo suele tener razón" no es un mecanismo de seguridad. Pregunta qué pasa con la salida equivocada-pero-segura, cuatro pasos adentro.
4. ¿Hay un mapa de permisos?
Cada agente que llama tools necesita un mapa explícito de qué puede leer, escribir, mutar, escalar y nunca tocar — el límite trazado antes de la primera llamada a una tool, no atornillado después de un incidente. Si el agente "puede hacer cualquier cosa que la API permita", eso no es un modelo de permisos, es el incidente esperando a pasar.
5. ¿Sabe cuándo se equivoca?
Un sistema que solo tiene un modo — responder — va a fabricar con confianza cuando debería rechazar o escalar. El comportamiento de rechazo y escalamiento es algo que diseñas y mides, no que esperas. Verifica que la evaluación lo puntúe.
6. ¿Cuánto cuesta bajo carga real, y se mide?
El tráfico de demo es indulgente; el de producción se compone. Pide latencia p95 y dólares-por-solicitud bajo carga realista, y si el loop es consciente del cache. Un sistema que está bien en la demo puede ser lento y ruinosamente caro a escala si nadie lo presupuestó.
7. ¿Hay un runbook y un rollback?
Cuando derive o se rompa a las 3 a.m. — y lo hará — ¿hay un documento de operación real: alertas, modos de degradación, cuándo despertar a un humano, cómo revertir? "Lo vamos a monitorear" no es un runbook.
Cómo usar esto
Para un build que es tuyo: esta es la definición de terminado. Para un proveedor que estás evaluando: pídele que recorra las siete con tu equipo técnico sobre un proyecto pasado. Una firma genuina puede. Una guiada por demos va a pivotar hacia el roadmap. La brecha entre las dos respuestas es exactamente la brecha entre un sistema y una diapositiva.
Evaluar un agente de IA no se trata de cuán impresionante se ve — se trata de si las siete cosas de arriba existen. Son la diferencia entre "funciona" y "sobrevive". Si quieres un segundo par de ojos sobre un sistema antes de lanzarlo o comprarlo, eso es literalmente nuestra auditoría.