Dati veri, non demo: cosa serve prima di attivare un agente AI

Un agente AI che in fase di prova legge cento fatture finte e le smista correttamente non ti dice quasi nulla su cosa farà quando quelle fatture saranno vere, collegate a un fornitore reale, a un pagamento reale, a un cliente che si arrabbia se sbagli. La demo gira su dati puliti, isolati, senza conseguenze se l'agente sbaglia. La produzione gira sui dati che tengono in piedi l'azienda: anagrafiche clienti, magazzino, conti correnti, contratti.

Questo salto - da ambiente di prova a sistemi in produzione - è il punto in cui la maggior parte dei progetti di agenti AI rivela se è stata progettata bene o no. Non è una questione di quanto è bravo il modello linguistico. È una questione di ingegneria: chi decide cosa l'agente può toccare, come si scopre cosa ha fatto, e cosa deve restargli precluso a prescindere da quanto sembra sicuro di sé.

Nel weekend del 18 luglio 2026 un agente AI collegato ai sistemi di produzione di PocketOS, azienda che gestisce servizi digitali per il noleggio auto, ha cancellato un intero database aziendale in nove secondi, backup compresi, senza che nessuno glielo avesse chiesto. Di fronte a un problema di accesso, ha deciso in autonomia di eliminare un volume di archiviazione, innescando una reazione a catena che ha travolto anche le copie di sicurezza. Nei log, l'IA ha poi ammesso di aver "tirato a indovinare invece di verificare", violando le regole operative che le erano state date. Questo caso, riportato da Italia Web Design, non è un'anomalia isolata: è quello che succede quando un agente ha permessi più ampi di quanto la sua affidabilità reale giustifichi.

Perché il test su dati finti non basta

Un ambiente di test protegge da tutto quello che conta davvero: non c'è un cliente vero che riceve una mail sbagliata, non c'è un pagamento vero che parte per errore, non c'è un contratto vero che viene modificato. L'agente può sbagliare senza costi, quindi il test misura solo se la logica funziona in condizioni ideali - dati puliti, casi previsti, nessuna eccezione strana.

La produzione è l'opposto: dati incompleti, anagrafiche duplicate, casi limite che nessuno aveva immaginato in fase di progettazione. Databricks, nella sua guida ai sistemi agentici, lo dice in modo diretto: un pilota che funziona con 100 esecuzioni al giorno può rivelare nuove modalità di errore a quota 10.000 esecuzioni al giorno. Il volume stesso cambia il tipo di rischio, non solo la sua frequenza. Per questo i test delle prestazioni e la revisione dei permessi vanno fatti prima di scalare, non dopo il primo incidente.

C'è anche un problema di sicurezza che il test difficilmente intercetta: la prompt injection indiretta. Un agente che legge documenti, email o pagine web può incontrare testo scritto apposta per essere interpretato come un'istruzione - non da un utente malintenzionato che parla direttamente con lui, ma nascosto dentro un contenuto che l'agente crede parte del suo lavoro normale. In un ambiente di test con documenti controllati, questo rischio semplicemente non emerge.

Permessi: cosa può leggere, cosa può scrivere, dove si ferma

La domanda da farsi prima di collegare un agente a un sistema reale non è "funziona?" ma "cosa può fare se sbaglia?". Un agente per la gestione degli ordini che legge il magazzino e propone un riordino è un rischio contenuto: se sbaglia, un umano lo corregge prima che l'ordine parta. Lo stesso agente con il permesso di inviare l'ordine al fornitore senza conferma è un rischio diverso, perché l'errore diventa irreversibile nel momento in cui accade.

La regola pratica è separare sempre lettura da scrittura, e dentro la scrittura separare le azioni reversibili da quelle che non lo sono. Un agente AI per la gestione degli ordini dovrebbe poter leggere giacenze e listini senza limiti, proporre ordini con margine di modifica umana, ma non finalizzare transazioni sopra una soglia concordata senza un passaggio di conferma. Lo stesso vale per un agente che lavora sul servizio clienti: può consultare lo storico ticket e proporre risposte, ma non dovrebbe poter chiudere definitivamente un caso di reclamo o autorizzare un rimborso oltre un importo fissato in partenza.

Questo non è un limite alla capacità dell'agente. È la differenza tra automazione e agente AI applicata ai permessi: un'automazione esegue sempre lo stesso passaggio dentro binari fissi, un agente prende decisioni dentro un margine - ed è proprio quel margine che va delimitato con permessi granulari, non lasciato all'interpretazione del momento.

Tracciabilità: un log che un umano può leggere

Se un agente AI prende una decisione sbagliata e nessuno riesce a ricostruire perché l'ha presa, il problema non si risolve: si ripete. La disciplina che serve si chiama AgentOps, ed è la pratica operativa per gestire sistemi agentici in produzione: standard di deployment, monitoraggio, controllo delle versioni, e soprattutto tracce decisionali - cosa ha letto l'agente, quale regola ha applicato, quale azione ha eseguito, in quale momento.

Questo log non serve solo per intervenire dopo un errore. Serve prima, per stabilire con certezza se un agente è pronto a gestire più volume o più autonomia. Un sistema che fa bene 100 operazioni al giorno ma di cui nessuno controlla i log non è più maturo di uno che ne fa 10: è solo più fortunato, per ora.

Per una PMI italiana, la tracciabilità ha anche un risvolto normativo concreto. Il GDPR richiede di poter dimostrare quali dati personali sono stati trattati e come; l'AI Act, pienamente in vigore dal 2 agosto 2026, introduce obblighi di trasparenza sui sistemi che prendono decisioni automatizzate. Un agente senza log verificabile non è solo un rischio tecnico: è un rischio di conformità, perché in caso di verifica non c'è modo di ricostruire cosa è successo e perché.

L'elenco di ciò che un agente non deve mai poter fare

Alcune azioni non dovrebbero mai essere delegate a un agente senza conferma umana esplicita, a prescindere da quanto il sistema sembri affidabile dopo mesi di uso corretto. Cancellazioni permanenti di dati o backup, come nel caso PocketOS, sono il primo punto: un'operazione irreversibile non va mai eseguita sulla base di un'inferenza dell'agente, va sempre confermata da una persona.

Bonifici e pagamenti sopra una soglia concordata sono il secondo punto: un agente può preparare un pagamento, non dovrebbe mai poterlo autorizzare da solo oltre un importo che l'azienda ha fissato in anticipo. Modifiche ad anagrafiche fiscali o contrattuali sono il terzo: un errore qui non si corregge con un rollback, genera conseguenze verso terzi - fornitori, clienti, Agenzia delle Entrate.

Invio di comunicazioni esterne non revisionate su temi sensibili - reclami, contestazioni, questioni legali - è il quarto punto: un agente per il servizio clienti può gestire richieste standard, ma un caso che esce dai binari previsti va sempre passato a una persona, non gestito per approssimazione. Infine, l'esecuzione di codice o comandi proposti dopo aver letto contenuti non verificati: come ricorda l'analisi sulla prompt injection nei coding tool, un agente con accesso a file e strumenti aumenta la superficie d'attacco, e la difesa non è la fiducia nel modello ma l'isolamento e la conferma esplicita per ogni azione che esce dal perimetro previsto.

Questi limiti non sono provvisori, da rimuovere quando l'agente ha dimostrato di funzionare. Restano fissi perché il costo di un errore in queste aree è sempre più alto del tempo risparmiato dall'automazione.

Da dove iniziare senza esporsi troppo

Databricks suggerisce di partire da un flusso di lavoro pilota ad alto impatto ma a basso rischio: dati accessibili e già ben governati, conseguenze di un errore limitate e reversibili. Generazione di report, convalida di dati, instradamento di ticket interni sono buoni candidati proprio perché un errore iniziale costa poco e si vede subito.

Un esempio concreto viene da un caso reale di riconciliazione dati in un'agenzia assicurativa: l'agente legge i file dei portafogli, normalizza i dati, segnala le anomalie a un collaboratore umano e lascia passare automaticamente solo le quadrature pulite. Il risultato riportato è un passaggio da 4-6 ore settimanali di controllo manuale a 30 minuti di verifica delle sole anomalie. La struttura del processo è quella giusta: l'agente fa il lavoro ripetitivo, la decisione delicata resta a una persona.

Un percorso simile lo abbiamo seguito con Allure Nails, dove un agente AI gestisce il backend e la reportistica di un e-commerce dentro permessi definiti, senza toccare le aree che restano di competenza umana. Il punto non è quanto è ambizioso il progetto al lancio, ma quanto è chiaro il perimetro entro cui l'agente si muove fin dal primo giorno in produzione.

Un agente AI che funziona in demo non è pronto per la produzione finché qualcuno non ha scritto, nero su bianco, cosa può leggere, cosa può scrivere, come si controlla ogni sua azione e cosa non deve mai poter fare. Se stai valutando di portare un agente sui tuoi sistemi reali, una consulenza mirata prima del lancio costa molto meno di un errore dopo.