Respuesta breve
Empiece con un agente de IA con acceso de solo lectura y cuenta propia, y añada después un permiso cada vez. Clasifique sus acciones en tres clases: leer y redactar borradores sin aprobación, cambios internos reversibles con revisión y acciones irreversibles o externas aprobadas una a una por una persona designada. Aplique las reglas en los propios sistemas, limite el volumen y el gasto, mantenga un registro que el agente no pueda editar y pruebe el procedimiento de parada antes del lanzamiento.
Un error cuesta lo que los permisos autorizan
Un agente de IA es un programa al que se le permite hacer cosas: leer un buzón, actualizar un registro, enviar un mensaje, emitir un reembolso. El modelo que lleva dentro se equivocará a veces, y otras veces lo confundirá un texto que lea por el camino. Ninguna de las dos cosas puede descartarse con una redacción mejor. Lo que sí puede decidirse de antemano es hasta dónde puede llegar un paso en falso.
El proyecto OWASP Gen AI Security Project llama a este riesgo Excessive Agency, agencia excesiva: acciones dañinas ejecutadas en respuesta a salidas inesperadas, ambiguas o manipuladas de un modelo de lenguaje. Sitúa la causa raíz en una o varias de tres cosas: funcionalidad excesiva, permisos excesivos y autonomía excesiva. Las tres son decisiones de quien configura el agente.
Por eso conviene tratar los permisos de un agente de IA como algo que se gana. El agente empieza casi sin ninguno, demuestra durante un periodo de trabajo registrado que una clase de acción es segura en sus manos y solo entonces recibe el siguiente.
Enumere las acciones antes de conectar las herramientas
Escriba la tarea como una secuencia de pasos y, en cada uno, anote qué debe leer el agente y qué debe cambiar. La lista suele ser más corta que el catálogo de funciones de la herramienta. El ejemplo de OWASP es un asistente de correo que resume los mensajes entrantes: necesita leerlos, de modo que la extensión que utilice no debería poder además borrarlos ni enviarlos.
Después elimine lo que la lista no justifique. Las primeras recomendaciones de OWASP son reducir al mínimo las extensiones que un agente puede invocar, reducir al mínimo las funciones de cada una y evitar las herramientas abiertas, como ejecutar un comando de shell o descargar cualquier URL, en favor de otras acotadas. Una herramienta probada durante el desarrollo y abandonada después debe desconectarse, no simplemente ignorarse.
Aplique la misma contención a los datos. En la ilustración de OWASP, un agente que recomienda productos solo necesita acceso de lectura a la tabla de productos, sin capacidad para insertar, actualizar o borrar registros ni para ver otras tablas. En una empresa pequeña, el equivalente es una carpeta compartida o un embudo del CRM, no la cuenta entera.
El modo de solo lectura va primero y dura semanas
Durante el primer periodo el agente lee, busca y redacta borradores, y una persona ejecuta cada acción. La guía de OpenAI para construir agentes distingue las herramientas de datos, que recuperan información, de las herramientas de acción, que cambian algo en otro sistema. Empiece solo con las primeras. La salida del agente es una propuesta: una respuesta redactada, una actualización sugerida, una lista de facturas que parecen erróneas.
Esta etapa no es tiempo perdido. Muestra con qué frecuencia se aceptan los borradores sin cambios, en qué tipos de caso se equivoca el agente y si sus errores son pequeños o extraños. La misma guía califica la intervención humana de especialmente importante al principio del despliegue, porque ayuda a identificar fallos y a descubrir casos límite.
Decida la regla de promoción antes de empezar, para que la impaciencia no pueda torcerla después. Por ejemplo: una categoría de acción pasa a ser automática solo tras un número acordado de borradores consecutivos aprobados sin correcciones, y vuelve a manual después de cualquier error grave. Las cifras las fija usted; lo importante es que queden escritas primero.
Quién aprueba qué: tres clases de acción
Asigne cada acción de la lista a una de tres clases. La primera es leer, buscar y redactar borradores: sin aprobación, pero con registro. La segunda es un cambio dentro de sus propios sistemas que puede deshacerse, como etiquetar una incidencia, rellenar un campo que conserva su historial o guardar un borrador. El responsable del proceso puede aprobar estas acciones por lotes o revisarlas por muestreo.
La tercera clase es todo lo irreversible, externo o financiero: enviar un mensaje a un cliente, publicar, borrar, pagar, reembolsar, cambiar derechos de acceso. OWASP recomienda un control con intervención humana (human-in-the-loop), de modo que una persona apruebe las acciones de alto impacto antes de que se ejecuten. La guía de OpenAI dice que las acciones sensibles, irreversibles o de alto riesgo deben activar la supervisión humana hasta que crezca la confianza en la fiabilidad del agente, y pone como ejemplos cancelar pedidos, autorizar reembolsos elevados y realizar pagos.
Nombre al aprobador por su función y nombre a un suplente, porque una cola de aprobaciones sin nadie al otro lado se convierte en un motivo para desactivar el control. Muestre al aprobador la acción exacta, los datos en que se apoya y lo que ocurrirá después, no un resumen que el agente haya escrito sobre sí mismo.
La regla vive en el sistema, no en el prompt
Una instrucción como «nunca borres registros» es una petición al modelo. No es un control, porque el modelo es precisamente la pieza que puede fallar. El consejo de OWASP es la mediación completa: implante la autorización en los sistemas de destino y no confíe en que un modelo de lenguaje decida si una acción está permitida.
En la práctica, el agente recibe una cuenta propia, no el usuario de un empleado y nunca una clave de administrador, con el rol más restringido que ofrezca el sistema. Cuando el agente actúa en nombre de un usuario concreto, OWASP recomienda ejecutar en el contexto de ese usuario con los privilegios mínimos necesarios, por ejemplo mediante una autorización OAuth con el alcance mínimo requerido.
El paso de aprobación debe estar en el mismo lugar. Si los reembolsos por encima de un umbral necesitan una segunda firma en el sistema de pagos, el agente se encuentra con esa regla igual que un empleado. La guía de OpenAI añade que las barreras de protección deben ir acompañadas de autenticación y autorización sólidas, controles de acceso estrictos y medidas habituales de seguridad del software.
Límites de volumen, gasto y alcance
Un límite convierte un fallo sin tope en un fallo acotado. OWASP señala que la limitación de frecuencia reduce el número de acciones indeseadas que pueden producirse en un periodo dado y aumenta la posibilidad de descubrirlas mediante la monitorización antes de que el daño sea importante. Un correo equivocado es una disculpa; mil son un incidente.
Fije los límites donde el agente no pueda cambiarlos: un máximo de acciones por ejecución y por día, un máximo de destinatarios, una lista de carpetas, dominios o tipos de registro permitidos. La guía de Anthropic sobre la construcción de agentes menciona las condiciones de parada, como un número máximo de iteraciones, como una forma habitual de mantener el control.
El coste también necesita un techo. Anthropic observa que la naturaleza autónoma de los agentes implica costes más altos y la posibilidad de errores que se acumulan. Si la cuenta del proveedor del modelo ofrece un límite de gasto o una alerta, fíjelo por debajo de la cifra que le dolería. La guía de OpenAI añade un límite de comportamiento: ponga tope a los reintentos del agente y pase el caso a una persona cuando se alcance.
Un registro que alguien lee de verdad
Registre cada llamada a una herramienta: la hora, la tarea, la herramienta, su entrada, el resultado y quién la aprobó. Guarde el registro donde el agente no tenga permiso para editarlo. OWASP es franco sobre lo que se consigue: el registro y la monitorización no evitan la agencia excesiva, pero limitan el daño al mostrar dónde se están produciendo acciones indeseadas.
Un registro no protege a nadie hasta que una persona lo mira. Encargue a un responsable designado una revisión semanal con tres preguntas: qué hizo el agente que nos sorprendió, qué rechazaron los aprobadores y por qué, y qué límites se alcanzaron. Las respuestas deciden si un permiso se amplía, se mantiene o se retira.
El marco de gestión de riesgos de IA del NIST («AI Risk Management Framework»), un documento voluntario, expresa las mismas expectativas en forma de resultados. Una de sus subcategorías pide que el comportamiento de un sistema de IA se supervise en producción. Otra pide que los incidentes y errores se comuniquen a las personas pertinentes, incluidas las comunidades afectadas, y que los procesos de seguimiento, respuesta y recuperación se cumplan y se documenten.
El camino de vuelta se escribe antes del lanzamiento
El mismo marco pide mecanismos, con responsabilidades asignadas y comprendidas, para sustituir, desconectar o desactivar un sistema de IA cuyo rendimiento o cuyos resultados no se correspondan con su uso previsto. Para un equipo pequeño eso es una frase: quién puede apagar el agente y cómo. Debe ser algo que esa persona pueda hacer sola, como desactivar la integración o revocar las credenciales del agente, sin esperar a un desarrollador.
Después escriba cómo se deshace cada acción reversible. Un registro modificado se restaura desde su historial, un archivo movido vuelve desde la carpeta anterior, un borrador simplemente se descarta. Haga una copia de seguridad o una exportación antes de cualquier operación masiva. Si una acción no tiene forma de deshacerse, estaba mal clasificada: pertenece a la tercera clase y espera aprobación.
Ensáyelo una vez con datos copiados. Detenga el agente en mitad de una ejecución, restaure un cambio y cronometre ambas cosas. Decida también quién avisa a los clientes si les llegó algo que no debía. El momento de encontrar las lagunas de un plan es antes del primer uso real.
Una página que cerrar antes del primer uso real
Antes del lanzamiento, reúna las decisiones en una sola página. Indique la finalidad del agente y las tareas que no debe intentar. Enumere sus acciones por clase, con el aprobador y el suplente de cada una. Anote qué cuenta utiliza, con qué rol y cuándo caducan sus credenciales. Añada los límites, dónde se guarda el registro, quién lo revisa, el procedimiento de parada y la fecha del ensayo.
Pruebe primero contra esa página en un entorno aislado, con copias de datos reales. Anthropic recomienda pruebas exhaustivas en entornos aislados (sandbox) junto con las barreras de protección adecuadas. Incluya casos hostiles: un documento que contiene instrucciones dirigidas al agente, una petición ajena a su finalidad, una herramienta que devuelve un error. Anote lo que hizo, no lo que dijo que haría.
El marco del NIST pide que las funciones, las responsabilidades y las líneas de comunicación estén documentadas y sean claras, y que los procesos de supervisión humana estén definidos, evaluados y documentados. El NIST describe el marco como un documento vivo, así que consulte en su sitio la versión vigente. Ponga también una fecha de revisión a su propia página. Los permisos de un agente de IA se añaden de uno en uno, y cada uno debería seguir teniendo un responsable dentro de un año.
Lista práctica
- Enumere todas las acciones que el agente podría ejecutar y desconecte las herramientas y funciones que la tarea no necesita.
- Dé al agente una cuenta propia con acceso de solo lectura al principio y añada un permiso cada vez.
- Nombre a la persona que aprueba cada acción irreversible, externa o financiera, y a un suplente para sus ausencias.
- Fije límites de acciones por ejecución, destinatarios y gasto diario en los propios sistemas, no en el prompt.
- Ensaye el procedimiento de parada y una reversión con datos copiados antes de que el agente toque trabajo real.
Preguntas frecuentes
¿Qué significa el mínimo privilegio para un agente de IA?
Significa que el agente solo tiene las herramientas, las funciones y el acceso a datos que exige su tarea definida, y nada que sea simplemente cómodo. Los ejemplos de OWASP son concretos: un asistente que resume el correo debe poder leer mensajes, pero no enviarlos ni borrarlos, y una extensión que lee una base de datos debe conectarse con una identidad limitada a la lectura. La prueba es si cada permiso puede vincularse a un paso de la tarea.
¿Qué acciones de un agente de IA deben requerir siempre aprobación humana?
Las que no pueden deshacerse, las que salen de su organización y las que mueven dinero o accesos: enviar a clientes, publicar, borrar, pagar, reembolsar y cambiar permisos. La guía de OpenAI cita como ejemplos las cancelaciones de pedidos, los reembolsos elevados y los pagos; OWASP añade publicar en redes sociales en nombre de un usuario. Más adelante la aprobación puede relajarse para una categoría estrecha, pero solo mediante una decisión que quede registrada.
¿Basta una instrucción en el prompt para impedir que un agente haga algo?
No. Un prompt orienta al modelo, y el modelo es el componente que puede confundirse o ser manipulado. OWASP recomienda aplicar la autorización en los sistemas a los que se conecta el agente, de modo que una petición prohibida se rechace allí decida lo que decida el modelo. Use el prompt para explicar el trabajo, y use roles, alcances y reglas de aprobación en los sistemas de destino para fijar los límites.
¿Cuándo es seguro dar más permisos a un agente?
Cuando hay pruebas y un camino de vuelta. Las pruebas son un periodo registrado en el que los borradores del agente para esa categoría se revisaron y aceptaron según un umbral fijado de antemano. El camino de vuelta significa que usted sabe cómo deshacer ese tipo de acción y cómo retirar el permiso. Añada un permiso cada vez, para que un problema nuevo pueda atribuirse a un único cambio.
¿Necesita una pequeña empresa un marco formal para gestionar un agente de IA?
No un programa formal. El documento del NIST sobre gestión de riesgos de IA es voluntario y está escrito para organizaciones de todos los tamaños, y sus preguntas se adaptan bien a escala reducida: quién es responsable, cómo se define la supervisión humana, cómo se vigila el sistema y cómo se apaga. Una sola página que las responda, mantenida al día, hace el trabajo esencial para un equipo pequeño.