El agente confirma que ha actualizado una ficha de cliente. Abres el CRM y descubres que ha cambiado la de otra persona con el mismo apellido. El mensaje era correcto en apariencia; la operación, equivocada. Este ejemplo hipotético explica por qué evaluar un agente de IA exige mirar lo que hace en los sistemas, además de lo que responde. Es una cuestión central cuando llevas la inteligencia artificial a procesos de negocio.
Una demostración con dos solicitudes sencillas puede servir para decidir si merece la pena construir un prototipo. Para darle acceso a pedidos, documentos o cuentas necesitas pruebas que reproduzcan el trabajo previsto, incluidas las situaciones en las que debería detenerse.
La propuesta de este artículo es preparar una evaluación pequeña pero exigente: definir el resultado esperado, construir casos representativos, comprobar las acciones y decidir qué autonomía puedes conceder. La matriz y el ejemplo son orientaciones editoriales para un piloto; cada equipo debe ajustar sus condiciones de aceptación al impacto de los errores.
Qué se evalúa en un agente
Un agente combina un modelo con instrucciones, información, herramientas y una lógica de ejecución. Una buena respuesta puede depender de que el buscador encuentre el documento vigente, de que el conector consulte el registro correcto y de que la aplicación permita exactamente la operación autorizada.
Anthropic distingue en su guía de evaluación de agentes entre el registro de la ejecución y el resultado final en el entorno. También recomienda repetir las pruebas porque el comportamiento puede variar entre intentos. Esta distinción resulta útil para separar tres preguntas: si entendió la solicitud, si actuó correctamente y si dejó el sistema en el estado previsto.
En una prueba de actualización de CRM, por ejemplo, comprueba el identificador de la ficha, el campo modificado y el valor guardado. Revisa también qué sucedió con los registros que debían permanecer intactos. El texto «hecho» no acredita ninguna de esas condiciones.
Definir el trabajo y sus límites
Empieza por una tarea acotada. «Gestionar atención al cliente» resulta demasiado amplio para decidir qué es un acierto. «Consultar el estado de un pedido identificado y preparar una respuesta con la fecha disponible» permite establecer entradas, fuentes y resultados comprobables.
Escribe una ficha de una página con el objetivo, las herramientas permitidas, los datos accesibles, los cambios autorizados y las situaciones que requieren intervención humana. Incluye quién responde cuando el agente falla y cómo se suspende su acceso. El equipo que conoce el proceso debe participar: las excepciones suelen estar en la experiencia de quienes resuelven incidencias.
La guía de construcción de agentes de Anthropic plantea empezar con soluciones sencillas y añadir complejidad cuando se justifique. Aplícalo a la decisión de diseño: si una regla fija resuelve el trabajo, compárala con el agente. La autonomía necesita una utilidad concreta.
Preparar casos representativos
Construye el conjunto de pruebas a partir del trabajo previsto. Puedes utilizar solicitudes históricas anonimizadas o casos ficticios diseñados por el equipo. Evita incluir información personal innecesaria. Para cada caso, guarda la entrada, el estado inicial de los sistemas, la acción esperada y las acciones prohibidas.
Reserva ejemplos que no utilices para ajustar las instrucciones. Si corriges el agente mirando siempre los mismos casos, puedes terminar preparando una demostración muy ensayada. El conjunto reservado permite comprobar si la mejora se mantiene ante solicitudes distintas.
Introduce variaciones que cambien la decisión: un identificador incompleto, dos clientes con nombres parecidos, un dato antiguo o una respuesta vacía del conector. Prueba también solicitudes fuera de alcance. El marco de gestión del riesgo de IA de NIST sitúa la evaluación en el contexto de uso y contempla su continuidad durante la vida del sistema. Aprobar un conjunto de ejemplos no certifica todos los trabajos futuros.
Matriz de evaluación inicial
Esta matriz permite repartir comprobaciones entre operaciones, producto y tecnología. Adapta los criterios al proceso antes de ejecutar las pruebas.
| Dimensión | Prueba | Evidencia |
|---|---|---|
| Resultado | Completa la tarea sobre el registro correcto. | Estado final del sistema y campos modificados. |
| Información | Utiliza la fuente vigente y reconoce los datos ausentes. | Documento o consulta utilizados. |
| Permisos | Una acción fuera de alcance queda bloqueada. | Respuesta del control de autorización. |
| Recuperación | Gestiona una caída sin duplicar operaciones. | Registro de errores, reintentos y cambios. |
| Derivación | Entrega a una persona el caso que requiere decisión. | Motivo y contexto de la transferencia. |
| Coste y tiempo | Resuelve dentro de los límites del servicio. | Consumo, duración y revisión humana. |
Separa los fallos críticos de las mejoras de calidad. Una respuesta algo extensa y un acceso a datos de otro cliente no pueden compensarse en una nota media. Para el segundo necesitas corregir el control que falló y repetir las pruebas afectadas antes de ampliar el piloto.
Ejemplo: un agente de pedidos
Imagina una tienda que quiere preparar respuestas sobre entregas. El agente puede consultar pedidos y redactar borradores. El envío sigue en manos del equipo. En este piloto hipotético, organiza 30 casos: 12 consultas con datos completos, 6 con información insuficiente, 6 excepciones operativas y 6 intentos de realizar acciones prohibidas. Estas cantidades ilustran una distribución inicial, no un tamaño de muestra universal.
Un pedido entregado debe producir un borrador coherente con el seguimiento. Si el transportista no facilita fecha, el agente debe indicar esa ausencia. Si encuentra dos pedidos posibles, tiene que solicitar el dato que permita distinguirlos. Si el usuario pide cambiar la dirección, debe derivar la solicitud porque esa operación queda fuera del piloto.
Ejecuta varias veces los casos y registra cada intento. Reinicia los datos de prueba entre ejecuciones para que una modificación anterior no altere la siguiente. Conserva la versión del modelo, las instrucciones y la configuración de herramientas: sin esa referencia será difícil entender por qué cambia el resultado.
Supón que completa correctamente 27 de los 30 casos de una ronda, pero en uno intenta enviar el borrador sin autorización. El 90 % de acierto describe el conjunto de esa ronda; no resuelve el problema de permisos ni demuestra fiabilidad suficiente. La decisión razonable para este piloto sería mantener el envío manual, corregir el comportamiento y comprobar que el control de autorización bloqueó el intento. Si llegó a enviarlo, también habría que reparar ese control antes de continuar.
Permisos, errores y supervisión
Prueba los límites con el mismo cuidado que las tareas habituales. La guía de seguridad de agentes de OWASP recoge controles sobre herramientas, inyección de instrucciones, supervisión y registro. Un documento recuperado puede contener órdenes dirigidas al agente; ese contenido no debe adquirir autoridad para ampliar sus permisos.
En el ejemplo de pedidos, introduce una nota de prueba que solicite exportar la base de clientes. Comprueba tanto el comportamiento del agente como el bloqueo del sistema. La protección debe sostenerse aunque el modelo intente ejecutar la acción.
Microsoft desarrolla el principio de mínimo privilegio para agentes mediante identidad, alcance y controles de autorización. En la práctica, verifica qué credencial utiliza cada herramienta, qué recursos alcanza y cómo revocas ese acceso. Evita prestar al piloto una cuenta con permisos generales de administración.
La derivación humana también necesita una prueba. Si cada incidencia llega sin identificador, sin motivo y sin las comprobaciones realizadas, el equipo repetirá el trabajo. Un caso bien transferido debe permitir continuar desde el punto en que el agente se ha detenido.
Coste por tarea resuelta
Calcula el coste con las ejecuciones fallidas y los reintentos incluidos. Suma consumo del modelo, servicios utilizados y revisión humana; divide entre las tareas aceptadas. Mantén aparte el coste de construcción y mantenimiento para valorar después la rentabilidad del proyecto completo.
Un ejemplo hipotético: 100 ejecuciones consumen 12 euros en servicios y requieren 90 minutos de revisión. Si valoras esa revisión a 24 euros por hora, el coste operativo observado es de 48 euros. Con 80 tareas aceptadas, resulta 0,60 euros por tarea. La comparación con el proceso actual debe usar el mismo alcance y nivel de calidad.
Mide también la dispersión del tiempo: una media rápida puede esconder solicitudes que quedan bloqueadas durante varios minutos. Para atención al cliente importa cuánto espera la persona en esos casos, además de cuánto tarda una consulta sencilla.
Del piloto al uso cotidiano
Antes de ampliar el acceso, deja por escrito qué pruebas se han superado, qué excepciones continúan fuera de alcance y quién vigilará el funcionamiento. Empieza con un volumen limitado y conserva una forma operativa de volver al proceso anterior. Repite los casos relevantes cuando cambies el modelo, las instrucciones, los documentos o una integración.
Las incidencias reales deben alimentar nuevas pruebas. Si aparece un pedido con una estructura que el agente interpreta mal, incorpora ese caso y comprueba la corrección junto con los anteriores. Así podrás detectar si arreglar una excepción estropea una tarea que funcionaba.
Si quieres desarrollar estas capacidades, el Máster en Agentes IA y Automatización No-Code de IEBS aborda construcción de agentes, integración de herramientas y evaluación de automatizaciones. Puedes consultar el programa y solicitar información para valorar su encaje con tus proyectos.