Il processo è semplice da descrivere e noioso da fare. Arriva una mail dal committente: c’è un interruttore guasto, un rubinetto che perde, una porta che non chiude. Chi la riceve deve capire di quale immobile si parla, e non è scontato: la lista degli edifici in gestione ne conta più di cento e nella mail spesso c’è il nome dell’ufficio, non l’indirizzo. Poi apre il gestionale, che è un’applicazione web senza interfaccia di integrazione, compila il ticket, salva, annota il codice progressivo, crea la cartella dell’intervento e risponde al mittente che la richiesta è presa in carico. Se manca il numero di telefono per fissare l’appuntamento, lo chiede.
Circa dieci volte al giorno, da mesi, in mezzo al resto del lavoro. Il candidato ideale per un agente: input in linguaggio naturale, azioni ripetitive, un’applicazione fatta per esseri umani.
Ed è proprio qui che si sbaglia di più. La tentazione è dare al modello la mail, l’accesso al browser e l’istruzione «apri il ticket». Funziona alla prima prova. Poi, un giorno, il modello legge AB946 dove c’è scritto AB945, o ritenta un salvataggio andato a buon fine e apre due ticket per la stessa segnalazione, o interpreta come richiesta una frase nel corpo della mail che nessuno intendeva come tale. E nessuno se ne accorge, perché il modello riferisce di aver finito.
Indice degli argomenti
Il modello fa una cosa sola
La scelta di progetto è stata togliere al modello tutto quello che non gli serve. Il modello legge la mail e dice di quale immobile si parla, che tipo di guasto è, se c’è un telefono. Basta. Tutto il resto lo fa codice normale, e il codice verifica ogni cosa che il modello propone.
Qualche esempio concreto, perché il principio senza esempi non vale niente.
L’immobile proposto dal modello viene confrontato con l’elenco ufficiale, stringa contro stringa. Se la somiglianza non supera una soglia fissa, il ticket non si apre: la segnalazione finisce in una coda che una persona guarda. Il modello può essere convinto da una mail scritta male; il confronto con una lista, no.
Prima di ogni salvataggio il sistema controlla che il modulo del gestionale sia identico a quello registrato all’inizio: stessi campi, stesse etichette. Se il fornitore aggiorna il software e sposta un campo, il sistema si ferma prima di cliccare. Meglio un agente fermo che un agente che compila il campo sbagliato con sicurezza.
Il salvataggio viene annotato prima del clic, non dopo. Se qualcosa si interrompe a metà, alla ripartenza il sistema cerca il ticket già creato invece di crearne un altro. Un tentativo ripetuto non può produrre due ticket.
Dopo il salvataggio il codice del ticket viene letto due volte, in due modi indipendenti, e deve rispettare un formato preciso e un intervallo plausibile rispetto all’ultimo codice noto. Poi il ticket viene riaperto e i campi riletti e confrontati con quelli previsti. Solo allora la segnalazione si considera aperta.
E per le prime settimane il bottone Salva lo preme l’operatore. Il sistema compila tutto, mostra una tabella con quello che si aspettava e quello che c’è a schermo, e aspetta. Il passaggio al funzionamento autonomo ha una condizione numerica scritta in anticipo: un certo numero di ticket consecutivi senza correzioni. Non una sensazione, un contatore.
Ogni volta che una segnalazione finisce nella coda umana, la persona che la risolve prende una decisione: quel caso diventa una regola nuova, oppure resta umano per sempre. Non c’è una terza via, e il modello non ha voce in capitolo.
Cosa ho imparato sul mio sistema prima di toccare quello di un cliente
Questi principi non li ho letti da qualche parte. Li ho pagati. Chi scrive gestisce da solo un sistema di 35 automazioni in produzione e circa 70 job schedulati, secondo l’inventario interno aggiornato al 6 agosto 2026. È un sistema piccolo, e per questo utile: si vede tutto, ogni guasto ha la sua autopsia.
Due guasti, su tutti.
Giugno 2026: il controllo automatico che verifica i contenuti prima della pubblicazione, basato su un modello, approvò un video che attribuiva al mio sistema una tecnologia mai usata. Il controllo aveva letto un’affermazione in prima persona e le aveva concesso fiducia. La correzione non è stata un modello più severo: è stata una lista esplicita e versionata di ciò che nel sistema esiste e non esiste, con esito negativo nel dubbio. Il modello è rimasto, ma il perimetro dentro cui può dire sì è diventato un confine scritto.
Luglio 2026: un’automazione che invia mail registrò «inviato» su ogni riga del suo registro. Nessuna mail era partita. L’automazione aveva verificato di aver dato il comando, non che il comando avesse avuto effetto. Da allora, nel mio sistema come nel ticket del cliente, un’azione conta come riuscita solo se un controllo indipendente rilegge la prova dal sistema di destinazione.
Un’altra persona, in un’azienda con cui lavoro, ha chiesto a un modello di controllare le scadenze dei documenti in una cartella. Un documento scadeva dopo tre anni e il modello ha applicato quella regola a tutti, compresi quelli con scadenza mensile. Non è un errore del modello: è una richiesta senza regole per tipo di documento. Scritte le regole, la tabella è venuta giusta, e il documento senza data è finito in una colonna «da chiedere» invece di ricevere una data inventata.
La lezione comune: un controllo che si può convincere non è un controllo. Un modello che giudica legge testo, e il testo può argomentare. Cambia la versione del modello, cambia il contesto, e la stessa domanda dà risposte diverse. Una regola eseguibile, a parità di condizioni osservabili, dà lo stesso esito. Passa o non passa.
La fabbrica ci è arrivata prima
Niente di tutto questo suona nuovo a chi lavora in produzione. Il telaio di Sakichi Toyoda si fermava da solo quando un filo si spezzava, e proprio quell’arresto automatico permise a un operatore di sorvegliare più macchine invece di una: è il jidoka (Lean Enterprise Institute, Jidoka). La supervisione che non scala è un problema più vecchio dell’informatica, e la soluzione non fu un sorvegliante più capace: furono macchine capaci di fermarsi da sole davanti a un’anomalia definita in anticipo.
Il Lean Enterprise Institute distingue i poka-yoke di shutdown, come la macchina che non parte se il pezzo è posizionato male, da quelli di warning, che segnalano l’anomalia (Lean Enterprise Institute, Poka-yoke). Il controllo sul modulo del gestionale è un poka-yoke di shutdown: se il pezzo non è quello atteso, la macchina non parte. La coda umana è un poka-yoke di warning.
E i due principi che ho ritrovato per tentativi stanno già scritti nell’ingegneria d’impianto. Il riparo mobile interbloccato deve essere progettato in modo che «la mancanza o il guasto di uno dei loro elementi impedisca l’avviamento o provochi l’arresto» delle funzioni pericolose: è la logica del blocco in caso di dubbio, requisito essenziale del Regolamento Macchine europeo. E il sistema strumentato di sicurezza nasce storicamente indipendente dal controllo che sorveglia, ricorda la guida NIST sui sistemi OT; le architetture integrate esistono, ma la funzione di sicurezza resta soggetta ai propri requisiti (NIST SP 800-82 Rev. 3). Il guardiano non deve condividere il destino di ciò che sorveglia. Nel ticket del cliente, il codice che verifica non usa il modello per verificare.
Un’avvertenza dovuta: un controllo che blocca un ticket sbagliato non è un interlock che salva una mano. Il paragone con l’impianto è di metodo, mai di conseguenze.
Quando il software apprende, la legge chiede più verifica
La distinzione fra software che apprende e software che esegue è intanto entrata nel diritto dei prodotti. Il nuovo Regolamento Macchine, il regolamento (UE) 2023/1230 applicabile dal 20 gennaio 2027, tratta il software come possibile componente di sicurezza e mette i componenti «dotati di un comportamento integralmente o parzialmente autoevolutivo che utilizzano approcci di apprendimento automatico» fra quelli per cui l’autocertificazione del fabbricante non basta: serve una valutazione con organismo notificato. Fra i requisiti sui sistemi di comando, esclude modifiche ai limiti delle funzioni di sicurezza «neanche durante la fase di apprendimento della macchina». Il raccordo con l’AI Act è stato ridisegnato dall’Omnibus digitale sull’IA (regolamento UE 2026/1744, in vigore dal 27 luglio 2026, consultato il 2026-08-24), che porta i requisiti per i sistemi di IA ad alto rischio destinati alle macchine dentro il Regolamento Macchine, con atti delegati applicabili entro il 2 agosto 2028.
È una disciplina circoscritta ai componenti di sicurezza delle macchine, e niente di ciò che descrivo qui vi ricade. Ma il criterio è lo stesso a cui sono arrivato per tentativi: davanti al software che apprende, più verifica esterna e limiti che l’apprendimento non può spostare. Una guida della Institution of Engineering and Technology su intelligenza artificiale e sicurezza funzionale lo dice in una riga: attorno a un componente AI servirà in molti casi «a deterministic rule-based protective layer», uno strato protettivo basato su regole (IET, The Application of Artificial Intelligence in Functional Safety, 2024).
Il modello propone, la regola dispone
Nel giugno 2025 Innovation Post raccontava i Guardian Agents, gli agenti AI che secondo Gartner sorveglieranno gli altri agenti (L’AI che controlla l’AI: il ruolo dei Guardian Agents). L’argomento portante è forte: non ci sono abbastanza persone per guardare tutti i sistemi in arrivo. La tassonomia di quel pezzo aiuta a dire dove mettere il modello: i guardiani possono fare da «giudice e giuria» sulla qualità, da «protettori» che bloccano, da «supervisori» che informano. Nel ticket del cliente, e nel mio sistema, i modelli fanno i giudici e i supervisori: leggono, classificano, cercano anomalie che nessuna regola prevedeva, propongono. Il ruolo di protettore, l’unico che blocca, sta a controlli con ingresso osservato, condizione e esito scritti. L’essere umano resta sopra entrambi.
In un altro articolo di questa testata c’è poi una distinzione che uso spesso: fra l’umano «in the loop», che rallenta ogni operazione, l’umano «on the loop», che supervisiona, e l’umano «out of the loop», che è il pericolo vero (L’AI a supporto delle decisioni e il rischio dell’human out-of-the-loop). L’operatore che preme Salva è in the loop. Il contatore dei ticket senza correzioni è lo strumento che lo porterà on the loop senza farlo diventare out of the loop: quando il freno si toglie, i controlli restano, e la linea si ferma da sola.
Una regola operativa, per chiudere. Quando un controllo basato su modello scopre un problema vero, la domanda non è come farlo sorvegliare di più, ma quale regola eseguibile estrarne. Il pezzo del 2025 si chiudeva con il consiglio di Gartner di tornare a «una rigorosa gestione dei processi», e citava come punti di osservazione un evento non gestito, una chiamata non autorizzata, un file di log che viola determinate regole. Sono regole. Scritte in codice, con il blocco nel dubbio, sono già il guardiano. Ciò che si costruisce sopra, agente o persona, serve a vederle invecchiare e a proporne di nuove, non a sostituirle quando bisogna dire no.
