Autorización de agentes de IA: qué puede tocar un agente en tu empresa y quién lo aprueba

TL;DR: Un agente de IA solo debería poder hacer lo que le permiten sus credenciales y el código de sus herramientas, nunca lo que el prompt le prohíbe. Dale a cada agente su propia identidad con los permisos justos, deja que una persona apruebe lo que cuesta deshacer y registra cada acción con sus argumentos y quién la aprobó.

---

Qué es la autorización de un agente de IA

Autorizar a un agente de IA es decidir, fuera del modelo, qué herramientas puede usar, sobre qué datos y con qué límites. La autenticación responde a quién es el agente. La autorización, a qué tiene permitido hacer.

Cuando montamos un agente que atiende tickets o consulta pedidos, el modelo de lenguaje elige en cada momento qué herramienta usar: buscar un pedido, cambiar una dirección, contestar al cliente. Lo que no debe elegir es si tiene permiso para hacerlo. Eso lo decide el código que envuelve cada herramienta y la credencial con la que entra en tu ERP, en tu tienda o en tu correo.

OWASP, la fundación que mantiene las listas de riesgos de seguridad más usadas del sector, dedica un apartado entero a esto en su lista para aplicaciones con modelos de lenguaje: LLM06:2025 Excessive Agency. Lo divide en funciones de más, permisos de más y autonomía de más. Casi todo lo que hemos visto torcerse en proyectos reales cabe en alguno de esos tres cajones.

¿Por qué no basta con escribir en el prompt lo que el agente no puede hacer?

Porque el modelo lee mucho más texto que tus instrucciones: el correo del cliente, el PDF adjunto, la descripción de producto que manda el proveedor. Cualquiera de esos textos puede traer instrucciones escondidas y el modelo no siempre distingue las tuyas de las ajenas. Es la inyección de prompt.

Simon Willison, uno de los desarrolladores que más ha escrito sobre el tema, bautizó el caso peligroso como la trifecta letal: acceso a datos privados, exposición a contenido que no controlas y capacidad de comunicarse hacia fuera. Un agente que contesta emails de clientes tiene las tres por definición, así que el control tiene que estar en otro sitio.

En uno de los bots de ecommerce que mantenemos, un usuario intentó que el bot le redactara textos ajenos a la tienda, primero por las buenas y luego con amenazas. Reforzamos el prompt, pero lo que de verdad nos dejaba tranquilos era que ese bot solo tenía una herramienta: consultar un pedido con email y número. Aunque lo hubieran convencido, no había nada dañino a su alcance.

En AgentDesk, nuestra plataforma de atención al cliente, el prompt se puede editar desde el panel. Las reglas que no deben desaparecer con una edición viven en el código.

¿Qué puede tocar un agente? Clasifica las acciones por lo que cuesta deshacerlas

Repartimos permisos según lo que cuesta deshacer cada acción. La confianza que el modelo dice tener en su respuesta sirve para decidir si una conversación se escala, pero como control de permisos es floja: un modelo puede estar muy seguro y equivocarse.

¿Cómo se limitan los permisos en la práctica?

Una identidad por agente, con lo justo

Cada agente debería entrar en tus sistemas con su propia credencial, y esa credencial debería poder hacer lo mínimo. Si el código falla, que sea el sistema de destino el que diga que no. El buscador que montamos para Boticasur lee el catálogo de la base de datos de producción de su PrestaShop con un usuario dedicado que solo tiene permiso de lectura. En Navarro Hermanos, el buscador lee del ERP y nunca escribe en sus tablas.

Fuera de las bases de datos pasa lo mismo con otros nombres:

• En Shopify, los permisos de cada app se reparten por ámbitos (scopes), y su documentación sobre scopes recuerda que un permiso de escritura incluye el de lectura. Pedir write_orders para consultar pedidos ya es pedir de más.
• Un permiso de aplicación como Mail.Send en Microsoft 365 permite enviar como cualquier buzón de la organización. Exchange Online deja acotarlo a buzones concretos con RBAC para aplicaciones, con un matiz que explica esa misma página: si mantienes también el permiso general en Entra ID, los dos se suman y el acotado no sirve de nada.

Conviene blindar especialmente quién es el cliente. En el agente de Boticasur, el identificador del cliente sale de su sesión iniciada y el modelo nunca lo recibe como argumento, así que no puede aceptar el que alguien le dicte en el chat.

Herramientas estrechas mejor que herramientas genéricas

Una herramienta ejecutar_sql es cómoda de programar y un problema desde el primer día. Preferimos herramientas con nombre y apellidos, como buscar_pedido(email, numero), que llevan dentro sus propias comprobaciones.

En AgentDesk, que tenemos en producción en una empresa de retail, la herramienta de cancelar pedidos no se fía del modelo. Antes de tocar nada comprueba que el pedido siga en preparación y que la tienda de origen admita cancelaciones automáticas. Si es una tarjeta regalo, pasa el caso a una persona. Y a cada ticket solo le llegan las herramientas permitidas para su categoría, más dos que están siempre: reclasificar el ticket y escalarlo a una persona. El agente siempre tiene una salida, y cada ejecución tiene un tope de cinco vueltas para que no se quede dando tumbos.

¿Cuándo tiene que aprobar una persona antes de que el agente actúe?

Modo sombra antes de dar autonomía

En AgentDesk cada categoría de ticket puede estar apagada, en sombra o en autónomo. En sombra, las lecturas son reales y las escrituras se simulan y se guardan como propuestas. Después, un evaluador compara cada propuesta con la primera respuesta que dio una persona a ese ticket y la marca como equivalente, parcial o divergente. Las divergentes se leen a mano antes de encender nada.

Montarlo nos dejó dos lecciones. La primera: si no tienes en cuenta el tiempo, el informe miente. El agente decía «tu pedido está en tránsito» el lunes y la persona contestaba «ya está entregado» el jueves; el paquete había avanzado, nadie se había equivocado. Desde entonces solo se comparan respuestas separadas por menos de 12 horas. La segunda: las categorías que ejecutan acciones no se pueden medir así. Como la simulación devuelve «hecho», el agente escribe «he cancelado tu pedido», la persona le contradice y aparece una divergencia que es culpa del simulacro.

Una cola de aprobación cuando hay dinero de por medio

Para Electrotodo montamos AgentPrice, que compara sus precios con los de la competencia y sugiere uno nuevo dentro de una horquilla sobre el coste. Funciona con reglas, sin modelo de lenguaje, pero el problema de permisos es el mismo que tendría un agente. El motor no puede aplicar precios por su cuenta: las propuestas van a una cola donde el equipo de la tienda elige en cada fila el precio sugerido, uno puesto a mano o descartar. Cada 20 minutos se aplica en Shopify lo aprobado, y antes de escribir se vuelve a leer el precio vivo; si alguien lo ha cambiado mientras tanto, esa fila se marca como obsoleta y no se toca. Y un interruptor general detiene todas las escrituras sin desplegar nada.

Ese diseño nos salvó de un error nuestro. Al principio el techo de la horquilla se aplicaba como límite absoluto, y para una pieza que cuesta 0,60 €, que la tienda vendía a 2,11 € y que en el mercado estaba a 8,91 €, el sistema proponía bajarla a 1,80 €. Como el motor solo propone, se quedó en una propuesta absurda que revisamos antes de que llegara a la tienda.

Eso sí, una aprobación que se pulsa sin leer da una falsa sensación de control. Las colas tienen que ser cortas y concretas: una decisión por fila, con el dato de antes y el de después a la vista.

Borradores y confirmaciones que caducan

Para lo que sale hacia fuera usamos borradores. En AgentDesk, las categorías que siempre resuelve una persona reciben una respuesta preparada que nadie envía sin revisarla. En nuestro asistente interno, enviar o borrar un correo crea una acción pendiente que solo se ejecuta con una confirmación explícita y caduca a los cinco minutos.

¿Qué hay que registrar para poder auditar a un agente?

Si mañana un cliente dice que el agente le canceló un pedido sin pedírselo, necesitas reconstruir qué pasó sin adivinar. Lo mínimo que registraríamos en cualquier agente:

• la herramienta, los argumentos y lo que devolvió;
• en nombre de quién actuaba y desde qué conversación o ticket;
• si la acción fue autónoma, simulada o aprobada, y por quién;
• el valor anterior y el nuevo cuando cambia un dato;
• los errores de autenticación, que avisan de que algo se ha roto sin hacer ruido.

Igual de importante es lo que no se registra. En los logs de errores de nuestros bots de ecommerce viaja el identificador de la sesión y nunca el texto que escribió el cliente. Para decidir cuánto tiempo guardar las conversaciones, tienes los criterios en nuestra guía para montar un agente de IA que cumpla el RGPD.

Errores típicos, incluidos algunos nuestros

Compartir una misma credencial entre varios servicios

En uno de nuestros proyectos, el bot que pasaba solicitudes de clientes al ERP usaba la misma clave que cinco flujos de automatización. Se rotó la clave, se actualizaron los flujos y el bot se quedó fuera. Estuvo nueve días recibiendo errores 401 y tres solicitudes no llegaron al ERP, porque ese servicio no avisaba de ese error. Desde entonces: una credencial por consumidor, un inventario de quién usa cada una y alertas cuando falla la autenticación.

Confirmaciones que solo existen en el prompt

«No envíes nada hasta que el usuario diga que sí» funciona casi siempre. Casi. Revisando nuestros propios agentes para escribir este artículo hemos encontrado un par de reglas así que solo vivían en el prompt. Si una confirmación importa, tiene que comprobarla el código de la herramienta.

Mensajes de error que dan pistas

Si el agente contesta «ese email no coincide con el pedido», está confirmando a un desconocido que ese número de pedido existe. Mejor un mensaje único para cualquier combinación que no case y un límite de intentos por minuto.

Checklist antes de dar permisos a un agente

• Lista cada herramienta y clasifícala por lo que cuesta deshacer su efecto.
• Crea una credencial propia para el agente, de solo lectura donde no necesite más.
• Mete las comprobaciones de negocio en el código de las herramientas.
• Decide qué pasa por sombra, qué por cola de aprobación y qué va en borrador.
• Deja un interruptor para parar las escrituras sin desplegar.
• Registra argumentos, resultado y aprobador de cada acción, y avisa de los errores de autenticación.

Si estás valorando un agente de IA conectado a tus sistemas, esta es la conversación que deberías tener con quien te lo monte antes de hablar de modelos o de precios.

---

Preguntas frecuentes

¿Puede un agente de IA tener acceso a mi ERP?

Sí, y es donde más valor aporta. Lo sensato es empezar en lectura, con un usuario propio del agente, y abrir la escritura herramienta a herramienta cuando haya datos de que acierta. Si el ERP no tiene API, se puede leer de su base de datos con un usuario de solo lectura y montar encima una API pequeña con las operaciones justas. Es el tipo de trabajo que hacemos en automatización de procesos.

¿Quién responde si el agente se equivoca?

Tu empresa, igual que responde de lo que publica en su web o de lo que dice su equipo. Un tribunal canadiense lo dejó claro con una aerolínea y su chatbot, un caso que repasamos en chatbot o agente de IA para atención al cliente.

¿El Reglamento Europeo de IA obliga a que una persona supervise al agente?

La supervisión humana del artículo 14 es obligatoria en los sistemas de alto riesgo, como los que deciden en selección de personal o en la concesión de crédito: quien supervisa tiene que poder anular o revertir el resultado e interrumpir el sistema con un botón de parada. Un agente de atención al cliente normalmente no es de alto riesgo, y lo que más le afecta es la transparencia del artículo 50, avisar de que se está hablando con una IA. Aun así, esa lista del artículo 14 es un buen checklist de diseño para cualquier agente que actúe.