Los proveedores de IA adoptan el ensamblaje de contexto para aplicar permisos en tiempo real

AWS, Microsoft y Databricks han convergido en una arquitectura que llama ensamblaje de contexto: el momento en que el sistema decide qué fragmentos de conocimiento empresarial entregar a un modelo para un usuario concreto. La diferencia clave es que el ensamblaje ocurre antes de que el modelo vea los datos, de modo que los permisos se aplican estructuralmente y no como un filtro posterior.

En la práctica, AWS anunció AWS Context en junio, describiéndolo como una capa que hereda los permisos IAM y de Lake Formation del usuario que llama al agente. Sin embargo, la característica sigue en fase "coming soon" sin fecha de disponibilidad ni precios. Lo mismo ocurrió con Amazon Bedrock Managed Knowledge Base, que sí se lanzó, lo que ha generado confusión entre ambas ofertas.

Microsoft, por su parte, lanzó el Work IQ API el 16 de junio, disponible hoy y facturable mediante Copilot Credits. Este API opera bajo el usuario autenticado, respeta los permisos de Microsoft 365 y permite a los administradores activarlo inmediatamente. La disponibilidad contrastante muestra que, aunque la arquitectura sea idéntica, la ejecución varía entre proveedores.

Databricks ha extendido su Unity Catalog para incluir agentes, pero la protección está anclada al runtime de Databricks y no se propaga a herramientas externas como BI o servidores MCP. Por eso, cuando un agente necesita combinar datos de varios sistemas (Salesforce, Slack, Google Drive, etc.), el ensamblaje de contexto debe orquestar la autorización cruzada, algo que todavía depende de la lógica de la aplicación.

AWS documenta que su API bedrock:Retrieve no expone filtros de metadatos como clave de condición IAM, indicando que la garantía de autorización termina en el agente, que actúa como orquestador, no como guardián. Cada servicio downstream (Salesforce, GitHub, Jira) sigue aplicando sus propias reglas de compartición.

En resumen, la tendencia es clara: los permisos deben incorporarse al proceso de ensamblaje de contexto, no como filtros posteriores. Las organizaciones que ya usan RAG deberán revisar sus pipelines y asegurarse de que la autorización se aplique antes de la recuperación de documentos, o de lo contrario seguirán expuestas a fugas de información.

Qué sigue: monitorizar la disponibilidad de AWS Context, evaluar la integración de Work IQ API en entornos Microsoft 365 y considerar la extensión de Unity Catalog en Databricks. La decisión de adoptar una solución dependerá de la urgencia de cumplir con requisitos de seguridad y de la capacidad de la infraestructura para soportar el ensamblaje de contexto en tiempo real.