La svolta architettonica necessaria per governare gli agenti AI

L’AI non è più solo un chatbot che genera testo. Negli ambienti aziendali, gli agenti AI stanno eseguendo azioni come il recupero di dati sensibili, l’attivazione di flussi di lavoro, la chiamata di strumenti e la registrazione di attività tra sistemi. L’autonomia cambia completamente la discussione sulla governance; i controlli e le procedure inizialmente progettati per gli utenti umani e le applicazioni tradizionali non sono stati progettati per governare il software che può eseguire azioni multistep in fase di esecuzione.

Il rischio non è teorico. Piccole lacune nella visibilità, nel controllo degli accessi e nella tracciabilità possono accumularsi rapidamente, trasformandosi in fallimenti in fase di esecuzione che sono difficili da rilevare e ancora più difficili da invertire.

Per stare al passo con questa nuova era, la governance degli agenti AI non può essere effettuata aggiungendo più documenti di politica. Richiede una governance per progetto: un approccio architettonico in cui i controlli sono incorporati nel piano di controllo e applicati in modo continuo in fase di esecuzione. Se gli agenti devono agire come colleghi digitali, devono ereditare le stesse barriere di sicurezza aziendale degli esseri umani, più una maggiore supervisione in fase di esecuzione.

Perché la governance si rompe nell’era della convergenza

L’architettura aziendale è entrata in un’era di convergenza. I dati e i carichi di lavoro ora si estendono su più cloud, centri dati privati e ambienti edge.

Ci sono organizzazioni che eseguono le loro piattaforme in sistemi paralleli perché hanno più processi da gestire contemporaneamente. Ciò include sistemi di identità separati, pipeline di registrazione, cataloghi e processi approvati. Il risultato è ciò che alcuni chiamano una “piattaforma Frankenstein”, dove l’onere di integrazione aumenta con ogni nuovo strumento o ambiente cloud. In realtà, questa frammentazione si sta verificando nella realtà quotidiana.

Secondo un recente sondaggio, il 47% dei rispondenti cita requisiti di accesso complicati e processi, e il 44% cita una visibilità limitata su dove risiedono i dati come barriere all’uso efficace dei dati.

È proprio qui che gli agenti espongono le cuciture tra i sistemi.

Per rispondere a una domanda aziendale, un agente può dover estrarre dati da un sistema ERP on-premises, un CRM cloud, una telemetria operativa in un altro cloud e documenti in un pacchetto di collaborazione. Se l’organizzazione applica la politica in modo diverso in ogni luogo, l’agente fallirà o, peggio, avrà successo in modi che non si possono spiegare o controllare.

Questo è il momento in cui i leader aziendali devono prestare attenzione. Gli agenti stanno imponendo una barra più alta che richiede coerenza tra ambienti e responsabilità in fase di esecuzione.

La governance, per questo motivo, sta venendo portata alla ribalta da regulatori e agenzie di sicurezza. Un esempio di ciò è il NIST AI Risk Management Framework, che sottolinea la gestione del rischio in tutta la vita dell’AI, non solo al momento della costruzione. È un promemoria che la conformità e la fiducia sono responsabilità operative, non elenchi di controllo una tantum.

Dalla politica alla piattaforma

La governance per progetto significa che la governance viaggia con il carico di lavoro piuttosto che essere riimplementata in ogni silo. Nella pratica, ciò dipende da tre elementi fondamentali:

• Un piano di controllo unificato

Un posto in cui definire e applicare identità, accesso, politica, cataloghi e diritti across cloud e centri dati.

L’obiettivo è scrivere politiche una volta e applicarle ovunque i dati e i modelli vengono eseguiti, piuttosto che ricostruire sistemi di controllo sistema per sistema. Ciò impedisce la deriva del comportamento dell’agente, in cui lo stesso agente si comporta in modo sicuro in un ambiente ma pericolosamente in un altro.

Un test pratico è semplice: se un utente non può accedere a una colonna, verificare che un agente che agisce per suo conto non possa accedere ad essa. Ciò dovrebbe indicare se le politiche scritte vengono applicate across il piano.

• Un tessuto di dati basato su standard aperti

Gli agenti hanno bisogno di contesto per operare. Quando quel contesto è distribuito tra strutture diverse di proprietà di team diversi, un tessuto di dati aiuta a standardizzare la semantica e i modelli di accesso, in modo che gli agenti non debbano imparare un nuovo set di regole per ogni set di dati.

I formati di tabella aperti come Apache Iceberg supportano ciò, consentendo a più motori di condividere gli stessi dati governati senza copiarli in un nuovo silo. Ciò è importante perché la duplicazione dei dati è dove la governance di solito fallisce. Una volta che i team iniziano a copiare “solo ciò di cui l’agente ha bisogno”, si crea un nuovo ambiente meno governato.

Se gli agenti possono operare tra set di dati senza introdurre nuove lacune di autorizzazione, la governance funziona come previsto.

• Osservabilità e discendenza in tempo reale

Gli agenti sono governabili solo se si può vedere cosa stanno facendo in fase di esecuzione.

L’osservabilità qui non è solo un “nice-to-have”, ma è la base per i controlli in fase di esecuzione e la risposta agli incidenti.

In particolare, è necessario avere una prova end-to-end delle azioni degli agenti. Gli agenti dovrebbero essere in grado di provare azioni, come quali dati sono stati accessi e quali strumenti sono stati chiamati, e da lì, la discendenza può collegare i risultati agli input. Ciò consente ai team di verificare quelle decisioni e risolvere i fallimenti, se necessario, provando così la conformità complessiva.

Trattare gli agenti come “colleghi digitali”

Uno dei modelli mentali più utili è trattare gli agenti come colleghi digitali.

Ecco un confronto che lo spezza: proprio come i dipendenti hanno badge di accesso che concedono l’ingresso a alcuni edifici e stanze, ma non ad altri, la governance consente agli agenti di avere accesso con restrizioni. Un’aggiunta chiave è che gli agenti devono essere consapevoli della situazione di ciò che sono autorizzati a rivelare.

Considerare un agente di supporto. Potrebbe aver bisogno di accedere a casi di supporto precedenti per risolvere un problema, ma non può rivelare i dettagli privati di un altro cliente mentre lo fa. In altre parole, l’agente può utilizzare conoscenze restrittive per ragionare, ma deve comunque applicare i confini di divulgazione. Ciò non è un problema di “scrittura di prompt” che abbiamo storicamente saputo navigare; invece, è un problema di identità e applicazione in fase di esecuzione.

Cosa cambia nel 2026: gli agenti si spostano dagli esperimenti alla produzione

Il 2026 è l’anno in cui gli esperimenti finiscono e gli agenti prendono il posto di produzione.

Questo spostamento costringe le aziende a operare a due velocità. Una è la velocità di innovazione, in cui i team testano nuovi modelli, strumenti e flussi di lavoro degli agenti per ottenere un vantaggio competitivo. E l’altra è la velocità di sicurezza, in cui i sistemi devono soddisfare i requisiti di conformità e operativi, che possono includere controlli di accesso rigorosi e punti ciechi.

Senza una governance architettonica, queste due velocità saranno in conflitto.

Se i team distribuiscono questi agenti prima che siano governati, ci sarà un patchwork di controlli one-off e fallimenti operativi. E se si verifica il contrario, si verifica un modo di fallimento in cui la sicurezza blocca tutto e l’innovazione si sposta verso l’IT ombra, minando la governance.

L’obiettivo non è scegliere una velocità. È costruire un’architettura che supporti entrambe.

Una checklist pratica per governare gli agenti in fase di esecuzione

• Se si sta costruendo o scalando agenti, è imperativo chiedersi le seguenti domande per rivelare se la governance è veramente architettonica: È possibile spiegare, end-to-end, quali dati un agente ha accesso per produrre una risposta o eseguire un’azione?
• Le decisioni di accesso sono coerenti tra ambienti ibridi, o differiscono per piattaforma?
• È presente una telemetria per le azioni degli agenti, inclusi gli strumenti chiamati, i controlli di politica e le escalation umane?
• È possibile limitare, pausare o mettere in quarantena un agente in fase di esecuzione se si comporta in modo inaspettato?
• È presente un piano di monitoraggio post-distribuzione che si allinea con gli obblighi regolatori e l’appetito per il rischio?

Se non si possono rispondere a queste domande, trattare la distribuzione dell’agente come un incidente di produzione in attesa di verificarsi.

La svolta della governance deve essere architettonica, altrimenti non esiste

Gli agenti diventeranno una parte standard delle operazioni aziendali. La domanda è se diventeranno una parte affidabile delle operazioni aziendali.

Se gli agenti non sono governati almeno con la stessa fiducia degli esseri umani e del software mission-critical, le conseguenze saranno reali. Vedremo quelle ripercussioni in perdite di dati, fallimenti di conformità, interruzioni operative e perdita di fiducia nei programmi AI.

I leader devono smettere di trattare la governance degli agenti come un esercizio di documentazione. Man mano che le capacità della piattaforma si espandono, la governance degli agenti dovrebbe essere una di quelle che assume la supervisione di altri ruoli. Ciò significa incorporare controlli nel piano di controllo, rendendo le azioni osservabili e le decisioni verificabili. E poi scalare.

È così che si ottengono agenti che si muovono velocemente senza rompere l’azienda.