Durante los últimos años, controlar los accesos de una empresa parecía relativamente sencillo. Un trabajador entra en la compañía, se crea su usuario y recibe acceso al correo, al CRM, al ERP, a las carpetas y a las aplicaciones que necesita. Si cambia de puesto, cambian sus permisos. Y cuando se va, sus accesos deberían eliminarse.
Ahora estamos incorporando un nuevo participante a esa estructura.
No tiene nómina. No aparece en Recursos Humanos. No necesita escritorio. Pero puede tener acceso al correo, leer documentos internos, consultar clientes, conectarse a herramientas corporativas e incluso ejecutar acciones.
Es un agente de inteligencia artificial.
Y conforme las empresas empiecen a desplegar decenas o cientos de ellos, aparece una pregunta que será cada vez más importante:
¿Quién controla a la plantilla digital de tu empresa?
Un agente de IA no es simplemente otro chatbot
La diferencia es fundamental. Un chatbot tradicional recibe una pregunta y devuelve una respuesta. Un agente recibe un objetivo y realiza varias acciones para conseguirlo.
Imaginemos un agente comercial. Puede:
- consultar los nuevos contactos;
- buscar información del cliente y revisar su historial en el CRM;
- preparar una propuesta y enviarla por correo;
- actualizar la oportunidad y crear una tarea de seguimiento;
- avisar al comercial.
Todo ello sin que una persona tenga que ejecutar cada paso. Eso es lo que hace interesantes a los agentes. Pero también cambia por completo el problema de seguridad.
Microsoft lo resume con claridad: los agentes planifican, encadenan acciones entre sistemas e invocan herramientas sin que una persona apruebe explícitamente cada paso. Si los permisos están mal configurados, un agente puede acabar accediendo o modificando más información de la necesaria.
La pregunta deja de ser «¿qué puede responder esta IA?» y pasa a ser «¿qué puede hacer esta IA dentro de mi empresa?».
La acumulación de permisos: la cuenta que nadie recuerda haber creado
Imaginemos que una empresa quiere automatizar algunas tareas administrativas. Construye un agente y, para que funcione, alguien le da acceso al correo. Después necesita consultar documentos. Luego, el ERP. Después, el CRM. Y al final tiene que modificar algunos registros.
Poco a poco, lo que empezó como una pequeña automatización acaba con acceso a cuatro o cinco sistemas críticos. Es un fenómeno muy conocido en seguridad informática: la acumulación progresiva de permisos (permission creep). Microsoft lo describe en los despliegues de agentes: se dan permisos amplios para sacar adelante una prueba, el agente asume más funciones y nadie vuelve a revisar si todos siguen siendo necesarios.
Cada acceso, por separado, puede parecer razonable:
- Correo: razonable.
- CRM: razonable.
- Documentos: razonable.
- ERP: razonable.
Pero juntos pueden crear algo bastante diferente: un sistema capaz de reunir información de muchas áreas y actuar sobre ella.
El riesgo no siempre está en un permiso concreto. A veces está en la combinación de todos ellos.
Cada agente, una identidad propia
Hay una forma sencilla de entender este problema. Si tuvieras un empleado nuevo, nunca le harías trabajar con la cuenta del director financiero: le crearías una identidad propia. Con un agente debería aplicarse el mismo razonamiento.
El NIST, el organismo de estándares tecnológicos de Estados Unidos, abrió en 2026 un proyecto sobre la identidad y la autorización de los agentes de software e IA. Su punto de partida: el potencial de estos sistemas depende de darles acceso a datos, herramientas y aplicaciones, y eso exige mecanismos adecuados de identificación, autorización, auditoría y control.
Microsoft propone una idea parecida: tratar cada agente como un actor independiente, con su propia identidad. Eso implica poder responder con claridad:
- qué agente hizo algo;
- con qué identidad;
- bajo qué permisos;
- y quién era responsable de ese agente.
Porque si veinte agentes comparten las mismas credenciales, cuando ocurra algo inesperado quizá sepamos que «el sistema» hizo una acción, pero no qué agente fue, por qué estaba autorizado ni quién debía supervisarlo.
Mínimo privilegio: el agente de marketing no debería tocar la contabilidad
La lógica es prácticamente la misma que aplicaríamos con una persona. Un comercial no necesita acceso de administrador al servidor. Alguien de marketing no necesita modificar las nóminas. Y un técnico no debería poder autorizar transferencias solo porque su cuenta se usa también para otra aplicación.
En ciberseguridad existe desde hace décadas un principio fundamental: el mínimo privilegio. Cada usuario recibe únicamente los permisos que necesita para su función. Con los agentes, ese principio es todavía más importante.
Microsoft recomienda que cada agente tenga una identidad diferenciada, una función concreta y permisos ligados a tareas específicas; separar la lectura de la escritura, y exigir una aprobación adicional para las operaciones delicadas, como borrar, exportar o cambiar permisos.
Un agente que analiza facturas podría necesitar:
- leer facturas, pero no necesariamente eliminarlas;
- consultar proveedores, pero no necesariamente modificarlos;
- preparar una propuesta de pago, pero no necesariamente ordenar la transferencia.
Parece evidente explicado así. Pero en la fase inicial de muchos proyectos hay una tentación enorme: «Dale acceso a todo y primero conseguimos que funcione». Y ese acceso provisional acaba siendo permanente.
Una instrucción no es un control
Hay una diferencia importante entre decirle a un agente «nunca elimines documentos» y construir el sistema para que no pueda eliminar documentos. Lo primero es una instrucción. Lo segundo es un control. Y en una empresa la diferencia debería estar muy clara.
Microsoft advierte que confiar en instrucciones (prompts) para limitar lo que hace un agente no sustituye a los controles técnicos de autorización. El acceso real debe limitarse con permisos, herramientas autorizadas y validaciones en los sistemas que reciben cada acción.
Un buen sistema no debería depender de que la IA decida comportarse bien. Debería tener un límite técnico que funcione incluso cuando se equivoque.
Más autonomía debería significar más control
No todos los agentes necesitan la misma supervisión. Hay una diferencia enorme entre un agente que resume una reunión y uno que envía comunicaciones a clientes. Y otra todavía mayor con uno que modifica información financiera.
PwC propone tratar a los agentes como workforce counterparts, algo así como nuevos participantes de la plantilla aunque no sean empleados, con identidad verificable, función definida, permisos específicos por tarea, registros auditables y límites explícitos a su autonomía. Y cuanto mayor sea el impacto posible de sus acciones, más supervisión humana.
En su estudio Trust and Safety Outlook 2026, el 85 % de los encuestados en Estados Unidos confía en que un agente de IA haga al menos una tarea de su trabajo diario. Pero la confianza cae con fuerza cuando lo que está en juego es mayor: solo el 20 % confiaría en un agente para hacer transacciones financieras.
Esa creciente aceptación hace que la gobernanza sea más importante, no menos. Un agente que prepara una presentación tiene un riesgo muy diferente al de uno autorizado para aprobar, eliminar, publicar, enviar, comprar o modificar información crítica.
Un ejemplo sencillo: el agente de atención al cliente
Supongamos que construimos un agente para atender a los clientes. Para hacerlo bien necesita leer el correo, el historial del CRM, los pedidos, las facturas y la documentación del producto. Hasta aquí parece razonable.
Ahora imaginemos que además puede modificar el CRM. Después, hacer devoluciones. Y al final, aprobar ciertos descuentos. Hemos pasado de consultar información a generar consecuencias económicas.
No necesariamente hay que impedirlo: el objetivo de los agentes es precisamente automatizar acciones. Pero cada salto debería ser deliberado:
- Autonomía total para responder preguntas frecuentes.
- Autonomía limitada para modificar datos.
- Aprobación humana obligatoria para devoluciones a partir de cierta cantidad.
Así la supervisión humana pasa a ser una parte estructural del sistema, y no una recomendación escrita en algún documento. Esa aprobación debería exigirla el propio sistema según la acción y el importe, no depender de que el modelo decida si la necesita.
El inventario: saber qué agentes existen
Hay otro riesgo mucho menos espectacular, pero probablemente muy frecuente: que la empresa pierda la cuenta.
- Marketing crea uno.
- Informática crea tres.
- Un trabajador conecta otro con Zapier.
- Un proveedor instala dos más.
- Otro departamento prueba Copilot Studio.
- Un desarrollador crea uno por su cuenta.
Seis meses después, alguien pregunta: «¿cuántos agentes tenemos?». Y nadie tiene una respuesta exacta.
Recuerda mucho a lo que se conoce como shadow IT: herramientas que se usan dentro de una organización sin una gestión centralizada. Con los agentes, el problema puede ser más serio, porque no solo guardan información: también actúan. Es la misma pregunta que planteábamos a propósito del Plan IA360: antes de gobernar la IA hay que saber qué IA se está usando.
Siete controles para un registro de agentes
No hace falta empezar con una plataforma gigantesca. Una empresa que empieza a usar agentes puede fijar unas normas sencillas. Para cada agente debería existir, como mínimo:
- Una identidad propia. Sin compartir credenciales con personas ni con otros agentes.
- Un responsable humano. Alguien que sepa por qué existe y pueda decidir si sigue activo.
- Un objetivo definido. Qué proceso hace y qué acciones quedan fuera de su función.
- Permisos mínimos. Acceso solo a los sistemas, la información y las operaciones que necesita.
- Acciones delicadas separadas. Leer, escribir, eliminar, exportar o administrar no son equivalentes.
- Trazabilidad. Poder reconstruir qué hizo, cuándo, sobre qué información y con qué autorización.
- Un mecanismo de baja. Si el agente deja de usarse, sus credenciales y permisos deben poder revocarse en el acto.
Son controles bastante intuitivos. Y, sin embargo, serán cada vez más importantes conforme crezca el número de agentes. El NIST estudia precisamente la identificación, la autorización, la auditoría y el no repudio de los agentes; Microsoft recomienda inventariar sus identidades, eliminar los roles demasiado amplios y preparar su revocación, y PwC plantea gestionarlos con procesos parecidos a las altas, los cambios de puesto y las bajas.
La baja: el día en que un agente deja de trabajar
Las empresas están acostumbradas a pensar en el alta. Mucho menos en la baja.
Construimos una automatización. Funciona. Se abandona. Y nadie recuerda que aquella clave de acceso sigue activa, que aquel agente todavía puede consultar documentos o que mantiene acceso al CRM. Con cientos de agentes, esto puede convertirse en un problema serio.
La gestión debería cubrir el ciclo completo:
Crear → autorizar → utilizar → revisar → modificar → retirar
Microsoft recomienda prever desde el principio cómo suspender la identidad de un agente, rotar sus credenciales y revocar sus accesos con rapidez. Es el mismo principio que ya aplicamos con trabajadores y aplicaciones, solo que ahora hay una categoría nueva: las identidades de IA.
¿Significa esto que los agentes son demasiado peligrosos?
No. Sería justo la conclusión equivocada.
Poder conectar agentes con sistemas reales es lo que puede convertirlos en una tecnología muy valiosa para las empresas. Un agente que solo conversa puede ahorrar tiempo. Un agente bien integrado puede transformar un proceso completo: revisar cientos de documentos, clasificar solicitudes, preparar operaciones, coordinar herramientas, actualizar sistemas, detectar anomalías… y dejar que las personas dediquen su tiempo a lo que necesita criterio.
El objetivo no debería ser limitar la autonomía por miedo, sino aumentarla de forma controlada. Cuanto mejores sean nuestros controles, más responsabilidad podremos delegar con confianza.
Mejor muchos agentes pequeños que un superagente
Podemos imaginar el futuro como un superagente conectado a todos los sistemas de la empresa. Probablemente no sea la arquitectura más prudente.
Microsoft recomienda diseñar los permisos en torno a las unidades de trabajo más pequeñas que tengan sentido, sin juntar permisos que no guardan relación. Llevado a la arquitectura, se parece mucho a los microservicios: agentes con responsabilidades concretas, accesos limitados y capacidades bien definidas que se coordinan entre sí.
- Un agente para la facturación.
- Otro para la atención al cliente.
- Otro para el análisis.
- Otro para los informes.
Cada uno con las herramientas y los permisos que necesita su función, y una capa superior que coordine ciertas operaciones. Eso reduce el alcance del daño cuando algo falla, y hace mucho más fácil entender qué está pasando.
La plantilla que Recursos Humanos no conoce
Dentro de unos años, quizá Recursos Humanos no conozca toda tu plantilla. No porque las máquinas sustituyan necesariamente a las personas, sino porque junto a ellas habrá cada vez más sistemas autónomos haciendo trabajo: agentes comerciales, administrativos, de análisis, de programación, financieros o de atención.
Probablemente no serán empleados. Pero formarán parte de la capacidad operativa de las organizaciones. Y por eso necesitaremos saber quiénes son, qué hacen, a qué tienen acceso y quién responde por ellos.
La empresa que espere a tener cien agentes para plantearse estas cuestiones probablemente llegará tarde. La que empiece con cinco y establezca desde el principio una arquitectura correcta estará mucho mejor preparada para crecer.
Antes de desplegar más agentes, descubre cuáles tienes ya
La conversación sobre la inteligencia artificial suele centrarse en qué cosas nuevas podemos automatizar. Pero conforme la tecnología madure aparecerá otra pregunta igual de importante:
¿Tenemos control sobre todo lo que ya hemos automatizado?
Ese puede ser uno de los grandes retos de la siguiente fase de la IA en las empresas. No construir agentes. Gobernarlos.
Este artículo es informativo. Cuando un despliegue de agentes tenga implicaciones jurídicas o regulatorias concretas, conviene contar también con asesoramiento legal especializado.
