Cómo evaluar un agente de IA antes de producción: un marco práctico para B2B

Un agente de IA completa la demostración con éxito.

Encuentra la cuenta correcta, resume el historial, actualiza el CRM y redacta una respuesta útil.

El equipo aprueba el piloto.

Luego, la producción introduce condiciones que no existían en la demostración: falta un campo obligatorio; dos sistemas no coinciden; la API agota el tiempo de espera; el mismo evento se entrega dos veces; el cliente hace una pregunta ambigua; un documento contiene una instrucción maliciosa; la aprobación vence mientras el proceso continúa; y el agente reintenta una acción que ya se había completado.

No necesariamente se evaluó mal al agente.

Puede que nunca se haya evaluado.

Una demostración exitosa prueba que una ruta de ejecución puede funcionar.

Estar listo para producción exige evidencia de que el sistema se comporta de forma aceptable en condiciones normales, ambiguas, adversas y de falla parcial.

Un agente de IA debe evaluarse en cinco niveles: Resultado de la tarea - ¿completó correctamente la tarea de negocio? Traza de ejecución - ¿eligió las herramientas y acciones correctas? Seguridad y políticas - ¿se mantuvo dentro de sus permisos? Economía - ¿completó la tarea con un costo y una velocidad aceptables? Resiliencia operativa - ¿manejó correctamente los datos faltantes, las fallas, los reintentos y el escalamiento?

La unidad de evaluación debe ser la tarea de negocio completada, no la calidad de una sola respuesta del modelo. Antes de comenzar la evaluación, la empresa debe confirmar que las ocho condiciones de preparación descritas en nuestra guía sobre por qué los agentes de IA no son automatización estén cumplidas: claridad del proceso, responsables, acceso a datos, permisos, límites de decisión, reglas de aprobación, registro y reversión.

Por qué la evaluación estándar de LLM no es suficiente

Un chatbot puede evaluarse principalmente por su respuesta final.

Un agente puede producir una buena respuesta final y, al mismo tiempo, comportarse de forma incorrecta durante la ejecución.

Puede recuperar datos restringidos; usar la herramienta equivocada; enviar argumentos no válidos; actualizar la cuenta equivocada; repetir una acción irreversible; ocultar la incertidumbre; superar su límite de costo; y llegar al resultado correcto por una ruta insegura.

Por eso, la evaluación de agentes debe revisar tanto el resultado como la traza que lo produjo.

La guía oficial de evaluación actual describe cada vez más el proceso como una combinación de diseño de casos de prueba, ejecución, generación de trazas, puntuación, simulación y análisis de fallas. La documentación de evaluación de agentes de Google, por ejemplo, incluye escenarios de varios turnos y fallas simuladas de herramientas, como errores de servicio y picos de latencia. (Google Cloud Documentation)

Empiece con un contrato de tarea por escrito

Antes de crear un conjunto de pruebas, defina la tarea con precisión.

Un contrato de tarea útil incluye:

Sin este contrato, un equipo puede no ponerse de acuerdo sobre si la misma ejecución del agente fue exitosa.

Una persona evalúa la calidad de la respuesta.

Otra evalúa la velocidad.

Otra supone que estaba permitido actualizar el CRM.

No se puede medir al agente contra requisitos que nunca se definieron.

Evalúe primero el resultado de negocio

La métrica principal no es "la respuesta sonaba bien".

Es el éxito de la tarea.

Ejemplos: ¿Se identificó al cliente correcto? ¿Se vinculó la factura correcta? ¿Se envió el ticket a la cola correcta? ¿Se generó el informe solicitado a partir de la fuente de datos aprobada? ¿Se actualizó el registro con precisión? ¿Se escaló la tarea cuando la evidencia era insuficiente?

Una tarea solo debe marcarse como exitosa cuando se cumplen todas las condiciones obligatorias.

En flujos de trabajo de alto impacto, un éxito parcial puede seguir siendo una falla.

Un agente que calcula el monto de reembolso correcto pero lo aplica a la cuenta equivocada no logró un 90% de éxito.

Creó un incidente.

Métricas que revelan si el agente funciona

Tasa de éxito de las tareas

Tasa de éxito de tareas = Tareas completadas correctamente / Total de tareas evaluadas

Los criterios de éxito deben ser deterministas siempre que sea posible.

Por ejemplo: registro correcto; valor de campo correcto; ruta correcta; estado de aprobación correcto; ninguna acción prohibida; y evidencia requerida adjunta.

Precisión en la selección de herramientas

¿Eligió el agente la herramienta adecuada?

Un agente puede tener acceso a búsqueda en el CRM; consulta de facturación; recuperación de conocimiento; borrador de correo electrónico; actualización de clientes; y solicitud de aprobación.

Seleccionar una herramienta relacionada semánticamente pero incorrecta desde el punto de vista operativo debe contarse como un error, aunque el resultado final parezca razonable.

Validez de los argumentos de las herramientas

Una herramienta correcta con parámetros incorrectos sigue siendo una acción fallida.

Evalúe los argumentos obligatorios; los identificadores de cuenta; las fechas; los montos; los valores de estado; el alcance; el destinatario; la clave de idempotencia; y el token de aprobación.

Las salidas estructuradas y la validación de esquemas reducen el riesgo, pero la validación también debe verificar el significado para el negocio.

Un monto de $100,000 sintácticamente válido puede seguir violando el límite de aprobación del agente.

Tasa de cumplimiento de políticas

Mida si el agente: se mantuvo dentro de los sistemas permitidos; evitó la información restringida; obtuvo la aprobación requerida; respetó los límites de acción; se detuvo cuando la evidencia era insuficiente; evitó las acciones prohibidas; y trató las instrucciones externas como contenido no confiable.

OWASP recomienda privilegio mínimo, supervisión humana para acciones de alto riesgo, límites a la recursión y a los reintentos, validación de las entradas externas y pruebas adversas estructuradas antes de producción. (OWASP Cheat Sheet Series)

Para una acción irreversible prohibida, la cantidad aceptable de ejecuciones no autorizadas en las pruebas debe ser cero.

Tasa de corrección humana

Tasa de corrección = Tareas que requieren cambios humanos sustanciales / Tareas revisadas

No cuente las preferencias de formato como correcciones sustanciales.

Registre los cambios que afectan: la decisión; el destinatario; el monto; la clasificación; la evidencia; la acción en el sistema; y el compromiso con el cliente.

Una tasa de corrección alta significa que el agente puede estar trasladando el trabajo en lugar de eliminarlo.

Calidad del escalamiento

Un agente no debe intentar resolver todos los casos.

Evalúe si escala: cuando falta información obligatoria; cuando los registros se contradicen; cuando la confianza es insuficiente; cuando la acción supera su autoridad; cuando la solicitud es inusual; cuando fallan las herramientas; y cuando se requiere interpretar una política.

Importan tanto el escalamiento insuficiente como el excesivo.

El escalamiento insuficiente genera riesgo.

El escalamiento excesivo elimina el valor económico de la automatización.

Tasa de ejecuciones duplicadas

Los agentes deben probarse frente a mensajes repetidos, reintentos y respuestas demoradas.

El sistema no debe: emitir dos reembolsos; crear dos facturas; enviar correos duplicados; crear registros duplicados en el CRM; ni reabrir una tarea completada.

La idempotencia no es solo un tema de integración. Es parte de la corrección del agente.

Latencia y duración de la tarea

Mida el tiempo hasta la primera acción útil; la duración total de la tarea; el tiempo de espera de las herramientas; el número de iteraciones del modelo; la demora de la aprobación humana; y la demora por reintentos.

Una tarea puede ser precisa pero inservible en la operación si tarda más que el proceso manual.

Costo por tarea completada

Costo por tarea exitosa = (Modelo + Herramientas + Infraestructura + Costo de revisión) / Tareas completadas con éxito

Incluya las llamadas al modelo; la recuperación; el reordenamiento; las API externas; la observabilidad; la revisión humana; los intentos fallidos; los reintentos; y el soporte de ingeniería.

El costo por solicitud oculta las fallas.

El costo por tarea completada las expone.

Construya el conjunto de pruebas en torno a las fallas, no solo al éxito

Un conjunto de evaluación representativo debe contener varias clases de escenarios.

Casos normales

Tareas rutinarias con datos completos y consistentes.

Propósito: establecer el rendimiento de referencia.

Casos ambiguos

Solicitudes con varias interpretaciones plausibles.

Comportamiento esperado: pedir aclaración o aplicar una regla documentada.

Casos con datos faltantes

Falta información obligatoria.

Comportamiento esperado: identificar la evidencia faltante y detenerse o escalar.

Casos con datos contradictorios

Los sistemas de CRM, facturación y soporte no coinciden.

Comportamiento esperado: seguir la política de fuente de verdad en lugar de elegir la respuesta más conveniente.

Casos de falla de herramientas

Simule: tiempo de espera agotado; falla de autenticación; límite de tasa; respuesta mal formada; actualización parcial; e interrupción temporal del servicio.

Comportamiento esperado: reintentar solo cuando sea seguro, conservar el estado, evitar duplicados y escalar cuando se alcancen los límites.

Casos de eventos duplicados

Entregue el mismo disparador más de una vez.

Comportamiento esperado: reconocer que la tarea ya se completó.

Casos de estado desactualizado

Modifique un registro después de que el agente comience, pero antes de que actúe.

Comportamiento esperado: volver a validar los datos críticos antes de la ejecución.

Casos adversos

Coloque instrucciones maliciosas o engañosas dentro de: un correo electrónico; un PDF; una nota del CRM; una página web; un ticket de soporte; y un documento recuperado.

Comportamiento esperado: tratar el contenido externo como datos, no como una autoridad capaz de anular la política del sistema.

Casos de solicitudes no autorizadas

Pida al agente que realice una acción fuera de sus permisos.

Comportamiento esperado: negarse o enviar la solicitud a una aprobación autorizada.

Casos de falla parcial

La primera acción se completa y la segunda falla.

Comportamiento esperado: conservar un estado preciso, evitar repetir la acción exitosa y ofrecer un escalamiento recuperable.

Defina criterios de aceptación basados en el riesgo

No debería existir un único umbral de rendimiento universal para todos los agentes.

Clasifique las tareas según su impacto potencial.

Una tasa promedio de éxito alta no compensa una sola acción crítica no autorizada.

Por eso, los resultados deben reportarse por escenario y por severidad, no solo como un porcentaje combinado.

Registre la traza de ejecución completa

Para cada ejecución evaluada, conserve: ID del escenario; Entrada y contexto relevante; Versión del agente; Modelo y configuración; Versión de las instrucciones y de la política; Evidencia recuperada; Llamadas a herramientas y parámetros; Decisiones de permisos; Solicitudes y respuestas de aprobación; Errores y reintentos; Acción final; Duración y costo; Resultado de la evaluación; y Categoría de la falla.

Esto ofrece tres beneficios: el comportamiento fallido se puede reproducir; las versiones se pueden comparar; y las fallas ya corregidas pueden convertirse en pruebas de regresión.

El perfil de IA generativa de NIST organiza la gestión de riesgos en torno a las funciones Govern, Map, Measure y Manage. En un programa de agentes, la evaluación es el puente entre mapear el comportamiento previsto y gestionar el riesgo real en producción. (NIST)

Use un despliegue gradual en producción

Aprobar un conjunto de pruebas offline no es el final de la evaluación.

La producción introduce usuarios reales, datos cambiantes, integraciones, latencia, formulaciones inesperadas y el comportamiento propio de la organización.

Un despliegue más seguro usa cuatro etapas.

Modo sombra

El agente evalúa tareas reales, pero no puede actuar.

Compare sus decisiones propuestas con las decisiones humanas reales.

Mida la coincidencia; los falsos positivos; los falsos negativos; la evidencia faltante; y el comportamiento de escalamiento.

Modo de recomendación

El agente presenta recomendaciones a los empleados.

Las personas ejecutan la acción.

Esto revela si la recomendación es útil y si el agente aporta suficiente evidencia.

Modo de aprobación

El agente prepara la acción y la ejecuta después de una aprobación explícita.

Mida la tasa de aprobación; la tasa de corrección; el tiempo del revisor; las aprobaciones vencidas; las acciones rechazadas; y los errores posteriores a la ejecución.

Producción acotada

El agente actúa de forma autónoma solo en una categoría estrecha y de bajo riesgo.

Use listas de cuentas permitidas; límites de monto; límites de herramientas; límites de tasa; límites de tiempo; límites de gasto; escalamiento automático; y controles de apagado inmediato.

La autonomía debe ampliarse un límite a la vez.

El monitoreo en producción es evaluación continua

Después del lanzamiento, monitoree: el éxito de las tareas; las correcciones y reversiones; el escalamiento; las fallas de herramientas; los reintentos; las acciones duplicadas; los intentos no autorizados; el costo promedio por tarea; la latencia; el comportamiento anómalo; el rendimiento por tipo de escenario; y el rendimiento por versión del modelo o del agente.

Los promedios pueden ocultar fallas importantes.

Por ejemplo, una tasa de éxito del 95% puede incluir un 99% en casos rutinarios; un 60% en casos ambiguos; y un 40% cuando un sistema no está disponible.

La cifra agregada se ve saludable.

La operación, no. El monitoreo continuo a este nivel es uno de los diez controles mínimos de gobernanza descritos en nuestra guía de gobernanza de IA para empresas B2B medianas.

Un scorecard de preparación para producción

Use la siguiente estructura para llegar a una decisión de avanzar, avanzar con límites o no avanzar.

Los controles obligatorios deben funcionar como filtros de aprobación.

Por ejemplo, un agente no debe aprobar por tener una puntuación ponderada alta cuando: realizó una acción no autorizada; una ejecución crítica no se puede reconstruir; son posibles los pagos duplicados; el agente no se puede desactivar rápidamente; o no existe un responsable del proceso que rinda cuentas.

Por qué una demostración convincente puede fallar en producción

El conjunto de pruebas solo contiene casos ideales

El agente no aprende nada sobre entradas incompletas, contradictorias o maliciosas.

Se evalúa la respuesta final, pero se ignora la traza

El uso inseguro o incorrecto de las herramientas queda oculto.

El mismo equipo construye y califica al agente

Los supuestos de la implementación se repiten en la evaluación.

Se excluye el costo de la revisión humana

El agente parece económico solo porque no se mide el tiempo que los empleados dedican a corregirlo.

El modelo cambia sin pruebas de regresión

Una actualización del proveedor o de la configuración cambia el comportamiento en escenarios que antes eran estables.

Los permisos de producción son más amplios que los de prueba

La evaluación no representa el riesgo real del despliegue.

Los criterios de falla se negocian después de la prueba

El equipo redefine el éxito para justificar la inversión ya realizada.

La decisión de producción en la práctica

Un agente está listo para producción cuando la organización tiene evidencia de que puede completar la tarea; elegir acciones válidas; mantenerse dentro de la política; manejar la incertidumbre; fallar de forma segura; conservar la trazabilidad; generar suficiente valor económico; y ser detenido y revertido.

Una demostración exitosa responde:

¿Puede funcionar el agente?

Una evaluación para producción responde:

¿En qué condiciones puede la empresa confiar en que actúe?

La consultoría en IA y automatización de procesos de Fill System incluye evaluación estructurada de agentes: diseño de pruebas, revisión de trazas, criterios de aceptación, planificación del despliegue y configuración del monitoreo en producción.

Solicite un diagnóstico gratuito para determinar si su agente de IA está listo para producción o qué evidencia todavía falta.