Agents IA sûrs, non fiables, « porteurs de preuve » : vers l'entrepôt de données agentique

Informations de base

• ID de l'article : 2510.09567
• Titre : Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse
• Auteurs : Jacopo Tagliabue (Bauplan Labs), Ciro Greco (Bauplan Labs)
• Classification : cs.AI cs.DB
• Date de publication : 10 octobre 2025 (prépublication arXiv)
• Lien de l'article : https://arxiv.org/abs/2510.09567

Résumé

Les entrepôts de données (Data Lakehouse) exécutent des charges de travail sensibles, et l'automatisation pilotée par l'IA soulève des préoccupations concernant la confiance, la correction et la gouvernance. Cet article soutient qu'une approche basée sur les API pour les entrepôts de données programmables fournit l'abstraction appropriée pour les flux de travail d'agents conçus de manière sûre. En utilisant Bauplan comme étude de cas, nous démontrons comment la ramification des données et les environnements déclaratifs s'étendent naturellement aux agents, permettant la reproductibilité et l'observabilité tout en réduisant la surface d'attaque. Nous proposons une preuve de concept dans laquelle les agents utilisent des vérifications de correction inspirées par le code porteur de preuve pour corriger les pipelines de données. Le prototype démontre que les agents IA non fiables peuvent fonctionner en toute sécurité sur les données de production et esquisse un chemin vers un entrepôt de données entièrement agentique.

Contexte et motivation de la recherche

Définition du problème

1. Problème central : Comment permettre aux agents IA de gérer en toute sécurité le cycle de vie des données dans les entrepôts de données, en particulier dans les environnements de production sensibles, compte tenu de l'amélioration des capacités de raisonnement et d'utilisation d'outils des LLM ?
2. Analyse des défis :
   • Les entrepôts de données sont des systèmes distribués construits pour la collaboration d'équipes humaines, traitant des données de production sensibles, inadaptés à l'automatisation de bout en bout
   • L'hétérogénéité des plates-formes rend les priorités des cas d'usage des agents peu claires
   • Les systèmes traditionnels résistent à l'automatisation en raison de l'hétérogénéité des interfaces et des modèles d'accès complexes
3. Besoins pratiques :
   • Les ingénieurs de données consacrent beaucoup de temps à la correction des pipelines de données
   • La correction de pipelines est une pierre de touche pour les scénarios à haut risque et non triviaux
   • Nécessité d'automatiser tout en garantissant la sécurité

Motivation de la recherche

• Valeur pratique : Les pipelines couvrent la majorité des charges de travail des entrepôts de données (mesurées par le temps de développement et le volume de calcul total)
• Défi technique : Tester les capacités de pénétration des agents dans des scénarios à haut risque
• Exigences système : Besoin d'une interface unifiée pour relier les agents, les systèmes cloud et les superviseurs humains

Contributions principales

1. Conception abstraite : Introduction d'abstractions pour modéliser le cycle de vie des données dans les entrepôts de données programmables, avec construction et exécution complètes des pipelines cloud via le code
2. Cadre de sécurité : Examen et résolution des objections courantes à l'automatisation des charges de travail à haut risque, arguant que les modèles favorisent la confiance et la correction concernant les artefacts de données et de code
3. Implémentation de prototype : Publication de code fonctionnel démontrant une preuve de concept de pipeline auto-réparant utilisant Bauplan comme entrepôt de données et boucle d'agent
4. Planification de trajectoire : Esquisse des étapes pratiques suivantes pour réaliser un entrepôt de données entièrement agentique basé sur le prototype

Détails méthodologiques

Architecture de l'entrepôt de données programmable

Définition des pipelines

Les pipelines sont définis comme des DAG (graphes acycliques dirigés) de transformations, avec les caractéristiques suivantes :

@bauplan.model(materialization="REPLACE", name="A")
@bauplan.python("3.10", pip={"pandas": "2.0"})
def join_and_filter(
    trips=bauplan.Model("taxi_trips"),
    zones=bauplan.Model("taxi_zones")
):
    return trips.join(zones).do_something()

Choix de conception clés :

1. Abstraction FaaS : La logique métier est exprimée comme une simple fonction Table(s) → Table
2. E/S déclaratif : Les fonctions sont complètement isolées, l'environnement Python est spécifié de manière déclarative

Exécution des pipelines

L'exécution adopte un modèle transactionnel, combinant les concepts de Git :

$ pip install bauplan
$ bauplan run --project_dir P_folder

Garanties transactionnelles :

• Modèle de ramification-fusion : L'exécution se déplace automatiquement vers une branche de copie-sur-écriture
• Opérations atomiques : Seules les exécutions réussies sont fusionnées avec la branche principale
• Écritures en bac à sable : Lecture depuis la production mais écriture isolée, évitant les lectures sales

Conception des mécanismes de sécurité

Liste de contrôle de sécurité à quatre dimensions

Mesures de sécurité spécifiques

1. Confiance aux données :
   • L'E/S est toujours médiatisé par la plate-forme
   • Les agents ne peuvent pas accéder à la couche de données physique (S3)
   • RBAC basé sur les clés API fournissant des permissions granulaires
2. Confiance au code :
   • Les fonctions s'exécutent comme des processus indépendants, isolés de l'hôte et des autres fonctions
   • Pas d'accès à Internet
   • La syntaxe déclarative supporte la vérification de la liste blanche des paquets
3. Correction des données :
   • Les pipelines incomplets n'affectent pas les systèmes en aval
   • L'examen humain peut contrôler les permissions de fusion vers la branche principale
   • Les commits historiques permettent la récupération des tables à tout moment
4. Correction du code :
   • Adoption du protocole « code porteur de preuve »
   • Les fonctions de vérification Branch → bool permettent aux agents de fusionner les branches
   • Exploitation du flux de demande de tirage de Git-for-Data

Architecture de mise en œuvre des agents

Composants du système

• Bauplan : Plate-forme d'entrepôt de données programmable
• Bauplan MCP : Exposition de l'API de l'entrepôt de données en tant qu'outils
• smolagents : Framework ReAct, gestion des boucles, appels d'outils et journalisation
• Support multi-LLM : Support d'OpenAI, Anthropic, TogetherAI via interface LiteLLM
• Vérificateur : Étape de « vérification de preuve » avant la fusion

Capacités des outils

• Observabilité : Récupération des tâches échouées et de leurs journaux
• Exploration des données : Interrogation des tables, vérification des types
• Contrôle d'exécution : Création de branches, lancement d'exécutions

Configuration expérimentale

Scénario expérimental

Simulation de défaillance : Basée sur les rapports industriels et l'expérience, simulation de problèmes d'incompatibilité de paquets autour de la version NumPy 2.0, causant l'effondrement des conteneurs utilisant pandas 2.0.

Pile technologique

• Modèles d'inférence : Claude Sonnet 4.5 et autres modèles de pointe
• Framework : smolagents (ReAct basé sur Python)
• Plate-forme : Entrepôt de données Bauplan
• Ensemble de données : Ensemble de données des taxis de New York

Dimensions d'évaluation

• Taux de succès : Proportion de pipelines corrigés avec succès par l'agent
• Utilisation de tokens : Ressources de calcul nécessaires pour accomplir la tâche
• Nombre d'appels d'outils : Fréquence d'interaction de l'agent avec le système
• Sécurité : Stabilité du système en cas d'échec de l'agent

Résultats expérimentaux

Résultats principaux

1. Différences de performance des modèles significatives :
   • Les modèles de pointe (comme Sonnet 4.5) montrent des variations importantes en termes de taux de succès, d'utilisation de tokens et de nombre d'appels d'outils
   • Même en cas d'échec du modèle (comme GPT-4-mini), l'entrepôt de données n'a pas connu d'interruption ni de comportement non sûr
2. Limitations des systèmes traditionnels :
   • Les piles technologiques traditionnelles leaders de l'industrie (comme Snowflake + dbt) ne supportent pas la correction d'agents
   • Même s'ils disposent tous deux de serveurs MCP et desservent des cas d'usage qui se chevauchent
   • MCP est une condition nécessaire mais non suffisante pour l'automatisation
3. Flexibilité du système :
   • Le changement de modèle ne nécessite qu'une modification de configuration unique
   • Support de la sélection de modèles par étape dans les scénarios de contrainte budgétaire
   • La ramification des données supporte le contrôle de concurrence à grande échelle

Vérification de la sécurité

• Pas d'interruption de production : Aucune corruption de données de production dans toutes les expériences
• Contrôle des permissions efficace : Les mécanismes RBAC et de clé API fonctionnent correctement
• Garanties transactionnelles : Les tentatives de correction échouées n'ont pas affecté les systèmes en aval

Travaux connexes

Évolution des entrepôts de données

• Les entrepôts de données sont l'architecture standard de facto pour l'analyse cloud et les charges de travail IA
• Bénéficiant du découplage stockage-calcul, du support multilingue et de la sémantique de table unifiée

Utilisation d'outils par les agents IA

• L'amélioration du raisonnement et de l'utilisation d'outils par les LLM a stimulé les capacités de prise de décision autonome
• Les agents d'infrastructure existants se concentrent généralement sur des tâches spécifiques, manquant du support du cycle de vie complet

Code porteur de preuve

• Inspiré par « Safe, Untrusted Agents Using Proof-Carrying Code » de Necula et Lee
• Adaptation à l'environnement des données, focus sur le contexte métier plutôt que sur les propriétés formelles

Conclusion et discussion

Conclusions principales

1. Les entrepôts de données programmables sont naturellement adaptés à l'agentification : Les DAG déclaratifs et la gestion des données de type Git sont très appropriés pour supporter les utilisations d'agents conçues de manière sûre
2. La sécurité peut être garantie : Grâce à des abstractions appropriées et des mécanismes de vérification, les agents IA non fiables peuvent fonctionner en toute sécurité sur les données de production
3. La praticité a été validée : Le prototype a démontré avec succès la capacité à corriger les pipelines de données dans des scénarios réels

Limitations

1. Échelle expérimentale limitée : Le prototype actuel n'implique pas le traitement parallèle à grande échelle
2. Dépendance au modèle : Les performances dépendent fortement des capacités du LLM sous-jacent
3. Spécificité du scénario : Focus principal sur la correction de pipelines, d'autres cas d'usage nécessitent une validation supplémentaire

Directions futures

1. Parallélisme à grande échelle : C'est le principal défi des systèmes OLAP à l'ère de l'exploration de données par agents
2. Cas d'usage supplémentaires : Extension à la surveillance de la qualité des données, l'optimisation des performances, etc.
3. Normalisation : Établissement des normes industrielles et des meilleures pratiques pour les entrepôts de données agentifiés

Évaluation approfondie

Points forts

1. Approche systématique : Première résolution systématique du défi ouvert de la correction des pipelines cloud
2. Valeur pratique élevée : Résolution des points douloureux réels des ingénieurs de données
3. Conception de sécurité : Cadre de sécurité complet considérant les risques multidimensionnels
4. Contribution open-source : Fourniture de code fonctionnel complet facilitant la reproduction et l'amélioration par la communauté
5. Fondations théoriques solides : S'appuyant sur des théories matures comme le code porteur de preuve

Insuffisances

1. Évaluation incomplète : Manque d'évaluation systématique à grande échelle et dans des scénarios diversifiés
2. Dépendance à la plate-forme : Fortement dépendant de la plate-forme Bauplan, la généralité reste à vérifier
3. Analyse de coûts manquante : Absence d'analyse détaillée du rapport coûts-bénéfices
4. Mécanismes de gestion d'erreurs : Description insuffisante du traitement des scénarios d'erreur complexes

Impact

1. Contribution académique : Fourniture d'une nouvelle direction de recherche pour l'application des agents IA dans l'infrastructure de données
2. Valeur industrielle : Fourniture d'une solution pratiquement viable pour l'automatisation de l'ingénierie des données
3. Avancement technologique : Promotion du développement d'infrastructures de données programmables

Scénarios applicables

1. Équipes de données d'entreprise : Approprié pour les entreprises nécessitant l'automatisation de la maintenance des pipelines de données
2. Architecture cloud-native : Particulièrement approprié pour les organisations ayant adopté une architecture API-first
3. Culture DevOps : Approprié pour les équipes possédant une culture DevOps forte et des flux de travail Git

Références bibliographiques

L'article cite 24 références connexes, couvrant principalement :

• Architecture des entrepôts de données (Zaharia et al., 2021)
• Utilisation d'outils par les agents IA (Shen, 2024)
• Code porteur de preuve (Necula & Lee, 1998)
• Défis de l'ingénierie des données (Data World, 2021)
• Infrastructure programmable (Tagliabue et al., 2024)

Évaluation globale : Cet article est une étude systématique d'une valeur pratique importante, explorant pour la première fois de manière systématique l'application sûre des agents IA dans les environnements d'entrepôts de données. L'article combine l'innovation théorique et la mise en œuvre pratique, fournissant de nouvelles perspectives et outils pour l'automatisation de l'ingénierie des données. Bien qu'il y ait de la place pour l'amélioration en termes de complétude d'évaluation et de généralité, son travail novateur et ses contributions open-source lui confèrent une valeur académique et industrielle importante.