Governare gli agenti AI su larga scala con Unity Catalog

Un anno fa, la vostra organizzazione aveva una dozzina di agenti AI. Oggi ce ne sono migliaia.

Ogni sviluppatore ha un agente di codifica che scrive, revisiona e distribuisce codice insieme a loro. Il vostro team di analisi ha creato agenti di previsione. Le operazioni di vendita hanno implementato il lead scoring. L'organizzazione di supporto ha automatizzato l'instradamento dei ticket. Il marketing ha lanciato la personalizzazione. La finanza ha creato flussi di lavoro di riconciliazione. Ogni team ha colto un'opportunità e si è mosso rapidamente.

Ora qualcuno chiede: "Quali agenti stanno accedendo ai PII dei clienti?"

La risposta richiede di estrarre i log da decine di sistemi, correlarli manualmente e sperare che nulla sia stato tralasciato. Ogni agente registra, autentica e accede ai dati in modo diverso. Non c'è un unico posto dove cercare.

O forse avete preso la strada opposta. Avete bloccato tutto. Nessun agente è stato distribuito senza un'ampia revisione. La sicurezza è rimasta rigorosa. Ma ora siete sei mesi indietro rispetto ai concorrenti che si sono mossi più velocemente. Sviluppatori e utenti sono frustrati. Alcuni sono passati a società dove possono effettivamente utilizzare gli strumenti AI.

Nessuno dei due estremi funziona. Gli agenti non governati creano rischi che non potete misurare. Gli ambienti bloccati creano un diverso tipo di rischio: rimanere indietro mentre i talenti se ne vanno.

La governance tradizionale presupponeva che gli esseri umani prendessero decisioni e che le applicazioni le eseguissero in modo prevedibile. Gli agenti non funzionano così. Sono autonomi, prendono decisioni diverse ogni volta e concatenano gli strumenti in modi che non potete prevedere leggendo il codice. Non potete governare un agente revisionando ciò che potrebbe fare. Lo governate controllando ciò che può accedere e monitorando ciò che fa effettivamente.

Quattro pilastri della governance degli agenti

Unity Catalog ha governato i dati aziendali dal 2021 attraverso un unico modello di permessi, una lineage unificata e una traccia di audit coerente su ogni asset. Stiamo ora estendendo la stessa infrastruttura di governance per coprire ogni asset toccato da un sistema AI: LLM, server MCP, skill e agenti. Il catalogo che già sa chi può accedere ai vostri dati cliente ora governa anche quali agenti possono chiamare quali strumenti e a quali condizioni.

Unity AI Gateway è il tessuto di applicazione per il mondo agentico. Ogni chiamata di modello, ogni invocazione di strumento, ogni interazione di agente fluisce attraverso il gateway. Ognuna viene valutata rispetto alle policy definite in Unity Catalog prima dell'esecuzione e registrata successivamente. Gli strumenti di governance tradizionali sono stati costruiti per applicazioni statiche. Non hanno visibilità su nulla di tutto questo. Unity AI Gateway sì.

Pilastro 1: Accesso delegato

Gli agenti devono operare entro confini di permesso chiaramente definiti, sia in termini di chi possono rappresentare sia di cosa possono accedere. La maggior parte delle piattaforme gestisce questo come gestisce i permessi delle applicazioni: account di servizio con credenziali statiche e accesso ampio. Si perde la responsabilità e non si può contenere il raggio d'azione.

Databricks adotta un approccio diverso: l'identità fluisce end-to-end, dall'utente che pone la domanda alla specifica riga della tabella che l'agente recupera. Gli agenti ereditano i permessi sui dati dell'utente che li invoca in tempo reale tramite il passaggio di token "on-behalf-of", non un account di servizio condiviso. Se non potete accedere a una tabella in Unity Catalog, nemmeno l'agente che agisce per vostro conto può farlo. Ogni azione viene registrata rispetto a entrambe le identità: l'utente reale che ha attivato la richiesta e l'agente che ha agito per suo conto, catturando quali tabelle sono state accedute, quali operazioni sono state eseguite e quando. Quando qualcosa va storto, sapete esattamente da dove proviene l'azione e chi l'ha autorizzata.

Estendiamo questo modello ai server MCP. I team registrano i server MCP esterni (GitHub, Jira, Slack, ecc.) in Unity Catalog e li governano come qualsiasi altro elemento securabile: permessi, gestione delle credenziali e logging di audit completo in un unico posto.

Abbiamo riconosciuto che lo stesso principio si applica in fase di runtime, non solo in fase di accesso. Sapere che un agente è autorizzato a chiamare GitHub non vi dice se dovrebbe eliminare un file o unire una pull request. Così abbiamo creato le Service Policies, che sono funzioni UC, gestite in UC e collegate a MCP registrati in Unity Catalog che controllano quali chiamate di strumenti hanno successo. Ogni chiamata di strumento viene valutata prima dell'esecuzione: in base al nome dello strumento, ai suoi argomenti o all'identità del chiamante, la policy restituisce "allow", "deny" o chiede il consenso dell'utente. Se la valutazione della policy risulta in un "Deny", la chiamata viene bloccata.

Al livello del modello, i guardrail ispezionano ciò che fluisce attraverso l'inferenza in tempo reale, scansionando gli input per PII e tentativi di jailbreak, controllando gli output per allucinazioni e contenuti sensibili prima che raggiungano l'utente. Vengono eseguiti in linea su ogni richiesta e falliscono in modo sicuro.

In pratica, questi tre livelli lavorano insieme: i permessi controllano chi può chiamare cosa. Le Service Policies controllano se una specifica chiamata di strumento debba procedere nel contesto di una data richiesta. I guardrail controllano quali contenuti fluiscono in entrata e in uscita.

Pilastro 2: Governance AI data-centrica

Ecco il principio che la maggior parte degli strumenti di governance AI non coglie: il comportamento di un agente è quasi interamente determinato dai dati a cui ha accesso. Cosa può leggere, quanto sono aggiornati quei dati, se i campi sensibili sono mascherati, queste non sono domande di governance AI. Sono domande di governance dei dati. Trattatele separatamente e vi ritroverete con due sistemi incompleti. Trattatele insieme e la governance diventa auto-rinforzante.

Innanzitutto, avete bisogno di una traccia di audit completa, e la regolamentazione la sta rendendo non negoziabile. Le normative emergenti sull'AI richiedono alle organizzazioni di dimostrare cosa hanno fatto i loro sistemi AI, cosa è stato loro fornito e cosa hanno prodotto. AI Gateway scrive il payload completo di ogni chiamata di modello su tabelle di inferenza: il prompt esatto inviato, la risposta esatta restituita, i conteggi dei token e la latenza. Unity Catalog cattura ogni operazione di accesso nei log di audit, inclusi quale principale ha chiamato cosa, da quale agente e a che ora. Entrambi finiscono nel vostro lakehouse come tabelle, conservabili alle vostre condizioni. La maggior parte delle architetture di logging impone un compromesso tra completezza e costo, richiedendovi di campionare, filtrare e impostare brevi finestre di conservazione. Poiché Unity AI Gateway cattura i dati di osservabilità nel vostro lakehouse, non dovete farlo.

In secondo luogo, quei dati di audit sono utili solo quanto la vostra capacità di analizzarli. L'analisi richiede una piattaforma dati, non uno strumento di logging. Le tracce degli agenti sono tabelle in Unity Catalog, interrogabili con lo stesso SQL che usate per tutto il resto. Nessun nuovo linguaggio di query, nessun tool separato. Quando un agente fa qualcosa di inaspettato, i dati da investigare sono già lì: quali agenti hanno acceduto a un servizio specifico la scorsa settimana, quanto sta spendendo ogni team per l'inferenza e se qualche agente ha toccato credenziali o PII. Poiché i dati di audit vivono accanto ai vostri dati aziendali, potete andare oltre, unendo il comportamento degli agenti ai risultati aziendali per capire non solo cosa hanno fatto gli agenti, ma se ha funzionato. Lakewatch, il SIEM agentico di Databricks costruito sul security lakehouse, porta questo concetto ancora oltre, trasformando la stessa traccia di audit in intelligenza di sicurezza attiva: rilevamento e risposta alle minacce basati sull'AI, costruiti sul lakehouse. Gli attaccanti usano gli agenti. Anche i difensori dovrebbero farlo.

Terzo, è necessario sapere che i dati su cui si basavano i vostri agenti erano affidabili fin dall'inizio. Un audit trail completo vi dice a cosa ha avuto accesso un agente. Non vi dice se quei dati erano validi. Il monitoraggio della qualità dei dati traccia continuamente la freschezza e la completezza attraverso il vostro catalogo. Unitelo alle tracce degli agenti e passerete da "l'agente ha dato una risposta sbagliata" a "l'agente ha interrogato una tabella che era stata contrassegnata come obsoleta", collegando il comportamento dell'agente alla qualità dei dati sottostanti. La classificazione dei dati aggiunge un ulteriore livello: un sistema AI agentico scansiona e tagga continuamente le colonne sensibili, come i dati PII, HIPAA e regolamentati dal GDPR, e questi tag alimentano direttamente il controllo degli accessi. Le colonne mascherate rimangono mascherate indipendentemente dall'agente o dal framework che le richiede. La governance dei dati che già possedete diventa automaticamente la vostra governance AI.

Pilastro 3: Intelligenza dei costi

Ogni chiamata di modello ha un costo. La maggior parte delle aziende non ha idea di chi le stia eseguendo, a quale scopo, o se stiano funzionando, finché non arriva la fattura e il reparto finanziario si trova a dover spiegare un numero che nessuno si aspettava.

La causa principale non è un processo interrotto. È l'infrastruttura mancante: nessun livello di misurazione che veda tutto il traffico AI in un unico posto, nessun sistema di tagging che lo attribuisca a team o casi d'uso, nessun controllo della spesa che si affianchi ai controlli di accesso che governano le stesse risorse.

Abbiamo integrato questo in Unity Catalog e Unity AI Gateway. Il tracciamento dell'utilizzo (Usage-tracking) registra ogni richiesta in tabelle di utilizzo, inclusi i conteggi dei token, la latenza, l'identità del richiedente e la destinazione del modello attraverso provider Databricks-hosted ed esterni in un'unica tabella. Permette di taggare le richieste per team, progetto o centro di costo. Poiché si presenta come una tabella accanto alle tracce degli agenti e ai dati aziendali, è possibile collegare il costo ai risultati. Un agente che costa $200 e genera $50K in pipeline qualificata è un affare. Un agente che costa $200 interrogando dati obsoleti in un ciclo è uno spreco. Senza collegare il costo al risultato, non è possibile distinguere la differenza.

I budget in Unity AI Gateway aggiungono il livello di policy. Gli amministratori impostano soglie di spesa mensili per utente o gruppo e ricevono avvisi quando il consumo si avvicina o le supera — il segnale di cui si ha bisogno prima che la spesa diventi un problema, non dopo. L'applicazione rigorosa è il prossimo passo naturale, e avremo presto maggiori informazioni da condividere su questo.

Pilastro 4: Aperto e interoperabile

Ogni strategia di governance AI aziendale affronta alla fine la stessa funzione di forzatura: un nuovo team sceglie un framework diverso, un nuovo provider rilascia un modello migliore. Se la vostra governance è integrata nelle scelte di strumenti attuali, siete su un tapis roulant: ogni nuovo framework è una nuova integrazione, ogni nuovo modello è una nuova policy.

Abbiamo riconosciuto questo, ed è per questo che abbiamo adottato un approccio diverso dalla maggior parte degli strumenti di governance. La governance non può risiedere solo nel livello dell'agente. Deve anche risiedere nei dati e nei servizi a cui gli agenti accedono, indipendentemente dal fatto che tali servizi siano gestiti da Databricks o meno. Un agente costruito su LangGraph e uno costruito su CrewAI interrogano entrambi lo stesso Unity Catalog, invocano gli stessi server MCP governati e fluiscono attraverso lo stesso AI Gateway. Il framework è irrilevante. La governance viaggia con le risorse, non con il codice che le chiama.

Gli standard aperti rendono questo concreto. Gli MCPs offrono agli agenti un protocollo universale di connettività degli strumenti: registrare una volta in Unity Catalog, invocare da qualsiasi framework con le stesse autorizzazioni e audit trail. Unity AI Gateway fornisce un unico endpoint governato per i modelli ospitati su Databricks, Azure OpenAI, AWS Bedrock e Anthropic, con un'unica policy, un unico audit trail e un unico livello di attribuzione dei costi tra i provider. Il tracing di MLflow auto-strumenta LangChain, LlamaIndex, AutoGen, l'SDK OpenAI, l'SDK Anthropic e altro ancora, con tracce che vengono memorizzate in Unity Catalog come tabelle senza strumentazione personalizzata per framework.

Il risultato finale è che la governance diventa una proprietà della vostra piattaforma piuttosto che qualcosa che ricostruite per ogni nuovo framework o modello. Ogni agente che implementate, indipendentemente da come è stato costruito o da quale modello lo alimenta, accede agli stessi dati governati, alla stessa logica di business e alle stesse autorizzazioni. Definite le regole una volta, e ogni agente successivo le acquisirà automaticamente.

Per saperne di più

Le aziende che implementano correttamente la governance AI non si limiteranno a evitare incidenti. Si muoveranno più velocemente di quelle che non lo fanno perché i loro team si fidano dell'infrastruttura sottostante, e la fiducia elimina l'attrito che rallenta tutti gli altri.

Se state costruendo in questa direzione, iniziate con il nostro corso gratuito sulla governance degli agenti AI, scaricate il Databricks AI Security Framework (DASF), e visitate la nostra pagina web sulla governance AI per risorse aggiuntive.

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