Governance oltre la sicurezza: conoscenza, contesto e ontologia sul lakehouse

Chiedi alla maggior parte delle organizzazioni cosa significhi la data governance per l'AI e otterrai una risposta incentrata sulla sicurezza: blindare tutto, limitare l'accesso, superare l'audit. Nel settore sanitario, la sicurezza non è negoziabile, ma è incompleta. La sicurezza ti dice chi può toccare i dati. Non dice nulla su cosa i dati significhino, se siano affidabili o se un modello di AI debba mai apprendere da essi.

Il nostro Data Empowerment Program (DEP) parte da una premessa diversa: la governance è conoscenza, contesto e ontologia, non solo controlli. Gli elementi che la maggior parte dei team considera come un sovraccarico di conformità, come i tag di classificazione, le policy di de-identificazione, le model card e i data contract, sono in realtà la materia prima per la semantica dei dati aziendali.

Se vista in questo modo, non ti trovi a scegliere tra governance e AI; al contrario, la governance aiuta a creare l'AI. Nell'era dell'AI è necessario implementare nuovi approcci alla governance. L'unica domanda è se fare questo lavoro in un secondo momento solo per superare l'audit, o adesso, per gettare le fondamenta su cui si basa la tua AI.

Il nostro obiettivo è dimostrare che il lavoro di sicurezza e governance che già svolgi è la base su cui poggia la tua AI. Gestisci i dati in modo adeguato e l'AI potrà basarsi su modelli più economici e con maggiore affidabilità.

La governance deve pensare più in grande attraverso cinque pilastri e un'unica prospettiva

Partiamo dal presupposto che ogni elemento di governance contribuisce alla semantica. Ogni tag di classificazione è un concetto. Ogni model card è contesto. Ogni data contract è una definizione condivisa. Ogni collegamento di lineage è una relazione. In quest'ottica, lo stack di sicurezza che già utilizzi è la prima bozza della tua ontologia, e il catalogo è il luogo in cui risiede.

La governance smette quindi di essere un elemento isolato e diventa cinque sfaccettature di un'unica disciplina: i dati stessi e il modo in cui vengono controllati, l'AI creata su di essi, le persone che devono comprenderli, i prodotti che li introducono nel business e il contesto condiviso che unisce tutti e quattro gli aspetti. È la stessa prospettiva, ma vista da cinque fronti diversi.

Con il DEP, immaginiamo la semantica attraverso cinque pilastri:

• Data Governance — Catalogo, qualità, cura, lineage e con sicurezza e conformità integrate come la classificazione PII, il controllo degli accessi, HIPAA/GDPR e i rischi per la privacy specifici dell'AI.
• Knowledge (AI/ML) Governance — Documentazione dei modelli, governance e standard di AI responsabile come bias e correttezza, spiegabilità, supervisione umana e conformità all'EU AI Act.
• Data Literacy — Formazione, abilitazione self-service, certificazione dei professionisti e KPI come tassi di adozione, metriche di utilizzo e ROI del programma.
• Data Management — Architettura, data engineering e contratti dei data product che dovrebbero includere accordi sugli schemi, SLA e soglie di qualità, nonché obblighi per produttori e consumatori.
• Ontology — Glossario, tassonomia, knowledge graph - culmina in un livello semantico di AI. Include il contesto per LLM, grounding RAG e predisposizione per query via chat.

Rendere operativa la visione attraverso gli agenti

La nostra visione basata su cinque pilastri rimane solo teoria su slide a meno che la piattaforma non riesca a tradurla in qualcosa di operativo. Una volta che gli elementi di governance diventano metadati strutturati e leggibili dalle macchine, smettono di essere una semplice documentazione e iniziano a fungere da set di istruzioni per gli agenti.

Quando parliamo di "agente", lo intendiamo in due modi: "build agent" che assemblano e distribuiscono data product, e "analytic agent" che rispondono a domande di business basandosi su di essi; ciascuno associato a un singolo data product.

Iniziamo con i build agent. I build agent automatizzano il ciclo di vita del rilascio dei data product, dalla mappatura delle sorgenti attraverso ETL, test e de-identificazione, fino al rilascio in produzione. Tutto ciò di cui hanno bisogno risiede in Unity Catalog sotto forma di metadati controllati: mappature da sorgente a destinazione, definizioni di business, livelli di classificazione, policy di de-identificazione, data contract e model card. La piattaforma attinge da tag, commenti, flag di certificazione, lineage e termini collegati al glossario. Il catalogo non è solo il luogo in cui si documenta la governance; è l'ambiente di runtime su cui vengono eseguiti gli agenti.

Ogni agente lavora in un ciclo continuo. Legge le istruzioni dal catalogo, esegue un compito concreto (come generare codice di pipeline, eseguire una suite di test, produrre dati de-identificati o distribuire un dataset certificato) e quindi registra i risultati come esiti dei test, punteggi di qualità, lineage o dati di change capture. Questo processo si ripete.

In pratica, mettiamo in sequenza per primi gli agenti di De-ID e di Testing. Eliminano fin da subito i rischi più elevati e il lavoro manuale più pesante. Iniziare dove il ritorno sull'investimento è più rapido aiuta a creare slancio fin da subito. Mentre proseguiamo nel ciclo, nessun agente agisce su dati che non siano descritti nel catalogo.

I cataloghi moderni rendono questo approccio scalabile perché possono generare automaticamente le descrizioni di colonne e tabelle che uno steward deve approvare, classificare automaticamente i campi sensibili e acquisire il lineage a livello di colonna senza che nessuno debba gestirlo manualmente. Il ruolo delle persone passa dalla creazione dei metadati alla loro approvazione, che è esattamente il tipo di attività decisionale che gli esseri umani dovrebbero svolgere.

Il ciclo di vita di creazione di dati e AI: prove e contesto continuo

I build agent operano all'interno di un ciclo di vita end-to-end progettato per rilasciare contemporaneamente due risorse: il data product controllato (mappatura, cura, pipeline) e l'analytic agente eseguito su di esso (livello semantico, configurazioni dei prompt, suite di valutazione).

Questo approccio segna un passaggio fondamentale dall'ingegneria incentrata sulle pipeline (spostamento dei dati da un punto A a un punto B) all'ingegneria incentrata sul contesto (rendere i dati comprensibili e utilizzabili per i LLM). Invece di certificare solo la qualità del codice, i passaggi di controllo in questo ciclo di vita convalidano la semantica, il contesto e la proprietà.

Due proprietà fondamentali distinguono questo framework da un SDLC tradizionale:

• È auto-dimostrante: la prova di affidabilità è un sottoprodotto naturale del rilascio, piuttosto che una procedura d'emergenza per l'audit preparata a posteriori.
• Migliora continuamente il contesto: il comportamento in produzione alimenta un ciclo di AgentOps, trasformando query non riuscite, cluster di allucinazioni e voti negativi degli utenti nel backlog semantico dello sprint successivo.

Gli steward umani fungono da livello di responsabilità per entrambe le proprietà: gli agenti propongono, le persone approvano. Anche se la gestione di cinque passaggi di controllo su due percorsi diversi potrebbe sembrare la causa di lunghi colli di bottiglia, la maggior parte di essi può essere superata in poche ore. Le approvazioni avvengono direttamente all'interno degli strumenti standard degli sviluppatori. Le suite di test automatizzate allegano i risultati sulla qualità dei dati, i punteggi di valutazione e il lineage prima dell'apertura di un ticket. Una riunione formale di approvazione è un'eccezione da esaminare, non la procedura operativa standard.

La certificazione AI è il motore alla base dei passaggi di controllo

Il meccanismo che rende questi passaggi di controllo oggettivi anziché arbitrari è la certificazione AI. Registrata direttamente in Unity Catalog, questa certificazione funge da scorecard automatizzata e interrogabile, anziché da attestazione legale manuale. Regola l'idoneità al rilascio attraverso quattro dimensioni fondamentali:

• Punteggio automatizzato vs. umano: i punteggi di governance, qualità e semantica vengono calcolati automaticamente a partire da tabelle di sistema interrogabili, risultati delle pipeline ed esecuzioni di valutazione. Il punteggio di proprietà e il timbro di distribuzione finale richiedono la firma esplicita di uno steward.
• Scadenza continua: la certificazione è dinamica. Una modifica dello schema, un aggiornamento del contratto o una suite di valutazione non riuscita revocano istantaneamente la certificazione fino a quando i controlli non vengono eseguiti nuovamente con successo.
• Applicazione a livello di dati: i controlli di accesso operano tramite Attribute-Based Access Control (ABAC) a livello di dati, non a livello di applicazione. Se un utente non può interrogare una riga in SQL, nessun agente può recuperarla tramite ricerca vettoriale o embedding.
• Isolamento rigoroso dei confini: gli ambienti non di produzione (SIT, regressione, test dei modelli) utilizzano esclusivamente dati sintetici o de-identificati. Ciò garantisce che i PHI di produzione non lascino mai il confine controllato.

Quando l'agente sbaglia, chi rimedia?

La certificazione e i gate dimostrano che un agente era affidabile al momento del rilascio. Ma la domanda che si pongono i responsabili della governance non è "come funziona?", bensì "chi è responsabile quando fornisce la risposta sbagliata?" La risposta deve essere un nome specifico, non un comitato direttivo.

Per risolvere questo problema, ogni agente analitico (ad esempio, un Databricks Genie Agent) è associato a un singolo data product governato con un unico proprietario designato. Quando un agente restituisce un risultato errato a causa di una metrica sottostante definita in modo errato, il problema non riguarda il team di ingegneria dell'AI. Invece, va direttamente al Data Product Owner, che corregge la definizione nel catalogo. Associare un agente a un data product certificato e limitato al dominio è anche la più grande leva di accuratezza disponibile: un agente focalizzato che interroga metadati certificati supera costantemente un modello globale che tira a indovinare sull'intero patrimonio aziendale.

In particolare, questa definizione condivisa delle metriche viene applicata anziché essere semplicemente documentata. Una volta definita una metrica certificata nel catalogo, l'agente di risposta è tenuto a calcolare direttamente a partire da essa. Questo trasforma la documentazione statica in logica di runtime attiva.

La responsabilità viene mantenuta grazie a un limite rigoroso su ciò che l'AI può fare senza supervisione: nessun agente promuove codice in produzione, modifica le policy o opera su dati non classificati senza l'intervento umano. Mentre i punteggi di certificazione vengono calcolati automaticamente, il gate di rilascio finale richiede sempre una firma umana. Se il catalogo non descrive esplicitamente un asset di dati, il sistema opta per la soppressione predefinita anziché tirare a indovinare. Al runtime, questa policy fail-closed impone limiti chiari:

• Per gli agenti analitici: invece di speculare o dedurre il contesto da dati grezzi, l'agente rifiuta esplicitamente di rispondere, restituendo un messaggio trasparente (ad es., "Questo dataset è privo della certificazione attiva o della mappatura semantica necessarie per elaborare la richiesta.")
• Per gli agenti di build: se viene rilevato uno schema non classificato o un contratto mancante durante l'assemblaggio della pipeline, l'esecuzione si interrompe automaticamente prima di raggiungere gli ambienti di staging, registrando un flag di asset non mappato per la revisione dello steward.

Definire questi guardrail sulla carta è facile, ma farli funzionare nella pratica richiede di sostituire i vaghi comitati di governance con quattro ruoli distinti e responsabili:

• Data Product Owner: responsabile delle definizioni e della qualità di un prodotto governato. È l'unico punto di contatto quando una risposta è errata.
• Data & AI Governance Engineer: traduce le policy in metadati di catalogo eseguibili (classificazioni, contratti, lineage) in modo che le regole vengano eseguite a runtime anziché rimanere in un PDF.
• Steward: esamina i risultati automatizzati e approva i gate di rilascio. L'automazione propone, lo steward decide.
• Security / IAM: gestisce i livelli di classificazione e gli attributi di accesso che guidano automaticamente la de-identificazione e le autorizzazioni a livello di riga.

Eseguire test rigorosi senza compromettere la sicurezza

Il ciclo di vita che abbiamo descritto nasconde un prerequisito fondamentale: ciascuna di queste fasi di test e valutazione richiede dati realistici su cui essere eseguita e, nel settore sanitario, non è possibile testare PHI reali. Quindi, la sfida diventa la necessità di disporre ovunque di dati di test realistici senza compromettere la sicurezza.

La de-identificazione è il modo in cui manteniamo i dati sicuri e utili per l'analisi. Da dove ottiene le sue informazioni l'agente di de-identificazione? Non da un foglio di calcolo gestito manualmente. Funziona in base alle policy di sicurezza già prodotte dagli strumenti aziendali. Il flusso si articola in tre passaggi:

• Discover - Gli scanner di rilevamento automatico e i motori di policy InfoSec classificano colonne e file sensibili.
• Curate - Le classificazioni vengono inserite nel catalogo come metadati di policy curati; l'agente legge tale cura dei dati ed esegue.
• Execute - Inserisce i metadati e produce dati sintetici o file sorgente de-identificati. Conforme a HIPAA Safe Harbor, con integrità referenziale preservata e idoneo all'analisi.

Per il team di security e IAM, si tratta di una strada a doppio senso. Le policy InfoSec smettono di essere PDF e diventano eseguibili: i livelli di classificazione e le regole di conservazione guidano automaticamente la de-identificazione. In cambio, la sicurezza ottiene una vista costantemente aggiornata dei dati sensibili, una protezione fail-closed per qualsiasi elemento appena rilevato e scansioni residue che generano prove di audit a ogni esecuzione. Il modello di accesso rimane lo stesso dall'inizio alla fine. Poiché qualsiasi recupero di dati da parte dell'agente eredita le autorizzazioni di catalogo dell'utente che effettua la query, gli approcci RAG non possono mostrare l'embedding di una riga che l'utente non è autorizzato a visualizzare. Le stesse regole ABAC si applicano sia a SQL che alla ricerca vettoriale, e gli agenti agiscono con le autorizzazioni dell'utente che effettua la query, non con un account di servizio privilegiato. Ogni prompt dell'agente viene registrato con la lineage utilizzata per rispondere, sotto la stessa governance dei dati stessi.

Questa è la vera svolta: un unico modello di autorizzazione per dati, modelli, embedding e audit trail, anziché un catalogo dati collegato a un registro dei modelli separato, a sua volta collegato a un vector store separato. Il lavoro di governance diventa la base dell'AI anziché un progetto parallelo.

Acquisire metriche, dimostrare i risultati, conquistare la fiducia

Notate cosa ha fatto il ciclo di vita per tutto questo tempo: ogni fase, ogni gate, ogni certificazione ha prodotto metriche. Riunite le quattro dimensioni di certificazione in un unico punteggio di idoneità all'AI (AI-readiness) per dataset e rendetelo operativo, non teorico. La semantica raggiunge il 100% solo quando ogni colonna ha una definizione collegata al glossario e la tabella ha un contratto dati firmato; l'ownership raggiunge il 100% solo quando un proprietario designato risponde ai problemi.

Il risultato che segue il punteggio è il business case per l'intero programma DEP: le metriche dimostrano i risultati dell'AI, la dimostrazione conquista la fiducia e la fiducia è ciò che trasforma un progetto pilota in un utilizzo quotidiano. Nessun utente aziendale adotta un agente perché il diagramma dell'architettura è elegante. Lo adottano perché i numeri erano corretti la scorsa settimana e qualcuno responsabile li ha corretti quando non lo erano. Il punteggio spiega innanzitutto perché i numeri sono corretti: più alto è il punteggio, meno il modello deve tirare a indovinare. Non deve dedurre il significato di una colonna, compensare i duplicati o allucinare join, perché il catalogo glielo ha già comunicato.

Non inseguite i titoli sensazionali sui modelli. Inseguite l'economia dei modelli.

Ogni settimana porta un modello più grande e costoso. Ecco cosa sfugge al ciclo dell'hype: quando il catalogo fornisce già il significato, la qualità e il contesto, il modello non deve farlo. I modelli più piccoli o open-weights soddisfano la maggior parte delle esigenze di reporting e analisi sui dati governati.

I modelli di frontiera vengono spesso utilizzati per mascherare le lacune dei metadati sottostanti. Quando gli schemi e le regole aziendali sono esplicitamente catalogati, modelli più piccoli e specifici per il dominio offrono un'accuratezza identica a una frazione del costo dei token.

Si tratta di una scelta di rapporto costo-qualità, non di un limite massimo di qualità. Dimensionate correttamente il lavoro quotidiano e riservate la spesa per i modelli di frontiera ai problemi che ne hanno davvero bisogno, e il costo non costringerà mai l'AI a fermarsi. Sistemate i dati. Dimensionate correttamente il modello. Mantenete l'accuratezza. Questo è ciò che le radici della governance offrono a una strategia di AI: non un'AI più economica, ma un'AI inarrestabile.

Agite: iniziate con un solo data product

Non tentate una ristrutturazione a livello aziendale tutta in una volta. Dimostrate l'efficacia del modello guidando un singolo data product attraverso l'intero ciclo di vita:

1. Scan: abilitate la scansione di rilevamento automatico su un singolo schema di destinazione.
2. Define: impostate soglie di certificazione esplicite in Unity Catalog per completezza, semantica e qualità.
3. Bind: collegate un agente analitico al dataset insieme a una suite di valutazione dedicata e a un percorso di test de-identificato.
4. Assign: nominate un singolo Data Product Owner designato responsabile delle definizioni e della risoluzione dei problemi.

Una volta avviato il loop, ripeti il processo un prodotto dati certificato alla volta. La sicurezza ti dice chi può accedere ai tuoi dati, ma la governance ti dice cosa significano e se un'AI può fidarsi.

La governance non è il cancello davanti a un'organizzazione data-driven. Se fatta bene, è il terreno su cui poggia.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale