Cómo anclar los agentes de Genie tanto en datos estructurados como en documentos sin perder la gobernanza

Crear un agente para automatizar tareas empresariales sencillas puede ser fácil. Pero desarrollar uno que realmente entienda su negocio y respete el gobierno de datos existente es mucho más difícil.

Durante mucho tiempo, los equipos tuvieron que utilizar sistemas independientes para analizar datos estructurados y no estructurados, a menudo pasando semanas solo para conectar ambos. Al permitir el análisis directamente desde tablas y archivos no estructurados, Genie Agents simplifica esta arquitectura, lo que le permite basar un único agente tanto en datos estructurados como no estructurados.

A medida que consolida estos datos, surge una pregunta crítica: si un agente tiene acceso a todo, ¿qué le impide decirle algo incorrecto a la persona equivocada?

La buena noticia es que con Databricks, la respuesta se encuentra dentro de la base de gobierno de datos que ya tiene. Los mismos mecanismos de Unity Catalog en los que confía hoy en día (sincronización de identidad, privilegios de objetos, ABAC, filtros de filas y máscaras de columnas) gobiernan automáticamente a Genie Agents sin ninguna configuración adicional. Esta herencia fluida se basa en una estrategia de gobierno bien estructurada, que exploraremos en detalle.

Para dar vida a estos conceptos, analizaremos estos escenarios utilizando como punto de referencia ejemplos de Brickstore, una tienda minorista global de ladrillos ficticia.

El contrato de gobierno: Genie Agents se ejecutan con las credenciales del usuario final

El principio arquitectónico fundamental es sencillo: Genie Agents se ejecutan con las credenciales del usuario final. Unity Catalog aplica el gobierno de forma predeterminada, lo que garantiza que el acceso a las tablas y los volúmenes esté vinculado directamente a la identidad y los permisos existentes del usuario final.

Esto es fundamental, porque muchos sistemas de desarrollo propio otorgan a los agentes un acceso amplio y dependen de la ingeniería de prompts para filtrar los resultados en la capa del modelo. Esto convierte efectivamente al LLM en su perímetro de seguridad, una apuesta peligrosa, dado que los modelos se pueden manipular o eludir. Decirle a un auditor que "agregué instrucciones que decían que no se mostraran datos restringidos" no es un control de gobierno defendible.

Con el marco de gobierno descrito en este artículo, Unity Catalog, y no el modelo, sigue siendo su perímetro de seguridad, al igual que en el resto de Databricks. Aunque Genie determina cómo consultar los datos, es incapaz de devolver un registro que el usuario final no esté autorizado a ver, ya que cada respuesta se filtra en la capa de datos antes de salir del Lakehouse.

Paso 0: Comienza con la identidad: Automatic Identity Management (AIM) y aprovisionamiento Just-in-Time (JIT)

La base arquitectónica comienza por garantizar que las identidades de su empresa sean precisas y estén actualizadas.

Los controles de acceso son, fundamentalmente, tan confiables como las identidades que evalúan. Una política que dice "los miembros de brickstore_apac solo pueden ver los pedidos de APAC" no tiene sentido si las membresías de sus grupos en Databricks son una copia desactualizada y mantenida manualmente de lo que hay en su proveedor de identidad.

Automatic Identity Management para Microsoft Entra ID y Okta cierra esa brecha. Cuando está habilitado, los usuarios, grupos, membresías de grupos y principios de servicio se sincronizan desde esos proveedores de identidad a Databricks automáticamente, sin necesidad de una aplicación SCIM. El aprovisionamiento Just-in-time está siempre activo, por lo que un usuario que nunca ha iniciado sesión en Databricks se aprovisiona en su primer inicio de sesión y llega con sus membresías de grupo existentes.

Aquí está el flujo paso a paso:

1. El IdP es la fuente de verdad. Alguien se une a la organización de ventas de APAC; su proveedor de identidad lo coloca en el grupo brickstore_apac.
2. AIM sincroniza eso en Databricks, incluida la membresía del grupo. JIT aprovisiona al usuario en Databricks la primera vez que abre Genie One.
3. Las políticas de Unity Catalog se basan en esos grupos: los privilegios de objetos, las políticas de ABAC, los filtros de filas y las máscaras de columnas evalúan la membresía del grupo en el momento de la consulta.
4. El usuario le hace una pregunta a un Genie Agent y la respuesta se adapta exactamente a lo que permite el permiso de su grupo. Ni más ni menos.

La ventaja es que el gobierno es continuo, no una configuración puntual. Cuando un empleado se transfiere de APAC a AMER, el IdP lo mueve entre grupos, la sincronización lo propaga y la siguiente pregunta que le haga a Genie devolverá la vista de AMER, sin que nadie tenga que abrir un ticket ni realizar cambios en el Genie Agent. Cuando el empleado deja la empresa, se desactiva en el IdP y su acceso a todos los Genie Agents se elimina de inmediato.

Paso 1: Fundamentación de los datos estructurados y controlar cuatro capas de acceso

Una vez que las identidades se han establecido correctamente, podemos enfocarnos en lo que se les permite ver. Para los datos estructurados, un Genie Agent puede acceder a cualquier activo de datos de Unity Catalog: tablas, vistas, vistas materializadas, vistas métricas, tablas de streaming e incluso tablas externas federadas desde sistemas externos.

Por ejemplo, las tablas Delta son los hechos y las dimensiones. En Brickstore eso es brickstore.sales.orders (cada pedido, con un region y un customer_email) y brickstore.sales.products (el catálogo de ladrillos). Metric Views son la capa semántica gobernada que se encuentra por encima: codifican las definiciones de sus métricas comerciales (por ejemplo, qué significa "ingresos netos", cómo se calcula "ladrillos vendidos", qué cuenta como un "ladrillo más vendido") una sola vez, en YAML, para que cada consumidor las calcule de la misma manera.

Por encima de esos activos se encuentran cuatro capas de control de acceso que la gente suele confundir:

Los privilegios de objetos son la primera capa de acceso: sin SELECT, Genie no puede consultar la tabla en nombre del usuario final. Pero otorgar acceso a una tabla no significa que deba otorgar todo el acceso. Puede superponer filtros de filas y máscaras de columnas sobre esas concesiones, de modo que un gerente regional pueda consultar la tabla de pedidos viendo únicamente las filas de su propia región y nunca el correo electrónico directo del cliente. Esos controles de filas y columnas se basan en los mismos grupos que ya utilizan sus concesiones: is_account_group_member('brickstore_apac') y similares. ABAC, que veremos a continuación, no reemplaza nada de esto; es solo una forma de asociar los mismos filtros y máscaras mediante una política en lugar de hacerlo tabla por tabla.

ABAC: defina la política una vez, deje que se propague

La forma anterior de aplicar la seguridad de filas y columnas era por tabla: escribir un filtro de fila, asociarlo a orders; escribir una máscara de columna, asociarla a otra tabla; y repetir el proceso indefinidamente. Sigue siendo útil para lógicas puntuales, pero en cientos de tablas es una configuración propensa a dejar vacíos de seguridad.

Las políticas ABAC, que ya están disponibles de forma general (GA) en Unity Catalog junto con las etiquetas gobernadas y la clasificación de datos automatizada, invierten eso. Etiqueta los datos confidenciales con etiquetas gobernadas (pares clave/valor a nivel de cuenta y con control de acceso como pii:email) y escribe una política que dice "dondequiera que aparezca esta etiqueta, aplica esta protección". Las nuevas tablas heredan la protección en el momento en que se etiquetan, por lo que no hay trabajo por tabla.

Una máscara de columna + política ABAC que protege cada columna de correo electrónico en el catálogo, en una sola instrucción:

Y un filtro de filas + política ABAC para que cada gerente vea solo los pedidos de su región, impulsado por la pertenencia al grupo:

El resultado: el gerente de APAC hace una pregunta sobre los pedidos y el agente Genie devuelve solo las filas de APAC, con customer_email enmascarado. El gerente de AMER consulta la misma tabla y obtiene las filas de AMER.

Step 2: Extender la misma gobernanza a los documentos

Históricamente, la estrategia de gobernanza para los equipos ha sido más desafiante al tratar con datos no estructurados. Mientras que los datos estructurados se gestionan de forma segura en un data warehouse o una base de datos, los documentos a menudo se guardan en un sistema de almacenamiento aislado gobernado por ACL independientes.

La solución es mantener los archivos dentro del mismo plano de gobernanza que sus datos estructurados. Puede guardarlos en Unity Catalog Volumes y se convertirán en objetos protegibles como todo lo demás. Otorga GRANT READ VOLUME a los grupos y usuarios que deberían verlos, y Genie razona sobre ellos bajo el mismo contrato de identidad:

Vale la pena comprender un comportamiento antes de diseñar su agente: cuando asocia un volumen a un agente Genie, este se convierte en una fuente requerida. Esto significa que el agente valida el acceso a cada fuente asociada cuando se carga, por lo que un usuario que no tenga READ VOLUME en un volumen asociado no podrá usar ese agente en absoluto. En otras palabras, las concesiones de volumen gobiernan los documentos como un requisito previo para usar el agente, así que asegúrese de delimitar las fuentes de documentos de cada agente para el público que debería usar ese agente. Si dos públicos necesitan documentos diferentes, es posible que deba proporcionarles diferentes agentes Genie (cada uno montando solo los volúmenes que el usuario puede leer).

También tenga en cuenta que un Unity Catalog Volume es la unidad protegible más pequeña, por lo que los permisos se aplican a todo el volumen en lugar de a archivos individuales. No puede elegir archivos específicos para compartir; debe otorgar acceso a todo el volumen o a nada.

Teniendo en cuenta estas consideraciones, los volúmenes se pueden asociar directamente a los agentes Genie como una fuente de conocimiento de la misma manera que lo haría para una tabla o vista. Los agentes Genie leen mucho más allá de los PDF: los formatos admitidos incluyen PDF, archivos de imagen (JPG, JPEG, PNG, TIFF, TIF) y documentos de Office (DOC, DOCX, PPT, PPTX), junto con texto sin formato y Markdown. En la práctica, eso significa que los contratos escaneados, las presentaciones de diapositivas y las hojas de especificaciones son válidos, no solo los PDF limpios. (Consulte la documentación de volúmenes de agentes Genie para obtener la lista completa y los límites actuales).

Para garantizar un enrutamiento preciso y un rendimiento óptimo, siga estas mejores prácticas para configurar sus volúmenes:

• Agregue una descripción clara: Describa exactamente qué contenido contiene el volumen, cómo está organizado y cómo debe usarlo el agente. No utilice marcadores de posición genéricos. Por ejemplo, en lugar de "archivos regionales", utilice "Informe de mercado de APAC: factores de demanda, tendencias y elementos a vigilar para la región de APAC". Genie se basa en esta descripción para seleccionar el volumen correcto.
• Evite el contenido duplicado: asociar varios volúmenes que contienen información superpuesta dificulta que el agente recupere los documentos relevantes. Lo mismo se aplica a los archivos individuales dentro de un volumen.
• Evite archivos irrelevantes: incluya solo archivos que sean relevantes para el dominio del agente. Los archivos irrelevantes pueden confundir al agente.
• Use nombres de archivo claros: use nombres de archivo descriptivos para que el agente pueda distinguir entre archivos.

Step 3: Agentes Genie en producción: misma pregunta, diferentes respuestas

En este punto, el agente Genie está plenamente capacitado para actuar como un verdadero experto en el dominio, con acceso completo a datos estructurados y no estructurados. La base de conocimientos subyacente sigue estando completamente protegida por filtros de filas, máscaras de columnas y concesiones de volumen basadas en permisos por usuario.

Evaluamos nuestra implementación probándola con dos usuarios diferentes que hacen exactamente la misma pregunta, lo que debería producir dos respuestas de corrección única.

Considere dos sesiones simultáneas de agentes Genie, ambas basadas en los mismos activos: la tabla orders, el catálogo products y el volumen market_report. Aunque un solicitante pertenece a brickstore_apac y el otro a brickstore_amer, ambos envían exactamente la misma consulta:

"¿Cuál es nuestro producto más vendido este trimestre y qué está impulsando esa demanda? También enumere los principales clientes detrás de esas ventas y sus correos electrónicos".

Response 1: para el gerente de APAC

Response 2: para el gerente de AMER

Vale la pena señalar tres cosas:

• Los números son diferentes y ambos son correctos. La consulta de "ladrillos más vendidos" de ambos gerentes extrae datos de las mismas tablas; la diferencia radica puramente en las filas a las que cada uno tiene derecho, no en una diferencia en cómo se calculó la métrica.
• La diferencia requirió cero ingeniería de prompts por usuario. Nadie escribió "si el usuario es de APAC, oculta otras regiones". Las instrucciones del agente son idénticas. Unity Catalog realizó el filtrado en el momento de la consulta, tanto en las filas como en la columna enmascarada. Tenga en cuenta que la columna de correo electrónico está enmascarada para proteger la PII.
• Datos estructurados, enriquecidos con conocimiento no estructurado. Sin los documentos regionales, es posible que Genie hubiera podido identificar la pregunta sobre el “qué” fácilmente, pero habría tenido dificultades para descubrir qué factores están impulsando la demanda. Con los datos no estructurados disponibles, Genie tiene todo el contexto del negocio.

Patrones a tener en cuenta

Algunos patrones a tener en cuenta a medida que llevas a producción lo aprendido en este blog:

• Primero etiqueta, luego política. No apliques máscaras tabla por tabla. El instinto es proteger las tres tablas que tienes delante. Resístelo. Define etiquetas gobernadas y políticas ABAC para preparar tu gobernanza de datos para el futuro.
• Una audiencia por volumen. Dado que el volumen es la unidad mínima a la que se pueden conceder permisos, decide el acceso a los documentos en el límite del volumen. Si dos documentos necesitan lectores diferentes, necesitarán volúmenes diferentes y diferentes agentes de Genie; planifica la estructura de antemano.
• Ten cuidado al exponer Genie One o agentes de Genie externamente a través de MCP o API: debes gestionar la identidad con cuidado. A diferencia de cuando lo ejecutas a través de la UI de Databricks, no siempre tienes permiso para usar la identidad del usuario final (por ejemplo, al usar un Service Principal para la autenticación). Hay patrones específicos que adoptar, y Databricks detalla las configuraciones de U2M, M2M y OBO en Access Genie everywhere.
• Prueba mediante suplantación, no mediante inspección. No valides la gobernanza leyendo la política y convenciéndote de que es correcta: haz la misma pregunta como miembro de cada grupo y compara las respuestas. Conviértelo en una prueba de regresión y ejecútala cada vez que cambien las políticas o las agrupaciones.

La conclusión clave

Crear un agente puede ser fácil, pero gobernarlo requiere un verdadero trabajo de diseño. En Databricks, las identidades empresariales se sincronizan desde el IdP, los privilegios de los objetos restringen el acceso, ABAC y las etiquetas gobernadas aplican protección a escala, los filtros de filas y las máscaras de columnas controlan lo que se devuelve, y los documentos se mantienen en el mismo sistema que los datos.

Con esta configuración, los agentes de Genie heredan toda la gobernanza sin ninguna configuración adicional.

Para comenzar a crear tu primer agente de Genie gobernado, visita la documentación de Genie y la documentación de las políticas de ABAC.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original