Cómo evaluar un agente de IA antes de darle más autonomía

Una buena demo no es una evaluación

Imagine un agente que recibe un email, consulta el CRM, prepara una respuesta y crea una tarea para el comercial adecuado. En la demo todo ocurre correctamente: interpreta la intención, encuentra al cliente, actualiza el registro y redacta un mensaje convincente.

Ahora cambie una sola condición. El cliente tiene dos empresas con nombres parecidos. La herramienta de CRM devuelve un error temporal. El usuario solicita algo que el agente no tiene permiso para modificar. La información llega en otro idioma. O una nueva versión del prompt cambia el orden de las acciones.

La pregunta relevante deja de ser “¿puede hacerlo?” y pasa a ser “¿en qué condiciones podemos confiar en que lo haga correctamente y qué ocurre cuando esas condiciones no se cumplen?”.

Las cuatro herramientas son útiles, pero responden a preguntas distintas. Una demo puede justificar seguir desarrollando. Una eval ayuda a decidir si una capacidad cumple criterios antes de ampliar su alcance. La monitorización detecta después problemas que el entorno controlado no había previsto.

Qué es una eval cuando el agente usa herramientas y toma varios pasos

La palabra eval aparece cada vez más en documentación técnica, pero para un decisor de negocio puede resultar innecesariamente opaca. Aquí la utilizamos como abreviatura de evaluación repetible de un sistema de IA: planteamos una tarea, ejecutamos el agente en condiciones definidas y comprobamos si cumple uno o varios criterios.

No estamos evaluando solo el modelo. Estamos evaluando el sistema completo: instrucciones, modelo, herramientas, permisos, memoria, integraciones, lógica de orquestación y entorno.

Hay además un sexto concepto especialmente importante: el resultado final. Un agente puede escribir “tarea creada correctamente”, pero el verdadero resultado debe comprobarse, cuando sea posible, en el sistema: ¿la tarea existe?, ¿está asociada al cliente correcto?, ¿tiene el responsable adecuado?, ¿se creó una sola vez?

Antes de evaluar, defina el contrato de la tarea

El error más habitual es construir casos de prueba antes de definir qué significa exactamente “hacerlo bien”. Si dos personas del equipo pueden discutir durante diez minutos sobre si una ejecución debería aprobar o suspender, probablemente el criterio todavía es demasiado ambiguo.

Para cada capacidad conviene especificar:

• Qué entrada recibe el agente;
• Qué resultado debe conseguir;
• Qué acciones puede ejecutar;
• Qué acciones están prohibidas;
• Qué herramientas tiene disponibles;
• Qué datos y permisos puede utilizar;
• Cuándo debe pedir información;
• Cuándo debe escalar a una persona;
• Qué significa que la tarea está realmente terminada;
• Qué evidencia permite comprobarlo;
• Qué errores son tolerables y cuáles bloquean el despliegue.

Este “contrato” no tiene que convertirse en un documento jurídico. Es una especificación operativa. Su valor está en transformar expresiones vagas —“debe responder bien”, “debe ser prudente”, “debe saber usar el CRM”— en comportamientos observables.

La Matriz de confianza Yarvia: seis evidencias antes de ampliar autonomía

Para estructurar la decisión proponemos una matriz editorial propia. No pretende ser un estándar universal, sino una forma práctica de impedir que la conversación sobre autonomía se reduzca a una puntuación agregada.

La salida no debería ser “el agente es fiable” en abstracto. Debe ser algo más concreto: “esta capacidad puede pasar de recomendar a ejecutar esta acción acotada bajo estos controles”.

Esto enlaza con el criterio de mínima autonomía suficiente: no buscamos que el agente haga todo lo posible, sino que asuma únicamente el nivel de decisión y acción que aporta valor y está respaldado por evidencia.

Casos normales, casos límite, excepciones y rechazos: la suite debe parecerse al mundo real

Una suite de evaluación es simplemente el conjunto de casos que utilizamos para comprobar una o varias capacidades. Si solo contiene ejemplos cómodos, su puntuación puede ser excelente y no decir prácticamente nada sobre producción.

No existe un reparto universal —por ejemplo, “30 % de casos límite”— que sirva para todos los agentes. La cobertura debe responder al uso real, al impacto del error, al tipo de herramientas y al riesgo de cada proceso.

Cuando ya hay producción, los fallos reales son una fuente especialmente valiosa. Un incidente relevante puede convertirse en un caso reproducible que permanezca para siempre en la suite.

No basta con mirar la respuesta final: resultado y trayectoria son cosas distintas

Los agentes pueden resolver una misma tarea siguiendo rutas diferentes. Eso obliga a evitar dos errores opuestos.

El primero es penalizar cualquier ruta que no coincida exactamente con la secuencia imaginada por el diseñador. Si dos trayectorias son válidas y terminan en el mismo estado correcto, no tiene sentido suspender una por ser distinta.

El segundo error es el contrario: mirar solo el resultado final y no detectar que el agente violó un control obligatorio durante el camino.

Por eso conviene separar:

• Resultado: qué estado o entregable final quedó realmente;
• Trayectoria: cómo llegó el sistema hasta ese resultado;
• Controles obligatorios: qué pasos o restricciones no pueden omitirse, aunque existan otras rutas posibles.

Qué son las tool calls y cómo se evalúan

Una de las diferencias entre un chatbot convencional y muchos agentes es su capacidad para usar herramientas. Una tool call, o llamada a una herramienta, es una petición estructurada que el agente realiza a una función o sistema externo para hacer algo que el modelo por sí solo no puede ejecutar.

Por ejemplo, el agente puede llamar a una herramienta para consultar el CRM, crear una cita, leer una factura, buscar un pedido en el ERP o enviar un email. El modelo decide qué herramienta utilizar y qué argumentos enviar; la aplicación ejecuta la acción y devuelve un resultado.

Este último punto es esencial. Una herramienta puede responder “200 OK” o “operación completada” y que la tarea de negocio no esté bien resuelta. Puede haberse modificado el registro equivocado, creado una cita duplicada o guardado un dato incompleto.

Cuando el resultado puede verificarse de forma determinista, hay que comprobarlo directamente. Es mejor consultar si la cita existe que pedir a otro modelo que opine sobre si probablemente fue creada.

Qué grader utilizar: reglas, IA o revisión humana

Un grader es el mecanismo que evalúa una dimensión del resultado o de la trayectoria. No hay un único tipo adecuado para todo.

Qué significa LLM-as-a-judge

LLM-as-a-judge significa utilizar un modelo de lenguaje como evaluador de la salida de otro sistema de IA. En español, podemos hablar simplemente de evaluación mediante otro modelo.

Puede ser útil cuando la calidad no cabe en una regla exacta. Por ejemplo: ¿la respuesta explica correctamente una política?, ¿el resumen conserva los datos esenciales?, ¿el tono es profesional?, ¿la contestación está bien fundamentada en las fuentes proporcionadas?

Pero un modelo evaluador no es un árbitro infalible. Para utilizarlo con sentido necesita:

• Una rúbrica clara: qué dimensiones debe evaluar y qué significa cada nivel;
• Ejemplos de casos buenos, malos y fronterizos cuando sean necesarios;
• Comparación periódica con criterio humano;
• Versionado del modelo, prompt y rúbrica cuando queremos comparar resultados en el tiempo;
• Una salida como “no se puede determinar” cuando no tiene información suficiente.

Por qué hay que repetir pruebas: trials, pass rate, pass@k y pass^k

Los sistemas generativos pueden producir resultados diferentes ante el mismo caso. Por eso una única ejecución puede dar una falsa sensación de seguridad o de fracaso.

Un trial es simplemente un intento. Si ejecutamos el mismo caso varias veces, podemos observar hasta qué punto el comportamiento es estable.

No existe un número universal de repeticiones. Dependerá de la variabilidad, el coste de ejecutar la prueba, la criticidad de la acción y la precisión que necesitemos para decidir.

Para un decisor empresarial, la diferencia práctica es sencilla. “Alguna vez consigue hacerlo” y “lo hace de forma consistente” son preguntas distintas.

En una tarea exploratoria, encontrar una solución válida entre varios intentos puede ser suficiente. En una acción que modifica un sistema de producción, una tasa de acierto esporádica puede ser inaceptable.

Un promedio alto puede ocultar un error crítico

Supongamos que un agente supera 95 de 100 pruebas. La cifra parece buena. Pero si los cinco fallos consisten en modificar el cliente equivocado, saltarse una autorización o confirmar acciones que no se ejecutaron, el promedio deja de ser tranquilizador.

Por eso la suite debe separar errores críticos, graves, recuperables y menores según el proceso. La severidad no puede esconderse dentro de una media.

Regresiones: cuando mejorar una cosa rompe otra

Una regresión aparece cuando una capacidad que antes cumplía los criterios deja de hacerlo después de un cambio.

Puede ocurrir al sustituir el modelo, modificar el prompt, añadir una herramienta, cambiar permisos, ampliar el contexto, alterar la memoria, ajustar una integración o modificar la forma en que se recupera información.

Sin una suite estable, el equipo puede corregir un fallo visible y crear otro silenciosamente.

El baseline es la versión de referencia con la que comparamos una candidata. No tiene por qué ser perfecta; simplemente necesitamos una línea de partida conocida.

La comparación no debería reducirse a “87 frente a 89 puntos”. Conviene mirar qué categorías suben, cuáles bajan, si aparecen fallos críticos nuevos, cómo cambia la variabilidad y si el coste o la latencia empeoran.

Un fallo real que ya fue corregido debería valorarse como candidato a prueba permanente. De esa manera, la suite acumula memoria operativa del sistema.

Autonomía guiada por evaluación: de recomendar a actuar

En este artículo utilizamos el término inglés eval-driven autonomy. Para un lector no técnico es más claro hablar de autonomía guiada por evaluación: el alcance del agente aumenta solo cuando existen pruebas suficientes sobre las capacidades concretas que va a asumir.

No significa que una suite “certifique” al agente. Significa que la decisión de darle más capacidad de acción deja de basarse en intuición y se apoya en evidencia repetible.

Los niveles son orientativos; no constituyen un estándar universal. La regla importante es otra: una capacidad no evaluada no hereda confianza por analogía. Que un agente gestione bien consultas de estado no demuestra que pueda modificar datos, autorizar devoluciones o enviar comunicaciones externas sin revisión.

Qué debe pasar antes de llevar una nueva versión a producción

Las evals offline —ejecutadas en un entorno controlado— y la monitorización de producción se complementan. Ninguna sustituye a la otra.

Antes del despliegue, la suite permite comparar versiones sin exponer el cambio directamente a usuarios o sistemas reales. Después del despliegue, la producción aporta algo imposible de reproducir por completo: distribución real de casos, entradas inesperadas, combinaciones nuevas, incidencias de infraestructura y cambios de comportamiento de los usuarios.

Las trazas son la caja negra del proceso

Una traza registra qué pasó durante la ejecución. Dependiendo de la arquitectura puede incluir generaciones del modelo, llamadas a herramientas, resultados, handoffs —traspasos entre agentes o roles—, controles, errores y cambios de estado.

OpenAI, por ejemplo, documenta tracing integrado en su Agents SDK para registrar generaciones, tool calls, handoffs, guardrails y eventos personalizados. Es un ejemplo de capacidad de plataforma, no una definición universal de cómo debe implementarse la observabilidad.

La traza permite reconstruir por qué falló una tarea y convertir ese fallo en un nuevo caso de evaluación. Pero también contiene potencialmente información sensible, por lo que debe diseñarse con minimización, permisos y retención adecuados.

La intervención humana también se mide

La intervención humana no debería contabilizarse simplemente como “mala” porque queremos automatizar más. Hay intervenciones previstas por diseño —una aprobación obligatoria— y otras que aparecen porque el agente falló o no supo resolver una excepción.

Separar ambos motivos permite responder una pregunta más útil: ¿la autonomía actual está funcionando como fue diseñada o las personas están corrigiendo continuamente al agente?

Coste y latencia forman parte de la decisión

Un agente puede resolver correctamente una tarea y seguir siendo inviable si necesita demasiadas llamadas al modelo, demasiadas herramientas, mucho tiempo o demasiada revisión humana.

Eso no significa optimizar siempre para “menos tokens” o “menos humanos”. Significa evaluar si el coste operativo es compatible con el valor del proceso sin degradar controles importantes para abaratarlo.

El NIST AI Risk Management Framework y su perfil para IA generativa pueden aportar una referencia institucional para pensar en testing, evaluation, verification and validation. Es importante no presentarlos como obligación legal: el AI RMF es un marco de uso voluntario.

Qué revisaría Yarvia en una auditoría de un agente

Antes de ampliar el alcance de un agente, revisaríamos el sistema desde el proceso de negocio y no únicamente desde el modelo utilizado.

• Qué tareas puede ejecutar hoy y cuáles debería poder ejecutar.
• Qué resultado verificable define el éxito de cada capacidad.
• Qué herramientas utiliza y qué permisos tienen.
• Qué acciones son reversibles y cuáles tienen mayor impacto.
• Qué casos normales, límite, rechazos y excepciones están cubiertos.
• Qué fallos reales deberían convertirse en regresiones permanentes.
• Qué puede verificarse con reglas y estados en lugar de con otro LLM.
• Qué criterios semánticos necesitan grader basado en modelo o revisión humana.
• Qué trazas existen y si permiten reconstruir fallos sin registrar datos innecesarios.
• Qué porcentaje de intervención humana es diseño previsto y cuál aparece por fallo.
• Cómo se comparan versiones candidatas con una baseline.
• Qué criterio concreto permitiría ampliar autonomía y qué fallo la bloquearía.

Si su empresa ya tiene un agente funcionando, pero no existe una suite capaz de indicar qué tareas resuelve, dónde falla, qué cambios introducen regresiones y qué acciones pueden ampliarse con evidencia, todavía falta una capa de evaluación.

Revisar la fiabilidad de un agente de IA