Agenti AI Sicuri, Non Affidabili, "Proof-Carrying": verso il lakehouse agenziale

Informazioni Fondamentali

• ID Articolo: 2510.09567
• Titolo: Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse
• Autori: Jacopo Tagliabue (Bauplan Labs), Ciro Greco (Bauplan Labs)
• Classificazione: cs.AI cs.DB
• Data di Pubblicazione: 10 ottobre 2025 (preprint arXiv)
• Link Articolo: https://arxiv.org/abs/2510.09567

Riassunto

I data lakehouse gestiscono carichi di lavoro sensibili e l'automazione guidata dall'IA ha suscitato preoccupazioni riguardanti la fiducia, la correttezza e la governance. Questo articolo sostiene che un lakehouse programmabile orientato alle API fornisce l'astrazione corretta per flussi di lavoro agenziali progettati in modo sicuro. Utilizzando Bauplan come caso di studio, si dimostra come il branching dei dati e gli ambienti dichiarativi si estendono naturalmente agli agenti, consentendo riproducibilità e osservabilità, riducendo al contempo la superficie di attacco. Viene proposto un proof-of-concept in cui gli agenti utilizzano controlli di correttezza ispirati al codice proof-carrying per riparare le pipeline di dati. Il prototipo dimostra che agenti IA non affidabili possono operare in modo sicuro su dati di produzione e delinea il percorso verso un lakehouse completamente agenziale.

Contesto di Ricerca e Motivazione

Definizione del Problema

1. Problema Centrale: Con il miglioramento delle capacità di ragionamento e utilizzo di strumenti dei modelli di linguaggio di grandi dimensioni (LLM), come consentire agli agenti IA di gestire in modo sicuro il ciclo di vita dei dati nei data lakehouse, in particolare in ambienti di produzione sensibili?
2. Analisi delle Sfide:
   • I lakehouse sono sistemi distribuiti costruiti per la collaborazione tra team umani, gestiscono dati di produzione sensibili e non sono adatti all'automazione end-to-end
   • L'eterogeneità delle piattaforme rende poco chiara la priorità dei casi d'uso agenziali
   • I sistemi tradizionali resistono all'automazione a causa dell'eterogeneità delle interfacce e dei complessi modelli di accesso
3. Esigenze Pratiche:
   • Gli ingegneri dei dati dedicano molto tempo alla riparazione delle pipeline di dati
   • La riparazione delle pipeline è una pietra di paragone per scenari ad alto rischio e non banali
   • È necessaria l'automazione garantendo al contempo la sicurezza

Motivazione della Ricerca

• Valore Pratico: Le pipeline rappresentano la maggior parte dei carichi di lavoro del lakehouse (misurati per tempo di sviluppo e volume di calcolo totale)
• Sfida Tecnica: Test delle capacità di penetrazione agenziale in scenari ad alto rischio
• Requisiti di Sistema: È necessaria un'interfaccia unificata per collegare agenti, sistemi cloud e supervisori umani

Contributi Principali

1. Progettazione dell'Astrazione: Introduzione di astrazioni per modellare il ciclo di vita dei dati in un lakehouse programmabile, con costruzione ed esecuzione di pipeline cloud completamente tramite codice
2. Framework di Sicurezza: Revisione e affrontamento delle obiezioni comuni all'automazione di carichi di lavoro ad alto rischio, argomentando come i modelli promuovono affidabilità e correttezza rispetto agli artefatti di dati e codice
3. Implementazione del Prototipo: Rilascio di codice funzionante che dimostra un proof-of-concept di pipeline auto-riparanti utilizzando Bauplan come lakehouse e ciclo agenziale
4. Pianificazione del Percorso: Delineazione dei passaggi pratici successivi per realizzare un lakehouse completamente agenziale sulla base del prototipo

Dettagli Metodologici

Architettura del Lakehouse Programmabile

Definizione delle Pipeline

Le pipeline sono definite come DAG (grafi aciclici diretti) di trasformazioni, con le seguenti caratteristiche:

@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()

Scelte Progettuali Chiave:

1. Astrazione FaaS: La logica di business è espressa come funzione semplice Table(s) → Table
2. I/O Dichiarativo: Le funzioni sono completamente isolate, l'ambiente Python è specificato in modo dichiarativo

Esecuzione delle Pipeline

L'esecuzione adotta un modello transazionale, combinando concetti da Git:

$ pip install bauplan
$ bauplan run --project_dir P_folder

Garanzie Transazionali:

• Modello Branch-Merge: L'esecuzione si sposta automaticamente su un branch con copia-in-scrittura
• Operazioni Atomiche: Solo le esecuzioni riuscite vengono unite al branch principale
• Scritture in Sandbox: Lettura dalla produzione ma scrittura isolata, evitando letture sporche

Progettazione dei Meccanismi di Sicurezza

Checklist di Sicurezza Quadridimensionale

Misure di Sicurezza Specifiche

1. Fiducia nei Dati:
   • L'I/O è sempre mediato dalla piattaforma
   • Gli agenti non possono accedere al livello di dati fisico (S3)
   • RBAC basato su chiavi API fornisce autorizzazioni granulari
2. Fiducia nel Codice:
   • Le funzioni vengono eseguite come processi indipendenti, isolati dall'host e da altre funzioni
   • Nessun accesso a Internet
   • La sintassi dichiarativa supporta il controllo della whitelist dei pacchetti
3. Correttezza dei Dati:
   • Le pipeline incomplete non influenzano i sistemi downstream
   • La revisione manuale può controllare i permessi di unione al branch principale
   • L'utilizzo della cronologia dei commit consente il ripristino della tabella in qualsiasi momento
4. Correttezza del Codice:
   • Adozione del protocollo "proof-carrying code"
   • La funzione validatore Branch → bool consente l'unione del branch agenziale
   • Sfruttamento del flusso di pull request di Git-for-Data

Architettura di Implementazione dell'Agente

Componenti di Sistema

• Bauplan: Piattaforma lakehouse programmabile
• Bauplan MCP: Espone l'API del lakehouse come strumenti
• smolagents: Framework ReAct, gestisce cicli, chiamate di strumenti e logging
• Supporto Multi-LLM: Supporta OpenAI, Anthropic, TogetherAI tramite interfaccia LiteLLM
• Validatore: Fase di "verifica della prova" prima dell'unione

Capacità degli Strumenti

• Osservabilità: Ottenere processi falliti e relativi log
• Esplorazione dei Dati: Interrogare tabelle, controllare tipi
• Controllo dell'Esecuzione: Creare branch, avviare esecuzioni

Configurazione Sperimentale

Scenario Sperimentale

Simulazione di Guasti: Basata su rapporti industriali ed esperienza, simula problemi di incompatibilità di pacchetti intorno al rilascio di NumPy 2.0, causando crash di contenitori che utilizzano pandas 2.0.

Stack Tecnologico

• Modelli di Inferenza: Modelli all'avanguardia come Claude Sonnet 4.5
• Framework: smolagents (ReAct basato su Python)
• Piattaforma: Lakehouse Bauplan
• Dataset: Dataset dei taxi di New York City

Dimensioni di Valutazione

• Tasso di Successo: Proporzione di pipeline riparate con successo dall'agente
• Utilizzo di Token: Risorse computazionali necessarie per completare l'attività
• Numero di Chiamate di Strumenti: Frequenza di interazione dell'agente con il sistema
• Sicurezza: Stabilità del sistema quando l'agente fallisce

Risultati Sperimentali

Risultati Principali

1. Differenze di Prestazioni Significative tra Modelli:
   • I modelli all'avanguardia (come Sonnet 4.5) mostrano differenze significative in tasso di successo, utilizzo di token e numero di chiamate di strumenti
   • Anche quando i modelli falliscono (come GPT-4-mini), il lakehouse non ha subito interruzioni o comportamenti non sicuri
2. Limitazioni dei Sistemi Tradizionali:
   • Gli stack tecnologici tradizionali leader del settore (come Snowflake + dbt) non supportano la riparazione agenziale
   • Anche se dispongono di server MCP e servono casi d'uso sovrapposti
   • MCP è una condizione necessaria ma non sufficiente per l'automazione
3. Flessibilità del Sistema:
   • Il cambio di modello richiede solo una modifica di configurazione singola
   • Supporta la selezione di modelli dipendenti dai passaggi in scenari con vincoli di budget
   • Il branching dei dati supporta il controllo della concorrenza su larga scala

Verifica della Sicurezza

• Nessuna Interruzione di Produzione: Nessun danneggiamento dei dati di produzione in tutti gli esperimenti
• Controllo dei Permessi Efficace: I meccanismi RBAC e chiave API funzionano correttamente
• Garanzie Transazionali: I tentativi di riparazione falliti non hanno influenzato i sistemi downstream

Lavori Correlati

Evoluzione del Data Lakehouse

• Il data lakehouse è l'architettura standard di fatto per l'analisi cloud e i carichi di lavoro IA
• Beneficia dal disaccoppiamento storage-compute, dal supporto multilingue e dalla semantica di tabella unificata

Utilizzo di Strumenti da Parte di Agenti IA

• I miglioramenti nei LLM nel ragionamento e nell'utilizzo di strumenti hanno spinto le capacità decisionali autonome
• Gli agenti infrastrutturali esistenti si concentrano su compiti specifici, mancando di supporto per il ciclo di vita completo

Codice Proof-Carrying

• Ispirato a "Safe, Untrusted Agents Using Proof-Carrying Code" di Necula e Lee
• Adattato all'ambiente dei dati, focalizzato sul contesto aziendale piuttosto che su proprietà formali

Conclusioni e Discussione

Conclusioni Principali

1. I Lakehouse Programmabili sono Naturalmente Adatti all'Agenzialità: I DAG dichiarativi e la gestione dei dati simile a Git sono molto adatti al supporto di utilizzi agenziali progettati in modo sicuro
2. La Sicurezza Può Essere Garantita: Attraverso astrazioni appropriate e meccanismi di verifica, agenti IA non affidabili possono operare in modo sicuro su dati di produzione
3. La Praticità è Verificata: Il prototipo ha dimostrato con successo la capacità di riparare le pipeline di dati in scenari reali

Limitazioni

1. Scala Sperimentale Limitata: Il prototipo attuale non coinvolge l'elaborazione parallela su larga scala
2. Dipendenza dal Modello: Le prestazioni dipendono fortemente dalle capacità dell'LLM sottostante
3. Specificità dello Scenario: Principalmente focalizzato sulla riparazione delle pipeline, altri casi d'uso richiedono ulteriore verifica

Direzioni Future

1. Parallelismo su Larga Scala: Questa è la sfida principale per i sistemi OLAP nell'era dell'esplorazione dei dati agenziale
2. Ulteriori Casi d'Uso: Estensione al monitoraggio della qualità dei dati, all'ottimizzazione delle prestazioni e altri scenari
3. Standardizzazione: Stabilimento di standard e best practice industriali per i lakehouse agenziali

Valutazione Approfondita

Punti di Forza

1. Approccio Sistematico: Primo affrontamento sistematico della sfida aperta della riparazione delle pipeline cloud
2. Valore Pratico Elevato: Risolve i problemi reali degli ingegneri dei dati
3. Progettazione della Sicurezza: Framework di sicurezza completo che considera i rischi multidimensionali
4. Contributo Open Source: Fornisce codice funzionante completo, facilitando la riproduzione e il miglioramento della comunità
5. Fondamenti Teorici Solidi: Basato su teorie consolidate come il codice proof-carrying

Insufficienze

1. Valutazione Non Sufficientemente Completa: Manca una valutazione sistematica su scenari su larga scala e diversificati
2. Dipendenza dalla Piattaforma: Altamente dipendente dalla piattaforma Bauplan, l'applicabilità generale rimane da verificare
3. Analisi dei Costi Assente: Manca un'analisi dettagliata del rapporto costi-benefici
4. Meccanismi di Gestione degli Errori: La descrizione della gestione di scenari di errore complessi non è sufficientemente dettagliata

Impatto

1. Contributo Accademico: Fornisce una nuova direzione di ricerca per l'applicazione di agenti IA nell'infrastruttura dei dati
2. Valore Industriale: Fornisce una soluzione pratica e fattibile per l'automazione dell'ingegneria dei dati
3. Spinta Tecnologica: Promuove lo sviluppo dell'infrastruttura dei dati programmabile

Scenari Applicabili

1. Team di Dati Aziendali: Adatto per aziende che necessitano di automazione della manutenzione delle pipeline di dati
2. Architetture Cloud-Native: Particolarmente adatto per organizzazioni che hanno già adottato architetture orientate alle API
3. Cultura DevOps: Adatto per team con forte cultura DevOps e flussi di lavoro Git

Bibliografia

L'articolo cita 24 riferimenti correlati, principalmente coprenti:

• Architettura del data lakehouse (Zaharia et al., 2021)
• Utilizzo di strumenti da parte di agenti IA (Shen, 2024)
• Codice proof-carrying (Necula & Lee, 1998)
• Sfide dell'ingegneria dei dati (Data World, 2021)
• Infrastruttura programmabile (Tagliabue et al., 2024)

Valutazione Complessiva: Questo è un articolo sistematico con importante valore pratico che affronta per la prima volta in modo sistematico l'applicazione sicura di agenti IA nell'ambiente del data lakehouse. L'articolo combina innovazione teorica e implementazione pratica, fornendo nuove prospettive e strumenti per l'automazione dell'ingegneria dei dati. Sebbene vi sia spazio per miglioramenti nella completezza della valutazione e nell'applicabilità generale, il suo lavoro pioneristico e i contributi open source gli conferiscono importante valore accademico e industriale.