Qué permisos debe tener un agente de IA en la empresa

El agente que mandó un descuento a toda la base de clientes por una instrucción ambigua

Un lunes por la mañana, alguien del equipo comercial conectó un agente de IA al CRM y a la cuenta de correo de la empresa con un objetivo simple: que redactara y enviara recordatorios de renovación a los clientes con contrato por vencer ese mes. Para no perder tiempo configurando permisos campo por campo, le dieron acceso de lectura y escritura sobre toda la base de contactos y autorización para enviar correo sin revisión previa, “total, era viernes y había prisa”. La instrucción que recibió el agente no distinguía con precisión el segmento: hablaba de “clientes activos” sin excluir a los que ya habían cancelado ni acotarlo a los que vencían ese mes. El agente, con acceso a toda la base y sin nadie que aprobara el envío antes de salir, interpretó la instrucción de forma razonable dentro de lo ambiguo que era, y mandó un correo con un descuento de renovación a la base completa, incluidos clientes que ya se habían ido meses atrás.

Nadie se dio cuenta hasta que empezaron a llegar respuestas confundidas y una consulta de un cliente que preguntaba por qué le ofrecían renovar algo que ya había cancelado con reclamo de por medio. Para cuando alguien revisó qué había pasado, el correo ya estaba entregado a miles de contactos y no había forma de deshacerlo. Nadie en la empresa podía decir con precisión quién había autorizado que el agente tuviera acceso de escritura a toda la base ni por qué el envío no pasaba por la revisión de una persona antes de salir. Esa pregunta, quién decidió esto y por qué, es la que casi ninguna empresa se hace antes de conectar un agente a un sistema real.

Esto no es un caso de un agente “malo” ni de una IA que se rebeló. Es un caso de arquitectura de permisos: nadie definió qué podía tocar el agente, solo se decidió que “tuviera acceso” al CRM y al correo, como si el acceso fuera una sola cosa binaria. Es exactamente el mismo error que contratar a alguien nuevo y entregarle todas las llaves de la oficina el primer día, sin entrevista, sin periodo de prueba y sin decirle qué puertas no debe abrir. Tarde o temprano abre la que no debía, no por mala intención: porque nadie le dijo lo contrario ni construyó nada que se lo impidiera.

El principio de mínimo privilegio aplicado a un agente de IA

El mínimo privilegio no es una idea nueva ni nació con la IA: es un principio viejo de seguridad de sistemas que dice que a cada usuario, proceso o cuenta se le debe dar exactamente el acceso que su función requiere, ni un permiso más “por si acaso”. Durante años se aplicó a personas y a cuentas de servicio con bastante disciplina en empresas grandes, y con bastante menos disciplina en el resto. Con un agente de IA ese mismo principio no es opcional ni un detalle de configuración: es la diferencia entre un sistema que se equivoca en lo pequeño y uno que se equivoca a la escala de todo lo que puede tocar. Un agente no comete un error a la vez como una persona cansada un viernes: ejecuta a la velocidad y el volumen de una máquina, así que un permiso de más no es un riesgo pequeño multiplicado, es un riesgo grande desde el primer minuto.

Mínimo privilegio no significa “sin acceso” ni significa desconfiar del agente: significa que el acceso se define mirando la tarea, no mirando el sistema completo al que esa tarea pertenece. Un agente que redacta recordatorios de renovación necesita leer el estado del contrato y el nombre del cliente, no necesita ver el historial completo de facturación ni la ficha de recursos humanos del vendedor asignado, aunque las tres cosas vivan en el mismo CRM. Cada permiso adicional que se concede “por si el agente lo necesita después” no es comodidad, es superficie expuesta: si el agente razona mal, si recibe una instrucción ambigua o si algo dentro de lo que procesa intenta manipularlo, solo puede hacer daño dentro de lo que sus permisos permiten. Esto es justamente lo que explica por qué el prompt injection es una amenaza que se toma en serio en el diseño de agentes: si alguien logra que una instrucción no autorizada llegue disfrazada dentro de un documento, un correo o una página que el agente procesa, esa instrucción solo puede ejecutar lo que el agente ya tenía permiso de ejecutar. Limitar permisos no elimina ese riesgo, pero sí le pone techo al daño posible, y ese techo es la diferencia entre un incidente contenible y uno que compromete a toda la empresa.

Qué debe poder leer, escribir y ejecutar un agente, y qué no

Definir el permiso de un agente exige separar tres capas que casi nunca se distinguen cuando alguien dice “dale acceso al sistema”: qué puede leer, qué puede escribir y qué puede ejecutar. Son tres decisiones distintas, con distinto nivel de riesgo, y tratarlas como una sola es la raíz de la mayoría de los sustos.

• Lectura: el agente ve solo los campos y registros que su tarea necesita consultar, no la tabla completa ni los sistemas vecinos. Un agente de soporte que resuelve tickets no necesita leer la nómina ni el historial de compras de un cliente que no está atendiendo.
• Escritura: el agente modifica o crea registros dentro de un alcance acotado y reversible, como actualizar el estado de un ticket, agregar una nota o programar un recordatorio. La escritura sobre campos que afectan dinero, contratos o la identidad de otra persona pertenece a la siguiente categoría, no a esta.
• Ejecución: el agente dispara una acción sobre un sistema externo al suyo, como enviar un correo, procesar un pago, cerrar una cuenta o cambiar el permiso de otro usuario. Es la capa de mayor riesgo porque una acción ejecutada ya ocurrió en el mundo real, y es la que con más frecuencia se concede de más “para que el agente no tenga que parar a preguntar”.

La regla práctica que sostiene esto es simple de enunciar y difícil de mantener con disciplina: cuanto más se acerca un permiso a la ejecución, más se acerca también a lo irreversible, y lo irreversible exige más control, no menos. La mayoría de los agentes que hoy funcionan bien en una empresa solo necesitan lectura amplia y escritura acotada; la ejecución directa sobre sistemas de registro debería ser la excepción revisada caso por caso, no el punto de partida por comodidad de configuración. Cuando se contrata un servicio externo para operar agentes, este es justo el tipo de alcance que debería quedar explícito en el contrato: qué lee, qué escribe y qué ejecuta cada agente, no una promesa genérica de “acceso a tus sistemas”.

Las acciones que siempre requieren aprobación humana, sin excepción

Hay una forma simple de decidir qué acción necesita una persona que apruebe antes de que ocurra: preguntar si se puede deshacer. Si un agente clasifica mal un ticket, alguien lo reclasifica en un minuto y no pasó nada grave. Si un agente envía un correo a la base completa, reembolsa un pago o borra un registro, esa acción ya ocurrió en el mundo y no hay botón de deshacer. La reversibilidad, no la complejidad de la tarea, es el criterio que debería decidir dónde va un punto de aprobación humana obligatorio, lo que en la práctica se conoce como human in the loop.

• Comunicación externa masiva: cualquier correo, mensaje o notificación que salga a más de un cliente a la vez, y en particular cualquier envío que mencione dinero, descuentos o cambios contractuales.
• Movimiento de dinero: reembolsos, pagos, ajustes de facturación o cualquier acción que cambie lo que un cliente debe o lo que la empresa le debe a alguien.
• Borrado o modificación irreversible de registros: eliminar contactos, cancelar cuentas o sobrescribir un historial que no se puede reconstruir después.
• Cambios de permisos: que un agente pueda otorgar, quitar o modificar el acceso de otro usuario o de otro agente. Un agente nunca debería poder ampliar su propio alcance ni el de otro.
• Decisiones sobre personas: cualquier acción que afecte de forma individualizada y sensible a un cliente o a un empleado, como suspender un servicio o marcar una cuenta como riesgo.

Aprobación humana no significa que una persona repita el trabajo que ya hizo el agente: significa que alguien confirma, con la información que el agente preparó, antes de que el paso irreversible se ejecute. Ese punto de control tiene que estar diseñado en el flujo desde el principio, no agregado después de un incidente, y su cumplimiento sostenido en el tiempo es justamente lo que una empresa debería verificar de forma regular, no darlo por hecho una sola vez al lanzar el proyecto.

Por qué cada agente necesita su propia credencial, y nunca la de otra persona

Un error frecuente, y barato de cometer porque ahorra una hora de configuración, es darle a un agente la misma credencial que usa un empleado, o crear una sola cuenta de servicio compartida para varios agentes distintos. Funciona el primer mes. El problema aparece cuando algo sale mal: si dos agentes comparten credencial y uno de los dos actuó fuera de lugar, el registro no puede decir cuál de los dos lo hizo, porque para el sistema ambos son la misma identidad. Y si la credencial es la de un empleado real, cualquier acción del agente queda mezclada con las acciones humanas de esa persona en el mismo historial, lo que vuelve inútil cualquier intento serio de auditoría.

La regla es simple de aplicar aunque tome un poco más de trabajo inicial: cada agente tiene su propia credencial, con su propio nombre identificable y su propio alcance de permisos, aunque dos agentes hagan tareas parecidas sobre el mismo sistema. Esto no es burocracia, es lo que permite dos cosas que de otro modo son imposibles: saber con certeza qué agente hizo qué acción, y poder apagar el acceso de un solo agente de forma instantánea sin tocar el acceso de los demás. Una credencial compartida obliga a elegir entre dejar el problema activo o apagar varios agentes a la vez para frenar uno solo, y ninguna de las dos opciones es aceptable cuando ya hay un incidente en curso.

El registro de auditoría: qué tiene que quedar grabado de cada acción

Un agente sin registro de auditoría es una caja negra con permisos reales sobre sistemas reales, y eso no es una simplificación exagerada: es literalmente lo que ocurre cuando nadie configuró el log. El registro tiene que capturar, como mínimo, qué credencial actuó, en qué momento, con qué información de entrada, qué decisión tomó y qué acción ejecutó hacia afuera, y si esa acción pasó por una aprobación humana o no. No hace falta guardar cada paso de razonamiento interno del modelo: lo que hace falta es poder reconstruir, después de los hechos, la secuencia de qué pasó y con qué permiso, sin depender de que alguien recuerde o de que el propio agente “explique” lo que hizo.

Ese registro tiene que ser inmutable y estar fuera del alcance del propio agente: si el sistema que audita al agente puede ser editado por el agente auditado, no hay auditoría, hay una simulación de auditoría. Es la diferencia entre poder decir con precisión “el agente X, con esta credencial, hizo esta acción a esta hora” y tener que reconstruir a ciegas qué pasó y qué hacer en el momento cuando algo ya salió mal y nadie puede explicar el origen exacto del error.

Qué se revisa cada trimestre, no solo cuando algo ya falló

Los permisos de un agente no son una configuración que se hace una vez y se olvida: son una decisión viva que envejece igual que cualquier otro control de acceso en la empresa. Un agente que empezó leyendo tres campos hace seis meses probablemente hoy hace más cosas, y sus permisos casi nunca se actualizaron al mismo ritmo que su alcance real. La revisión trimestral no es un trámite de cumplimiento: es la única forma de que el permiso otorgado siga pareciéndose al permiso que el agente de verdad usa.

• Permisos otorgados contra permisos usados: si un agente tiene acceso de escritura a un campo que nunca tocó en tres meses, ese permiso sobra y hay que retirarlo, no dejarlo “por si acaso”.
• Rotación de credenciales: cambiar las claves y tokens de cada agente en un ciclo regular, igual que se hace con cualquier cuenta de servicio crítica.
• Uso real del registro de auditoría: un log que nadie abre en tres meses es decorativo, no un control. Revisar si alguien de hecho lo está leyendo es parte de la revisión.
• Alcance actual contra alcance original: confirmar si la tarea del agente cambió desde la última revisión y si sus permisos crecieron a la par o quedaron desactualizados en algún sentido.

Esto se conecta directamente con cómo se monitorea un agente ya en producción: el monitoreo mira el comportamiento día a día, la revisión trimestral mira la arquitectura de acceso completa, y ninguna de las dos reemplaza a la otra.

Los errores más comunes al dar permisos a un agente

Casi todos los sustos con agentes que he visto en empresas repiten el mismo puñado de errores, y ninguno tiene que ver con que el modelo sea malo. El primero es dar permiso amplio “para no tener que configurar campo por campo”, tratando la configuración fina como una pérdida de tiempo en vez de como el trabajo real del proyecto. El segundo es reutilizar la credencial de un empleado o de otro agente porque crear una nueva cuenta de servicio “toma tiempo de TI”. El tercero es tratar el permiso como algo que se decide una sola vez al lanzar el proyecto, sin dueño ni fecha de revisión después. El cuarto, y el más silencioso, es no dejar escrito quién aprobó cada permiso y por qué: cuando algo falla meses después, nadie puede reconstruir el criterio que llevó a esa decisión.

El permiso que le das a un agente es una decisión de riesgo, no un paso de instalación

Ninguna empresa que conecta un agente de IA a un sistema real piensa que está tomando una decisión de riesgo: piensa que está configurando una herramienta. Esa es la confusión de fondo que sostiene este artículo entero. El permiso que un agente tiene hoy sobre el CRM, el correo o el ERP no es un detalle técnico que resuelve quien instala el sistema: es, en los hechos, la política de riesgo de la empresa frente a ese agente, decidida muchas veces por default, sin que nadie firme nada ni se haga responsable.

El estándar no es complicado de enunciar, aunque exige disciplina sostenida para mantenerlo: privilegio mínimo por tarea, credencial propia por agente, aprobación humana obligatoria en lo irreversible, registro de auditoría inmutable y revisión periódica de que todo lo anterior sigue siendo cierto. Ninguna empresa que se toma en serio a un agente de IA empresarial debería aceptar menos que eso solo porque configurarlo bien toma más tiempo que darle acceso de administrador y esperar que no pase nada.