Configuración de Dust Spaces y Control de Acceso Basado en Roles: Cómo Prevenir Fugas de Datos Interdepartamentales en Asistentes de IA Empresariales

Cuando las organizaciones despliegan asistentes de inteligencia artificial generativa a gran escala, los administradores de TI y los directores de cumplimiento y seguridad se enfrentan a un desafío crítico: los empleados obtienen un aumento masivo de productividad al consultar bases de conocimiento corporativas mediante lenguaje natural, pero las arquitecturas convencionales de Generación Aumentada por Recuperación (RAG) introducen riesgos graves de fuga de información entre departamentos. Si un empleado de marketing pregunta a un asistente corporativo general: "¿Cuáles fueron los aumentos salariales aprobados el mes pasado para el equipo directivo?" o "Resume la estrategia procesal confidencial sobre el litigio con nuestro proveedor", un sistema RAG tradicional que consulte un almacén de vectores unificado recuperará y sintetizará sin filtros dichos documentos reservados.

Confiar en barreras a nivel de instrucciones del sistema (Prompt Guardrails, como indicar al modelo "no respondas sobre temas salariales") resulta insuficiente frente a inyecciones de comandos maliciosas, formulaciones indirectas o variaciones semánticas. El aislamiento de datos empresariales debe ser determinista y arquitectónico, garantizando que los datos no autorizados nunca ingresen en la ventana de contexto del modelo de lenguaje (LLM).

Dust resuelve este problema mediante un Modelo de Permisos de Doble Capa (Dual-Layer Permission Model), complementado con Spaces (contenedores de datos aislados), Control de Acceso Basado en Roles (RBAC), aprovisionamiento de directorios mediante SCIM e IdP y delimitación de alcance a nivel de conectores. Esta guía detalla cómo los administradores de TI pueden configurar metódicamente Dust Spaces y matrices de privilegios para implementar asistentes de IA seguros que respeten estrictamente las fronteras departamentales.

1. Arquitectura Central: El Modelo de Permisos de Doble Capa de Dust

Para impedir cualquier fuga de datos entre departamentos, es imprescindible desacoplar el acceso del agente a los datos del acceso de los usuarios al agente. Las plataformas SaaS tradicionales emplean un modelo de acceso unidimensional: ¿tiene el usuario X permiso para ver el documento Y? Sin embargo, los asistentes autónomos pueden sintetizar, cruzar y transformar información en representación del usuario, eludiendo controles simples.

Dust estructura la seguridad mediante dos capas complementarias:

[ Sistemas Externos (Drive, SharePoint, Slack, Notion) ]
                         │
                         ▼ (Alcance de Administrador y Cuenta de Servicio)
                 [ Conexiones de Dust ]
                         │
                         ▼ (Subconjuntos de Datos Asignados)
          ┌──────────────┴──────────────┐
          ▼                             ▼
   [ Open Spaces (Públicos) ]   [ Restricted Spaces (Restringidos) ]
   (ej. Company Data)           (ej. Finanzas, Legal, RRHH)
          │                             │
          ▼                             ▼
   [ Agentes Generales ]        [ Agentes Departamentales ]
          │                             │
          ▼                             ▼
   (Toda la Organización)       (Solo Miembros del Espacio Restringido)
          ▲                             ▲
          └──────────────┬──────────────┘
                         │
              [ Usuarios y Grupos ]
              (Sincronizados vía SCIM / IdP)

Capa 1: Acceso del Agente a los Datos (Contención Estricta)

Cuando se crea un agente en Dust, sus herramientas y capacidades de recuperación quedan limitadas exclusivamente a los Spaces designados. Si un asistente está configurado únicamente con el espacio de soporte técnico y el espacio general de la empresa, carece de rutas de ejecución o índices vectoriales para consultar los espacios restringidos de Finanzas o Asesoría Jurídica. Esta restricción se aplica en la capa de base de datos antes de enviar cualquier consulta al LLM.

Capa 2: Acceso de los Usuarios al Agente (Visibilidad Segura por Defecto)

Dust aplica el principio de seguridad por defecto: los espacios utilizados por un agente determinan qué usuarios pueden verlo y utilizarlo. Un empleado solo puede encontrar, visualizar e interactuar con un agente si pertenece a todos y cada uno de los espacios vinculados a las fuentes de datos y herramientas de dicho agente.

Si un asistente consulta el espacio restringido de Finanzas, Dust lo oculta automáticamente de la interfaz de cualquier empleado ajeno a ese departamento. Esto bloquea cualquier intento de ataque por elevación de privilegios indirecta: ningún usuario puede recurrir a un agente con permisos elevados para eludir sus propias restricciones de acceso.

2. Estrategia de Spaces: Separación entre Dominios Abiertos y Restringidos

En Dust, toda la información se organiza en Spaces. Definir una estructura adecuada de espacios constituye la primera línea de defensa contra fugas de información.

Comparativa: Open Spaces frente a Restricted Spaces

El Espacio predeterminado "Company Data"

Cada workspace en Dust cuenta con un espacio predeterminado denominado Company Data:

• Es abierto para todos los miembros y no se puede eliminar, renombrar ni convertir en restringido.
• Su contenido es accesible por agentes predeterminados del sistema, como @dust.
• Regla de oro de gobernanza: Jamás asocie a Company Data carpetas salariales, canales ejecutivos o información contractual confidencial. Considere este espacio como el tablón de anuncios público de la empresa.

Límites de Espacios según el Plan

• Plan Business: Permite crear hasta 5 espacios. Adecuado para organizaciones con estructura plana que requieren segmentación básica (Company Data, Dirección, Ingeniería, Ventas y Operaciones).
• Plan Enterprise: Permite crear hasta 100 espacios. Diseñado para empresas con múltiples departamentos, subsidiarias o proyectos confidenciales que exigen aislamiento riguroso.

3. Guía de Implementación en 6 Pasos para Administradores de TI

Para desplegar asistentes departamentales sin riesgo de fugas, los equipos de infraestructura y seguridad deben aplicar el siguiente flujo de trabajo:

Paso 1: Aprovisionamiento Automatizado de Identidades mediante SCIM 2.0

Gestionar usuarios de manera manual genera desfases en los permisos cuando los empleados cambian de función o abandonan la empresa. En planes Enterprise, la integración con el proveedor de identidades (Okta, Microsoft Entra ID o Google Workspace) es fundamental.

1. En Dust, acceda a Admin > Organization > Members > Groups > User provisioning > Set up Directory sync.
2. Seleccione su IdP y complete la sincronización mediante SCIM 2.0.
3. Configure la propagación de grupos organizativos (por ejemplo: dept-finance, dept-legal, dept-people, exec-board).
4. Al producirse un traslado departamental o una baja en el IdP, los permisos en Dust se actualizan en tiempo real: si un empleado deja el departamento financiero en Entra ID, pierde de inmediato el acceso al espacio restringido de Finanzas y a todos sus asistentes asociados.

Paso 2: Conexiones de Datos con Cuentas de Servicio Dedicadas

Los conectores de Dust (Google Drive, Microsoft SharePoint/OneDrive, Notion, Confluence, Slack) sincronizan repositorios empresariales. Para garantizar el mínimo privilegio:

1. Evite cuentas personales de administradores: Nunca vincule repositorios mediante el usuario individual de un administrador. Si esa persona se desvincula de la empresa, la sincronización se interrumpe y sus borradores personales podrían indexarse por error.
2. Utilice identidades de servicio dedicadas:
   • Google Drive: Cree un usuario específico como dust-admin@suempresa.com y concédale permisos exclusivos de lectura y descarga en las unidades compartidas destinadas a la IA.
   • Microsoft SharePoint / OneDrive: Registre una aplicación en Entra ID con permisos de aplicación Sites.Selected, o utilice una cuenta de servicio (dust-service@suempresa.com) y limite su acceso a las colecciones de sitios autorizadas mediante PowerShell (Grant-PnPAzureADAppSitePermission) o Microsoft Graph API.
   • Slack: Invite al bot de Dust únicamente a canales públicos o canales de archivo controlados, impidiendo su presencia en conversaciones confidenciales no autorizadas.
3. Seleccione subdirectorios de manera selectiva: En el cuadro de diálogo de Dust, explore el árbol de carpetas y marque únicamente los directorios pertinentes, evitando sincronizar la raíz completa de los repositorios.

Paso 3: Creación de Espacios Restringidos y Asignación de Grupos

Una vez sincronizados los datos con Dust, estos permanecen en un área común administrada hasta que se vinculan a un espacio concreto.

1. Diríjase a la pestaña Spaces en Dust y haga clic en New.
2. Asigne un nombre al espacio (por ejemplo, Finance & Accounting).
3. Seleccione el tipo Restricted.
4. En la configuración de miembros, elija Provisioned group access y vincule el grupo aprovisionado desde el IdP (como dept-finance).
5. Abra el nuevo espacio restringido, vaya a Connected Data y pulse Add data from connections.
6. Seleccione únicamente las carpetas de Drive o bibliotecas de SharePoint correspondientes a ese departamento.
7. Guarde los cambios para aislar los documentos dentro del contenedor restringido.

Panel de Control de Dust: Configuración de Espacio Restringido
┌─────────────────────────────────────────────────────────────┐
│ Crear Nuevo Espacio (Create New Space)                      │
│ Nombre: [ Finance & Accounting                            ] │
│ Tipo de Acceso: ( ) Open (Abierto)   (•) Restricted         │
│ Asignación de Miembros:                                     │
│   [ Provisioned group access                              ▼]│
│   Grupos: [ dept-finance x ] [ exec-cfo x ]                 │
│                                                             │
│ Fuentes Conectadas (Connected Data):                        │
│   [x] Google Drive: /Shared Drives/Finance/FY26_Budgets/    │
│   [x] SharePoint: /sites/FinanceOps/Financial_Statements/   │
│   [ ] Google Drive: /Shared Drives/Company_Wide/ (Excluido) │
│                                                             │
│ [ Cancelar ]                                [ Crear Espacio ]│
└─────────────────────────────────────────────────────────────┘

Paso 4: Ajuste de Roles y Gobernanza de Creación de Asistentes

Por defecto, los nuevos workspaces de Dust permiten a todos los usuarios crear y publicar agentes. En entornos corporativos, esto debe restringirse.

Vaya a Admin > Governance para configurar la matriz de permisos:

1. Create agents y Publish agents: Modifique el acceso de Everyone a grupos autorizados (como un grupo de creadores certificados AI Builders) o a Admin only, evitando la proliferación descontrolada de asistentes no auditados.
2. Create skills y Manage skill availability: Mantenga estas opciones en Admin only para restringir la integración de herramientas o endpoints de API externos.
3. Mapeo de Roles: En Admin > Members > Roles, asigne roles a grupos. Reserve el rol de Admin para los responsables principales de TI. A los responsables de departamento se les puede otorgar el rol de Manager o nombrarlos Group Managers (Gestores de Grupo) para administrar miembros y consumo sin acceso a la configuración de seguridad del sistema.
4. Delegación de Funciones de Seguridad: Tenga en cuenta que el permiso Access security features no se incluye por defecto en el rol de Manager; debe ser concedido de manera explícita por un Administrador.

Paso 5: Creación de Asistentes Departamentales y Regla de Intersección

Al crear un asistente en el Agent Builder:

1. Redacte las Instructions estableciendo claramente el ámbito operativo y las normas de confidencialidad.
2. En la sección Knowledge / Tools, añada la herramienta Search data sources:
   • Seleccione únicamente el espacio restringido correspondiente (por ejemplo, Finance & Accounting).
   • No incluya el espacio Company Data salvo que resulte estrictamente indispensable.
3. Comprenda la Regla de Intersección Multiespacio (Condición AND):
   • Si un asistente incluye herramientas vinculadas al Espacio A (Finanzas) y al Espacio B (Dirección), el usuario debe pertenecer simultáneamente a ambos espacios para poder ver y utilizar el agente.
   • Si solo pertenece al Espacio A, el agente permanecerá oculto.
   • Práctica recomendada: Diseñe asistentes vinculados a un único espacio restringido para evitar bloqueos accidentales a usuarios legítimos.

Paso 6: Configuración de Credenciales en Herramientas Externas (Personal vs. Shared)

Cuando los asistentes interactúan con plataformas externas (GitHub, Salesforce, Jira, HubSpot o servidores MCP), el administrador debe elegir el modelo de credenciales en Knowledge > Tools:

• Credenciales Compartidas (Shared Credentials): Todos los usuarios invocan la herramienta mediante una cuenta de servicio configurada por el administrador. Apropiado para bases de datos de consulta de uso general.
• Credenciales Personales (Personal Level Credentials): El administrador realiza la conexión OAuth inicial y, posteriormente, cada usuario debe autenticarse individualmente con su cuenta externa al usar la herramienta por primera vez.
  • Recomendado para sistemas confidenciales: En herramientas como Salesforce o repositorios privados de GitHub, este ajuste garantiza que el agente solo acceda a los registros que el usuario específico tiene autorizados dentro de esa plataforma, sumando el control de acceso del sistema de origen al aislamiento del espacio en Dust.

4. Auditoría, Monitorización y Gestión del Ciclo de Vida

Una gobernanza eficaz requiere visibilidad constante y trazabilidad de las acciones ejecutadas en el entorno corporativo.

┌──────────────────────────────────────────────────────────────┐
│                Flujo de Eventos en Tiempo Real               │
└──────────────────────────────┬───────────────────────────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
     [ Acción de Usuario Humano ]           [ Acción Derivada del Agente ]
     actor: "user"                          actor: "user"
     action: "agent.executed"               metadata.actor_type: "agent"
     targets: ["agent-finance-01"]          metadata.initiating_user: "..."
            │                                     │
            └──────────────────┬──────────────────┘
                               ▼
               [ Motor de Auditoría Enterprise ]
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
    [ Visor de Auditoría Interno ]         [ Transmisión a SIEM ]
    (Admin > Security > Audit Logs)        (Datadog, Splunk, S3, GCS)

Registros de Auditoría y Atribución de Acciones

Los registros de auditoría de Dust Enterprise (en Admin > Organization > Security > Audit Logs) documentan cada evento relevante:

• Identidad (Actor): Identifica si la acción proviene de un usuario humano (user), una clave de API (api_key) o un proceso de sistema (system), registrando direcciones IP y agentes de usuario.
• Acción ejecutada: Registra eventos como agent.executed, space.created, space.deleted, data_source.updated y tool.executed.
• Diferenciación entre Humanos e IA: Cuando un asistente consulta una fuente de datos o ejecuta una herramienta, el registro indica metadata.actor_type: "agent", pero conserva los identificadores del usuario humano que inició la petición (initiating_user_id e initiating_user_email), garantizando una trazabilidad completa ante cualquier auditoría.

Transmisión a Plataformas SIEM

Las organizaciones pueden reenviar los registros de auditoría en tiempo real a soluciones como Datadog, Splunk, AWS S3, Google Cloud Storage (GCS) o terminales HTTPS personalizados. En redes corporativas con filtrado estricto, asegúrese de incluir en la lista blanca las direcciones IP de entrega de WorkOS detalladas en la documentación de Dust.

Desaprovisionamiento y Bajas de Personal

Cuando un empleado deja la organización:

1. La sincronización mediante SCIM desactiva su cuenta en Dust al instante.
2. El acceso a todos los espacios restringidos queda revocado de inmediato.
3. Se eliminan automáticamente todas las automatizaciones y activadores (Triggers) personales creados por ese usuario.
4. Procedimiento de continuidad para administradores: Antes de dar de baja a usuarios clave, revise en Programmatic Usage > Automations las tareas activas para reasignar editores. En el caso de asistentes no publicados creados por el empleado saliente, un administrador puede abrir el Agent Builder y pulsar Become an editor as an admin para asumir su gestión sin perder la configuración.

5. Matriz de Diseño y Lista de Comprobación para TI

Matriz de Gobernanza de Espacios y Permisos

Lista de Comprobación Previa al Despliegue

• Sincronización SCIM 2.0 activa: Grupos departamentales de Okta o Entra ID replicados correctamente en Dust.
• Revisión de Company Data realizada: Verificado que ningún archivo salarial, financiero o judicial confidencial resida en el espacio abierto.
• Cuentas de servicio configuradas: Conexiones de Drive y SharePoint vinculadas mediante identidades no personales con permisos restringidos por carpeta.
• Espacios Restringidos delimitados: Espacios creados y configurados con Provisioned group access para cada departamento sensible.
• Asignación precisa de datos conectados: Documentos confidenciales agregados exclusivamente a sus respectivos espacios restringidos.
• Control de creación de agentes aplicado: Creación y publicación de asistentes limitada a administradores o grupos autorizados en Admin > Governance.
• Credenciales personales exigidas: Herramientas con permisos por usuario (Salesforce, GitHub, Jira) configuradas en modo Personal Credentials.
• Integración SIEM verificada: Flujo de registros de auditoría transmitiéndose correctamente a Datadog o Splunk con pruebas de alerta validadas.

Mediante este marco estructurado, los administradores de TI pueden poner a disposición de la organización toda la potencia de la inteligencia artificial generativa, manteniendo un aislamiento inquebrantable que previene fugas de información entre departamentos.

Referencias

• Spaces management
• Workspace Governance: Roles, Groups & Permissions
• Access Controls and Permissions
• Users and groups provisioning
• Personal vs Shared Credentials for Tools & MCP Servers
• Agents management
• Audit Logs
• Google Drive
• Microsoft
• Dust Security: Enterprise-Grade Data Protection