Comment ancrer les agents Genie à la fois dans des données structurées et des documents sans perdre la gouvernance

Créer un agent pour automatiser des tâches professionnelles simples peut être facile. Mais en concevoir un qui comprend réellement votre entreprise et respecte votre gouvernance des données existante est bien plus difficile.

Pendant longtemps, les équipes ont dû utiliser des systèmes distincts pour analyser les données structurées et non structurées, passant souvent des semaines simplement à faire le lien entre les deux. En permettant l'analyse directement à partir de tables et de fichiers non structurés, les agents Genie simplifient cette architecture, vous permettant d'ancrer un agent unique à la fois sur des données structurées et non structurées.

À mesure que vous consolidez ces données, une question cruciale se pose : si un agent a accès à tout, qu'est-ce qui l'empêche de divulguer la mauvaise information à la mauvaise personne ?

La bonne nouvelle, c'est qu'avec Databricks, la réponse se trouve déjà au sein de la structure de gouvernance des données que vous possédez. Les mêmes Unity Catalog mécanismes sur lesquels vous vous appuyez aujourd'hui (synchronisation des identités, privilèges sur les objets, ABAC, filtres de lignes et masques de colonnes) régissent automatiquement les agents Genie sans aucune configuration supplémentaire. Cet héritage transparent repose sur une stratégie de gouvernance bien conçue, que nous explorerons en détail.

Pour donner vie à ces concepts, nous allons parcourir ces scénarios en utilisant comme point de référence des exemples de Brickstore, un détaillant mondial de briques fictif.

Le contrat de gouvernance : les agents Genie s'exécutent avec les identifiants de l'utilisateur final

Le principe d'architecture fondamental est simple : les agents Genie s'exécutent avec les identifiants de l'utilisateur final. Unity Catalog applique la gouvernance par défaut, garantissant que l'accès aux tables et aux volumes est directement lié à l'identité et aux autorisations existantes de l'utilisateur final.

C'est crucial, car de nombreux systèmes développés en interne accordent aux agents un accès étendu et s'appuient sur l'ingénierie de requêtes (prompt engineering) pour filtrer les résultats au niveau du modèle. Cela fait de l'LLM votre périmètre de sécurité, un pari dangereux sachant que les modèles peuvent être manipulés ou contournés. Dire à un auditeur « j'ai ajouté des instructions demandant de ne pas afficher les données restreintes » n'est pas un contrôle de gouvernance défendable.

Avec le cadre de gouvernance décrit dans cet article, Unity Catalog, et non le modèle, reste votre périmètre de sécurité, tout comme pour le reste de Databricks. Bien que Genie détermine comment interroger les données, il est incapable de renvoyer un enregistrement que l'utilisateur final n'est pas autorisé à voir, car chaque réponse est filtrée au niveau de la couche de données avant même de quitter le Lakehouse.

Étape 0 : Tout commence par l'identité : la gestion automatique des identités (AIM) et le provisionnement juste-à-temps (JIT)

Le fondement de l'architecture commence par la garantie que vos identités d'entreprise sont à la fois précises et à jour.

Les contrôles d'accès ne sont fondamentalement fiables qu'à la mesure des identités qu'ils évaluent. Une politique indiquant que « les membres de brickstore_apac ne peuvent voir que les commandes APAC » n'a aucun sens si vos appartenances aux groupes dans Databricks sont une copie obsolète et gérée manuellement de ce qui se trouve chez votre fournisseur d'identité.

La gestion automatique des identités pour Microsoft Entra ID et Okta comble cette lacune. Lorsqu'elle est activée, les utilisateurs, les groupes, les appartenances aux groupes et les principaux de service se synchronisent automatiquement depuis ces fournisseurs d'identité vers Databricks, sans qu'aucune application SCIM ne soit requise. Le provisionnement juste-à-temps est toujours actif, de sorte qu'un utilisateur qui ne s'est jamais connecté à Databricks est provisionné lors de sa première connexion et arrive en bénéficiant déjà de ses appartenances aux groupes existantes.

Voici le flux étape par étape :

1. L'IdP est la source de vérité. Quelqu'un rejoint l'organisation commerciale APAC ; votre fournisseur d'identité l'ajoute au groupe brickstore_apac.
2. L'AIM synchronise cela dans Databricks, y compris l'appartenance au groupe. Le JIT provisionne l'utilisateur sur Databricks la première fois qu'il ouvre Genie One.
3. Les politiques de Unity Catalog s'appuient sur ces groupes : les privilèges sur les objets, les politiques ABAC, les filtres de lignes et les masques de colonnes évaluent tous l'appartenance au groupe au moment de la requête.
4. L'utilisateur pose une question à un agent Genie, et la réponse est précisément définie par ce que l'autorisation de son groupe permet. Ni plus, ni moins.

L'avantage est que la gouvernance est continue, et non une configuration ponctuelle. Lorsqu'un employé passe de la région APAC à la région AMER, l'IdP le déplace d'un groupe à l'autre, la synchronisation propage la modification, et la question suivante qu'il pose à Genie renvoie la vue AMER, sans que personne n'ait à créer de ticket ou à modifier l'agent Genie. Lorsque l'employé quitte l'entreprise, il est désactivé de l'IdP et son accès à tous les agents Genie est immédiatement révoqué.

Étape 1 : Ancrer les données structurées et contrôler quatre couches d'accès

Une fois les identités correctement établies, nous pouvons nous concentrer sur ce qu'elles sont autorisées à voir. Pour les données structurées, un agent Genie peut accéder à n'importe quel actif de données Unity Catalog : tables, vues, vues matérialisées, vues de métriques, tables de streaming et même tables étrangères fédérées à partir de systèmes externes.

Par exemple, les tables Delta constituent les faits et les dimensions. Dans Brickstore, il s'agit de brickstore.sales.orders (chaque commande, avec un region et un customer_email) et de brickstore.sales.products (le catalogue de briques). Metric Views constituent la couche sémantique régie au-dessus : elles encodent les définitions de vos indicateurs métier (par exemple, ce que signifie le « chiffre d'affaires net », comment sont calculées les « briques vendues », ce qui correspond à une « brique la plus vendue ») une fois pour toutes, en YAML, afin que chaque consommateur les calcule de la même manière.

Au-dessus de ces actifs se trouvent quatre couches de contrôle d'accès que l'on a souvent tendance à confondre :

Les privilèges sur les objets constituent la première couche d'accès : sans SELECT, Genie ne peut pas interroger la table pour le compte de l'utilisateur final. Mais accorder l'accès à une table ne signifie pas que vous devez en accorder la totalité. Vous superposez des filtres de lignes et des masques de colonnes à ces autorisations, de sorte qu'un responsable régional puisse interroger la table des commandes tout en ne voyant que les lignes de sa propre région, sans jamais accéder à l'adresse e-mail brute du client. Ces contrôles de lignes et de colonnes s'appuient sur les mêmes groupes que vos autorisations utilisent déjà (is_account_group_member('brickstore_apac') et autres). L'ABAC, que nous verrons ensuite, ne remplace rien de tout cela ; c'est simplement un moyen d'associer les mêmes filtres et masques via une politique globale plutôt que table par table.

ABAC : définir la politique une fois, la laisser se propager

L'ancienne méthode pour gérer la sécurité des lignes et des colonnes se faisait par table : écrire un filtre de ligne, l'associer à orders ; écrire un masque de colonne, l'associer à une autre table, et ainsi de suite à l'infini. Cela convient toujours pour une logique ponctuelle, mais sur des centaines de tables, c'est une configuration propice aux oublis.

Les politiques ABAC, qui sont désormais GA dans Unity Catalog aux côtés des balises gouvernées et de la classification automatique des données, inversent la tendance. Vous étiquetez les données sensibles avec des balises gouvernées (des paires clé/valeur contrôlées par accès au niveau du compte comme pii:email), et vous écrivez une seule politique qui indique "partout où cette balise apparaît, appliquez cette protection". Les nouvelles tables héritent de la protection dès qu'elles sont étiquetées, il n'y a donc aucun travail par table.

Un masque de colonne + une politique ABAC qui protège chaque colonne d'e-mail dans le catalogue, en une seule instruction :

Et un filtre de ligne + une politique ABAC pour que chaque responsable ne voie que les commandes de sa région, en fonction de son appartenance à un groupe :

Résultat : le responsable APAC pose une question sur les commandes et l'agent Genie ne renvoie que les lignes APAC, avec customer_email masqué. Le responsable AMER interroge la même table et obtient les lignes AMER.

Étape 2 : Étendre la même gouvernance aux documents

Historiquement, la stratégie de gouvernance pour les équipes a été plus complexe lorsqu'il s'agit de données non structurées. Alors que les données structurées sont gérées de manière sécurisée dans un data warehouse ou une base de données, les documents sont souvent conservés dans un système de stockage isolé régi par des ACL distinctes.

La solution consiste à conserver les fichiers au sein du même plan de gouvernance que vos données structurées. Vous pouvez les stocker dans des volumes Unity Catalog et ils deviennent des objets sécurisables comme tout le reste. Vous accordez le privilège GRANT READ VOLUME aux groupes et utilisateurs qui doivent les voir, et Genie effectue ses raisonnements sur ces derniers selon le même contrat d'identité :

Il convient de comprendre un comportement spécifique avant de concevoir votre agent : lorsque vous associez un volume à un agent Genie, il devient une source requise. Cela signifie que l'agent valide l'accès à chaque source associée lors de son chargement. Ainsi, un utilisateur qui ne dispose pas du privilège READ VOLUME sur un volume associé ne peut pas du tout utiliser cet agent. En d'autres termes, les autorisations sur les volumes régissent les documents en tant que condition préalable à l'utilisation de l'agent. Veillez donc à adapter les sources de documents de chaque agent au public cible qui doit l'utiliser. Si deux publics ont besoin de documents différents, vous devrez peut-être leur attribuer des agents Genie différents (chacun ne montant que les volumes que l'utilisateur est autorisé à lire).

Gardez également à l'esprit qu'un volume Unity Catalog est la plus petite unité sécurisable, de sorte que les autorisations s'appliquent à l'ensemble du volume plutôt qu'à des fichiers individuels. Vous ne pouvez pas choisir des fichiers spécifiques à partager ; vous devez accorder l'accès à l'ensemble du volume ou à aucun d'entre eux.

Compte tenu de ces éléments, les volumes peuvent être associés directement aux agents Genie en tant que source de connaissances, de la même manière que pour une table ou une vue. Les agents Genie lisent bien plus que les simples PDF : les formats pris en charge incluent le PDF, les fichiers image (JPG, JPEG, PNG, TIFF, TIF) et les documents Office (DOC, DOCX, PPT, PPTX), ainsi que le texte brut et le Markdown. En pratique, cela signifie que les contrats numérisés, les présentations et les fiches techniques sont tous exploitables, et pas seulement les PDF propres. (Consultez la documentation sur les volumes des agents Genie pour obtenir la liste complète et connaître les limites actuelles.)

Pour garantir un routage précis et des performances optimales, suivez ces meilleures pratiques pour configurer vos volumes :

• Ajoutez une description claire : Décrivez précisément le contenu du volume, la façon dont il est organisé et la manière dont l'agent doit l'utiliser. N'utilisez pas d'espaces réservés génériques. Par exemple, au lieu de "fichiers régionaux", utilisez "Rapport sur le marché APAC — moteurs de la demande, tendances et points de vigilance pour la région APAC". Genie s'appuie sur cette description pour sélectionner le bon volume.
• Évitez le contenu en double : l'association de plusieurs volumes contenant des informations redondantes complique la tâche de l'agent pour récupérer les documents pertinents. Il en va de même pour les fichiers individuels au sein d'un volume.
• Évitez les fichiers non pertinents : incluez uniquement les fichiers pertinents pour le domaine de l'agent. Des fichiers non pertinents peuvent induire l'agent en erreur.
• Utilisez des noms de fichiers clairs : utilisez des noms de fichiers descriptifs afin que l'agent puisse les distinguer les uns des autres.

Étape 3 : Les agents Genie en production : même question, réponses différentes

À ce stade, l'agent Genie est pleinement habilité à agir comme un véritable expert du domaine, avec un accès complet aux données structurées et non structurées. La base de connaissances sous-jacente reste rigoureusement protégée par des filtres de ligne, des masques de colonne et des autorisations de volume basés sur les permissions de chaque utilisateur.

Nous évaluons notre implémentation en la testant avec deux utilisateurs différents qui posent exactement la même question, ce qui devrait générer deux réponses distinctes et correctes.

Prenons l'exemple de deux sessions d'agent Genie simultanées, toutes deux basées sur les mêmes ressources : la table orders, le catalogue products et le volume market_report. Bien qu'un demandeur appartienne à brickstore_apac et l'autre à brickstore_amer, ils soumettent tous deux exactement la même requête :

"Quel produit est notre meilleure vente ce trimestre et qu'est-ce qui stimule cette demande ? Indiquez également les principaux clients à l'origine de ces ventes ainsi que leurs adresses e-mail."

Réponse 1 - pour le responsable APAC

Réponse 2 - pour le responsable AMER

Il convient de souligner trois points :

• Les chiffres sont différents, et tous deux sont corrects. La requête "meilleures ventes de briques" des deux responsables extrait des données des mêmes tables — la différence réside uniquement dans les lignes auxquelles chacun a droit, et non dans la manière dont la métrique a été calculée.
• Cette différence n'a nécessité aucune ingénierie de prompt par utilisateur. Personne n'a écrit "si l'utilisateur est APAC, masquer les autres régions". Les instructions de l'agent sont identiques. Unity Catalog a effectué le filtrage au moment de la requête — à la fois sur les lignes et sur la colonne masquée. Notez que la colonne d'e-mail est masquée pour protéger les PII.
• Données structurées, enrichies par des connaissances non structurées. Sans les documents régionaux, Genie aurait pu facilement identifier la question du « quoi », mais aurait eu du mal à déterminer les facteurs qui stimulent la demande. Grâce aux données non structurées, Genie dispose d'un contexte complet sur l'entreprise.

Modèles à surveiller

Voici quelques modèles à surveiller lorsque vous transposez les enseignements de ce blog en production :

• Tags, puis politiques. Ne masquez pas table par table. Le premier réflexe est de sécuriser les trois tables devant vous. Résistez-y. Définissez des tags gouvernés et des politiques ABAC pour pérenniser votre gouvernance des données.
• Une seule audience par volume. Le volume étant la plus petite unité attribuable, déterminez l'accès aux documents au niveau du volume. Si deux documents nécessitent des lecteurs différents, ils ont besoin de volumes différents et d'agents Genie différents — planifiez la structure dès le départ.
• Soyez prudent lorsque vous exposez Genie One ou des agents Genie en externe via MCP ou API - vous devez gérer l'identité avec soin. Contrairement à une exécution via l'interface utilisateur de Databricks, vous n'êtes pas toujours autorisé à utiliser l'identité de l'utilisateur final (par exemple, lors de l'utilisation d'un principal de service pour l'authentification). Il existe des modèles spécifiques à adopter, et Databricks détaille les configurations U2M, M2M et OBO dans Access Genie everywhere.
• Testez par l'usurpation d'identité, pas par l'inspection. Ne validez pas la gouvernance en lisant simplement la politique pour vous convaincre qu'elle est correcte — posez la même question en tant que membre de chaque groupe et comparez les réponses. Faites-en un test de régression et exécutez-le à chaque modification des politiques ou des groupes.

Ce qu'il faut retenir

Créer un agent peut être facile, mais le gouverner demande un véritable travail de conception. Dans Databricks, les identités d'entreprise sont synchronisées à partir de l'IdP, les privilèges sur les objets filtrent l'accès, l'ABAC et les tags gouvernés appliquent une protection à grande échelle, les filtres de lignes et les masques de colonnes contrôlent les données renvoyées, et les documents sont conservés dans le même système que les données.

Avec cette configuration, les agents Genie héritent de toute la gouvernance sans aucune configuration supplémentaire.

Pour commencer à créer votre premier agent Genie gouverné, consultez la documentation de Genie et la documentation sur les politiques ABAC.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original