Collegare un LLM a un data catalog e chiedergli di “documentare tutto” è una demo da dieci minuti. Quando un operatore internazionale delle energie rinnovabili ci ha chiesto di rendere i propri dati documentati e interrogabili, abbiamo scoperto che la parte difficile non è far scrivere l’AI, ma stabilire quando può farlo e con quali garanzie.
La Sfida: far scrivere un agente nel catalogo senza perdere il controllo
I dati del cliente vivono in un lakehouse Microsoft Fabric organizzato nei livelli Bronze, Silver e Gold, a cui si aggiungerà il database NetSuite. I soli Bronze e Silver contano 83 tabelle e quasi 4.400 colonne, con poca documentazione condivisa. Come piattaforma di governance abbiamo scelto OpenMetadata 2.0. Gli ostacoli erano tre:
- Comprensibilità: senza descrizioni, né un analista né un agente AI capiscono che cosa contiene una colonna.
- Fiducia: chi risponde dei dati non può accettare un agente che modifica i metadati senza controllo.
- Sicurezza e qualità: i dati sensibili e i criteri di qualità richiedono regole esplicite.
L’Approccio Tecnico
1. L’agente dentro OpenMetadata, senza modificarlo. Un reverse proxy nginx inietta un widget di chat in ogni pagina, lasciando intatta l’immagine ufficiale. Il backend (Python, FastAPI) interroga Claude e opera sul catalogo tramite il server MCP (Model Context Protocol) nativo di OpenMetadata. Il widget ricava dall’URL la tabella aperta, così l’agente sa sempre di cosa si parla.
2. Un agente governato. Le garanzie stanno nel codice: un’istruzione nel prompt si può aggirare, un permesso no.
- Permessi per utente. In modalità Safe, aperta a tutti, l’agente usa un’identità senza diritti di modifica e può solo aprire task di approvazione. La modalità Advanced è riservata ai ruoli abilitati: l’agente scrive con un’identità dedicata, ma ogni modifica nasce come proposta in anteprima e parte solo dopo la conferma dell’utente. Il token cambia con il pulsante dell’interfaccia, mai con il testo della richiesta, e i tool esposti al modello dipendono dalla modalità.
- Audit. Ogni scrittura dell’agente compare nella Version History con la sua firma ed è registrata nel log del backend.
- Rollback. Un pulsante Revert riporta una tabella a qualsiasi versione precedente. Agisce con le credenziali dell’utente: l’agente non può usarlo.
3. Un catalogo governato. Ogni metadato ha due lettori: le persone e l’agente.
- Descrizioni di tabelle e colonne: dicono a chi legge che cosa contiene un dato e danno all’agente il contesto per rispondere (context engineering).
- Lineage colonna per colonna: si vede da dove nasce ogni dato e l’agente lo legge per spiegarlo.
- Glossario: un nome univoco per colonne che esprimono lo stesso concetto, per esempio tutte quelle che rappresentano i valori di una grandezza misurata in megawatt. L’agente propone i termini, che nascono in revisione e diventano ufficiali solo dopo l’approvazione.
- Tag sulle colonne con dati sensibili, richiamabili dalle policy di accesso. Prima di proporne uno, il backend verifica che il tag esista.
- Test di data quality, scritti a mano o proposti dall’agente sulla base di descrizioni, lineage e glossario. Quando i dati violano un criterio, un alert avvisa i responsabili.
Il Risultato
Gli analisti interrogano il catalogo in linguaggio naturale e il data owner lavora per correzioni invece di scrivere da zero. Ogni intervento dell’agente è autorizzato, firmato e reversibile. Una guida d’uso, ancora in lavorazione, insegna al cliente a gestire il catalogo in autonomia.
Le due governance si sostengono a vicenda: un catalogo descritto dà all’agente un contesto affidabile, e un agente con permessi, audit e rollback permette di arricchire il catalogo senza perderne il controllo.