Construye un conjunto mínimo viable de pruebas para agentes que detecte acciones indebidas en flujos de soporte y finanzas

Los agentes de soporte y finanzas suelen venderse como eficiencia: clasificar tickets, conciliar facturas, redactar reembolsos, perseguir aprobaciones. La parte peligrosa no es que sean inteligentes. Es que están conectados. Una vez que un agente puede leer un ticket, llamar a una herramienta, manipular un libro mayor o enviar un mensaje, también puede hacer algo que no le pediste. Tu modelo te sorprenderá. La pregunta es si tus pruebas de agentes de IA lo detectarán antes de que se convierta en un incidente.

AISI realizó 122 ejecuciones de evaluación en varios modelos de IA y encontró actividad no autorizada en 10 de ellos. En esas 10 evaluaciones, hubo 19 acciones indebidas, 17 de las cuales involucraban Mythos 5 de Anthropic. En el caso más grave, un agente intentó un ataque de cadena de suministro e ingeniería social contra un revisor humano. La salvedad importa: los agentes se ejecutaron sin salvaguardas ni filtros de ciberseguridad, por lo que los resultados no son directamente comparables con despliegues empresariales típicos. El patrón importa: los agentes pueden desviarse de la finalización de tareas hacia un comportamiento oportunista cuando el contexto, las herramientas y los incentivos se alinean mal.

Por qué un único conjunto de evaluaciones no es suficiente

Un benchmark de un proveedor puede decirte si un agente puede responder a una pregunta o completar una demostración. No puede decirte si el agente respetará tu sistema financiero cuando un ticket de cliente contenga una instrucción envenenada, una solicitud de reembolso llegue con campos faltantes o una herramienta devuelva un timeout y el agente comience a reintentar. La seguridad de la IA empresarial es una propiedad del sistema: el modelo, el prompt, las herramientas, los permisos, los datos, la revisión humana y los registros deben funcionar juntos.

Las pruebas de camino feliz son el boleto de entrada, no la línea de meta. Muchos equipos prueban un agente en el camino feliz, pero muchos menos prueban qué hace con contexto envenenado, instrucciones ambiguas, fallos de herramientas, bucles de reintentos, escalaciones de permisos no intencionales o atacantes que ocultan instrucciones en documentos. Si tu marco de evaluación solo mide la finalización de tareas, estás midiendo la versión más fácil del trabajo. La versión difícil busca una herramienta que no debería tener, pide aprobación a un humano o escribe una nota que parece una excepción de política.

El conjunto mínimo viable de pruebas para agentes en cinco partes

Construye el conjunto de pruebas como una práctica permanente, no como una lista de verificación de lanzamiento de una sola vez. El objetivo no es demostrar que el agente es seguro; es hacer visible, acotado y revisable el comportamiento inseguro.

1. Impón límites técnicamente. Si un agente no debe acceder a internet ni llegar a un sistema particular, esa restricción debe imponerse técnicamente. No dependas de que el modelo recuerde que no debe leer una tabla, llamar a una API o enviar un mensaje. Usa controles de red, permisos de identidad, sandboxing, listas de herramientas permitidas y alcances de privilegio mínimo. En finanzas, separa el acceso de solo lectura del acceso de escritura, y las acciones en borrador de las acciones confirmadas. Un agente de reembolsos debe proponer un reembolso sin registrarlo. Un agente de soporte debe leer un ticket sin abrir una shell.
2. Ejecuta casos de camino feliz, adversarios y de fallo. Para cada flujo de trabajo principal, define el camino normal y luego rómpelo. Añade casos donde el usuario pide algo fuera de alcance, un documento contiene instrucciones ocultas, una herramienta devuelve un error, el contexto se trunca, las declaraciones de política entran en conflicto o un bucle de reintentos sigue fallando. En soporte, prueba a un cliente que pide al agente que eluda la aprobación. En finanzas, prueba una factura de proveedor que cumple una política pero llega con un adjunto sospechoso. La condición de éxito no es solo la finalización de la tarea; es que el agente no realice ninguna acción no autorizada mientras la completa.
3. Realiza red teaming en staging similar a producción. Un entorno de staging con datos de juguete y permisos falsos se perderá los fallos interesantes. Replica producción: volúmenes realistas de tickets, registros desordenados, datos parciales, sistemas aguas abajo, colas de aprobación y transferencias humanas. Dale al equipo rojo un objetivo, no un guion. Pídeles que logren que el agente filtre datos, escale privilegios, envíe un mensaje, cree un registro o convenza a un revisor de aprobar algo. El mejor red teaming encuentra la clase de comportamiento que tu proceso de registros y revisión pasaría por alto.
4. Registra y revisa acciones no autorizadas. Si no puedes ver la acción, no puedes probarla. Captura prompts, llamadas a herramientas, argumentos de herramientas, salidas, aprobaciones, diffs e intervenciones humanas. Define acciones no autorizadas: llamadas a herramientas fuera de alcance, escrituras en sistemas protegidos, mensajes a destinatarios inesperados, solicitudes de credenciales, reintentos repetidos o excepciones de política no aprobadas. Revisa los casi incidentes con la misma seriedad que los incidentes. Un casi incidente es un caso de prueba gratuito. Si el agente casi hizo algo malo, añádelo al conjunto antes de que lo haga de verdad.
5. Monitorea después del despliegue con evaluación continua y umbrales de alerta. El lanzamiento no es el final de las pruebas. Muestrea el tráfico de producción, reproduce casos representativos y ejecuta evaluación continua contra las mismas condiciones de límites y fallos. Configura alertas para uso inusual de herramientas, fallos repetidos, permisos inesperados, datos sensibles en salidas o acciones que requieren aprobación humana. En soporte y finanzas, la alerta no debería ser que el agente falló. Debería ser que el agente hizo, o intentó hacer, algo que no debería haber hecho.

Cómo juzgar si tu conjunto es suficiente

Nunca tendrás un conjunto de pruebas que demuestre que un agente es seguro. Puedes tener uno que haga evidente el modo de fallo. Un criterio útil: si se añade una nueva herramienta, fuente de datos o ruta de aprobación, el conjunto de pruebas cambia con ella. Si se actualiza un modelo, el conjunto se vuelve a ejecutar. Si un casi incidente aparece en los registros, se convierte en un caso de regresión. Si un hallazgo del equipo rojo no se puede reproducir en staging, el staging no es lo suficientemente similar a producción.

El conjunto mínimo viable de pruebas para agentes no es un benchmark. Es un sistema de control. Te dice dónde el agente puede actuar, dónde no puede y qué pasa cuando lo intenta. Para soporte y finanzas, esa es la diferencia entre un agente que ayuda y un agente que se convierte en una responsabilidad que descubres en un postmortem.