Agents AI natifs des données : pourquoi les agents doivent se rapprocher de vos données

La plupart des projets pilotes d'AI d'entreprise franchissent la même étape facile : connecter un LLM à vos données, ajouter une base de données vectorielle et faire une démonstration à la direction. La partie difficile vient plus tard. La sécurité signale des failles de gouvernance. La latence dans les agents multi-étapes nuit à l'expérience utilisateur. La facture de votre fournisseur de modèles ne cesse de grimper. Ces problèmes découlent généralement d'une seule décision : extraire les données de systèmes gouvernés pour les intégrer dans une pile d'AI qui n'a jamais été conçue pour appliquer vos politiques.

Cet article plaide pour une direction architecturale différente : déplacer les modèles et les agents vers les données, et non l'inverse. Au lieu de créer une infrastructure AI parallèle et de la connecter à votre lakehouse, vous traitez les agents comme des charges de travail natives qui s'exécutent au sein de votre plateforme de données, sous les mêmes contrôles de gouvernance, de sécurité et d'observabilité auxquels vous faites déjà confiance pour vos données.

Le lakehouse vous a offert un espace unique pour gouverner vos données. La question suivante est de savoir si vos agents vivent à l'intérieur ou à l'extérieur de cette limite. Deux paradigmes émergent.

Agents externes

Les agents et les LLM s'exécutent dans une pile AI distincte. Les données sont exportées ou interrogées via le réseau vers des bases de données vectorielles externes, des LLM SaaS ou des couches de service sur mesure. La gouvernance, la sécurité et l'observabilité sont réimplémentées pour l'AI en parallèle.

Agents natifs des données

Les agents, les modèles, les outils, la récupération (retrieval) et la mémoire des agents s'exécutent au sein de la même plateforme que les données elles-mêmes, sous une couche de gouvernance et de sécurité unifiée. L'AI devient une autre charge de travail sur votre pile de données existante.

La taxe cachée des agents externes

Les données ont une gravité. Le calcul est peu coûteux à déplacer ; les données ne le sont pas, en particulier à mesure que les volumes augmentent et que les modalités se multiplient. Les extraire introduit une série d'inconvénients bien connus :

• La gouvernance s'affaiblit. La réimplémentation du contrôle d'accès, du lignage (lineage) et de la résidence des données dans chaque intégration laisse des failles que les audits détectent.
• La latence s'accumule. Chaque saut vers un magasin de vecteurs externe, un LLM, et retour, s'additionne pour les agents multi-outils.
• Les coûts se fragmentent. Les frais de sortie (egress), le stockage en double et la tarification par jeton chez différents fournisseurs impactent le budget de trois manières différentes.
• Le cycle de vie devient une coordination de fournisseurs. Les schémas, les index et les modèles dérivent entre des systèmes qui ne partagent pas de pipeline de déploiement.
• L'observabilité se fragmente. Tracer une requête de bout en bout implique d'assembler les journaux (logs) de trois ou quatre outils.
• Le contexte métier reste en arrière. Les définitions de métriques, le glossaire métier et les regroupements de domaines résident dans votre couche de gouvernance ; un agent externe les recrée à partir des noms de colonnes, ou les devine.

Pourquoi la gouvernance a posteriori échoue pour les agents

De tous ces inconvénients, la gouvernance mérite une attention particulière car c'est le seul qui ne peut pas être corrigé après coup. La plupart des approches de la gouvernance de l'AI la traitent comme un filtre appliqué après que l'agent a déjà accédé aux données, par exemple en masquant les champs sensibles de la réponse, en bloquant certains sujets au niveau de la couche de sortie et en auditant les journaux après coup. Cela fonctionne pour des démos simples de Q&A. Cela s'effondre dès que les agents commencent à effectuer des calculs sur les données.

Prenons l'exemple d'un agent qui calcule un résumé financier sur des lignes soumises à une sécurité au niveau des lignes (row-level security). L'agrégation elle-même (la somme, la moyenne, la tendance) est une valeur dérivée qui dépend des lignes incluses. Si la gouvernance n'est pas appliquée avant l'exécution de la requête, le résultat encode déjà des données que l'utilisateur n'aurait pas dû influencer. Aucun masquage en aval ne peut annuler ce calcul. La décision de politique devait être prise au moment de la planification de la requête, et non au moment du rendu de la réponse.

C'est la lacune fondamentale de la gouvernance basée sur le périmètre ou a posteriori : elle suppose que les données peuvent être censurées en toute sécurité après avoir atteint l'agent. En pratique, une fois qu'une agrégation ou une transformation a eu lieu, l'intention de gouvernance est déjà perdue. Les contrôles rétroactifs sont fondamentalement incomplets.

Il y a un second coût à faire fausse route, et il se voit sur la facture. Le problème ne concerne pas seulement ce que l'agent est autorisé à toucher, même si cela en fait partie. Lorsque la gouvernance est résolue après coup plutôt qu'à la source, l'agent finit par faire le travail de réconciliation lui-même : parcourir les journaux d'audit, joindre des fragments de systèmes externes, extraire le même enregistrement de plusieurs endroits pour déterminer s'il peut l'utiliser, et réévaluer chaque résultat partiel. Rien de tout cela n'est sa tâche principale. C'est l'agent qui compense l'absence d'une réponse gouvernée fournie dès le départ. Les sorties bloquées ou masquées ne font qu'alimenter la spirale, car l'agent les interprète comme des échecs et réessaie. Les sessions s'allongent, chaque saut charge plus de contexte dans le modèle, et une seule requête se transforme discrètement en milliers de jetons facturés. C'est la boucle de consommation excessive de jetons, et la gouvernance a posteriori est ce qui la déclenche.

Les agents natifs des données répondent à ces défis en intégrant l'application des politiques directement dans la planification et le calcul des requêtes. Chaque résultat intermédiaire reflète les mêmes contraintes de gouvernance. La gouvernance doit être évaluée avant et pendant l'exécution, ce que vous ne pouvez pas vous permettre d'appliquer après coup une fois le calcul terminé. Les Custom Guardrails dans Unity AI Gateway en sont la forme concrète : des politiques composables et déterministes que la passerelle applique à chaque requête et réponse, et non des filtres auxquels on demande au modèle d'obéir après coup. Définir la politique au moment de la planification, sur des données qui résident déjà dans un espace gouverné unique, signifie également que l'agent obtient une réponse claire en un seul passage au lieu d'explorer divers systèmes pour en assembler ou en justifier une.

L'état et la mémoire de l'agent ont besoin de gouvernance

Jusqu'à présent, nous nous sommes concentrés sur la manière dont les agents lisent les données. Mais les agents en production écrivent également : historique des conversations, progression des tâches, préférences des utilisateurs, résultats mis en cache et sorties d'outils pour un audit ultérieur. À mesure que les agents assument davantage de rôles, la couche d'état importe tout autant que la couche de données. Laissez-la en dehors de la limite de gouvernance, et chaque promesse d'auditabilité de bout en bout comportera une faille.

L'état est le bloc-notes à court terme de l'agent : la conversation en cours, la tâche en vol, le cache qu'il vient de remplir. La mémoire est ce qui survit à la session : les clients avec lesquels un agent a interagi, ce qu'un utilisateur préfère, les résultats passés qui valent la peine d'être réutilisés. Les deux nécessitent un stockage transactionnel, et les deux perdent leur gouvernance dès qu'ils quittent la plateforme. Une mémoire telle que "l'utilisateur X est un client EU à forte valeur" constitue en soi une donnée sensible, soumise aux mêmes règles d'accès et de résidence que l'enregistrement qu'elle résume. Et il s'agit d'une charge de travail transactionnelle : les tables Delta sont conçues pour de grands balayages analytiques, mais l'état de l'agent nécessite des lectures et écritures rapides par ligne, des recherches par clé et des mises à jour atomiques.

La solution de contournement habituelle consiste à utiliser un système Postgres ou Redis externe. Mais cela vous ramène au problème contre lequel cet article s'élève : l'état de l'agent quitte le périmètre gouverné pour un système que votre couche de gouvernance ne peut pas voir, avec sa propre sécurité et son propre cycle de vie à gérer. Vous avez ainsi construit un agent natif des données avec une dépendance non gouvernée.

Et le problème s'amplifie dès qu'un agent se multiplie. Un essaim (swarm) travaillant vers un objectif plus large (un planificateur déléguant à des spécialistes, un superviseur réconciliant leurs résultats) a besoin d'une mémoire partagée, et c'est sur l'alignement de celle-ci que ces systèmes échouent. Lorsque chaque agent conserve un état privé et transmet le contexte de pair à pair, il n'y a pas de source unique de vérité. Les agents divergent, les écritures entrent en collision, et chaque transfert est un autre canal non gouverné qui se multiplie à mesure que l'essaim grandit. L'échange de mémoire s'avère être la partie difficile.

Lakebase comble ces lacunes. Il s'agit d'un stockage PostgreSQL entièrement géré au sein de la plateforme Databricks, sous le même plan de gouvernance que tout le reste. L'état de l'agent devient un actif gouverné : il hérite des contrôles d'accès de la plateforme, coexiste avec les données et les outils de l'agent, et ne nécessite aucune équipe d'infrastructure distincte. Et parce que chaque agent lit et écrit dans cette même couche transactionnelle, elle sert également de source unique de vérité pour l'essaim. L'état reste cohérent, les mises à jour atomiques empêchent deux agents de corrompre la même tâche, une politique sur la vue d'un agent s'applique à tout ce qu'il écrit pour le suivant, et toute mémoire peut être tracée à travers l'essaim : quel agent l'a écrite, lequel l'a lue, et comment une conclusion approfondie remonte à sa source.

Le plaidoyer pour les agents natifs des données

L'argument de la gouvernance est le plus percutant, mais les avantages vont plus loin. Lorsque les agents s'exécutent au sein de la pile de données, les avantages se cumulent dans toutes les dimensions opérationnelles : sécurité, qualité, observabilité, déploiement, latence et coût. Les outils et les dépendances de données sont configurés et enregistrés aux côtés du modèle, de sorte que l'ensemble du système est versionné, auditable et reproductible par défaut.

La comparaison suivante résume la manière dont ces deux paradigmes diffèrent selon les dimensions qui importent le plus pour les systèmes en production :

À quoi ressemblent réellement les agents natifs de données sur Databricks

La Data Intelligence Platform met cela en pratique. Au lieu de créer une "pile AI" distincte et de la connecter à vos données, vous construisez des agents AI directement au sein de la pile de données. Un agent natif de données sur Databricks est un agent qui :

• Achemine tout le trafic des modèles et des agents via Unity AI Gateway, où chaque requête est vérifiée avant exécution et chaque réponse inspectée après, avec des politiques déterministes ALLOW / DENY / ASK remplaçant le filtrage au mieux après coup. Le contrôle d'accès, la limitation du débit, la journalisation de la charge utile et le suivi des coûts résident tous dans le même plan de contrôle, y compris les appels aux fournisseurs de LLM externes et aux agents de codage.
• Traite chaque primitive AI (modèles, agents, MCPs, compétences et les outils qu'ils appellent) comme un actif Unity Catalog aux côtés des tables et des fonctions, de sorte que l'identité, la traçabilité et les contrôles d'accès s'appliquent uniformément à l'ensemble de la surface AI.
• Capture les traces complètes des requêtes via MLflow 3 : chaque appel de LLM, invocation d'outil, score, évaluation, document récupéré et boucle de surveillance de bout en bout devient auditable pour la conformité et observable pour le débogage.
• Exécute l'inférence à l'intérieur de votre périmètre de sécurité Databricks sur Model Serving, sans mouvement de données non gouverné vers des piles AI tierces.
• Récupère le contexte à partir d'index basés sur Delta qui respectent les ACL de Unity Catalog et suivent automatiquement la traçabilité, propulsé par AI Search.
• Se souvient d'une session à l'autre grâce à l'état et à la mémoire basés sur Lakebase : le contexte de conversation à court terme, la progression des tâches en plusieurs étapes, les préférences utilisateur à long terme et le rappel épisodique des appels d'outils passés coexistent avec les données sur lesquelles l'agent raisonne.
• Ancre le raisonnement dans un contexte métier grâce aux Unity Catalog Semantics (Metrics, Business Glossary, Domains) et à Genie Ontology, un graphe de connaissances auto-géré extrait des tables, requêtes, tableaux de bord et applications que l'équipe utilise déjà.
• Délègue le raisonnement spécialisé à d'autres agents, y compris Genie pour les questions sur les données structurées, avec une coordination multi-étapes et inter-domaines au sein des limites de la plateforme.
• Étend la même gouvernance aux agents de codage via Omnigent, un méta-harnais qui achemine Claude Code, Codex et Cursor à travers Unity AI Gateway avec des sessions partagées et une piste d'audit commune.

Par où commencer

Certaines entreprises construisent déjà de cette manière. Leurs agents s'exécutent dans les mêmes limites que leurs données, avec des politiques Unity Catalog couvrant les deux, un état dans Lakebase et un trafic passant par Unity AI Gateway. Aucune d'entre elles n'y est parvenue grâce à un projet unique de changement de plateforme. Elles ont comblé le fossé entre le lakehouse et la pile AI un projet pilote à la fois, puis ont cessé d'en ouvrir de nouveaux.

Pour les équipes qui débutent sur cette voie, le travail n'est pas insurmontable. La plupart des éléments existent déjà du côté de la plateforme : Model Serving, Unity Catalog, Lakebase, MLflow. Ce qui manque, c'est la décision de les traiter comme le foyer de l'agent plutôt que comme de simples sources de données pour une pile parallèle. Cette décision a tendance à être la partie la plus difficile.

Le point de départ le plus utile consiste à faire l'inventaire de ce qui s'exécute déjà en dehors du périmètre. C'est de là que proviendra le prochain incident de gouvernance, et c'est ce travail qui rend tout le reste possible.

Si vous souhaitez approfondir la manière d'opérationnaliser des agents natifs de données avec les garde-fous et les modèles appropriés, ces ressources constituent une excellente prochaine étape :

• Pour traduire votre stratégie en contrôles concrets, lisez A Practical AI Governance Framework for Enterprises, qui montre comment transformer des objectifs de haut niveau en rôles, politiques et flux de travail sur la Databricks Data Intelligence Platform.
• Pour une vision plus large de l'AI responsable en pratique, AI Governance Best Practices: How to Build Responsible and Effective AI Programs présente les principes et les modèles opérationnels que vous pouvez adopter au sein de vos équipes.

Pour explorer les fonctionnalités de la plateforme présentées dans cet article :

• Unity AI Gateway: What’s New at Data + AI Summit 2026 — un plan de contrôle unique pour tout le trafic des modèles et des agents, avec des Custom Guardrails déterministes ALLOW/DENY/ASK.
• Agent Bricks: Data + AI Summit 2026 — des agents auto-optimisés fournis sous forme de charges de travail gouvernées de premier ordre sur la plateforme.
• Omnigent: A Meta-Harness to Combine, Control and Share Your Agents — achemine les agents de codage (Claude Code, Codex, Cursor) à travers Unity AI Gateway avec une piste d'audit partagée.
• Introducing Genie One, Genie Agents, and Genie Ontology — le graphe de connaissances auto-géré qui ancre les agents dans votre contexte métier.
• Memory Scaling for AI Agents — comment l'état et la mémoire des agents évoluent sur Lakebase, régis par Unity Catalog au sein de la plateforme.

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