La sfida architettonica necessaria per governare gli agenti AI

L’AI non è più solo un chatbot che genera testi. Negli ambienti aziendali, gli agenti AI stanno assumendo azioni come il recupero di dati sensibili, l’avvio di flussi di lavoro, la chiamata di strumenti e la registrazione di attività in più 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 costruiti per governare il software che può eseguire azioni multi-step 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 progettata: un approccio architettonico in cui i controlli sono incorporati nel piano di controllo e applicati continuamente 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 di dati privati e ambienti edge.

Esistono 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 dell’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% degli intervistati 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.

Questo è esattamente dove 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 barriera 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 enfatizza la gestione del rischio in tutta la vita dell’AI, non solo durante la fase di costruzione. È un promemoria che la conformità e la fiducia sono responsabilità operative, non elenchi di controllo una tantum.

Dalla politica alla piattaforma

La governance progettata significa che la governance viaggia con il carico di lavoro invece di essere reimplementata in ogni silo. Nella pratica, ciò dipende da tre blocchi costitutivi:

• Un piano di controllo unificato

Un luogo in cui definire e applicare l’identità, l’accesso, la politica, i cataloghi e i diritti across cloud e centri di dati.

L’obiettivo è scrivere le politiche una volta e applicarle ovunque i dati e i modelli vengano eseguiti, invece di ricostruire i sistemi di controllo sistema per sistema. Ciò impedisce la deriva del comportamento degli agenti, dove lo stesso agente si comporta in modo sicuro in un ambiente ma pericoloso 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 attraverso 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 sta funzionando 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 “bello da avere”, ma è la base per i controlli in fase di esecuzione e la risposta agli incidenti.

In particolare, c’è bisogno di 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 gli output agli input. Ciò consente ai team di verificare quelle decisioni e risolvere i problemi di guasto, se necessario, dimostrando 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 scompone: proprio come i dipendenti hanno badge di accesso che concedono l’accesso a alcuni edifici e stanze, ma non ad altri, la governance consente agli agenti di avere l’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 limitate per ragionare, ma deve comunque applicare i confini di divulgazione. Ciò non è un problema di “scrittura di prompt” che storicamente abbiamo conosciuto come 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 passaggio costringe le aziende a operare a due velocità. Una è la velocità dell’innovazione, dove i team testano nuovi modelli, strumenti e flussi di lavoro degli agenti per ottenere un vantaggio competitivo. E l’altra è la velocità della sicurezza, dove 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 il contrario si verifica, si ottiene 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.

Un elenco di controllo pratico per la governance degli agenti in fase di esecuzione

• Se si sta costruendo o scalando gli 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?
• Si dispone di telemetria per le azioni degli agenti, comprese le chiamate di strumenti, i controlli di politica e le escalation umane?
• È possibile limitare, interrompere o mettere in quarantena un agente in fase di esecuzione se si comporta in modo inaspettato?
• Si dispone di un piano di monitoraggio post-distribuzione che si allinea con gli obblighi normativi 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 accadere.

La sfida della governance deve essere architettonica, altrimenti non esiste

Gli agenti diventeranno un’aggiunta standard alle 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 critico per la missione, le conseguenze saranno reali. Vedremo quelle ripercussioni nella perdita di dati, nella mancata conformità, negli outage operativi e nella 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 i 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.