Genie autonome de Databricks : approbations, budgets et garde-fous à définir avant son lancement

Concrètement, cela tient en trois points : commencez par des tâches qui se contentent de lire et de rendre compte, placez une validation humaine devant tout ce qui modifie un système ou contacte une personne, et ne considérez pas un budget Genie comme un plafond de votre facture totale.

Ce qui change avec Genie autonome

Les tâches Genie n'attendent plus qu'on les sollicite. Le billet d'annonce de Databricks indique qu'une fois lancée, une tâche Genie peut s'exécuter selon un planning ou réagir à des déclencheurs, par exemple la baisse d'un indicateur ou plus de 10 clients demandant la même fonctionnalité.

Ces déclencheurs peuvent puiser dans un éventail de données bien plus large. Selon Databricks, Genie Search s'étend à plus de 100 sources de données d'entreprise, dont le lakehouse et des applications métier comme Google Drive, Jira et Confluence.

Cette portée élargie s'accompagne d'un autre modèle de facturation. Dans son communiqué de presse, Databricks précise que les clients paient à l'usage plutôt qu'au siège, et que les administrateurs peuvent fixer des limites de dépenses par équipe ou par utilisateur via Unity AI Gateway. Genie One est gratuit pour les utilisateurs jusqu'au 31 janvier 2027, et Databricks affirme que des contrôles de coûts plus détaillés seront disponibles d'ici là.

Pour illustrer le modèle à grande échelle, Databricks cite deux clients. L'éditeur indique que General Motors a déployé plus de 1,000 agents Genie dans les ventes, l'ingénierie, la chaîne d'approvisionnement et les opérations RH. HelloFresh aurait déclaré que Genie a réduit de 75% le temps nécessaire pour identifier les publicités gagnantes sur Meta. Ces deux affirmations sont publiées par Databricks, aucune ne constitue une mesure indépendante et aucune ne précise quels contrôles étaient en place : elles renseignent sur la demande, mais en disent peu sur le comportement de Genie dans votre environnement.

Pourquoi les agents toujours actifs exigent un autre modèle de risque

Dans un chat, une personne lit chaque réponse avant d'agir, et la session a une fin claire. Une tâche déclenchée peut s'exécuter en pleine nuit ou dès qu'un indicateur franchit un seuil, sans personne pour suivre, et elle continue jusqu'à ce que quelque chose l'arrête. Ses permissions se décident donc dès la conception.

Cette décision de conception se complique à mesure que les connecteurs se multiplient. Selon ses outils, une tâche capable de lire Jira et Confluence peut aussi être capable de les modifier. Pour chaque tâche, notez donc ce qu'elle peut modifier en plus de ce qu'elle peut voir.

Le volume aggrave le problème. La documentation de configuration de Databricks indique que chaque agent Genie peut prendre en charge jusqu'à 200,000 conversations, et que chaque conversation peut contenir jusqu'à 10,000 messages. Un déclencheur mal configuré pourrait se déclencher de nombreuses fois dans ces limites avant que quiconque ne s'en aperçoive.

Nous structurons cela avec ce que nous appelons l'échelle d'autonomie Lire-Rapporter-Agir. Chaque outil qu'une tâche pourrait appeler se voit attribuer un échelon, et chaque tâche gravit un échelon à la fois.

L'autonomie se gagne échelon par échelon, elle ne s'accorde pas agent par agent.

Approbations et listes d'outils autorisés

Partir par défaut sur la lecture et le rapport

Faites démarrer chaque tâche autonome sur les deux échelons inférieurs, et faites attendre une validation humaine pour tout ce qui écrit dans un système, envoie un message ou ouvre un ticket. C'est volontairement prudent : vous pourrez assouplir une politique plus tard, mais il est difficile de rappeler quelque chose qui a déjà atteint un client.

Rédiger les politiques de service sous forme de listes d'autorisation

Les politiques de service d'Unity AI Gateway déterminent quels appels d'outils MCP sont autorisés. La syntaxe et les options d'approbation peuvent évoluer : appuyez-vous donc sur les exemples de politiques de service et sur la documentation Govern an MCP de Databricks plutôt que de supposer qu'une fonctionnalité existe. Si vous avez besoin d'une étape d'approbation pour des outils de l'échelon Agir que la documentation ne décrit pas, interrogez Databricks, ou faites passer ces actions par un workflow existant qui exige déjà une validation.

Chaque politique doit nommer les outils qu'une tâche peut appeler.

S'attendre à ce que les politiques échouent en mode fermé

Les politiques de service échouent en mode fermé : une comparaison sur un champ manquant, une fonction non prise en charge ou toute erreur d'évaluation aboutit à DENY. C'est le bon choix par défaut en matière de sécurité, mais il a un coût opérationnel, car une faute de frappe ou une règle qui vérifie un champ absent de certains appels bloquera discrètement du travail légitime.

Les fournisseurs de garde-fous externes se comportent de la même façon. La documentation Govern an MCP précise que les politiques de service externes échouent en mode fermé : si le point de terminaison du fournisseur est injoignable ou lent, Databricks refuse l'appel. Une panne du fournisseur se traduit donc par des tâches en échec, et non par des tâches qui contournent le garde-fou. Configurez des alertes sur les refus, et décidez à l'avance si une exécution échouée est relancée plus tard ou se contente de signaler qu'elle n'a pas pu aboutir.

Tester une politique avant de lui faire confiance

Prenons une tâche de rapport hebdomadaire sur l'attrition, placée sur l'échelon Rapporter. La politique ci-dessous est un pseudocode illustratif avec des noms d'outils hypothétiques, et non de la syntaxe Databricks.

policy: churn-weekly-report
applies_to: tools/call
allow_if: tool_name in [run_readonly_sql, write_internal_summary]
otherwise: DENY

Effectuez ensuite trois appels depuis l'identité propre de la tâche :

1. Chemin autorisé. run_readonly_sql doit être autorisé.
2. Outil hors périmètre. create_ticket doit renvoyer DENY.
3. Échec délibéré. Un appel auquel manque le champ vérifié par la politique, par exemple sans nom d'outil, doit renvoyer DENY. S'il est autorisé, la politique ne fait pas ce que vous croyez.

Consignez les résultats avec le responsable de la tâche et relancez les trois tests chaque fois que la politique ou la liste d'outils change. Si votre outillage ne permet pas facilement d'envoyer un appel malformé, demandez à Databricks comment tester ce cas.

S'arrêter en cas de rejet pour limite de débit

Les limites de débit MCP s'appliquent aux requêtes tools/call et se mesurent en requêtes par minute (QPM). Les appels qui dépassent la limite renvoient HTTP 429. Nous suggérons de traiter un rejet pour limite de débit dans une tâche sans surveillance comme le signe que quelque chose d'inattendu se produit peut-être, par exemple une boucle ou un déclencheur qui s'active plus souvent que prévu, et de faire en sorte que la tâche s'arrête et le signale plutôt que de réessayer en boucle serrée, ce qui ne ferait qu'accumuler les appels rejetés. Les équipes peuvent trouver utile de fixer des limites QPM par outil à partir des besoins d'une exécution normale, avec une certaine marge, afin qu'un rejet reste assez rare pour constituer un véritable signal. Lorsqu'une tâche doit être interrompue en cours d'exécution, notre runbook de coupe-circuit pour agents IA explique comment l'arrêter proprement.

Plafonner la fréquence des déclencheurs

Une condition comme « plus de 10 clients ont demandé ceci » peut rester vraie pendant des heures, et si chaque nouvelle demande relance la tâche, vous obtenez une pile d'exécutions quasi identiques. Les limites QPM n'y changent rien, puisqu'elles ralentissent les appels au sein d'une exécution sans empêcher de nouvelles exécutions. Fixez un intervalle minimal entre les exécutions et un plafond quotidien. Les sources examinées ici ne décrivent pas de paramètre d'anti-rebond intégré pour les déclencheurs Genie : vérifiez auprès de Databricks et, à défaut, intégrez la limite dans la tâche.

Budgets : ce qu'ils suivent et ce qui leur échappe

Les budgets Genie ne couvrent que l'usage des LLM

La documentation sur les budgets Genie indique que les budgets suivent l'usage des LLM, et que le calcul utilisé pour exécuter les requêtes, comme un SQL warehouse, est facturé séparément et n'est pas inclus. Pour un agent de données dont la tâche principale consiste à exécuter des requêtes, cet écart peut être important : lors de la session de test de SELECT, décrite plus bas, le calcul exclu représentait la totalité de la facture.

La documentation précise aussi qu'il ne faut pas utiliser les budgets pour garantir un plafond absolu sur les montants finalement facturés, et que Databricks n'est pas responsable des coûts engagés au-delà des seuils budgétaires configurés. Les seuils vous aident à surveiller. Ils ne garantissent pas une limite.

Chaque budget accepte au maximum quatre seuils partagés et 100 dérogations par utilisateur, et un compte peut avoir au maximum 1,000 budgets. Si chaque équipe et chaque tâche reçoit son propre budget, vérifiez que votre conception tient dans ces limites.

Quotas gratuits et principaux de service

Databricks a commencé à facturer l'usage de Genie Code au-delà d'un quota mensuel gratuit le 8 juillet 2026. Une analyse indépendante de SELECT indique que chaque utilisateur identifié reçoit chaque mois 150 DBU Genie Code gratuits d'usage LLM, soit environ $10 à $11 selon le fournisseur cloud et la région. SELECT rapporte également que les principaux de service ne bénéficient d'aucun quota gratuit : tout usage de Genie rattaché à un principal de service est donc facturé dès la première requête.

L'écart en pratique

La session de test de SELECT montre pourquoi les dépenses LLM et les dépenses de calcul doivent être suivies séparément. La session a coûté $5.12 au prix catalogue : $4.34 en SQL Serverless et $0.77 en All-Purpose Serverless, avec $0.00 d'usage LLM Genie. La session a pourtant consommé environ 102 DBU d'usage LLM Genie, répartis entre 79.7 pour Genie Code et 22.7 pour Genie One et Agents, le tout dans le quota gratuit. Un budget Genie aurait surveillé la partie gratuite et manqué toute la facture.

Une seule session ne permet pas de prédire vos coûts, mais elle montre où se situe le risque. Notre playbook de passerelle IA sur le routage, les budgets et le contrôle des fournisseurs aborde la même séparation du point de vue de la passerelle.

Plafonds stricts : confirmer quel contrôle s'applique

Un billet du blog Databricks sur Unity AI Gateway décrit des plafonds de dépenses stricts qui arrêtent automatiquement les requêtes lorsque les budgets sont dépassés. La documentation des budgets Genie décrit des seuils à ne pas considérer comme un plafond absolu. Les deux peuvent être exacts pour des produits ou des chemins de requête différents : demandez donc à Databricks lequel s'applique aux tâches Genie autonomes.

Ali Ghodsi, de Databricks, a déclaré à TechCrunch que les coûts peuvent être maîtrisés grâce à Unity AI Gateway, qui permet aux entreprises de fixer des limites d'usage et de basculer vers des modèles à poids ouverts moins coûteux.

Le playbook de prélancement

Suivez les étapes dans l'ordre. N'en commencez aucune tant que la précédente n'a pas rempli son critère de sortie.

Les plannings passent avant les déclencheurs parce qu'ils sont prévisibles et plus faciles à examiner. À l'étape 5, une approbation ne vous protège que si la personne qui valide lit ce qu'elle approuve ; notre guide pour approuver et arrêter des exécutions d'agents depuis un téléphone traite de la validation sur mobile.

Questions ouvertes à régler avec Databricks

Stade de disponibilité et cloud

Les sources examinées ici n'indiquent pas clairement si chaque capacité autonome est en disponibilité générale, en préversion publique ou en bêta, et les conditions de support varient selon le stade. Les pages Databricks citées dans cet article sont par ailleurs les versions AWS, et nous n'avons pas vérifié le comportement sur Azure ou Google Cloud.

Identité d'exécution

Les sources ne précisent pas non plus si les tâches planifiées et déclenchées s'exécutent sous l'identité de leur créateur, d'un principal de service ou de l'utilisateur demandeur, et ce seul choix détermine à la fois l'accès aux données, les pistes d'audit et la facturation.

Reprenons la tâche de rapport hebdomadaire sur l'attrition. Si elle s'exécute sous l'identité de l'analyste qui l'a créée, elle hérite de tout ce que cet analyste peut lire, ce qui dépasse généralement les besoins d'une tâche de l'échelon Rapporter, et le journal d'audit associe le nom de l'analyste à des exécutions qu'il n'a jamais suivies. La faire passer sous un principal de service règle les problèmes d'audit et de cycle de vie, mais SELECT rapporte que les principaux de service ne bénéficient d'aucun quota gratuit : l'usage LLM qui aurait tenu dans le quota gratuit d'un utilisateur nommé est alors facturé dès la première requête. Aucune des deux options n'est mauvaise dans tous les cas.

Contexte du benchmark

Databricks indique que, dans son benchmark réalisé avec Turing, Genie a répondu correctement dans 91% des exécutions de tâches, soit 1.6 fois le taux de l'agent frontière le plus performant, tout en consommant moins de la moitié des tokens. La couverture d'Unite.AI situe cet agent frontière à 58%, Genie consommant en moyenne 431,829 tokens et 100.3 secondes par exécution. Databricks prévient que le test reflète un déploiement établi, doté de connaissances métier accumulées, et que les écarts peuvent être moindres dans les nouveaux déploiements ou lorsque les schémas de tables suffisent à eux seuls.

Prévisions de coûts et contrôles en évolution

SELECT cite une prévision d'IDC selon laquelle les organisations du G1000 font face à une hausse pouvant atteindre 30% des coûts d'infrastructure IA sous-estimés d'ici 2027, moins à cause de dépenses excessives qu'en raison de modèles de consommation opaques que la budgétisation classique n'a jamais pris en compte. Il s'agit d'une prévision, et nous la citons via SELECT plutôt qu'à partir du rapport original d'IDC, mais elle plaide tout de même pour un suivi séparé des dépenses LLM et de calcul dès le premier jour. Les contrôles de coûts promis par Databricks pourraient combler certaines des lacunes ci-dessus : revenez donc à cette checklist lorsqu'ils seront disponibles.