Il tuo agente AI non è nessuno. E questo è un problema.

Negli ultimi due anni abbiamo reso gli agenti AI davvero capaci. Possono interrogare i tuoi database, riassumere i documenti, instradare i workflow e avviare Transactions per tuo conto. Alcuni sono davvero impressionanti.

La sfida più difficile è quella che la maggior parte delle organizzazioni non ha ancora risolto: garantire che siano chiamabili a rispondere delle loro azioni.

Un agente può agire. Ma la responsabilità è tutt’altra questione. Quando un dipendente umano compie un’azione, esiste una catena di identità associata. Quando lo fa un agente, spesso no. Quando gli agenti AI passano dalle demo alla produzione, quel divario diventa un problema di governance.

Questo è il problema dell’identità dell’agente AI. Un agente AI dovrebbe avere una propria identità verificabile: diritti definiti, ambito definito e una registrazione persistente di ciò che ha fatto. Senza tutto questo, non puoi dire cosa è successo, chi lo ha autorizzato o se è rimasto entro i propri limiti, e questo diventa una responsabilità nel momento in cui qualcosa va storto.  

La maggior parte non ce l’ha. E questo divario sta già rallentando l’adozione in alcuni dei programmi di intelligenza artificiale più sofisticati al mondo.

Le domande a cui ogni team di compliance deve rispondere

Nei settori regolamentati, l’intelligenza artificiale non riduce la complessità degli audit. La amplifica. Se un agente interroga il tuo database, genera una raccomandazione o avvia un’azione e tra sei mesi qualcosa va storto il tuo team dovrà rispondere a queste domande: 

• Chi ha creato l’agente? 

• Quali diritti aveva, e per quanto tempo? 

• A quali dati ha avuto accesso? 

• E se ha prodotto un insight derivato (ad esempio una proiezione, un riepilogo, un output che nessuno ha autorizzato esplicitamente), a chi appartiene?

Immagina un agente AI per la valutazione del merito creditizio. Interroga i dati di credito, segnala il rischio e produce una raccomandazione di approvazione. Un anno dopo, un mutuatario contesta l’esito. Il tuo team di compliance deve ricostruire esattamente a quali dati l’agente ha avuto accesso, sotto quale autorità, e se l’output è rimasto entro l’ambito approvato. Se quella registrazione non esiste, non sei solo esposto. Stai ripartendo da zero.

Sembrano domande ragionevoli. Il problema è che la maggior parte delle infrastrutture di identità non è stata progettata per rispondere.

Perché è più difficile di quanto sembri

I sistemi di identità tradizionali sono stati creati per ruoli stabili e accessi definiti. Gli agenti AI non rientrano in quel modello.

Un agente AI può attivarsi per un singolo task, attingere a quattro fonti dati e sparire entro mezzogiorno. Ogni fonte può avere controlli di accesso adeguati, se considerata isolatamente. Ma l’output combinato (un insight derivato) può sconfinare in aree che nessuno ha autorizzato. L’agente ha fatto esattamente ciò per cui era stato progettato. Il problema è che nessuno aveva definito il confine.

E anche dopo che un agente non esiste più, la registrazione deve continuare a esistere. 

Pensa a un tradizionale processo batch pianificato, uno script per le paghe che gira ogni notte a mezzanotte. Ha un nome, un responsabile, una traccia di audit completa. E un agente AI dinamico che ha operato per tre ore e ha restituito una raccomandazione? Senza un’architettura intenzionale, lascia pochissime tracce di governance.

Risolvere l’identità dell’agente AI parte dall’integrare la governance nell’architettura

La governance non si può aggiungere dopo. Deve essere parte dell’architettura fin dall’inizio.

Ecco come si traduce nella pratica:

• Identità al momento della creazione, non in runtime. Diritti dell’agente, accesso ai dati e ambito operativo devono essere definiti prima che agisca, non dedotti dall’utente che lo ha invocato. Le autorizzazioni esplicite con scadenza includono cosa può accedere, per quanto tempo e per conto di chi. Ad esempio, un agente AI invocato da un VP of Finance ottiene un proprio accesso con ambito definito, non una copia ereditata del suo.
• Governance sugli output, non solo sugli input. I controlli di accesso sui dati di origine non bastano. Quando gli agenti AI combinano dati tra sistemi, l’output combinato può superare limiti che nessuna singola fonte supererebbe. Le policy devono seguire gli insight derivati, non solo i dati che li hanno generati. Un agente AI autorizzato ad accedere separatamente ai dati HR e ai dati finanziari potrebbe non essere autorizzato a combinarli.
• Tracciamento del ciclo di vita che sopravvive all’agente AI. Anche gli agenti AI di breve durata hanno bisogno di una registrazione permanente di chi li ha creati, a cosa hanno avuto accesso, cosa hanno prodotto e chi li ha autorizzati. L’auditability non può dipendere dal fatto che l’agente sia ancora in esecuzione. Un agenteAI clinico eseguito per un’ora che ha restituito una raccomandazione ha comunque bisogno di una registrazione permanente.
• Supervisione umana come canarino, non come stampella. L’obiettivo non è avere una persona che controlla ogni interazione dell’agente AI. Così si perde il senso. Il modello giusto è una revisione periodica e sistematica, e una funzione di audit che intercetta le deviazioni prima che si amplifichino. Pensalo come un audit finanziario: non ogni transazione, ma abbastanza da far emergere schemi.

Ecco perché questi principi sono integrati in Snowflake fin dalla progettazione: guidano lo sviluppo dei nostri agenti AI e quelli che permettiamo ai clienti di sviluppare. 

Quando abbiamo sviluppato il nostro Snowflake Go-To-Market AI Assistant, volevamo mettere i team nelle condizioni di avere a portata di mano tutte le conoscenze di vendita pertinenti, le customer story e gli insight sugli account. Per farlo funzionare, dovevamo fare bene due cose: garantire che le informazioni fornite fossero affidabili e mettere in atto controlli affinché l’agente AI esponesse solo le informazioni giuste alle persone giuste, al momento giusto.

Di conseguenza, siamo partiti da questi vincoli di progettazione, non da feature:

• Accesso ai dati basato sui ruoli
• Query certificate che distinguono le risposte validate da quelle inferite
• Ambito definito al momento della creazione
• Un modello dati logico che applica l’accesso ai dati su più fonti

Il risultato: oggi il nostro agente AI supporta oltre 6.000+ dipendenti e risponde a oltre 35.000 domande a settimana — un agente di cui i nostri team si fidano per operare in autonomia, con auditability completa a posteriori.

Su larga scala, supportiamo i clienti allo stesso modo. Clienti di aziende come TS Imagine, Fanatics e United Rentals stanno tutti sviluppando agenti AI su Snowflake per accelerare il business. 

Tipalti, una piattaforma globale per i pagamenti che elabora oltre 75 miliardi di dollari in transazioni annuali, ad esempio, utilizza l’AI Data Cloud Snowflake per democratizzare l’esplorazione dei dati basata su LLM tra i team. La piattaforma consente alle principali business unit di accelerare gli insight finanziari e agire più rapidamente sulle decisioni critiche, risparmiando tempo e denaro, e dando alle persone più vicine al lavoro le informazioni di cui hanno bisogno per muoversi con sicurezza.

Risolvere l’identità dell’agente AI è la chiave per l’adozione dell’enterprise AI

Risolvere l’identità dell’agente AI non riduce solo il rischio. Elimina l’attrito che sta frenando l’adozione.

Oggi la paura dell’ignoto spinge le aziende ad assegnare una persona a ogni agente, sviluppare app invece di veri agenti, o evitare del tutto questa categoria. È costoso. E fa perdere il senso.

Quell’esitazione scompare quando puoi dire chi è l’agente AI, cosa è autorizzato a fare e cosa ha effettivamente fatto. Gli agenti AI si guadagnano la fiducia nello stesso modo delle persone. Non con le intenzioni. Con le prove.

La capacità non è più il vincolo. Lo è la fiducia.