El riesgo de la IA agéntica es la posibilidad de daño o pérdida que surge cuando un sistema de IA puede tomar acciones hacia un objetivo con una dirección humana paso a paso limitada. El riesgo aumenta cuando un sistema puede usar herramientas, modificar datos, comunicarse con otros sistemas o delegar trabajo en otros agentes.

Un agente puede planificar una secuencia de pasos, llamar a herramientas de software, recuperar información o actuar en nombre de un usuario. Esto puede hacer que una tarea sea más eficiente, pero también amplía la autoridad del sistema. Una interpretación errónea que sería inofensiva en una respuesta de texto puede tener mayores consecuencias si el agente puede enviar un mensaje, alterar un registro, realizar una compra o iniciar otro proceso.

La delegación cambia el límite del riesgo

La delegación de agente a agente puede dificultar ver qué sistema tomó una decisión y qué instrucciones la moldearon. Cada transferencia puede cambiar el contexto, los permisos o el nivel de verificación. Una organización debe mapear la cadena de agentes y herramientas, limitar el acceso de cada actor a lo que necesita y mantener registros que permitan atribuir las acciones. También debe probar cómo se comporta la cadena cuando un agente recibe datos malos, un objetivo ambiguo o instrucciones hostiles.

Cuando varios agentes interactúan, su comportamiento combinado puede no ser predecible probando cada uno de forma aislada. Los agentes pueden repetir acciones, reforzar errores, competir por recursos compartidos o transmitir suposiciones erróneas. Esta emergencia multiagente es una preocupación a nivel de sistema: monitorear solo un modelo o una interfaz de usuario puede pasar por alto la actividad que ocurre en todo el flujo de trabajo conectado.

La supervisión debe funcionar a nivel de sistema

La supervisión humana solo es significativa si una persona puede comprender cuándo se necesita intervención y puede actuar antes de que el daño sea difícil de revertir. Los puntos de revisión deben reflejar el impacto y la reversibilidad de una acción. Los pasos de impacto bajo pueden automatizarse dentro de límites claros; las acciones consecuentes o externas pueden requerir confirmación, aprobación dual o un modo de operación restringido.

Un interruptor de apagado de emergencia (kill switch) debe diseñarse y probarse como parte del sistema, no dejarse como una promesa informal. Los equipos necesitan saber qué detiene el interruptor, si revoca los permisos de las herramientas y las tareas en cola, y cómo restaurar el servicio de manera segura. Un propietario designado debe poder pausar el agente, mientras que los respondedores a incidentes pueden preservar los registros e investigar qué sucedió.

Antes de la implementación, las organizaciones pueden comenzar con permisos limitados, pruebas en entornos de prueba y límites de acción explícitos. Durante el uso, deben monitorear no solo la calidad de las salida sino también las llamadas a herramientas, los patrones de delegación, los cambios en el alcance de las tareas y los intentos de exceder la autoridad. La revisión de riesgos debe repetirse cuando cambien el modelo, las herramientas, los permisos o el entorno operativo.