Cómo dar permisos a un agente de IA sin perder el control
Dar acceso a un agente de IA se parece más a dar llaves de casa que a instalar una app: conviene decidir qué puertas abre, cuándo y quién se entera. Esta guía propone un método sencillo: empezar con lo mínimo, separar leer de modificar, pedir confirmación en lo importante y dejar siempre una vía de parada.
Leer no es lo mismo que modificar
Es la distinción más útil y la más olvidada. Mirar tu agenda no equivale a cambiarla, y leer un correo no equivale a enviar uno en tu nombre.
Esto es un hecho verificado: los servicios que usamos a diario separan esas capacidades en sus APIs mediante permisos o *scopes*. En Gmail, por ejemplo, gmail.readonly es de solo lectura, gmail.send permite enviar, gmail.compose gestiona borradores y envío, y gmail.modify abarca lectura, redacción y envío. En Google Calendar, calendar.events.readonly permite ver eventos, calendar.events permite verlos y editarlos, y calendar.freebusy solo da acceso a la disponibilidad.
Mira cuánto cambia el panorama entre «ver si estoy libre el jueves» y «editar todos mis eventos». Son escalones distintos, y cada uno merece una decisión consciente.
Un matiz importante: que un permiso sea amplio no significa que el agente pueda usarlo sin tu consentimiento. Ese consentimiento y esos límites los fija quien configura el sistema, y de eso va el resto del artículo.
Empieza por lo mínimo necesario
El principio de mínimo privilegio consiste en dar solo el acceso imprescindible para la tarea. Reduce el alcance de un error o de un abuso: si el agente solo puede leer, lo peor que puede pasar con esa llave es mucho más acotado.
Microsoft Graph lo recomienda expresamente y ofrece permisos granulares. Además distingue dos contextos que conviene no mezclar:
- Permisos delegados: la aplicación actúa en nombre de un usuario concreto.
- Permisos de aplicación: la aplicación opera sin un usuario presente y puede tener más privilegios.
Su referencia de permisos insiste en pedir los menos privilegiados que hagan falta. En el mismo sentido, la documentación de credenciales de Google Workspace explica que un ID de cliente OAuth accede a datos del usuario mediante su consentimiento, y que las cuentas de servicio deben gestionarse de forma segura y limitarse a los recursos autorizados.
Práctica recomendada: empieza en modo lectura, limita los recursos (una carpeta, un calendario, un conjunto de documentos, no «todo») y amplía solo cuando el agente haya demostrado que hace bien lo básico. Dar el acceso completo el primer día es como entregar el juego de llaves a quien acaba de empezar en la oficina: puede que salga bien, pero no es un plan.
Un ejemplo hipotético: el agente de Marta
Imaginemos a Marta, que tiene un agente para gestionar reuniones. Es un ejemplo didáctico, no el retrato de ningún producto concreto ni una capacidad universal.
Alguien le escribe a Marta pidiendo una reunión. El recorrido sensato sería este:
1. Leer la disponibilidad. Permiso de bajo riesgo: el agente mira huecos libres. Podría bastar con ver si está libre u ocupada, sin acceder al contenido de los eventos.
2. Proponer un horario. El agente sugiere «el jueves a las 10:00» y se lo muestra a Marta. Todavía no ha tocado nada.
3. Crear el evento. Aquí ya modifica el calendario. Conviene que Marta lo apruebe.
4. Enviar la invitación. La acción sale al mundo exterior y afecta a otra persona. Pide aprobación.
5. Registrar lo ocurrido. Queda constancia de qué se pidió, qué se hizo y quién dio el visto bueno.
Fíjate en que cada paso sube un peldaño de riesgo. Un agente con acceso de solo lectura no puede enviar nada por error, por muy confiado que esté. Y si alguna vez envía la invitación al «Jorge equivocado», será mucho mejor que Marta lo haya visto antes de pulsar el botón y no después.
Aprobaciones: confirmar lo que importa
No hace falta aprobar cada gesto, o el agente se convertiría en un colega que pregunta «¿puedo respirar?» cada cinco minutos. La idea es separar lo trivial de lo importante.
Como práctica de un proveedor (no una garantía universal), Anthropic describe herramientas configurables con tres modos: permitir siempre, pedir aprobación o bloquear. Su ejemplo es leer el calendario sin aprobación y pedirla para invitar a alguien. La misma publicación advierte del riesgo de *prompt injection* en correos, es decir, que un mensaje externo contenga instrucciones pensadas para engañar al agente.
Sobre esa base, el análisis que proponemos es un criterio sencillo:
- Permitir sin preguntar: consultar información acotada y de bajo riesgo.
- Pedir aprobación: enviar, borrar, compartir o crear citas que involucren a terceros.
- Bloquear: lo que el agente no necesita para su tarea.
Si quieres reforzar la otra mitad, la de comprobar lo que el agente te devuelve, tenemos una guía sobre cómo dar instrucciones a una IA y comprobar sus respuestas.
Registros y botón de parada
Los registros (*logs*) permiten reconstruir qué se pidió, qué herramienta se llamó y quién aprobó. Son útiles para entender un fallo y para aprender de él.
Pero tienen un límite claro: un registro no corrige una acción errónea. Es como la cámara de seguridad, que te dice quién entró pero no cierra la puerta. Por eso la parada tiene que estar prevista y probada, no solo escrita en un manual. Pregúntate de antemano: ¿cómo revoco el acceso?, ¿quién puede hacerlo?, ¿he comprobado que funciona?
El marco de gestión de riesgos de IA del NIST (Apéndice C) es una guía voluntaria que apunta en la misma dirección. Propone definir responsabilidades humanas y del sistema, documentar la supervisión y estudiar cuándo las personas cuestionan o revocan las salidas del sistema.
Si el agente trabaja de forma continua, estos controles pesan todavía más. Para ese contexto puedes leer De asistente a trabajador permanente.
Lista rápida antes de dar acceso
- ¿Necesita leer, o también modificar? Empieza por leer.
- ¿Puedo limitarlo a un calendario, una carpeta o una cuenta concreta?
- ¿Qué acciones (enviar, borrar, compartir, crear citas) requieren mi aprobación?
- ¿Se guarda un registro de lo que pide y hace?
- ¿Sé cómo detenerlo y revocar el acceso, y lo he probado?
Si alguna respuesta es «ni idea», todavía no es hora de dar permisos. Poner límites no es desconfiar de la tecnología, es lo mismo que haces con cualquier persona nueva que empieza a trabajar contigo.
Para ampliar información
Fuentes consultadas el 10 de octubre de 2026:
- Google, Gmail API: scopes
- Google, Calendar API: autorización
- Google, Crear credenciales en Google Workspace
- Microsoft, Visión general de permisos de Microsoft Graph
- Microsoft, Referencia de permisos de Microsoft Graph
- Anthropic, Trustworthy agents in practice
- NIST, AI RMF, Apéndice C: gestión del riesgo de IA e interacción humano-IA
En LedSolEo:
