Durante los primeros años de la IA generativa nos hemos acostumbrado a una interacción relativamente sencilla. Una persona formula una petición. El modelo procesa la información. El sistema genera una respuesta.
Puede redactar un documento, resumir información, analizar datos o proponer código. Pero, en términos generales, la acción posterior sigue dependiendo de una persona.
Los agentes de IA modifican esta relación. Un agente puede recibir un objetivo, decidir qué pasos necesita ejecutar, utilizar diferentes herramientas, consultar información, interactuar con sistemas corporativos y realizar acciones para intentar alcanzar ese objetivo.
La IA deja entonces de limitarse a decirnos qué podríamos hacer. Empieza a hacerlo. Y ese cambio tiene consecuencias importantes para la forma en la que diseñamos los sistemas.
De generar contenido a ejecutar acciones
Imaginemos un asistente de IA al que preguntamos por el estado de varios pedidos. El sistema consulta la información disponible y genera un resumen. La persona lo revisa y decide qué hacer.
Ahora imaginemos un agente. Recibe el objetivo de resolver los pedidos retrasados. Consulta el ERP, identifica las incidencias, revisa el inventario, solicita información a otro sistema, prioriza los casos, prepara comunicaciones para los clientes y actualiza determinados registros.
La diferencia no reside necesariamente en que el modelo sea más inteligente. La diferencia es que dispone de herramientas y permisos para intervenir en el entorno. Ese es uno de los elementos esenciales de los sistemas agénticos.
Un modelo puede razonar. Un agente combina esa capacidad con mecanismos que le permiten observar, decidir y actuar.
Un agente es más que un modelo
Hablar de agentes como si fueran simplemente una nueva generación de modelos puede llevar a diseñarlos incorrectamente. El modelo es solo una pieza.
Un sistema agéntico puede incluir memoria, herramientas, fuentes de datos, APIs, reglas, mecanismos de planificación, sistemas de identidad, permisos, validaciones y componentes de observabilidad. Puede además interactuar con otros agentes.
Por eso, su comportamiento no depende únicamente de la calidad del modelo, sino de todo el entorno de ejecución que construimos alrededor de él.
- ¿Qué información puede consultar?
- ¿Qué herramientas puede utilizar?
- ¿Qué acciones puede ejecutar?
- ¿Con qué credenciales?
- ¿Durante cuánto tiempo puede mantener un objetivo activo?
- ¿Cuándo debe detenerse?
- ¿En qué momento necesita autorización?
Estas preguntas son tan importantes como seleccionar el modelo que utilizará el agente.
La autonomía no es binaria
A veces hablamos de agentes como si solo existieran dos posibilidades: sistemas autónomos o sistemas controlados por personas. En realidad, existe un amplio espacio intermedio.
Un agente puede limitarse a recopilar información y proponer una acción. Puede preparar esa acción y esperar aprobación. Puede ejecutar automáticamente determinadas operaciones de bajo riesgo y solicitar autorización para otras. O puede actuar de manera autónoma dentro de unos límites claramente establecidos.
La autonomía puede diseñarse. Y debería hacerse en función del riesgo, la reversibilidad de las acciones y el contexto.
No es lo mismo permitir que un agente clasifique automáticamente documentos que autorizarle a realizar una transferencia, modificar una configuración crítica o enviar una comunicación externa en nombre de una organización.
La pregunta no es simplemente si puedes hacerlo, sino hasta dónde queremos permitirle hacerlo sin intervención.
Los permisos se convierten en una cuestión central
Cuando una IA únicamente genera texto, controlar qué información recibe ya es importante. Cuando además puede actuar sobre otros sistemas, la gestión de permisos se vuelve crítica.
Un agente no debería disponer automáticamente de todos los permisos del usuario o del sistema que lo ejecuta. Debería aplicar el mismo principio que utilizamos en otras áreas de seguridad: mínimo privilegio.
- Acceder únicamente a los datos que necesita.
- Utilizar únicamente las herramientas necesarias.
- Ejecutar únicamente las acciones autorizadas.
- Y hacerlo durante el tiempo necesario.
Esto implica integrar el diseño de agentes con sistemas de identidad y acceso, políticas corporativas y mecanismos de autorización.
La seguridad de un agente no debería depender únicamente de decirle mediante una instrucción qué cosas no debe hacer. Las restricciones importantes deben existir también fuera del modelo.
Las instrucciones no son controles de seguridad
Esta distinción resulta fundamental. Los modelos responden a instrucciones. Podemos indicarles que no realicen determinadas acciones, que soliciten confirmación o que sigan unas reglas concretas. Pero una instrucción no equivale necesariamente a un control técnico.
Un sistema robusto debe asumir que el modelo puede interpretar incorrectamente una petición, recibir información manipulada o producir una decisión inesperada. Por eso, determinadas restricciones deben implementarse en la arquitectura.
Si un agente no debe realizar operaciones superiores a una cantidad determinada, el sistema que ejecuta la operación puede aplicar ese límite independientemente de lo que solicite el modelo.
Si una acción requiere aprobación humana, la arquitectura puede impedir su ejecución hasta recibirla.
Si una herramienta solo debe utilizarse en determinadas circunstancias, los permisos pueden restringir su acceso.
La inteligencia puede ser probabilística. Los límites críticos no deberían serlo.
Cuando el dato también contiene instrucciones
Los agentes introducen además un reto particular. Para realizar su trabajo necesitan observar información externa: documentos, correos, páginas web, bases de datos, mensajes o resultados producidos por otras herramientas. Pero esa información puede contener instrucciones que el sistema interprete incorrectamente como parte de su objetivo.
Este tipo de problema, relacionado con técnicas como prompt injection, obliga a distinguir entre instrucciones confiables y datos que simplemente deben ser procesados. La diferencia es esencial.
Un correo recibido por un agente puede contener información que necesita analizar, pero no debería poder redefinir por sí mismo las reglas con las que opera.
Diseñar esa separación entre datos, instrucciones y permisos será una de las cuestiones fundamentales de seguridad en los sistemas agénticos.
Saber qué hizo el agente
La autonomía introduce también un requisito de trazabilidad más exigente. En un chatbot puede ser suficiente registrar una conversación. En un agente necesitamos comprender una secuencia.
- ¿Qué objetivo recibió?
- ¿Qué información consultó?
- ¿Qué decisiones intermedias tomó?
- ¿Qué herramientas utilizó?
- ¿Qué acciones intentó ejecutar?
- ¿Cuáles fueron autorizadas?
- ¿Cuáles fallaron?
- ¿Qué resultado produjo finalmente?
Esta información es necesaria para investigar errores, mejorar el sistema y determinar responsabilidades. También permite evaluar algo especialmente importante: no solo si el agente alcanzó el resultado esperado, sino cómo llegó hasta él.
Dos agentes pueden producir aparentemente el mismo resultado utilizando caminos muy diferentes. En sistemas empresariales, el camino también importa.
Diseñar para el fallo
Cualquier sistema puede fallar. Con los agentes, la cuestión adquiere una dimensión adicional porque un error puede propagarse a través de varias acciones.
Un dato incorrecto puede producir una decisión equivocada. Esa decisión puede activar una herramienta. La herramienta puede modificar otro sistema y esa modificación convertirse en la entrada de una acción posterior.
Por eso, el diseño debe considerar desde el principio qué ocurre cuando algo sale mal.
- ¿Puede detenerse el agente?
- ¿Podemos revertir una acción?
- ¿Existen límites de ejecución?
- ¿Puede detectar el sistema comportamientos anómalos?
- ¿Hay operaciones que necesitan siempre confirmación?
La capacidad de recuperación no debería añadirse después de comprobar que un agente funciona. Debe formar parte de su arquitectura.
De human in the loop a human on the loop
A medida que aumenta la autonomía, también cambia el papel de las personas. No siempre será eficiente exigir aprobación humana para cada acción.
En determinados entornos, el modelo adecuado puede ser diferente: permitir que el sistema actúe dentro de unos límites establecidos mientras una persona mantiene capacidad de observación e intervención.
Pasamos así de human in the loop a human on the loop.
La diferencia es relevante. El profesional deja de validar necesariamente cada paso y pasa a supervisar un sistema que dispone de un determinado espacio de autonomía.
Esto exige buenas interfaces, alertas adecuadas y una representación clara de lo que el agente está haciendo. La supervisión humana sigue existiendo. Pero evoluciona desde la ejecución hacia el control.
La verdadera pregunta sobre los agentes
Los agentes abren posibilidades muy importantes para automatizar procesos complejos. Pueden conectar conocimiento, razonamiento y acción de una forma que los sistemas anteriores difícilmente podían conseguir. Pero precisamente por eso necesitan una arquitectura diferente.
Cuanto más puede hacer un sistema, más importante resulta determinar qué puede consultar, qué puede decidir y qué puede ejecutar. No se trata de reducir su capacidad. Se trata de hacer que esa capacidad sea utilizable.
Porque el verdadero desafío de los agentes de IA no será conseguir que sean capaces de actuar.
Será conseguir que puedan hacerlo con autonomía suficiente para aportar valor y con límites suficientes para mantener el control.