Imagina que un empleado del equipo financiero abandona la compañía a las 9 de la mañana un lunes, pero tu sistema sincroniza los datos solo a las 2 de la madrugada siguiente. Durante diecisiete horas, esa persona podría seguir accediendo a documentos financieros, porque el sistema aún no refleja el cambio. Este ejemplo, utilizado por la empresa Truto y reconocido por numerosos equipos de seguridad, ilustra un problema muy común en la gestión de permisos dentro de sistemas de inteligencia artificial (IA).
El problema se agrava cuando, durante la revisión de seguridad, alguien plantea una pregunta crítica: ¿cómo evitar que un modelo de IA resuma la revisión salarial del CEO para un becario que preguntó inocentemente sobre las bandas salariales? La mayoría de los equipos no sabe responder, simplemente colocan un filtro. Sin embargo, los filtros aplicados después de ensamblar el contexto —el conjunto de información que el modelo ve para responder— llegan tarde para garantizar una seguridad real.
La solución más efectiva debe ser estructural: los permisos no deben aplicarse como un filtro tras formar el contexto, sino integrarse en el proceso mismo de ensamblaje de ese contexto. En ese momento final antes de que el modelo acceda a la información, el sistema decide qué piezas del conocimiento empresarial dar a una persona concreta según su identidad y la consulta específica. 
Esta idea, clave para evitar exposiciones accidentales de datos sensibles, está en el centro de las últimas arquitecturas que están adoptando los grandes proveedores de plataformas. Sin embargo, muchos productos que las empresas usan aún no lo han implementado completamente.
Lo anunciado no siempre está disponible
En junio de 2026, Amazon Web Services (AWS) presentó AWS Context en el AWS Summit de Nueva York, un sistema que promete respetar los permisos configurados en los lagos de datos mediante Glue Data Catalog, SageMaker Unified Studio y Lake Formation. Este sistema verificaría la identidad del usuario con políticas granulares que abarquen columnas, filas y celdas, mucho más detalladas que los permisos básicos en S3.
No obstante, tres meses después, AWS Context sigue sin estar disponible comercialmente, sin fecha clara de lanzamiento ni información sobre precios o regiones. El anuncio causó confusión porque coincidió con la salida general de Amazon Bedrock Managed Knowledge Base, por lo que a menudo se toman como lo mismo.
Por su parte, Microsoft adelantó un paso y lanzó el 16 de junio Work IQ API, que funciona respetando los permisos de Microsoft 365 en contexto del usuario autenticado, permitiendo su activación inmediata en producción. Un día antes que AWS, Microsoft ya ofrecía una solución real para la recuperación de información sensible cuya disponibilidad contrasta con la de AWS.
Otro actor, Databricks, también ha avanzado extendiendo Unity Catalog para agentes de IA, aunque sus socios advierten que la protección se implementa en el tiempo de ejecución Databricks Runtime, lo cual deja vulnerabilidades si se accede a la fuente de datos desde otras herramientas fuera de ese entorno.
Mientras tanto, muchas organizaciones han implementado versiones simplificadas sin control de identidad, utilizando índices planos y dejando la gestión real de permisos como una promesa futura. Pero esta discrepancia entre visión y realidad manifiesta la importancia de resolver los permisos en el ensamblaje del contexto.
El lago de datos no es todo el negocio
Lake Formation controla de manera efectiva los permisos dentro del lago de datos, pero esos mismos permisos no se extienden automáticamente a herramientas de uso cotidiano como Salesforce, Slack, Google Drive o Confluence. Cada plataforma posee y aplica sus propias reglas de acceso, o puede no tenerlas, creando vacíos en la seguridad.
AWS reconoce esos límites y, en su guía de agosto, sugiere que el agente actúa más como un orquestador que un guardián, delegando la aplicación de permisos a los servicios finales como Salesforce mediante tokens que reflejan la identidad real del usuario. Esta separación es lógica, pero resalta que Lake Formation no integra ni controla permisos fuera de su ecosistema.
Además, AWS recuerda que el filtrado de metadatos es una aplicación en la capa del software, no una condición de identidad integrada en el propio sistema de almacenamiento (IAM). Eso marca la frontera entre sus garantías y lo que debe implementar el cliente. En otras palabras, los tags o etiquetas en los fragmentos de datos no son una barrera real de identidad, sino una ayuda que espera ser respetada por el código que los maneja.
El fallo cuando la autorización llega tarde
El error común es realizar la autorización después de ya haber recuperado y procesado los documentos. Si el contenido sensible es extraído, ordenado o resumido sin la autorización previa, se abre una ventana durante la cual se puede acceder o filtrar información no autorizada. Esa ventana representa un riesgo importante de exposición.
De hecho, investigaciones recientes de Penn State demostraron que mecanismos como la sumarización —utilizados para reducir información— pueden funcionar contra ataques generales pero aumentar el riesgo frente a ataques específicos, ya que resaltan detalles sensibles que el atacante desea obtener. Otro estudio también mostró que combinar dos sistemas con seguridad individual puede crear una vulnerabilidad si no se reevalúan los permisos al pasar la información entre ambos.
Estos problemas no son marginales: la diseminación no autorizada de información sensible escaló del sexto al segundo lugar en los riesgos de seguridad para aplicaciones de modelos de lenguaje en el informe OWASP 2025. El informe recomienda usar almacenes conscientes de la identidad para evitar filtraciones entre usuarios que comparten bases de datos vectoriales.
En el contexto empresarial, Microsoft 365 Copilot ejemplifica esto: en su primer año, una encuesta mostró que el miedo a compartir información sensible retrasó su adopción en un 40%, debido a preocupaciones de privacidad. Microsoft garantiza que Copilot solo muestra resultados que el usuario puede ver, lo que no impide que la información sensible esté potencialmente expuesta en la base de datos, simplemente su acceso se controla en el momento de la consulta.
Cuándo y dónde debe llegar la identidad
La lección clave es que resolver la identidad en el momento de ensamblar el contexto es necesario, pero no suficiente. El sistema de permisos debe reflejar correctamente la realidad actual para que la recuperación de información sea segura. Si esa base de permisos está desactualizada o es demasiado permisiva, el acceso indebido seguirá ocurriendo aunque el sistema respete sus reglas.
Por eso, la etapa de ensamblaje es el último punto donde los permisos aún importan, ya que tras esa fase el modelo de IA habrá leído el contenido y no hay vuelta atrás. Grandes empresas tecnológicas, estándares de seguridad como OWASP y la experiencia de despliegue en producción coinciden en esta conclusión.
Finalmente, cualquier organización que quiera implementar sistemas de recuperación y generación de contenido mediante IA debería plantearse cuatro preguntas fundamentales: dónde se resuelve la identidad (antes o después de la recuperación), qué parte del contexto existe fuera del lago de datos en plataformas diversas, cuál es el tiempo máximo de desactualización de los permisos y si la autorización se verifica en cada paso o solo al principio.
Si estas cuestiones generan dudas incómodas, es una señal para revisar la arquitectura y evitar que proyectos innovadores derivados de IA se conviertan en retos críticos de seguridad que comprometan datos empresariales sensibles.
