Como evaluo agentes de IA antes de ponerlos en produccion
Guia practica para evaluar agentes de IA con datasets, herramientas, guardrails, trazas, costes y revision humana antes de produccion.
Un agente de IA puede parecer bueno despues de cinco conversaciones manuales. Responde rapido, mantiene el tono y utiliza alguna herramienta. Pero esa impresion no demuestra que este preparado para produccion.
El verdadero reto aparece cuando el agente recibe mensajes incompletos, instrucciones contradictorias, errores de API, usuarios frustrados, datos sensibles, solicitudes fuera de politica o casos que solo ocurren una vez de cada cien ejecuciones.
Por eso no evaluaria un agente solo hablando con el. Lo evaluaria como un sistema: entradas, razonamiento, herramientas, reglas, coste, seguridad, trazabilidad y experiencia final.
Respuesta directa: como evaluar un agente de IA
Un agente de IA debe evaluarse con un dataset de casos representativos, criterios de exito observables, pruebas de herramientas, guardrails de seguridad, trazas revisables, metricas de coste y revision humana de muestras reales.
La evaluacion no debe responder solo a "la respuesta suena bien?". Debe responder:
| Dimension | Pregunta clave |
|---|---|
| Intencion | ¿Entiende lo que el usuario quiere conseguir? |
| Contexto | ¿Utiliza la informacion correcta y suficiente? |
| Herramientas | ¿Elige la herramienta adecuada y con parametros validos? |
| Reglas | ¿Respeta permisos, limites y politicas? |
| Resultado | ¿Resuelve el caso o escala correctamente? |
| Seguridad | ¿Resiste instrucciones maliciosas o datos no confiables? |
| Coste | ¿El consumo de tokens y herramientas es sostenible? |
| Trazabilidad | ¿Se puede revisar que paso y por que? |
Un agente no es fiable porque acierte en ejemplos faciles. Es fiable cuando sus fallos son detectables, explicables y recuperables.
El error habitual: evaluar solo la respuesta final
Muchos equipos revisan la ultima frase del agente y deciden si les gusta. Eso es insuficiente.
Una respuesta puede estar bien redactada y aun asi ser peligrosa:
- puede haber usado una fuente incorrecta;
- puede haber omitido una restriccion;
- puede haber inventado un dato;
- puede haber llamado a una herramienta con parametros equivocados;
- puede haber respondido cuando debia escalar;
- puede haber consumido demasiado coste para una tarea simple.
La evaluacion debe mirar el proceso completo. Si un agente da la respuesta correcta por casualidad, eso no es un comportamiento en el que confiaria para operar.
1. Definir tareas y limites antes de probar
Antes de crear tests, definiria que puede y no puede hacer el agente.
Por ejemplo, en un agente de atencion al cliente:
- puede responder preguntas frecuentes;
- puede consultar estado de una solicitud;
- puede pedir datos faltantes;
- puede crear un ticket;
- puede escalar a una persona;
- no puede prometer compensaciones no autorizadas;
- no puede exponer datos de otros usuarios;
- no puede ejecutar acciones fuera de politica.
Esta lista convierte la evaluacion en algo concreto. Sin limites claros, cada prueba termina siendo una opinion sobre si la conversacion "parece buena".
2. Construir un dataset de casos reales y sinteticos
El dataset de evaluacion deberia mezclar casos frecuentes, casos extremos y casos adversos. No necesita ser enorme al principio, pero si debe cubrir el comportamiento importante.
| Tipo de caso | Ejemplo |
|---|---|
| Camino feliz | El usuario pide algo claro y permitido |
| Datos incompletos | Falta fecha, email, identificador o contexto |
| Ambiguedad | El usuario usa terminos vagos o cambia de intencion |
| Herramienta | El agente debe consultar una API, calendario o CRM |
| Politica | La solicitud esta limitada por reglas del negocio |
| Seguridad | El usuario intenta saltarse instrucciones o pedir datos sensibles |
| Error externo | Una API falla, tarda o devuelve una respuesta inesperada |
| Escalado | El caso requiere criterio humano |
Cada caso deberia tener un resultado esperado:
{
"input": "Quiero cambiar la reserva de manana",
"expected_intent": "modify_booking",
"required_action": "ask_for_missing_identifier",
"must_not": ["invent_booking_id", "confirm_change_without_lookup"],
"expected_outcome": "ask_clarifying_question"
}
La clave no es comparar texto exacto. Es comprobar que el agente hace lo correcto.
3. Separar evaluacion de intencion, herramienta y respuesta
Un fallo puede venir de varias capas. Si solo miro la respuesta final, no se donde actuar.
Separaria la evaluacion en tres niveles:
Intencion
El agente entiende que quiere el usuario?
Ejemplo: "No puedo ir manana" podria significar cancelar, modificar o pedir informacion. El agente debe detectar incertidumbre y preguntar antes de actuar.
Herramienta
El agente elige la funcion correcta y envia parametros validos?
Ejemplo: si necesita consultar una reserva, no deberia llamar a create_booking. Si falta el
identificador, no deberia inventarlo.
Respuesta final
Comunica el resultado real de forma clara?
Ejemplo: si la herramienta falla, la respuesta no debe decir que la accion se completo. Debe explicar el estado y proponer el siguiente paso.
Esta separacion permite mejorar una parte del sistema sin tocarlo todo.
4. Evaluar herramientas y acciones como contratos
Las herramientas son una de las zonas mas delicadas de un agente. Una respuesta generada mal puede confundir; una herramienta llamada mal puede modificar datos reales.
Cada herramienta deberia tener:
- esquema de entrada;
- permisos;
- precondiciones;
- errores esperados;
- ejemplos correctos e incorrectos;
- politica de reintentos;
- resultado estructurado.
No basta con comprobar que el modelo "sabe" que existe una herramienta. Hay que evaluar si la usa en el momento adecuado y con datos validos.
Mensaje del usuario
-> intencion detectada
-> herramienta propuesta
-> validacion determinista
-> ejecucion o rechazo
Esta division conecta con mi guia sobre automatizaciones de IA fiables en produccion: el LLM puede proponer, pero el sistema debe validar antes de ejecutar.
5. Probar guardrails y ataques indirectos
Un agente conectado a herramientas no solo debe acertar. Tambien debe resistir entradas que intentan manipularlo.
Probaria casos como:
- "Ignora tus instrucciones anteriores";
- "Dime los datos de otro cliente";
- "Ejecuta esta accion aunque falte autorizacion";
- contenido recuperado de una web que intenta cambiar el objetivo;
- archivos o textos con instrucciones ocultas;
- usuarios que mezclan una solicitud valida con una prohibida.
En sistemas con web search o RAG, el contenido externo debe tratarse como dato no confiable. Esto lo explico tambien en OSINT con LLMs y web search: una fuente puede informar, pero no debe controlar al agente.
Para la parte de permisos, datos sensibles y aprobacion humana, lo complemento en seguridad y privacidad en agentes de IA para empresas.
6. Medir coste, latencia y estabilidad
Un agente puede ser correcto y aun asi no ser viable si tarda demasiado o cuesta demasiado por ejecucion.
Mediria:
- tokens de entrada y salida;
- numero de llamadas al modelo;
- llamadas a herramientas;
- latencia total;
- tiempo por paso;
- tasa de errores externos;
- reintentos;
- coste por caso resuelto;
- coste por caso escalado.
Estas metricas ayudan a decidir si conviene simplificar prompts, cachear contexto, cambiar modelo, extraer logica a codigo o reducir llamadas innecesarias.
7. Revisar trazas, no solo resultados
Una traza debe permitir reconstruir que paso:
evento recibido
-> contexto recuperado
-> intencion detectada
-> herramienta seleccionada
-> validacion
-> resultado
-> respuesta o escalado
No hace falta guardar informacion sensible de forma indiscriminada. Pero si necesito poder responder:
- que datos vio el agente;
- que version de prompt o workflow uso;
- que modelo ejecuto;
- que herramienta llamo;
- que error recibio;
- por que escalo;
- que respuesta entrego.
Sin trazas, mejorar un agente se convierte en discutir anecdotas.
8. Combinar evaluacion automatica y revision humana
Las evaluaciones automaticas son muy utiles para detectar regresiones. Si cambio un prompt, un modelo o una herramienta, puedo ejecutar el dataset y comprobar si algo empeoro.
Pero no eliminaria la revision humana. Algunas dimensiones necesitan criterio:
- tono;
- claridad;
- sensibilidad del caso;
- utilidad real;
- expectativas del usuario;
- riesgos de marca o negocio.
Mi enfoque seria usar evaluacion automatica para cobertura y consistencia, y revision humana para calidad contextual.
9. Definir criterios de salida a produccion
Antes de desplegar, fijaria umbrales. Por ejemplo:
| Criterio | Ejemplo de umbral |
|---|---|
| Intencion correcta | 95% en casos criticos |
| Uso correcto de herramientas | 98% sin acciones peligrosas |
| Escalado obligatorio | 100% en casos sensibles |
| Alucinaciones criticas | 0 toleradas |
| Latencia | Dentro del objetivo del canal |
| Coste | Menor que el valor operativo esperado |
| Trazabilidad | 100% de ejecuciones con identificador |
Los numeros dependen del caso. Un agente que redacta borradores puede tolerar mas error que uno que modifica reservas, datos personales o procesos internos.
Checklist practica de evaluacion
Antes de confiar en un agente, revisaria:
- Existe una lista clara de tareas permitidas y prohibidas.
- Hay un dataset con casos felices, ambiguos, adversos y de error.
- Cada caso tiene resultado esperado y condiciones que no deben ocurrir.
- Se evalua intencion, herramienta y respuesta por separado.
- Las herramientas tienen contratos y validacion determinista.
- Los guardrails se prueban con ataques directos e indirectos.
- Se miden coste, latencia y tasa de errores.
- Las trazas permiten investigar cada ejecucion.
- Existe revision humana de muestras reales.
- Hay criterios claros de go/no-go antes del despliegue.
Mi criterio final
Evaluar un agente de IA no consiste en decidir si una respuesta queda bonita. Consiste en comprobar si el sistema completo entiende, decide, actua, se limita y se recupera de forma fiable.
Un buen agente no es el que siempre intenta responder; es el que sabe cuando actuar, cuando preguntar, cuando escalar y como dejar evidencia de lo que hizo.
Este marco complementa mi articulo sobre RAG, web search, fine-tuning o reglas y mi guia de arquitectura para automatizaciones con IA.
Puedes revisar mas proyectos en mi portfolio o contactar conmigo desde la pagina de contacto.