Note operative AI operativa

Agenti AI in azienda: cosa possono toccare davvero?

3 min di lettura

Bracci robotici in un reparto di produzione
Quando il software agisce sul mondo, i permessi diventano progetto.

Il 2025 è stato l’anno in cui l’AI ha smesso di limitarsi a scrivere e ha cominciato a fare: prenotare, ordinare, aggiornare sistemi, orchestrare flussi. Standard come il Model Context Protocol — nato in casa Anthropic e adottato nel giro di un anno da tutto il settore — hanno reso tecnicamente banale collegare un modello ai sistemi aziendali. Ed è esattamente questo il punto: collegare è diventato facile, governare no. Quando un agente può toccare il gestionale, la domanda “quanto è intelligente?” passa in secondo piano rispetto a “cosa gli è permesso fare, e chi risponde di quello che fa?”.

Il salto di categoria che molti non registrano

Un chatbot che sbaglia produce una risposta sbagliata: il danno passa da un umano che la legge. Un agente che sbaglia produce un’azione: un ordine modificato, una mail partita, un prezzo aggiornato. Il danno è immediato, e su sistemi connessi si propaga. Trattare gli agenti con le stesse cautele dei chatbot è l’errore architetturale più diffuso del momento — anche perché le demo dei fornitori mostrano sempre l’agente che funziona, mai il perimetro che lo contiene.

I quattro guardrail, in ordine di importanza

  1. Privilegio minimo, come per le persone. Un agente è un utente: ha credenziali, ruoli, permessi. Deve poter toccare solo i sistemi e le operazioni del suo compito — l’agente che ripianifica le consegne non ha bisogno di leggere le buste paga. Sembra ovvio; nella pratica, per fare presto, gli agenti girano con permessi amministrativi. È la prima cosa da verificare in qualunque installazione.
  2. Azioni tipizzate, non comandi liberi. L’agente non deve poter eseguire operazioni arbitrarie: deve scegliere da un catalogo di azioni definite — “sposta lo slot di consegna”, “apri un ticket”, “isola il lotto” — ciascuna con parametri validati su oggetti che esistono davvero. È la differenza tra un operatore con una tastiera e un operatore con una pulsantiera progettata: il secondo non può premere un tasto che non esiste. Nel nostro impianto questo catalogo vive nell’ontologia: l’agente agisce sul modello dell’azienda, mai direttamente sui sistemi.
  3. Approvazione umana sulle azioni critiche. Non su tutte — o l’automazione non serve a nulla — ma su quelle irreversibili, costose o verso l’esterno: la soglia si definisce per tipo di azione, importo, contesto. E la meccanica va progettata: chi approva, con quale informazione davanti, cosa succede se non risponde entro il tempo utile. È il modo in cui lavorano i nostri agenti, senza eccezioni.
  4. Registro completo, pensato per il “dopo”. Ogni azione: chi (quale agente), cosa, quando, su mandato di chi, con quale esito. Non è burocrazia: quando qualcosa va storto — e prima o poi va storto — la differenza tra un incidente gestito e una crisi è poter ricostruire la catena in dieci minuti. Lo stesso registro è ciò che l’AI Act si aspetta di trovare, e ciò che il vostro assicuratore comincerà a chiedere.

E la responsabilità?

La risposta breve, che vale come bussola: dell’azione dell’agente risponde chi lo esercisce, come per qualunque strumento aziendale. La giurisprudenza sulle allucinazioni lo ha già mostrato (il caso del chatbot di Air Canada insegna): “l’ha fatto il sistema” non è una difesa. Ed è proprio per questo che i quattro guardrail non sono prudenza da ingegneri: sono ciò che vi permette di firmare, con cognizione, la frase “questo agente opera per conto nostro”.

State collegando (o qualcuno vi propone di collegare) un agente ai vostri sistemi? Mezz’ora sul perimetro giusto prima di dargli le chiavi.

Fonti