Agentes de IA en empresas: cómo limitar permisos y acciones
Por Carlos Isidoro De Ayala Diaz ·
Agentes de IA en empresas: cómo definir identidad, permisos temporales, herramientas autorizadas, aprobación humana, registros y revocación antes del piloto.
Define la tarea, el propietario y la identidad antes de dar acceso
Un agente de inteligencia artificial no se limita a redactar una respuesta. Puede planificar varios pasos, consultar documentos, llamar a una API, actualizar un registro o activar un flujo sin que una persona confirme cada movimiento. Esa capacidad cambia la pregunta inicial: antes de elegir modelo o plataforma, la empresa debe describir qué tarea puede ejecutar, con qué datos, sobre qué sistemas, para quién y hasta qué resultado. Un objetivo como gestionar pedidos es demasiado amplio; revisar el estado de pedidos de una sede y preparar una propuesta sin enviarla ya define un límite comprobable.
Cada agente necesita un propietario de negocio, un responsable técnico y un mecanismo de suspensión. El inventario registra finalidad, entorno, modelo, orquestador, memoria, herramientas, fuentes de datos, proveedores, usuarios, coste y fecha de revisión. También distingue un asistente iniciado por una persona de un proceso autónomo que actúa por horario o evento. Microsoft advierte que los agentes pueden cambiar su comportamiento según contexto e inputs y operar de forma continua; por eso el control no puede depender solo de que el prompt describa bien la tarea.
La identidad del agente debe ser distinguible de la identidad humana que lo patrocina. Usar una cuenta compartida o copiar el token de un administrador impide atribuir las acciones y concede capacidad que la tarea quizá no requiere. NIST ha señalado identificación, autorización, auditoría y no repudio como cuestiones centrales para agentes de software. La identidad propia permite asociar permisos, registros, caducidad y revocación al agente, además de conservar quién inició el trabajo cuando actúa en nombre de un usuario.
El piloto empieza con información autorizada y un entorno controlado. Se excluyen datos y sistemas que no son necesarios para demostrar el caso de uso. Si el agente resume contratos, no necesita enviar correos; si prepara incidencias, no requiere borrar tickets; si consulta un ERP, no debe heredar permisos de configuración. El documento de alcance enumera acciones permitidas y prohibidas, resultado esperado, errores inaceptables y persona que acepta la prueba. Sin esas referencias, una demostración llamativa no demuestra que el sistema sea operable.
Separa lectura y escritura y concede permisos por tarea y tiempo
El principio de mínimo privilegio se aplica a datos, recursos, herramientas y acciones. No basta con dar acceso a una API y confiar en que el agente invoque solo el método adecuado. El sistema final vuelve a autorizar cada llamada según identidad, recurso y operación. Una herramienta de CRM puede exponer lectura, creación, modificación, exportación y borrado; el agente recibe únicamente las funciones necesarias. La interfaz que traduce lenguaje natural a una llamada no debe convertirse en un atajo alrededor de los controles del CRM.
Lectura y escritura se separan siempre que el proceso lo permita. Un agente puede recopilar evidencia y preparar un cambio con acceso de lectura, mientras una identidad temporal ejecuta la modificación después de una aprobación. Microsoft recomienda privilegios limitados en el tiempo mediante roles activados para el flujo, tokens de vida corta o puertas de aprobación. Esa medida reduce el acceso permanente, pero exige comprobar que el permiso expira también en el sistema de destino y que un token ya emitido no sigue funcionando después de deshabilitar el agente.
Las herramientas disponibles forman una lista positiva. El agente no descubre e incorpora por sí mismo conectores, plugins o servidores MCP de producción. Para cada herramienta se documentan versión, propietario, credenciales, destinos, datos que entran y salen, límites y forma de retirarla. También se revisa la suma de permisos: cinco accesos aparentemente pequeños pueden permitir leer clientes, generar un archivo y enviarlo fuera de la empresa. La evaluación considera la cadena completa y no solo cada rol por separado.
Los límites operativos reducen daños por error o manipulación. Se fijan número de pasos, tiempo, consumo, volumen de registros, frecuencia de llamadas y destinos. Una operación masiva, un cambio de privilegios, un envío externo, un pago o un borrado necesita una barrera adicional. El permiso humano incluye contexto suficiente para decidir: acción, recurso, motivo, datos afectados, resultado previsto y reversión. Un botón de aceptar sin esa información traslada la responsabilidad a una persona sin darle una decisión real.
Trata documentos, memoria y resultados de herramientas como entradas no confiables
Un agente procesa instrucciones del sistema, peticiones de usuarios, documentos recuperados, páginas web y respuestas de herramientas. Esas fuentes tienen niveles de confianza distintos. Una frase dentro de un PDF, un correo o una descripción de producto puede intentar cambiar el objetivo y provocar otra acción. El modelo de responsabilidad compartida de Microsoft recomienda tratar como no confiable el contenido recuperado, las salidas de herramientas y los mensajes de otros agentes. Las reglas que autorizan una acción deben vivir fuera del modelo y comprobarse de forma determinista.
La memoria requiere alcance y caducidad. Guardar automáticamente conversaciones, resultados o preferencias puede mezclar clientes, usuarios o proyectos y convertir un dato manipulable en contexto persistente. Se define qué puede memorizarse, quién lo consulta, durante cuánto tiempo y cómo se corrige o elimina. Los identificadores y metadatos útiles para continuidad se separan del contenido sensible. Antes de reutilizar un recuerdo, el sistema valida origen, propietario y vigencia; que el propio agente lo haya escrito no lo convierte en información fiable.
El entorno de ejecución limita archivos, red, procesos y secretos. Un agente que analiza documentos no necesita acceso general al equipo del empleado ni a todas sus sesiones. Los conectores se ejecutan con cuentas separadas y los secretos no aparecen en prompts, respuestas ni registros. OWASP plantea que los agentes empresariales deben ser inspeccionables, trazables e instrumentables y que las políticas puedan aplicarse en tiempo de ejecución. El control efectivo debe observar y bloquear la llamada aunque el agente intente justificarla en texto.
Las pruebas incluyen errores y entradas adversarias, no solo ejemplos ideales. Se presentan instrucciones conflictivas, documentos que solicitan ignorar reglas, resultados incompletos, APIs lentas, permisos retirados y costes próximos al límite. Se comprueba que el agente mantiene el alcance, pide aclaración, detiene el flujo o deriva a una persona según lo acordado. En acciones reversibles se valida la recuperación; en las irreversibles se exige aprobación previa. El resultado es una matriz de escenarios y evidencias, no la afirmación genérica de que existen guardrails.
Registra cada acción, prueba la revocación y amplía la autonomía por etapas
El registro debe reconstruir qué ocurrió entre usuario, agente, herramienta y sistema final. Como mínimo conserva identidad del agente, usuario o proceso iniciador, versión, objetivo, herramienta, acción, recurso, permiso efectivo, aprobación, resultado, hora y un identificador de correlación. No necesita copiar prompts completos ni datos personales si esos campos permiten investigar. El sistema destino conserva su propia evidencia porque el orquestador no debe ser la única fuente que afirma que una autorización se aplicó.
La monitorización busca desvíos respecto al comportamiento esperado: nuevas herramientas, destinos, horarios, volúmenes, fallos de autorización, acciones encadenadas o acceso a datos fuera de la tarea. Las alertas llegan a una persona con capacidad de bloquear el flujo y entender su impacto. Un mensaje del agente diciendo que todo salió bien no sustituye la confirmación del sistema final. Métricas de calidad, errores, derivaciones, coste y acciones canceladas ayudan a decidir si el caso aporta valor sin ocultar los intentos que los controles detuvieron.
La revocación se ensaya antes de producción. Deshabilitar el agente debe impedir nuevos tokens; además se invalidan sesiones, rotan claves, retiran roles, desconectan herramientas y revisan tareas pendientes. Microsoft señala que una identidad desactivada puede conservar asignaciones que reaparecerían si se reactiva, por lo que la baja necesita comprobar permisos residuales. También se prueba qué sucede con colas y operaciones en curso para evitar que una acción aprobada antes del corte se ejecute horas después sin revisión.
La autonomía aumenta por etapas: primero consulta, después propuesta, luego escritura limitada y finalmente tareas recurrentes si las evidencias lo permiten. Cada ampliación revisa identidad, datos, herramientas, permisos, aprobaciones, pruebas y reversión. Élite Solutions Tech puede ayudar desde Murcia a diseñar y evaluar pilotos de IA para empresas regionales y nacionales. La propuesta concreta el caso de uso, integración, límites, entregables y responsabilidades; para una primera valoración puedes describir la tarea y los sistemas implicados en el formulario de contacto, sin enviar credenciales ni documentos confidenciales.