Un sistema segnala un possibile deterioramento di un componente. La manutenzione propone un controllo; la produzione deve decidere se interrompere la lavorazione o completare il lotto. In questo passaggio una previsione diventa una scelta con conseguenze industriali. L’accuratezza del modello conta, ma da sola non spiega perché si sia deciso di proseguire.
Se quella scelta precede uno scarto, un fermo macchina o una situazione pericolosa, l’impresa può ricostruire quali informazioni erano disponibili, quale criterio è stato applicato e chi aveva la possibilità di intervenire? La domanda riguarda anche un sistema di visione che suggerisce di scartare un pezzo, un algoritmo che modifica la sequenza degli ordini o un modello che propone un nuovo parametro di processo.
La verifica dovrebbe cominciare dal punto in cui l’output entra nel processo operativo. Visualizzare un allarme, approvare una raccomandazione e modificare automaticamente un parametro sono funzioni diverse: richiedono controlli proporzionati alle conseguenze e tempi di intervento compatibili con il processo.
Indice degli argomenti
Perché il dato non è ancora un’evidenza
Un valore di vibrazione è una misura. Per usarlo a sostegno di una decisione occorre sapere da quale sensore proviene, quando è stato acquisito, in quali condizioni lavorava la macchina e se il segnale presentava anomalie. Un punteggio prodotto dal modello aggiunge un’inferenza, non la certezza di un guasto.
Consideriamo un esempio ipotetico, non un caso aziendale documentato. Un modello di manutenzione predittiva elabora segnali raccolti dopo un cambio di lavorazione e suggerisce un’ispezione. Il responsabile rinvia il controllo. Per valutare la scelta non basta conservare la schermata dell’allarme: servono il regime operativo, la validità dei dati, la versione del modello, la soglia applicata e la motivazione del rinvio.
Se il componente viene successivamente sostituito, anche il riscontro dell’ispezione va collegato alla segnalazione. La sostituzione, da sola, non dimostra che il modello avesse previsto correttamente il guasto. Analogamente, l’assenza di un fermo non dimostra che il rinvio fosse una scelta ben fondata.
In questo senso, un’evidenza è un elemento utilizzabile per sostenere o contestare un’affermazione, con provenienza, contesto e limiti espliciti. Può documentare anche un’incertezza. La tracciabilità rende possibile l’esame della decisione; non ne garantisce automaticamente la correttezza.
La catena da conservare
Il percorso da ricostruire collega fonte, acquisizione, trasformazioni, modello, output, validazione prevista, azione e risultato. Per una raccomandazione sottoposta ad approvazione, la validazione è umana. Per un’azione automatizzata entro limiti autorizzati, occorre documentare quei limiti e le condizioni di escalation: non avrebbe senso inventare una conferma umana per ogni ciclo macchina.
La catena può attraversare sistemi diversi: lo storico dei segnali, il servizio che esegue il modello, il sistema di gestione della produzione e quello della manutenzione. Una buona pratica è collegare gli eventi con identificativi coerenti di macchina, lotto e decisione, usando riferimenti temporali confrontabili. Il collegamento deve consentire di distinguere la raccomandazione dalla decisione e quest’ultima dal comando effettivamente eseguito.
Conservare soltanto la versione corrente del modello non permette di esaminare un output prodotto prima di un aggiornamento. Occorre rendere identificabili le versioni pertinenti, comprese configurazioni e trasformazioni dei dati. La riproduzione esatta del risultato, quando tecnicamente possibile, è utile; resta comunque necessario ricostruire il contesto nel quale è stato usato.
È il passaggio dalla Data Governance alla Evidence Governance: alla qualità e alla disponibilità del dato si aggiunge la cura del suo impiego come fondamento di una decisione. Qui l’espressione indica un approccio operativo, non una certificazione o un nuovo obbligo di legge.
Il limite del semplice human in the loop
Inserire una persona nel flusso non basta se quella persona vede soltanto un punteggio e un pulsante di conferma. La verifica perde sostanza quando mancano il tempo per valutare, la conoscenza dei limiti del sistema o un’alternativa praticabile alla raccomandazione.
Una misura organizzativa applicabile è definire in anticipo quali condizioni richiedano un approfondimento: dati mancanti, macchina fuori dal campo di utilizzo validato, modifica recente della configurazione o discordanza con un controllo indipendente. Il sistema dovrebbe rendere visibili tali condizioni al ruolo responsabile, invece di affidare a una conferma generica la gestione di qualunque anomalia.
Il NIST AI Risk Management Framework 1.0, volontario, organizza la gestione del rischio nelle funzioni Govern, Map, Measure e Manage. La conseguenza pratica è trattare ruoli, contesto d’uso, valutazioni e risposta ai problemi come attività connesse lungo il ciclo di vita, anziché limitarsi al collaudo iniziale del modello. [1]
Sorveglianza umana e autorità di intervento
Per i sistemi ad alto rischio, l’articolo 14 dell’AI Act prevede una sorveglianza proporzionata a rischi, autonomia e contesto. Include la comprensione dei limiti, l’attenzione all’eccessivo affidamento sull’output e, secondo appropriatezza, la possibilità di ignorarlo, modificarne gli effetti o interrompere il sistema in condizioni sicure. La sorveglianza prevista dalla norma comprende quindi poteri effettivi, non la sola osservazione. [2]
Human authority è qui il nome della verifica organizzativa di quei poteri: chi può sospendere l’uso dell’AI, con quali informazioni e attraverso quale comando? Chi gestisce il passaggio a una modalità alternativa? Chi autorizza il ripristino dopo l’analisi dell’anomalia? Non è una categoria giuridica separata dalla human oversight.
In fabbrica occorre inoltre distinguere la sospensione di una funzione AI dall’arresto della macchina. La risposta sicura dipende dall’impianto e dalla valutazione dei rischi. Una procedura di approvazione o un registro decisionale non sostituiscono le funzioni di sicurezza progettate e validate per il sistema.
Il punto di incontro tra AI Act e sicurezza industriale
La presenza di AI in uno stabilimento non rende automaticamente il sistema ad alto rischio. La classificazione dipende dalla destinazione d’uso e dai criteri normativi applicabili; richiede particolare attenzione quando l’AI svolge funzioni di sicurezza o rientra negli impieghi elencati dalla normativa. Le linee guida della Commissione sulla classificazione consultate sono pubblicate come bozza e vanno trattate come materiale interpretativo, non come obblighi aggiuntivi. [3]
Nel perimetro dei sistemi ad alto rischio, l’articolo 12 dell’AI Act prevede capacità di registrazione automatica degli eventi per una tracciabilità adeguata alla finalità del sistema. Non prescrive, per qualunque applicazione industriale, un identico fascicolo decisionale. La selezione delle evidenze proposta in questo articolo è una buona pratica da adattare al rischio, distinta dagli adempimenti e dalle rispettive decorrenze. [4]
Il Regolamento Macchine (UE) 2023/1230, applicabile in via generale dal 20 gennaio 2027, affronta anche funzioni di sicurezza basate sull’AI e protezione di software e dati rilevanti per la sicurezza. Per OEM e integratori, la conseguenza progettuale è valutare l’effetto di modifiche a modelli, configurazioni e collegamenti sull’intera macchina, senza considerare il software come un elemento isolato. [5]
La cybersecurity OT aggiunge la necessità di poter fare affidamento sulle registrazioni. La serie IEC 62443 distingue aspetti organizzativi e tecnici: la parte 2-1 riguarda il programma di sicurezza dell’asset owner; la parte 4-2 i requisiti di sicurezza dei componenti. Sono riferimenti tecnici, non una dimostrazione automatica della correttezza di una decisione AI. Operativamente, accessi, modifiche e integrità dei registri meritano controlli coerenti con il rischio dell’impianto. [6]
Anche Cyber Resilience Act e NIS2 hanno perimetri diversi. Il primo riguarda i prodotti con elementi digitali e la gestione delle vulnerabilità; la seconda la sicurezza di reti e sistemi dei soggetti che rientrano nel suo ambito, attraverso il recepimento nazionale. Non si applicano indistintamente a ogni software e a ogni fabbrica. Per le organizzazioni interessate è utile collegare la gestione degli incidenti alla storia di versioni, accessi e cambiamenti del sistema. [7–8]
ISO/IEC 42001:2023 offre invece un riferimento per il sistema di gestione dell’AI. Una certificazione secondo questo standard non equivale, da sola, alla conformità all’AI Act e non sostituisce la verifica della singola applicazione. La distinzione è concreta: una procedura aziendale può essere ben definita e lasciare comunque incompleta la ricostruzione di un particolare evento. [9]
Le evidenze minime da rendere disponibili
Per partire, l’impresa può scegliere una decisione circoscritta e costruire un record collegato ai sistemi esistenti. Questa è una proposta operativa, da dimensionare secondo criticità, vincoli di conservazione e dati personali eventualmente presenti:
- Identità e contesto: decisione, macchina, lotto o ordine, momento dell’evento e condizioni operative rilevanti.
- Dati e provenienza: sorgenti, intervallo di acquisizione, qualità, anomalie e riferimenti alle misure da conservare.
- Elaborazione: trasformazioni applicate, versione del modello e configurazione effettivamente utilizzata.
- Output e criterio: raccomandazione, incertezza disponibile, soglia e regola che ne consentono l’utilizzo.
- Responsabilità e azione: validazione richiesta, ruolo intervenuto, motivazione delle eccezioni e azione realmente eseguita.
- Esito e correzione: risultato osservato, riscontri successivi, eventuali modifiche e condizioni di ripristino.
Non è necessario riversare tutti i dati in un nuovo archivio. Servono riferimenti recuperabili, responsabilità di conservazione e protezioni adeguate contro alterazioni. Un identificativo o un’impronta digitale possono aiutare a verificare il collegamento o l’integrità, ma non sostituiscono il contenuto necessario all’analisi. Anche la durata di conservazione va definita per finalità e obblighi applicabili, senza trasformare la tracciabilità in raccolta indiscriminata.
Una prova concreta per OEM e utilizzatori
Prima di estendere un’applicazione AI, OEM, utilizzatore e responsabili di produzione possono eseguire una prova congiunta: selezionare una decisione recente e ricostruirla utilizzando le registrazioni disponibili. Il fornitore rende identificabili modello, configurazione e limiti; l’utilizzatore collega l’output al contesto e all’azione; il management assegna responsabilità, risorse e criteri di escalation.
La prova dovrebbe includere anche un’eccezione: una raccomandazione rifiutata, un dato mancante oppure il rientro dopo una sospensione. Si può misurare il tempo necessario alla ricostruzione e annotare quali passaggi richiedono ancora spiegazioni a memoria. Quei vuoti indicano dove intervenire.
Il risultato atteso è poter spiegare perché, con le informazioni disponibili in quel momento, sia stata autorizzata una determinata azione e che cosa sia accaduto dopo. È questa capacità che permette di discutere un errore, correggere il processo e attribuire responsabilità sulla base di elementi verificabili.
Fonti essenziali
Riferimenti ufficiali consultati il 22 settembre 2026. I richiami numerici collegano le fonti alle affermazioni nel testo. Gli esempi e la proposta di record decisionale sono elaborazioni dell’autore.
1. NIST — AI Risk Management Framework 1.0 (2023). Framework volontario; funzioni Govern, Map, Measure e Manage. DOI 10.6028/NIST.AI.100-1.
2. Regolamento (UE) 2024/1689 — articolo 14. Sorveglianza umana dei sistemi ad alto rischio.
Testo sul portale della Commissione
3. Commissione europea — Draft Commission guidelines on the classification of high-risk AI systems, 19 maggio 2026. Bozza interpretativa; classificazione ai sensi dell’articolo 6.
4. Regolamento (UE) 2024/1689 — articolo 12. Capacità di registrazione degli eventi nei sistemi ad alto rischio.
Testo sul portale della Commissione
5. Regolamento Macchine (UE) 2023/1230. Commissione europea, quadro ufficiale su applicazione, funzioni AI e cyber-safety.
Quadro ufficiale e collegamento al regolamento
6. IEC — Serie IEC 62443. Ambito delle parti 2-1 e 4-2: programma di sicurezza degli asset owner e requisiti tecnici dei componenti. Riferimento alla descrizione pubblica IEC, non a clausole del testo a pagamento.
Descrizione ufficiale della serie
7. Regolamento (UE) 2024/2847 — Cyber Resilience Act. Commissione europea, ambito, ciclo di vita e attuazione.
Quadro ufficiale e collegamento al regolamento
8. Direttiva (UE) 2022/2555 — NIS2. Commissione europea, ambito e recepimento nazionale.
Quadro ufficiale e collegamento alla direttiva
9. ISO/IEC 42001:2023 — Artificial intelligence management system. Descrizione pubblica ufficiale del sistema di gestione.
