Controles de acceso para agentes y asistentes de IA

Una empresa de cincuenta personas conecta un asistente a su Drive corporativo para que el equipo pueda preguntar por procedimientos internos sin perseguir a nadie por el pasillo. La primera semana va bien. La segunda, alguien pregunta por curiosidad cuánto cobra un compañero, y el asistente contesta con una cifra exacta. La hoja de nóminas de 2019 estaba en una carpeta que en su momento se compartió “con todo el equipo” para una revisión puntual, y nadie la volvió a cerrar.

No ha habido brecha, ni ataque, ni fallo del proveedor. El asistente hizo exactamente lo que se le pidió con los permisos que tenía. El problema estaba ahí desde hacía seis años; lo único nuevo es que ahora hay algo capaz de leerlo todo de golpe y contestar en dos segundos.

Resumen

Cuando entra un asistente o un agente en una empresa, los permisos dejan de ser un asunto administrativo y pasan a ser el límite real de lo que ese sistema puede hacer. La regla de fondo es vieja y sigue funcionando: cada identidad, humana o no, accede solo a lo que necesita para su tarea. Lo nuevo son tres matices. Que leer y escribir requieren decisiones distintas. Que hace falta un registro de lo que el sistema consulta y modifica, para poder responder después a la pregunta “¿quién hizo esto?”. Y que los agentes, capaces de encadenar acciones, no reciben permiso de escritura sin alguien mirando.

Lo que la IA hace no es abrir agujeros: es encontrarlos

En casi cualquier empresa que lleve unos años funcionando, los permisos se han ido acumulando por capas. La carpeta que se compartió para un proyecto que terminó. El becario que ya no está pero cuya cuenta sigue activa. La persona que pasó de administración a comercial y conserva los dos accesos. La unidad compartida que se puso en “toda la organización” un viernes para salir del paso.

Hasta ahora eso funcionaba porque nadie tenía tiempo ni paciencia para recorrer veinte mil documentos buscando lo que no debería ver. Un asistente sí. Y un buscador conversacional convierte un desorden latente en una respuesta instantánea. Por eso INCIBE insiste en la protección de la información como base y no como último paso: la capa de IA hereda tu desorden, no lo corrige.

Mínimo privilegio, traducido a asistentes

El principio de mínimo privilegio dice que cada identidad recibe únicamente los permisos que su función necesita, ni uno más. Aplicado a un asistente, se concreta en cuatro decisiones:

1. Fuentes cerradas, no abiertas. El asistente no se conecta “al Drive”: se conecta a un conjunto explícito de carpetas o espacios. Lo demás no existe para él.
2. Permisos por función, no por persona. Si el asistente responde dudas de atención al cliente, ve la base de conocimiento de atención al cliente. No ve contratos, no ve nóminas, no ve la carpeta de dirección.
3. Identidad propia. El sistema tiene su propia cuenta, con sus propios permisos, no la cuenta de la persona que lo montó. Si hereda las credenciales del administrador, hereda todo el mapa de la empresa.
4. Herencia del usuario cuando sea posible. Algunas plataformas permiten que la respuesta respete los permisos de quien pregunta. Es lo deseable, pero conviene comprobarlo con casos reales en vez de creerlo por lo que dice el folleto.

Esa segmentación también es la traducción práctica de lo que la Agencia Española de Protección de Datos llama protección de datos por defecto: la configuración de partida es la más restrictiva, y desde ahí se abre lo justo.

Leer y escribir no son el mismo permiso

Este es el punto donde más empresas se equivocan, porque en muchas herramientas basta un clic para pasar de uno a otro.

Capacidad	Riesgo principal	Cómo tratarla
Leer documentos internos	Exposición de información a quien no debía verla	Fuentes acotadas y prueba con preguntas incómodas antes de abrir al equipo
Leer datos personales de clientes o empleados	Tratamiento sin base ni límite claros	Solo si hay motivo, con registro de quién consulta qué
Escribir borradores en un espacio propio	Ruido, versiones duplicadas	Aceptable: el borrador no es la versión buena
Modificar registros del CRM o del ERP	Datos corruptos difíciles de detectar	Con validación humana antes de guardar
Enviar correos, mensajes o pagos hacia fuera	Daño externo e irreversible	Nunca sin confirmación explícita de una persona

La línea útil es sencilla: cuanto más difícil sea deshacer una acción, más cerca tiene que estar una persona.

Trazabilidad: poder responder a “¿quién hizo esto?”

Si un dato del CRM aparece cambiado el martes, alguien tiene que poder saber si lo cambió una persona, un asistente o una integración antigua. Sin eso, cada incidente se convierte en una investigación a ciegas.

Lo mínimo que conviene registrar: qué fuente consultó el sistema, en nombre de quién actuó, qué modificó y cuándo, y qué peticiones rechazó. Ese registro tiene un segundo uso, más práctico que el de auditoría: leerlo un rato revela qué está intentando hacer la gente con la herramienta, que casi nunca es lo que se había previsto.

Y tiene un tercero, incómodo pero real: si algún día hay una brecha, el plazo para notificar corre desde que se tiene conocimiento. La guía de brechas de seguridad de la AEPD describe el proceso, y llegar a él sin registros es llegar sin saber qué contar.

Los agentes son un caso aparte

Un asistente responde preguntas. Un agente encadena acciones para alcanzar un objetivo: consulta, decide, ejecuta y vuelve a empezar. La diferencia en materia de permisos es enorme, porque un error deja de ser una respuesta mala y pasa a ser una secuencia de acciones malas.

Tres reglas para no llevarse un disgusto:

• Escritura solo con supervisión. El agente prepara la acción y una persona la confirma. Cuando se automatice la confirmación, que sea para un tipo de acción concreto, acotado y reversible.
• Límites duros, no instrucciones amables. “No envíes correos a clientes” escrito en el prompt no es un control de acceso: es una sugerencia. El control está en no darle la credencial de envío.
• Un agente, un alcance. Es tentador montar uno que lo haga todo. Es mucho más seguro tener tres con permisos distintos, porque el día que uno falla, falla dentro de su parcela.

Si tu punto de partida es gente usando herramientas por su cuenta, conviene ordenar antes qué información puede salir hacia una herramienta externa, porque ese es el mismo problema visto desde el otro lado.

Si hoy no puedes decir con certeza quién accede a qué carpeta ni qué información entra en vuestras herramientas de IA, cuéntanos cómo está montado antes de conceder ni un permiso más.

La revisión que nadie tiene en el calendario

Los permisos no se pudren de golpe: se pudren despacio. Por eso la revisión periódica es la única medida que sostiene todo lo anterior, y la que casi nadie hace.

Una versión realista para una pyme, dos veces al año, en una tarde:

1. Lista de cuentas activas frente a lista de personas que trabajan hoy en la empresa. Las que sobran se desactivan.
2. Carpetas y espacios compartidos con enlaces abiertos: se cierran o se justifican por escrito.
3. Cada asistente y cada agente: qué fuentes ve, qué puede escribir, quién es su responsable.
4. Integraciones y conexiones antiguas que siguen con permisos vivos y ya no las usa nadie.
5. Excepciones concedidas desde la última revisión: cada una con dueño y fecha de caducidad.

Las plantillas de políticas de seguridad para pymes de INCIBE sirven de base para dejarlo escrito sin partir de cero. Y si buscas un marco más formal de referencia, el Esquema Nacional de Seguridad desarrolla el control de acceso con un nivel de detalle que, aunque obligue solo en determinados ámbitos, se puede leer como guía.

Errores frecuentes

Dar al asistente la cuenta del administrador. Es lo rápido el primer día y lo que arruina cualquier control después. Cuenta propia, permisos propios.

Confiar la restricción a las instrucciones del modelo. Lo que está escrito en el prompt se puede rodear. Lo que no está en la credencial, no.

Abrir el piloto a toda la empresa. Un grupo pequeño durante unas semanas encuentra los agujeros con mucho menos ruido.

No probar con las preguntas incómodas. Antes de abrir el asistente, alguien tiene que preguntarle por nóminas, por contratos y por el correo de dirección. Si contesta, todavía no está listo.

Preguntas frecuentes

¿Debe el asistente ver lo mismo que la persona que le pregunta?

Es el diseño más sensato: la respuesta se limita a lo que esa persona ya podría abrir por su cuenta. El problema es que muchas plataformas no lo implementan bien, o lo hacen solo con determinadas fuentes. Compruébalo con una prueba real: dos usuarios con permisos distintos haciendo la misma pregunta sobre un documento restringido. Si los dos reciben la misma respuesta, el aislamiento no existe.

¿Cómo se revoca el acceso de un agente que ya está funcionando?

Igual que el de una persona, y por eso importa que tenga identidad propia desde el principio: se desactiva su cuenta o se retiran sus credenciales de conexión. Lo que suele fallar no es la revocación, sino el inventario: nadie recuerda cuántas integraciones y claves se crearon durante el montaje. Anota cada credencial emitida el mismo día que la emites, con su responsable.

¿Hace falta esto en una empresa de diez personas?

Hace falta la parte proporcionada. Con diez personas no necesitas un catálogo de roles, pero sí saber qué carpetas ve el asistente, que tenga cuenta propia, que no pueda enviar nada al exterior sin confirmación y que alguien revise los accesos dos veces al año. Media jornada de trabajo, y evita justo el escenario del principio de este artículo.

Siguiente paso

Los permisos heredados de hace años son el agujero más común en cuanto entra una herramienta de IA nueva. Antes de conceder accesos nuevos, conviene mirar los que ya existen: cuéntanos qué carpetas y qué herramientas están en juego y te damos una primera lectura honesta, sin compromiso.