La reunión de aprobación de un agente suele girar en torno a la pregunta equivocada: ¿responde bien?
La respuesta casi siempre es sí, porque eso es lo que el equipo ajustó durante semanas. El agente resuelve la tarea, el tono está bien, los casos de prueba pasan.
La pregunta que importa es otra: ¿qué más puede hacer?
El software común hace lo que se escribió. Un agente hace lo que se le autorizó, en el orden que él elija. Por eso la prueba también tiene que cambiar.
Qué probar
Compara el alcance real con el alcance previsto
Toma cada credencial que carga el agente. Enumera todo lo que permite en la práctica, no lo que dice la documentación. La diferencia entre esas dos listas es tu superficie de riesgo.
Un token descrito como "lectura de pedidos" suele alcanzar también facturación, porque ambos viven en el mismo servicio.
Prueba secuencias, no llamadas aisladas
Probar endpoints uno por uno aprueba combinaciones peligrosas. Arma cadenas de tres a cinco llamadas, todas válidas por separado, y observa qué producen juntas. Ahí están los problemas que ningún escáner encuentra.
Trata todo dato de entrada como posible instrucción
Todo lo que entra en el contexto del agente puede llevar un comando. Vale para un ticket, un PDF, la respuesta de otra herramienta, un campo de nombre en la base. Prueba con entrada hostil desde cada una de esas fuentes, no solo desde el chat con el usuario.
Fuerza el límite
Los agentes fallan de formas creativas cuando algo sale del camino feliz. Revisa el tope de paginación, el bucle de reintentos y el costo por interacción. Mira también qué pasa cuando una herramienta devuelve error.
Intenta reconstruir cada decisión
Después de correr las pruebas anteriores, responde por qué el agente eligió cada acción. Si el log no permite reconstruir eso ahora, no va a ayudar en el incidente real.
Una pregunta separa una prueba útil de un teatro de aprobación. ¿Alguien aquí intentó hacer que el agente actúe contra su propio propósito? Si nadie lo intentó, el primero en hacerlo será alguien de afuera.
Quién debería hacer esta prueba
No debería ser el equipo que construyó el agente. Quien diseñó el camino feliz tiene un punto ciego para el camino hostil. Eso no es falta de competencia: probar la propia hipótesis es un ejercicio distinto de intentar romperla.
El trabajo es de seguridad de aplicaciones, y el método ya existe. Es el mismo razonamiento de un pentest de API. Cambia el consumidor: no un humano corriendo un script, sino un sistema que improvisa la siguiente llamada.
El criterio de aprobación
Un agente está listo cuando el equipo puede probar tres cosas. Que sabe todo lo que alcanza. Que probó las combinaciones que podría armar. Que tiene rastro para reconstruir cualquier decisión.
"Esto va a atrasar el lanzamiento" es la objeción más común, y no se sostiene. El primer punto lleva medio día y ya cambia la conversación. La mayoría de las veces, la lista de lo que permite la credencial es mucho más larga de lo que el equipo imaginaba.