Claude y Copilot están en tu sistema de archivos. ¿Quién decide qué pueden ver?
En algún momento de los últimos doce meses, los asistentes de IA llegaron a los sistemas de archivos de tu organización. Tal vez TI lo aprobó. Tal vez una unidad de negocio implementó Microsoft Copilot como parte de una adopción de M365. O quizás empleados conectaron Claude u otra herramienta de IA a sus unidades de trabajo por su cuenta.
Sin importar cómo ocurrió, el resultado es el mismo: los sistemas de IA ahora recuperan archivos empresariales en nombre de los empleados, y en la mayoría de las organizaciones, nadie ha decidido explícitamente qué pueden ver esos sistemas de IA. Los controles de acceso que regulan el acceso humano a archivos no fueron diseñados para actores de IA. Los registros de auditoría que rastrean el acceso humano a archivos no están configurados para capturar las recuperaciones de IA con el nivel de atribución que exige el cumplimiento. Las políticas que definen quién puede acceder a qué fueron escritas para empleados, no para sistemas de IA actuando en nombre de empleados.
Esta publicación es para CISOs y responsables de cumplimiento que necesitan responder una pregunta que ahora es operacionalmente urgente: ¿quién decide realmente qué pueden ver los asistentes de IA en tu sistema de archivos?
Resumen Ejecutivo
Idea principal: Los asistentes de IA acceden a sistemas de archivos empresariales bajo modelos de autorización diseñados para usuarios humanos — con derechos de acceso, límites de sesión y registros de auditoría que son estructuralmente inadecuados para actores de IA. La distancia entre lo que las organizaciones creen que cubren sus controles de acceso para IA y lo que realmente cubren es significativa, en gran parte invisible y conlleva una exposición directa de cumplimiento.
Por qué deberías preocuparte: Cuando un regulador o auditor pregunte a qué archivos accedió tu IA, quién autorizó cada recuperación y cómo puedes demostrar que se aplicaron las clasificaciones de sensibilidad — esas preguntas solo tienen respuesta si tu integración de IA fue diseñada para generarlas. La mayoría no lo está. El momento de descubrir esta distancia es antes de la consulta, no durante ella.
5 conclusiones clave
- Los asistentes de IA que acceden a sistemas de archivos empresariales suelen operar con cuentas de servicio que tienen permisos superiores a los de cualquier usuario individual — lo que significa que la IA puede recuperar documentos que el empleado que hace la consulta no tiene permitido ver por ningún otro canal.
- La autorización a nivel de sesión no equivale a la aplicación de RBAC y ABAC por solicitud. Es un único punto de control seguido de un acceso no monitoreado a velocidad de máquina.
- La mayoría de los registros de auditoría de acceso a archivos por IA registran la identidad de la cuenta de servicio, no del usuario humano cuya consulta desencadenó la recuperación. Esto no es solo una carencia en el registro — es una brecha de cumplimiento de HIPAA, una brecha de cumplimiento de GDPR y una brecha para investigaciones forenses.
- La clasificación de datos y las etiquetas de sensibilidad aplicadas a los archivos no afectan la recuperación por parte de la IA a menos que la integración de IA las evalúe explícitamente en la capa de recuperación. Un asistente de IA puede mostrar un documento marcado como Confidencial o Restringido tan fácilmente como uno no clasificado.
- La pregunta de gobernanza no es si se debe permitir el acceso de IA a archivos — los empleados son más productivos con ello, y bloquearlo fomenta la IA en la sombra. La pregunta es si el acceso de IA a archivos está gobernado por las mismas políticas, con la misma aplicación y el mismo registro de auditoría, que rigen cualquier otra forma de acceso a datos en la organización.
El modelo de acceso que nadie aprobó
Cuando una organización implementa un asistente de IA con acceso a sistemas de archivos, normalmente configura una cuenta de servicio para autenticar la IA ante el repositorio de archivos. A esa cuenta de servicio se le otorgan permisos lo suficientemente amplios para trabajar con toda la población de usuarios — porque la IA necesita poder recuperar cualquier archivo que cualquier usuario pueda necesitar legítimamente. El resultado es una sola credencial con acceso a todo lo que está dentro del alcance, compartida por todos los usuarios que interactúan con la IA.
Ninguna organización crearía deliberadamente una cuenta de usuario humano con este perfil de permisos. Una cuenta compartida con acceso a todos los archivos confidenciales del repositorio, utilizable por cualquier empleado, sin restricciones de acceso por usuario — eso fallaría en cualquier revisión de gestión de identidades y accesos, en cualquier evaluación de riesgos y en cualquier auditoría de cumplimiento.
Pero cuando la misma estructura de permisos se implementa para una cuenta de servicio de IA, frecuentemente pasa la revisión porque parece infraestructura, no política de acceso. La IA se trata como un sistema, no como un actor que toma decisiones de acceso a datos en nombre de los usuarios. Esa distinción no resiste el escrutinio — y ciertamente no resiste una consulta regulatoria.
La consecuencia práctica es que un asistente de IA conectado a un sistema de archivos empresarial mediante una cuenta de servicio puede recuperar documentos que el empleado que hace la consulta nunca estuvo autorizado a ver. Un analista junior que pide a Claude un resumen del panorama competitivo puede recibir una respuesta basada en documentos clasificados por encima de su nivel de autorización. Un representante de atención al cliente que pide a Copilot el historial de una cuenta puede mostrar sin querer archivos de otras cuentas. La IA no está funcionando mal — está haciendo exactamente lo que fue configurada para hacer. El modelo de acceso simplemente nunca fue diseñado para evitar esto.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Leer ahora
La autorización a nivel de sesión no es confianza cero. Es un perímetro con una sola puerta.
La respuesta de gobernanza más común ante las preocupaciones sobre el acceso de IA a archivos es señalar la autenticación: la IA se autentica antes de conectarse, se verifica el acceso, la sesión se establece dentro de la arquitectura de confianza cero de la organización. Esto es correcto hasta cierto punto — pero no es suficiente.
La autenticación a nivel de sesión verifica que el sistema de IA tenga permiso para conectarse al repositorio de archivos en el momento en que se establece la sesión. No verifica que el usuario específico que dirige la IA para una consulta concreta esté autorizado a acceder al archivo específico que la IA va a recuperar. Una vez abierta la sesión, todas las operaciones posteriores heredan la autorización establecida en el momento de la conexión — la IA puede recuperar cualquier cosa a la que la cuenta de servicio tenga acceso, para cualquier usuario, con cualquier propósito, sin una sola verificación adicional de autorización.
Esto equivale a verificar la identidad de un visitante en la entrada del edificio y luego darle acceso sin restricciones a todas las oficinas, salas de servidores y despachos ejecutivos durante toda su visita. La verificación inicial ocurrió. Todo lo que sigue es confianza implícita — que es precisamente lo que los principios de intercambio de datos de confianza cero buscan eliminar.
Para los usuarios humanos, los controles a nivel de sesión son una aproximación razonable de la verificación continua porque el comportamiento de la sesión humana está limitado por el ritmo operativo humano. Para un sistema de IA que puede ejecutar miles de operaciones de archivos en una sola sesión, la autorización a nivel de sesión es un único punto de control seguido de un periodo de acceso no monitoreado a velocidad de máquina. Eso es un modelo perimetral. No es confianza cero.
La aplicación de RBAC y ABAC por solicitud significa que cada operación individual de archivo — cada recuperación, cada búsqueda, cada descarga — se evalúa según los derechos de acceso reales del usuario solicitante en el momento en que ocurre. La IA no hereda la autorización a nivel de sesión; hereda los permisos específicos del usuario específico cuya consulta está ejecutando, solo para esa consulta. Si ese usuario no está autorizado a ver un documento, la IA no puede recuperarlo — sin importar a qué pueda acceder la cuenta de servicio, sin importar el estado de la sesión, sin importar cómo se formule la consulta.
Tus etiquetas de sensibilidad no te protegen de la IA — a menos que la IA las revise
La mayoría de las organizaciones con programas de gobernanza de datos maduros han invertido en marcos de clasificación de datos — etiquetas de sensibilidad aplicadas a archivos que definen cómo deben manejarse, quién puede acceder a ellos y qué se puede hacer con ellos. Microsoft Information Protection, sistemas nativos de clasificación de archivos, flujos de trabajo de clasificación manual — todo esto representa una inversión real en gobernanza, y funcionan bien para regular el acceso humano a archivos.
No tienen ningún efecto sobre la recuperación por parte de la IA a menos que la integración de IA las evalúe explícitamente. Un documento etiquetado como Confidencial no es más difícil de recuperar para una IA que uno no clasificado. La etiqueta de sensibilidad es metadato adjunto al archivo. Si ese metadato se evalúa antes de devolver el archivo a una IA — o se ignora por completo — depende totalmente de cómo se haya diseñado la integración de IA. En la mayoría de las integraciones de sistemas de archivos con IA, las etiquetas de sensibilidad no se evalúan en la capa de recuperación. La IA recupera los documentos más relevantes según la consulta, y la puntuación de relevancia no tiene en cuenta la clasificación de sensibilidad.
La implicación para los responsables de cumplimiento es directa: los controles de gobernanza de datos en los que has invertido no se extienden al acceso de IA a menos que tu integración de IA haya sido diseñada explícitamente para aplicarlos. Cada decisión de clasificación, cada etiqueta de sensibilidad, cada restricción de acceso aplicada a un archivo en tu repositorio — nada de eso limita la recuperación por IA a menos que la integración de IA lo evalúe en la capa de recuperación. Una organización que cree que su marco de clasificación protege archivos sensibles de la exposición no autorizada por IA tiene una falsa sensación de seguridad que no resistirá una auditoría.
Cinco fallos de control de acceso — y cómo se ven en la práctica
| Fallo de control de acceso | Qué falta | Qué ocurre realmente |
|---|---|---|
| Cuenta de servicio con privilegios excesivos | El asistente de IA opera con una cuenta de servicio con acceso a todos los recursos compartidos de archivos; cualquier usuario puede consultar cualquier archivo al que la cuenta tenga acceso | Un analista junior pide a Claude que resuma el pipeline de M&A. Claude recupera documentos de acuerdos a nivel de junta directiva que el analista no está autorizado a ver. |
| Solo autorización a nivel de sesión | La autorización de IA se verifica al momento de la conexión; todas las operaciones posteriores heredan esa autorización sin importar lo que se solicite | Un contratista se autentica durante el horario laboral; su sesión de IA permanece activa. Fuera de horario, la IA sigue recuperando documentos sin nueva verificación. |
| Sin aplicación de etiquetas de sensibilidad | La IA recupera documentos según la relevancia del contenido sin evaluar las etiquetas de clasificación | Un empleado pide a Copilot un análisis de la competencia. Recupera documentos marcados como Confidencial — incluyendo un borrador de hoja de términos de adquisición. |
| Falta de atribución por usuario | Todo el acceso a archivos por IA se registra bajo la cuenta de servicio; no hay registro de qué usuario desencadenó cada recuperación | Una investigación de filtración de datos revela miles de accesos a archivos por «AI-service-account». No hay registro de auditoría que identifique quién inició las consultas. |
| Sin limitación de tasa en la recuperación | La IA puede ejecutar recuperaciones ilimitadas de archivos en una sesión; sin controles de volumen en la capa de datos | Una sesión de IA comprometida recupera 40,000 documentos en 90 minutos antes de que se reconozca la alerta del SIEM. |
Las preguntas que no puedes responder — hasta que puedas
Para los responsables de cumplimiento, el problema de gobernanza del acceso de IA a archivos se resume en una pregunta específica e incómoda: si un regulador o auditor preguntara a qué accedieron tus asistentes de IA, quién autorizó cada recuperación y cómo puedes demostrar que cumpliste tus obligaciones de protección de datos — ¿podrías responder?
La respuesta depende totalmente de lo que tu integración de IA fue diseñada para registrar y aplicar. La mayoría de los registros de auditoría de acceso a archivos por IA solo indican que una cuenta de servicio recuperó un archivo. No registran qué empleado desencadenó la recuperación, si la recuperación fue coherente con los derechos de acceso de ese empleado, si se evaluó la clasificación de sensibilidad del archivo o qué se hizo con el contenido.
Esto no es un problema de configuración de registros — es un problema de arquitectura. El nivel de atribución necesario para responder preguntas de cumplimiento debe capturarse en el momento de la recuperación; no puede reconstruirse después.
La Regla de Mínimo Necesario de HIPAA exige que el acceso a información de salud protegida se limite a lo mínimo necesario para cumplir el propósito. Cuando una IA recupera PHI para responder una consulta, demostrar el cumplimiento de mínimo necesario requiere saber exactamente qué se recuperó, en respuesta a qué consulta y por qué usuario.
GDPR exige que el procesamiento de datos personales tenga una base legal documentada — lo que, para la recuperación por IA, requiere saber qué usuario dirigió la recuperación y con qué propósito. SOX exige registros completos de acceso a datos financieros.
El cumplimiento de FedRAMP exige registros de auditoría para todas las operaciones dentro de sistemas de información autorizados, incluidas las operaciones de IA, con un nivel de atribución que identifique al actor humano responsable.
Lo que preguntarán los auditores — y lo que se requiere para responder
| Pregunta que hará un auditor o regulador | Marco aplicable | Qué se requiere para responderla |
|---|---|---|
| ¿Qué empleados han usado un asistente de IA para acceder a archivos que contienen PHI o información personal identificable en los últimos 90 días? | HIPAA, GDPR | Requiere atribución por usuario en los registros de auditoría de IA — el registro solo por cuenta de servicio no puede responder esta pregunta |
| ¿Qué documentos específicos recuperó la IA en respuesta a una consulta de un usuario? | HIPAA Mínimo Necesario, minimización de datos de GDPR | Requiere registros a nivel de consulta que vinculen cada recuperación con la solicitud específica que la desencadenó |
| ¿Se impidió que la IA accediera a documentos que el usuario solicitante no estaba autorizado a ver? | Todos los marcos regulados | Requiere aplicación de RBAC/ABAC por solicitud con decisiones de política registradas — no solo autenticación de sesión |
| ¿Podemos demostrar que el acceso de IA a los datos fue coherente con las clasificaciones de sensibilidad aplicables? | GDPR, SOX, FedRAMP | Requiere evaluación de etiquetas de sensibilidad en la capa de recuperación y documentación de que se aplicaron |
| ¿Cuál es el historial completo de acceso para un archivo específico que pudo haber sido recuperado por IA? | HIPAA, derecho de acceso de GDPR, eDiscovery | Requiere registro de auditoría a nivel de archivo que incluya recuperaciones por IA con el mismo nivel de atribución que el acceso humano |
Bloquear la IA no es la respuesta. Gobernarla sí lo es.
La reacción instintiva ante las preocupaciones sobre el acceso de IA a archivos — bloquear las herramientas de IA, revocar el acceso, esperar a que el marco de gobernanza se ponga al día — genera otro problema. Los empleados que encuentran la IA realmente útil para su trabajo la usarán por otros medios. Cuentas personales, herramientas de IA en el navegador, aplicaciones de consumo que no tienen conexión con la gobernanza empresarial ni acceso a datos empresariales autorizados.
Esto no es hipotético: la IA en la sombra ya está presente en la mayoría de las organizaciones, y restringir las herramientas de IA autorizadas acelera en lugar de reducir el uso no gobernado de IA.
La pregunta de gobernanza no es si se debe permitir el acceso de IA a archivos. Es si el acceso de IA a archivos está gobernado por las mismas políticas, con la misma aplicación y el mismo registro de auditoría, que rigen cualquier otra forma de acceso a datos en la organización. Un empleado que accede a un archivo mediante una aplicación de escritorio está sujeto a controles de acceso, monitoreo de sesión y registro de auditoría.
Ese mismo empleado accediendo al mismo archivo mediante un asistente de IA debe estar sujeto a controles idénticos — autorización por solicitud, aplicación de etiquetas de sensibilidad, registro dual de atribución. Si la vía de IA omite cualquiera de esos controles, representa una brecha de gobernanza que tarde o temprano será explotada, descubierta o ambas cosas.
Cómo Kiteworks garantiza que la IA solo vea lo que debe
Las organizaciones que gestionarán la adopción de IA sin crear responsabilidad de cumplimiento no son las que bloquean la IA por más tiempo — son las que extienden la gobernanza a la IA más rápido. Esa extensión requiere una arquitectura donde la respuesta a «quién decide qué puede ver la IA» sea la misma que para cualquier otro actor: el motor de políticas, evaluado en el momento de cada solicitud individual, según los derechos de acceso reales del usuario específico.
Kiteworks aplica esto mediante RBAC y ABAC por solicitud a nivel de operación de IA — no en el establecimiento de la sesión. Cada recuperación de archivo, cada búsqueda, cada operación de carpeta ejecutada por Claude, Copilot o cualquier asistente de IA compatible con MCP a través de la Red de Datos Privados de Kiteworks se evalúa según los derechos de acceso actuales del usuario autenticado antes de devolver los datos.
La IA hereda los permisos del usuario — no los de la cuenta de servicio — para cada operación individual. Si el usuario no puede ver un documento, la IA no puede recuperarlo, sin importar el estado de la sesión, la construcción de la consulta o a qué pueda acceder la cuenta de servicio.
La aplicación de etiquetas de sensibilidad ocurre en la capa de recuperación: las clasificaciones de Microsoft Information Protection y las políticas de clasificación de datos de Kiteworks se evalúan antes de devolver los datos a la IA. Los documentos confidenciales no se muestran en respuesta a consultas de usuarios no autorizados — no porque se le indique a la IA que no los mencione, sino porque la capa de gobernanza no los devuelve.
Cada operación de archivo por IA se registra con doble atribución — identidad del sistema de IA y usuario humano autenticado — alimentando el registro de auditoría de Kiteworks e integrándose con SIEM en tiempo real. Las preguntas de cumplimiento de la tabla anterior tienen respuesta — porque la arquitectura fue diseñada para generarlas.
Para los CISOs que necesitan demostrar que el acceso de IA a archivos está gobernado con el mismo rigor que el acceso humano, y para los responsables de cumplimiento que necesitan documentación lista para auditoría sobre qué accedió la IA y quién lo autorizó, Kiteworks proporciona la capa de datos gobernada que lo hace posible. Para ver cómo funciona, agenda una demo personalizada hoy mismo.
Preguntas frecuentes
La mayoría de los asistentes de IA empresariales acceden a los sistemas de archivos mediante cuentas de servicio configuradas con permisos lo suficientemente amplios para trabajar con toda la población de usuarios. Esto significa que la IA puede recuperar cualquier archivo al que la cuenta de servicio tenga acceso — sin importar si el empleado que dirige la IA está autorizado a ver ese archivo. Combinado con la autorización a nivel de sesión, que otorga acceso implícito durante toda la sesión, esto crea un modelo de acceso donde la IA efectivamente elude los controles que regulan el acceso humano a archivos. El riesgo no es hipotético: los empleados pueden recibir sin querer respuestas generadas por IA basadas en documentos que nunca estuvieron autorizados a ver.
Solo si la integración de IA fue diseñada explícitamente para evaluarlas. Las etiquetas de clasificación de datos y las clasificaciones de sensibilidad aplicadas a los archivos son metadatos — no afectan la recuperación por IA a menos que la integración las evalúe en la capa de recuperación antes de devolver los datos. En la mayoría de las integraciones de sistemas de archivos con IA, la relevancia para la consulta determina qué se recupera; la clasificación de sensibilidad no se considera. Las organizaciones que creen que su marco de clasificación protege archivos sensibles de la exposición por IA deben verificar si su integración de IA realmente lo aplica.
La autorización a nivel de sesión verifica el sistema de IA al momento de la conexión y otorga acceso implícito durante toda la sesión. La aplicación de RBAC y ABAC por solicitud evalúa los derechos de acceso reales del usuario específico para cada operación de IA — cada recuperación de archivo, cada búsqueda, cada navegación de carpetas — en el momento en que se solicita. La diferencia en la práctica: con autorización a nivel de sesión, cualquier archivo accesible para la cuenta de servicio puede recuperarse para cualquier usuario; con la aplicación por solicitud, solo los archivos que el usuario solicitante esté específicamente autorizado a acceder pueden recuperarse, solo para esa solicitud.
Ambos marcos exigen documentación a nivel de atribución que identifique al humano responsable de cada evento de acceso a datos. Para el acceso de IA a archivos, esto significa registro dual de atribución: cada recuperación debe registrar tanto la identidad del sistema de IA como el usuario humano autenticado cuya consulta la desencadenó, junto con el archivo específico recuperado, la marca de tiempo y la acción realizada. El cumplimiento de HIPAA además exige que el acceso a PHI cumpla el estándar de mínimo necesario, lo que requiere saber exactamente qué se recuperó en respuesta a qué consulta. El registro solo por cuenta de servicio — que indica que «la IA accedió a un archivo» sin identificar al solicitante humano — no cumple los requisitos de documentación de ninguno de los dos marcos.
El objetivo es extender las políticas de gobernanza de datos existentes a los actores de IA — no crear políticas específicas para IA ni bloquear herramientas de IA que los empleados realmente encuentran útiles. Esto implica implementar una arquitectura de integración de IA que aplique autorización por solicitud usando las mismas políticas de RBAC y ABAC que regulan el acceso humano, evalúe las etiquetas de sensibilidad en la capa de recuperación y genere registros de auditoría con doble atribución para cada operación de IA. Las organizaciones que logran esto ofrecen a los empleados acceso a IA gobernado que es más capaz y más seguro que las alternativas no gobernadas que de otro modo usarían.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: Por qué el 91% de las pequeñas empresas juegan a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.