Quatre piliers pour gouverner chaque appel de modèle, invocation d'outil et interaction d'agent au sein de votre organisation
par David Nasi et Stefania Leone
• La gouvernance de l'IA est fondamentalement un défi de gouvernance des données. En combinant la traçabilité, les journaux d'audit, les traces d'inférence, la surveillance de la qualité des données et la classification dans le lakehouse, les organisations peuvent gouverner les systèmes d'IA de manière sécurisée tout en améliorant l'observabilité, la conformité et la confiance.
• Unity Catalog et Unity AI Gateway offrent une couche de gouvernance unifiée pour les agents d'IA, les modèles, les serveurs MCP et les données — appliquant un accès basé sur l'identité, des politiques d'exécution, des garde-fous et une auditabilité complète pour chaque interaction d'agent.
• Les standards ouverts et la gouvernance interopérable permettent aux entreprises de gouverner de manière cohérente n'importe quel modèle, framework ou plateforme d'agent. Unity Catalog et Unity AI Gateway centralisent les politiques, l'observabilité et l'intelligence des coûts à travers Databricks et les écosystèmes d'IA tiers.
Il y a un an, votre organisation comptait une douzaine d'agents IA. Aujourd'hui, il y en a des milliers.
Chaque développeur dispose d'un agent de codage qui écrit, révise et déploie du code à ses côtés. Votre équipe d'analyse a créé des agents de prévision. Les opérations de vente ont déployé la notation des leads. L'organisation du support a automatisé le routage des tickets. Le marketing a lancé la personnalisation. La finance a élaboré des workflows de rapprochement. Chaque équipe a vu une opportunité et a agi rapidement.
Maintenant, quelqu'un demande : « Quels agents accèdent aux informations personnelles identifiables (PII) des clients ? »
La réponse nécessite de récupérer les journaux de dizaines de systèmes, de les corréler manuellement et d'espérer que rien n'a été oublié. Chaque agent se connecte, s'authentifie et accède aux données différemment. Il n'y a pas d'endroit unique où chercher.
Ou peut-être avez-vous pris le chemin inverse. Vous avez tout verrouillé. Aucun agent n'a été déployé sans un examen approfondi. La sécurité est restée stricte. Mais maintenant, vous avez six mois de retard sur des concurrents qui ont agi plus vite. Les développeurs et les utilisateurs sont frustrés. Certains sont partis pour des entreprises où ils peuvent réellement utiliser les outils d'IA.
Aucun des deux extrêmes ne fonctionne. Les agents non gouvernés créent des risques incommensurables. Les environnements verrouillés créent un autre type de risque : prendre du retard pendant que les talents s'en vont.
La gouvernance traditionnelle supposait que les humains prenaient des décisions et que les applications les exécutaient de manière prévisible. Les agents ne fonctionnent pas ainsi. Ils sont autonomes, ils font des choix différents à chaque fois et ils enchaînent les outils de manière imprévisible en lisant le code. Vous ne pouvez pas gouverner un agent en examinant ce qu'il pourrait faire. Vous le gouvernez en contrôlant ce à quoi il peut accéder et en surveillant ce qu'il fait réellement.
Unity Catalog gouverne les données d'entreprise depuis 2021 grâce à un modèle de permissions unique, une lignée unifiée et une piste d'audit cohérente pour chaque actif. Nous étendons maintenant cette même infrastructure de gouvernance pour couvrir chaque actif qu'un système d'IA touche : les LLM, les serveurs MCP, les compétences et les agents. Le catalogue qui sait déjà qui peut accéder à vos données client gouverne désormais également quels agents peuvent appeler quels outils, et sous quelles conditions.
Unity AI Gateway est le tissu d'application pour le monde des agents. Chaque appel de modèle, chaque invocation d'outil, chaque interaction d'agent transite par la passerelle. Chacun est évalué par rapport aux politiques définies dans Unity Catalog avant son exécution, et enregistré après. Les outils de gouvernance traditionnels ont été conçus pour des applications statiques. Ils n'ont aucune visibilité sur tout cela. Unity AI Gateway, si.
Les agents doivent opérer dans des limites de permissions clairement définies, tant en termes de qui ils peuvent agir au nom de qui que de ce à quoi ils peuvent accéder. La plupart des plateformes gèrent cela de la même manière qu'elles gèrent les permissions d'application : des comptes de service avec des identifiants statiques et un accès large. Vous perdez en responsabilité et vous ne pouvez pas contenir le rayon d'impact.
Databricks adopte une approche différente : l'identité circule de bout en bout, de l'utilisateur qui pose la question à la ligne de table spécifique que l'agent récupère. Les agents héritent des permissions de données de l'utilisateur appelant en temps réel via le passage de jeton "au nom de", et non via un compte de service partagé. Si vous ne pouvez pas accéder à une table dans Unity Catalog, l'agent agissant en votre nom ne le peut pas non plus. Chaque action est enregistrée pour les deux identités : l'utilisateur réel qui a déclenché la requête et l'agent qui a agi en son nom, capturant les tables consultées, les opérations exécutées et le moment. En cas de problème, vous savez exactement d'où provient l'action et qui l'a autorisée.
Nous étendons ce modèle aux serveurs MCP. Les équipes enregistrent les serveurs MCP externes (GitHub, Jira, Slack, etc.) dans Unity Catalog et les gouvernent comme tout autre élément sécurisable : permissions, gestion des identifiants et journalisation d'audit complète en un seul endroit.
Nous avons reconnu que le même principe s'applique à l'exécution, et pas seulement au moment de l'accès. Savoir qu'un agent est autorisé à appeler GitHub ne vous dit pas s'il doit supprimer un fichier ou fusionner une pull request. Nous avons donc créé les Service Policies, qui sont des fonctions UC, gérées dans UC et attachées aux MCP enregistrés dans Unity Catalog qui contrôlent la réussite des appels d'outils. Chaque appel d'outil est évalué avant l'exécution : en fonction du nom de l'outil, de ses arguments ou de l'identité de l'appelant, la politique renvoie autoriser, refuser ou demande le consentement de l'utilisateur. Si l'évaluation de la politique aboutit à un « Refuser », l'appel est bloqué.
Au niveau de la couche modèle, les garde-fous inspectent ce qui transite par l'inférence en temps réel, analysant les entrées pour détecter les PII et les tentatives de jailbreak, vérifiant les sorties pour les hallucinations et le contenu sensible avant qu'elles n'atteignent l'utilisateur. Ils s'exécutent en ligne sur chaque requête et échouent en mode fermé.
En pratique, ces trois couches fonctionnent ensemble : les permissions contrôlent qui peut appeler quoi. Les Service Policies contrôlent si un appel d'outil spécifique doit se poursuivre dans le contexte d'une requête donnée. Les garde-fous contrôlent le contenu qui entre et sort.
Voici le principe que la plupart des outils de gouvernance de l'IA ignorent : le comportement d'un agent est presque entièrement déterminé par les données auxquelles il a accès. Ce qu'il peut lire, la fraîcheur de ces données, si les champs sensibles sont masqués, ce ne sont pas des questions de gouvernance de l'IA. Ce sont des questions de gouvernance des données. Traitez-les séparément, et vous vous retrouverez avec deux systèmes incomplets. Traitez-les ensemble, et la gouvernance devient auto-renforçante.
Premièrement, vous avez besoin d'une piste d'audit complète, et la réglementation rend cela non négociable. Les réglementations émergentes en matière d'IA exigent des organisations qu'elles démontrent ce que leurs systèmes d'IA ont fait, ce qui leur a été fourni et ce qu'ils ont produit. AI Gateway écrit la charge utile complète de chaque appel de modèle dans les tables d'inférence : le prompt exact envoyé, la réponse exacte renvoyée, le nombre de jetons et la latence. Unity Catalog capture chaque opération d'accès dans les journaux d'audit, y compris quel principal a appelé quoi, depuis quel agent et à quel moment. Les deux atterrissent dans votre lakehouse sous forme de tables, conservables selon vos conditions. La plupart des architectures de journalisation imposent un compromis entre l'exhaustivité et le coût, vous obligeant à échantillonner, filtrer et définir de courtes fenêtres de rétention. Parce que Unity AI Gateway capture les données d'observabilité dans votre lakehouse, vous n'avez pas à le faire.
Deuxièmement, ces données d'audit ne sont utiles que dans la mesure de votre capacité à les analyser. L'analyse nécessite une plateforme de données, pas un outil de journalisation. Les traces d'agents sont des tables dans Unity Catalog, interrogeables avec le même SQL que vous utilisez pour tout le reste. Pas de nouveau langage de requête, pas d'outils séparés. Lorsqu'un agent fait quelque chose d'inattendu, les données à investiguer sont déjà là : quels agents ont accédé à un service spécifique la semaine dernière, combien chaque équipe dépense pour l'inférence, et si un agent a touché des identifiants ou des PII. Parce que les données d'audit vivent à côté de vos données métier, vous pouvez aller plus loin, en joignant le comportement des agents aux résultats commerciaux pour comprendre non seulement ce que les agents ont fait, mais aussi si cela a fonctionné. Lakewatch, le SIEM agentique de Databricks construit sur le lakehouse de sécurité, va encore plus loin, transformant la même piste d'audit en intelligence de sécurité active : détection et réponse aux menaces basées sur l'IA, construites sur le lakehouse. Les attaquants utilisent des agents. Les défenseurs devraient aussi.

Troisièmement, vous devez savoir que les données sur lesquelles vos agents se sont appuyés étaient fiables dès le départ. Un journal d'audit complet vous indique ce qu'un agent a consulté. Il ne vous dit pas si ces données étaient de bonne qualité. La surveillance de la qualité des données assure un suivi continu de la fraîcheur et de l'exhaustivité de votre catalogue. En la combinant aux traces d'agents, vous passez de « l'agent a donné une mauvaise réponse » à « l'agent a interrogé une table signalée comme obsolète », reliant ainsi le comportement de l'agent à la qualité des données sous-jacentes. La classification des données ajoute une couche supplémentaire : un système d'IA agentique scanne et étiquette en continu les colonnes sensibles, telles que les données PII, HIPAA et réglementées par le RGPD, et ces étiquettes alimentent directement le contrôle d'accès. Les colonnes masquées restent masquées, quel que soit l'agent ou le framework qui les demande. La gouvernance des données que vous avez déjà devient automatiquement votre gouvernance de l'IA.
Chaque appel de modèle a un coût. La plupart des entreprises n'ont aucune idée de qui les utilise, à quelles fins, ou si cela fonctionne, jusqu'à ce que la facture arrive et que le service financier doive expliquer un montant que personne n'avait anticipé.
La cause profonde n'est pas un processus défaillant. C'est un manque d'infrastructure : pas de couche de mesure qui visualise tout le trafic d'IA en un seul endroit, pas de système de balisage qui l'attribue à des équipes ou à des cas d'utilisation, pas de contrôles des dépenses coexistant avec les contrôles d'accès régissant les mêmes ressources.
Nous avons intégré cela à Unity Catalog et Unity AI Gateway. Le suivi de l'utilisation enregistre chaque requête dans des tables d'utilisation, y compris le nombre de jetons, la latence, l'identité du demandeur et la destination du modèle, pour les fournisseurs hébergés par Databricks et les fournisseurs externes, dans une seule table. Il vous permet d'étiqueter les requêtes par équipe, projet ou centre de coûts. Parce qu'il se présente sous forme de table à côté de vos traces d'agents et de vos données commerciales, vous pouvez relier le coût aux résultats. Un agent qui coûte 200 $ et génère 50 000 $ de pipeline qualifié est une bonne affaire. Un agent qui coûte 200 $ à interroger des données obsolètes en boucle est un gaspillage. Sans relier le coût au résultat, vous ne pouvez pas faire la différence.
Les budgets dans Unity AI Gateway ajoutent la couche de politique. Les administrateurs définissent des seuils de dépenses mensuels par utilisateur ou par groupe et sont alertés lorsque la consommation s'en approche ou les dépasse — le signal dont vous avez besoin avant que les dépenses ne deviennent un problème, et non après. L'application stricte est la prochaine étape naturelle, et nous aurons plus à partager à ce sujet bientôt.

Toute stratégie de gouvernance de l'IA en entreprise est confrontée à la même contrainte : une nouvelle équipe choisit un framework différent, un nouveau fournisseur publie un meilleur modèle. Si votre gouvernance est intégrée aux choix d'outils actuels, vous êtes sur un tapis roulant : chaque nouveau framework est une nouvelle intégration, chaque nouveau modèle est une nouvelle politique.
Nous l'avons reconnu, et c'est pourquoi nous avons adopté une approche différente de la plupart des outils de gouvernance. La gouvernance ne peut pas se limiter à la couche d'agents. Elle doit également résider dans les données et les services auxquels les agents accèdent, que ces services soient gérés par Databricks ou non. Un agent construit sur LangGraph et un autre sur CrewAI interrogent tous deux le même Unity Catalog, invoquent les mêmes serveurs MCP gouvernés et transitent par le même AI Gateway. Le framework est sans importance. La gouvernance accompagne les ressources, et non le code qui les appelle.
Les standards ouverts concrétisent cela. Les MCPs offrent aux agents un protocole universel de connectivité d'outils : enregistrez une fois dans Unity Catalog, invoquez depuis n'importe quel framework avec les mêmes permissions et le même journal d'audit. Unity AI Gateway fournit un point de terminaison unique et gouverné pour les modèles hébergés par Databricks, Azure OpenAI, AWS Bedrock et Anthropic, avec une seule politique, un seul journal d'audit et une seule couche d'attribution des coûts pour tous les fournisseurs. Le traçage MLflow instrumente automatiquement LangChain, LlamaIndex, AutoGen, le SDK OpenAI, le SDK Anthropic, et plus encore, avec des traces enregistrées dans Unity Catalog sous forme de tables sans instrumentation personnalisée par framework.
Le résultat final est que la gouvernance devient une propriété de votre plateforme plutôt que quelque chose que vous reconstruisez pour chaque nouveau framework ou modèle. Chaque agent que vous déployez, quelle que soit la manière dont il a été construit ou le modèle qui l'alimente, accède aux mêmes données gouvernées, à la même logique métier et aux mêmes permissions. Vous définissez les règles une fois, et chaque agent qui suit les adopte automatiquement.
Les entreprises qui mettent en place une bonne gouvernance de l'IA ne se contenteront pas d'éviter les incidents. Elles avanceront plus vite que celles qui ne le font pas, car leurs équipes ont confiance dans l'infrastructure sous-jacente, et cette confiance élimine les frictions qui ralentissent tous les autres.
Si vous travaillez dans cette direction, commencez par notre cours gratuit sur la gouvernance des agents d'IA, téléchargez le Databricks AI Security Framework (DASF), et visitez notre page web sur la gouvernance de l'IA pour des ressources supplémentaires.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.