Per anni il software aziendale ha avuto un compito chiaro: registrare quello che succede. Un ordine, una richiesta di rimborso, un livello di scorte, un’interazione con un cliente. Qualcuno leggeva quei dati, li interpretava, e decideva cosa fare.
Quel modello sta cambiando rapidamente, e la maggior parte delle organizzazioni non si è ancora accorta di quanto.
Il salto che sta avvenendo sotto gli occhi di tutti
Negli ultimi dodici mesi i principali vendor enterprise hanno accelerato in modo evidente l’integrazione di agenti AI all’interno delle proprie piattaforme. Con “agente” non intendiamo un semplice assistente che suggerisce un’azione, ma un componente software capace di prendere decisioni operative entro regole definite ed eseguirle automaticamente. Quella che fino a poco tempo fa era una funzionalità sperimentale sta rapidamente diventando una componente standard del software aziendale.
Non è una crescita lineare. È un cambio di categoria.
Nei moderni CRM l’agente non si limita più a suggerire il prezzo migliore per un’offerta: lo propone direttamente al cliente, in autonomia, se l’operatore non interviene entro una finestra di tempo definita. All’interno di un ERP, non basta più un semplice alert quando le scorte scendono sotto soglia: il sistema avvia da solo la richiesta d’ordine al fornitore approvato, con i parametri negoziali già impostati. Un sistema di gestione delle spese non aspetta la firma del responsabile per ogni voce: approva automaticamente le richieste sotto una certa soglia, e instrada le altre con priorità calibrata sull’urgenza.
Il ciclo “registra, segnala, attendi, decidi” (quello su cui erano costruiti i sistemi aziendali da decenni) sta lasciando spazio a un ciclo diverso: valuta, decide quando autorizzato, agisce entro i limiti assegnati, notifica. E in molte organizzazioni questo passaggio è già avvenuto in alcuni processi, senza che nessuno l’abbia formalmente deciso a livello di governance.
Perché questo non è solo un aggiornamento di funzionalità
Quando un sistema smette di limitarsi a mostrare i dati e comincia ad agire su di essi, cambia la natura del rischio che quel sistema comporta.
Un database mal governato espone dati. È un problema serio, ma contenuto: l’informazione è esposta, non necessariamente usata per produrre un effetto. Un agente mal governato è un problema di natura diversa: prende decisioni sbagliate, le esegue, e genera conseguenze reali: un prezzo comunicato al cliente, un ordine inviato a un fornitore, un pagamento approvato, prima che qualcuno abbia la possibilità di accorgersene e intervenire.
Non è più una questione di chi può leggere un dato. È una questione di chi, o cosa, può agire per conto dell’organizzazione, e con quale livello di controllo. Non è un caso che il quadro normativo europeo stia dedicando sempre maggiore attenzione alla governance dei sistemi di AI e delle decisioni automatizzate, affiancando ai tradizionali requisiti di protezione dei dati nuove responsabilità legate all’uso dell’intelligenza artificiale.
Le quattro lacune che quasi nessuno ha ancora chiuso
Le analisi più recenti sulla sicurezza dei sistemi agentici convergono su problemi strutturali, presenti nella maggior parte delle implementazioni attuali.
Mancanza di identità formale. Gli agenti che operano dentro le applicazioni aziendali spesso non sono trattati come entità con permessi espliciti e verificabili. Agiscono con i privilegi del sistema che li ospita, non con un perimetro di autorizzazione proprio e definito.
Assenza di limiti operativi espliciti. Un agente dovrebbe sapere non solo cosa può fare, ma anche cosa non può fare senza un intervento umano. Senza confini chiari su questo punto, la differenza tra automazione utile e azione incontrollata dipende dal caso, non dalla progettazione.
Assenza di log auditabili sulle decisioni. Sapere che un agente ha eseguito un’azione non basta. Serve poter ricostruire perché l’ha fatto, su quali dati si è basato, e quale logica ha seguito e soprattutto quando la decisione coinvolge clienti, fornitori o obblighi contrattuali.
Difficoltà di attribuzione della responsabilità. Quando un agente agisce combinando input provenienti da più sistemi diversi, stabilire dove sia nato l’errore, e chi debba intervenire per correggerlo, diventa complesso in modo proporzionale al numero di sistemi coinvolti.
Nessuna di queste lacune è un problema di ingegneria del singolo agente. Sono problemi di architettura della fiducia: si risolvono prima di mettere un sistema in produzione, non dopo che ha già agito.
Cosa significa progettare per questo cambiamento
Le organizzazioni che stanno gestendo bene questa transizione non sono quelle che hanno aggiunto più agenti ai propri sistemi. Sono quelle che hanno trattato ogni agente come un’entità che richiede gli stessi principi di governance di qualsiasi altro elemento critico dell’architettura: un’identità definita, un perimetro di permessi esplicito, limiti chiari su cosa richiede sempre una conferma umana, una traccia verificabile delle decisioni prese.
Aggiungere capacità decisionale autonoma a un sistema progettato per registrare e basta non è un upgrade. È un cambiamento del contratto di fiducia tra l’organizzazione e il software che usa, e quel contratto va riprogettato esplicitamente, non assunto per default.
Per decenni il software aziendale è stato progettato per conservare informazioni. Oggi va progettato per prendere decisioni. È un problema completamente diverso e la vera innovazione non sta nel costruire agenti capaci di agire, ma nel costruire organizzazioni che possano fidarsi delle decisioni che il proprio software è autorizzato a prendere.