// TOM'S HARDWARE ITALIA — INTELLIGENZA ARTIFICIALE
Un agente AI va governato prima di accenderlo
La checklist pre-produzione serve a evitare agenti senza proprietario, confini e controllo: l'autonomia diventa un rischio reale se nessuno la misura.
Un agente AI non è un chatbot con più strumenti: è un pezzo di software che prende iniziativa dentro processi reali. Può leggere dati, chiamare API, scrivere nei sistemi, aprire ticket, inviare comunicazioni, proporre decisioni o eseguire attività con gradi diversi di autonomia. Per questo la domanda corretta non è soltanto se funzioni nella demo, ma che cosa succede quando entra in produzione.
Il passaggio cambia il peso della governance. Finché un agente vive in un laboratorio, l'errore resta contenuto. Quando tocca CRM, ERP, sistemi documentali, strumenti di assistenza o flussi interni, ogni permesso diventa superficie di rischio. L'agente deve avere identità, confini e responsabilità prima del rilascio, non dopo il primo incidente.
AI4Business ha impostato il problema come checklist pre-messa in produzione e come disciplina di vita in esercizio. Il punto utile per le imprese è il cambio di mentalità: un agente non si "pubblica", si mette in esercizio. Va scelto, progettato, testato, limitato, osservato, corretto e dismesso quando smette di servire. L'autonomia senza ciclo di vita è solo automazione senza freni.
La prima scelta riguarda quale agente fare per primo. L'errore classico è partire dal caso più vistoso, quello che impressiona in riunione o sembra sostituire un intero reparto. La scelta più solida è diversa: un processo frequente, misurabile, con dati abbastanza puliti, rischi contenibili, benefici chiari e possibilità di ritorno indietro. Il primo agente deve insegnare all'organizzazione a governare, non solo a stupire. Tom's Hardware ha già raccontato il profilo di rischio strutturale degli agenti AI che si comportano come malware: il punto di partenza conta più della velocità di rilascio.
Tom's Hardware ha già raccontato il problema nel pezzo su Forrester: il 75% delle aziende ha provato agenti AI, ma quasi nessuna li sa orchestrare davvero. Il dato da tenere è la distanza tra prova e produzione. Molti progetti restano bloccati perché l'azienda confonde agente, assistente e automazione di processo. La tecnologia arriva prima dell'architettura organizzativa.
Una demo riesce perché l'ambiente è controllato. I dati sono selezionati, i casi limite sono pochi, l'utente sa che cosa chiedere, il team tecnico osserva ogni passaggio. La produzione è un'altra cosa: richieste sporche, utenti frettolosi, permessi ereditati, sistemi lenti, dati contraddittori, eccezioni aziendali e richieste che nessuno aveva previsto. L'agente va valutato quando il mondo smette di essere gentile.
IBM descrive la governance agentica come passaggio da sistemi che informano a sistemi che agiscono. Nel suo playbook, l'azienda sottolinea che gli agenti pianificano, usano strumenti e guidano flussi di lavoro, quindi richiedono responsabilità, controllo e standard nuovi. Tradotto: un agente in produzione va trattato come un attore del sistema, con identità, confini e responsabilità proprie, non come una funzione decorativa.
Il primo controllo è l'identità. Ogni agente deve avere un nome, uno scopo, un proprietario umano, un registro dei sistemi a cui accede, un insieme di credenziali dedicate e un perimetro documentato. Usare account condivisi o token generici significa perdere tracciabilità. Senza identità separata non esiste audit serio.
Il secondo controllo è il privilegio minimo. Un agente che deve leggere ticket non deve poter esportare un intero database clienti; un agente che aggiorna campi nel CRM non deve poter modificare listini, permessi o condizioni contrattuali. L'errore di progettazione più pericoloso è dare all'agente tutti i permessi "per farlo funzionare". La comodità del test diventa debito di sicurezza in produzione. Tom's Hardware ha già approfondito il tema: gli agenti vanno trattati come dipendenti ad alto rischio, con credenziali dedicate e log completo di ogni azion