Qué accesos darle a un agente de IA y cuáles no
Esta objeción llega antes que ninguna otra, y es sana. «¿Y qué puede llegar a liar?» es la pregunta correcta para cualquier herramienta a la que le das las llaves de tus sistemas de trabajo.
La respuesta de abajo no es «no tengas miedo». Es un repaso por tipo de acceso: qué se abre con tranquilidad, qué se abre a medias, qué no se abre nunca y cómo comprobar un producto antes de pulsar «permitir».
El principio del que partir
Formalmente se llama principio de mínimo privilegio; en la práctica suena más simple: el agente debe ver exactamente lo que su tarea necesita, y ni un canal más.
No es paranoia, es la forma de hacer que el riesgo sea abarcable. Si el agente ve un canal y una carpeta, la pregunta «¿qué puede estropear?» tiene una respuesta corta. Si le has dado permisos de administrador, no hay respuesta corta.
Una comprobación útil: formula la tarea y mira qué acceso mínimo la cubre. «Procesar los documentos de los clientes» son una carpeta concreta y un chat concreto, no todo el disco y toda la correspondencia.
Qué abrir con tranquilidad
Lectura de sitios concretos. Un canal, una carpeta, una etiqueta del correo, un calendario, un tablero. No «el correo», sino «los mensajes con la etiqueta Clientes». No «el Drive», sino «la carpeta Proyectos 2026». Casi todas las integraciones decentes saben acotar el alcance — si un producto no sabe, eso ya es una señal.
Escritura donde el error se deshace. Un borrador de correo, un comentario, una tarea, una tarjeta, una fila en una hoja con historial de versiones. Aquí la palabra clave es reversible: un borrador se borra, un correo enviado no.
Acciones internas sin destinatario. Renombrar archivos según una regla, repartirlos por carpetas, poner etiquetas, cuadrar cifras en un informe. Nada de esto lo ve el cliente.
Qué abrir solo en lectura
Sistemas financieros. Ver cobros, extractos, estado de las suscripciones: sí. Iniciar movimientos de dinero: no, y mejor que sea una restricción técnica y no un ajuste que se puede cambiar sin querer.
Sistemas donde viven compromisos ajenos. El calendario de tus compañeros, las tareas del equipo. El agente puede ver que alguien está ocupado y proponer alternativas. Mover la reunión de otro es decidir por él, y eso se le pregunta.
El repositorio de código. Enseñar qué ha entrado en la última release, qué pull request lleva cuatro días sin revisión: útil. Escribir y hacer merge de código: es trabajo de los ingenieros y responsabilidad suya.
Qué no abrir nunca
Administración. Gestión de usuarios, roles y permisos. Una herramienta que puede darse permisos a sí misma deja de estar limitada.
Secretos. Claves de API, tokens, contraseñas, el contenido de los gestores de secretos. Aparte: un número de tarjeta no pinta nada en una conversación — si aparece, lo correcto es que el agente se niegue y pida que no se vuelva a hacer, no que lo «procese con cuidado».
Borrado irreversible. Eliminar archivos, correos o registros, vaciar la papelera. Una versión nueva junto a la vieja: sí. Borrar: no.
Canales personales. Mensajes privados, conversaciones que no van de trabajo. En la mayoría de productos es una restricción de la propia plataforma, y está bien que así sea.
Envíos masivos sin confirmación. Un envío no se puede retirar. Un fallo en el segmento y el correo se va a toda la base.
Mención aparte para los datos personales
Aquí no basta con limitar el acceso: hay que limitar también el volumen.
Si para la tarea basta con saber que el documento ha llegado y se lee bien, el agente no necesita el contenido de una historia clínica. Si para responderle a un cliente basta el número de pedido, no hace falta el perfil entero.
Y una regla que va aparte: donde el uso exige consentimiento, su ausencia detiene el proceso. No «lo hacemos con cuidado», sino no lo hacemos.
Qué tiene que quedar registrado
Acceso sin registro es confianza sin verificación. El mínimo que conviene exigir:
- qué ha leído el agente y cuándo;
- qué ha modificado, con la opción de ver la versión anterior;
- qué ha salido al exterior y quién lo confirmó;
- dónde se ha parado y por qué.
El último punto está infravalorado y es el más útil: por ahí se ve si tus límites funcionan o si el agente los está rodeando porque formulaste algo distinto de lo que tenías en la cabeza.
Cómo revocar
Compruébalo antes de conectar, no después. La respuesta tiene que ser sencilla: el acceso se da por OAuth y se revoca desde el propio servicio, en la sección de aplicaciones conectadas, en dos clics y sin escribir a soporte.
Si revocar un acceso exige un correo a soporte, eso no es una integración: es una dependencia.
Banderas rojas en cualquier producto
La lista es corta y nos aplica también a nosotros — úsala con todo el mundo, BossForce incluido:
- Te piden la contraseña en vez de OAuth. La contraseña de tu correo entregada a un servicio es acceso a todo y para siempre. Las integraciones serias funcionan por OAuth con permisos acotados.
- No se puede acotar el alcance. Si la única opción es «acceso a todo el buzón», no tienes elección y por tanto tampoco control.
- No hay registro de acciones. Si no se ve lo que ha pasado, no hay nada que comprobar.
- Envío sin confirmación por defecto. El ajuste «enséñamelo antes» tiene que ser el estado por defecto, no una casilla que hay que ir a buscar.
- A la pregunta sobre los límites responden «el modelo está entrenado para ser cuidadoso». El cuidado no es un límite. Un límite es que la acción sea técnicamente imposible.
Checklist antes de conectar
- qué acceso mínimo cubre la tarea;
- qué parte de eso puede quedarse solo en lectura;
- qué acciones son irreversibles y si están puestas a confirmación;
- dónde están los datos personales y si el agente necesita verlos;
- cómo se consulta el registro;
- cómo se revoca el acceso en dos minutos.
Si hay una respuesta clara a los seis puntos, la conversación sobre seguridad está cerrada: a partir de ahí es cuestión de configuración, no de confianza.