L’IA al servizio della commissione d’indagine: dall’agente cloud all’indagine offline sugli incidenti

Come siamo passati dai primi esperimenti in cloud a un flusso di lavoro operativo «strumento di mascheramento → agente IA → smascheramento», per poi creare un sistema d’indagine offline in fase di test e prepararci al passo successivo: Fire, l’ambiente IA aziendale protetto.

L’idea chiave: l’IA non deve «individuare il colpevole» e non sostituisce la commissione. Il suo ruolo utile è aiutare la commissione a ricomporre più in fretta materiali sparsi in un quadro unico, individuare le lacune, verificare la logica causale e preparare una prima bozza di lavoro dell’indagine.

Da dove è cominciato tutto

I primi tentativi di usare l’IA nelle indagini sugli incidenti risalgono al 2023. All’epoca l’idea sembrava piuttosto semplice: creare un proprio agente, caricarvi la metodologia d’indagine e i materiali di un evento specifico, quindi chiedergli di ricostruire la cronologia, trovare le contraddizioni nelle dichiarazioni scritte, proporre cause e azioni.

Nel 2024 le capacità dei modelli si sono ampliate in modo evidente: hanno cominciato a lavorare con sicurezza non solo sul testo, ma anche sulle immagini. Uno dei primi esperimenti non era nemmeno un’indagine vera e propria. In un sito remoto una lavoratrice era caduta e si era infortunata a un piede. La radiografia era stata eseguita sul posto, ma lì non c’era uno specialista in grado di refertarla subito. Abbiamo caricato l’immagine nell’IA e il modello ha indicato un’area compatibile con una frattura del quinto metatarso.

Lo sottolineo di proposito: non si trattava di una diagnosi medica, né doveva esserlo. La valutazione definitiva di un’immagine diagnostica spetta al medico. Ma per noi quell’episodio è stato un segnale tecnico importante: il modello è in grado di cogliere in un’immagine dettagli che un non specialista potrebbe non vedere. Quindi, in un’indagine, può potenzialmente lavorare non solo con il testo, ma anche con schemi, fotografie e altri materiali.

La prima versione operativa: un agente in cloud

Quando sono comparsi agenti personalizzati più affidabili, abbiamo cominciato a configurarli direttamente sulla nostra metodologia aziendale. Ne abbiamo realizzato versioni in GPT, Gemini e Perplexity; nella fase iniziale abbiamo provato anche Grok. Nell’agente caricavamo la metodologia, poi le dichiarazioni scritte, la descrizione iniziale dell’evento, singoli documenti e altri materiali.

L’effetto pratico si è visto subito. L’IA incrociava rapidamente le testimonianze, proponeva la sequenza degli eventi, trovava incongruenze negli orari e nelle formulazioni, stilava un elenco di domande aggiuntive. Per la commissione era utile come un «secondo analista» che non si stanca di rileggere decine di pagine.

Ma la prima versione aveva un difetto evidente: di fatto consegnavamo a un servizio esterno i materiali reali dell’indagine. Per gli incidenti è un aspetto particolarmente delicato: i materiali possono contenere nomi e cognomi, mansioni, dati sanitari, dichiarazioni scritte, fotografie e informazioni interne dell’azienda.

Più usavamo lo strumento, più diventava chiaro che la comodità non può giustificare l’invio all’esterno di dati superflui.

Vedi l’appendice con i prompt: Prompt 1 — versione sicura dell’agente cloud, che lavora solo con materiali anonimizzati in precedenza.

La metodologia è diventata più rigorosa — e questo ha cambiato i requisiti per l’IA

Nel frattempo si evolveva anche la metodologia aziendale d’indagine interna. Per me è un punto importante: all’IA non si può concedere di «inventarsi da sola come indagare». Prima deve esserci la metodologia, e solo su di essa si costruisce lo strumento digitale.

Nella metodologia vigente l’obiettivo principale della commissione non è cercare un colpevole, ma definire le misure più efficaci possibili per eliminare o ridurre la probabilità che un evento simile si ripeta. Se nella catena compare un’azione umana, bisogna andare oltre e capire perché quell’azione sia stata possibile o ritenuta accettabile.

L’indagine segue la logica delle barriere di protezione: sorgente di pericolo → evento indesiderato → conseguenze; le barriere preventive e quelle di mitigazione vengono esaminate separatamente. Nella fase di analisi delle informazioni si costruisce la cronologia degli eventi e si individuano i fattori critici. Poi si costruisce l’albero delle cause, che deve condurre dalle cause immediate e intermedie fino alle cause radice sistemiche.

Nelle analisi più semplici la catena dei «Perché?» può essere breve. In un evento complesso si ramifica e diventa un vero e proprio albero delle cause. La logica delle barriere del modello «bow-tie» aiuta a verificare separatamente perché l’evento si sia verificato e perché le conseguenze siano state proprio quelle.

È proprio questa sequenza a diventare, in seguito, l’ossatura della nostra applicazione locale.

Vedi Prompt 2–6: cronologia e fattori critici → domande e contraddizioni → barriere → albero delle cause → azioni.

La seconda versione: mascheramento manuale

La fase successiva era molto più sicura, anche se piuttosto scomoda. Prima di caricare i materiali nell’agente cloud sostituivamo a mano i cognomi e gli altri dati sensibili: «Lavoratore 1», «Lavoratore 2», «Responsabile 1», «Reparto 1» e così via.

Dal punto di vista della riservatezza era già un passo avanti. L’agente vedeva la logica dell’incidente, ma non i nomi reali. Terminata l’analisi, bisognava ripristinare a mano le denominazioni originali — spesso con la ricerca Ctrl+F.

Finché le persone coinvolte sono due o tre, il processo è sopportabile. Quando un’indagine comprende molte dichiarazioni scritte, testimoni, documenti e cognomi ricorrenti, il mascheramento manuale e il successivo ripristino diventano un lavoro a sé e creano il rischio di errori.

La terza versione: uno strumento di mascheramento locale e il problema a parte dell’audio

Quando abbiamo acquisito competenze di vibe coding, abbiamo sostituito l’operazione manuale con uno strumento di mascheramento locale, di cui ho parlato nel primo articolo della serie. Il documento Word viene elaborato sul computer e riceve denominazioni convenzionali, mentre la chiave di smascheramento viene salvata a parte. La chiave è protetta da password e non viene trasmessa all’agente.

A quel punto all’IA in cloud si possono inviare solo le dichiarazioni scritte e gli altri materiali già mascherati. Il risultato ottenuto torna sul computer e viene ripristinato in locale. È proprio questo il flusso che oggi usiamo nel lavoro reale: strumento di mascheramento locale → agente d’indagine configurato → smascheramento locale. Già così permette di sfruttare i punti di forza del modello in cloud senza trasmettergli i nomi originali né la chiave di ripristino.

Restava però un altro punto vulnerabile: le registrazioni audio. Dichiarazioni e interviste è comodo registrarle a voce, ma per analizzarle bisogna prima trasformarle in testo. In passato si usavano a questo scopo servizi online e app dedicate. Più tardi la trascrizione è arrivata direttamente nei grandi servizi di IA. È comodo, ma la registrazione originale con la voce della persona continua a finire all’esterno.

Per questo abbiamo realizzato un altro strumento: un trascrittore locale. Usa Whisper direttamente sul computer. Nei nostri test la qualità della trascrizione si è rivelata del tutto paragonabile a quella delle consuete soluzioni in cloud, e intanto la registrazione originale non lascia il computer. Dopo la trascrizione locale il testo può essere mascherato e solo allora, se necessario, trasmesso all’agente d’indagine operativo.

La catena di questa fase: trascrizione locale → strumento di mascheramento locale → agente cloud. Per l’analisi dei materiali vedi Prompt 1–6.

La quarta versione: il sistema offline esiste già — ora lo stiamo testando

A questo punto è sorta un’altra domanda. Se in locale funzionano già la trascrizione, la lettura dei documenti e il modello, perché non riunire tutto in un unico ambiente protetto? Così è nato il sistema d’indagine offline sperimentale. È già stato sviluppato e funziona, ma oggi scegliamo consapevolmente di considerarlo in fase di test: lo verifichiamo su casi didattici e anonimizzati, confrontiamo i risultati con il lavoro della commissione e cerchiamo le prossime iterazioni che renderanno il processo più rapido, più comodo e più solido.

L’obiettivo era questo: creare un’unica postazione di lavoro per la commissione in cui caricare la guida metodologica, le informazioni iniziali, le dichiarazioni scritte, file Word e PDF, registrazioni audio, fotografie e schemi; trascrivere in locale il parlato e i documenti; percorrere le fasi della metodologia e ottenere una prima bozza modificabile del rapporto in Word.

Detto in una frase sembra semplice. In pratica le iterazioni sono state tantissime. Il riconoscimento vocale locale non ha funzionato subito, poi abbiamo dovuto fare i conti con PDF scansionati, immagini, materiali voluminosi, il modello locale, la cronologia, le cause e il documento finale. Lo schema di sviluppo era lo stesso degli altri nostri progetti: una modifica → avvio → risultato o schermata dell’errore → iterazione successiva con ChatGPT.

Alla fine è nato un sistema locale con interfaccia nel browser e un proprio ambiente IA locale. Già oggi trascrive bene le registrazioni, legge i materiali preparati e genera una bozza d’indagine strutturata. Ora il nostro compito non è proclamarlo «prodotto finito», ma testarlo con calma, confrontare i risultati e migliorarne la logica di funzionamento. Per un modello locale completo e per elaborare rapidamente grandi volumi di materiale serve un computer piuttosto potente.

Vedi Prompt 8 — master prompt per realizzare in vibe coding la postazione locale della commissione.

Cosa sa già fare la versione offline di prova

Nella versione offline di prova l’intero ciclo è già costruito attorno alla metodologia, non attorno a una normale chat con l’IA.

Per prima cosa la commissione registra le informazioni iniziali: cosa è successo, la sorgente di pericolo, l’evento indesiderato, le conseguenze, le persone coinvolte, gli esiti del sopralluogo. Poi si definisce il piano: a quali domande occorre rispondere, chi sentire, quali documenti e perizie acquisire.

Nella sezione dei materiali si possono caricare file DOCX e PDF testuali. Scansioni e fotografie possono essere riconosciute in locale; schemi e immagini vengono conservati nel fascicolo e il modello può proporre una descrizione dei dettagli visibili. Audio e video vengono trascritti in locale. Si può anche registrare un’intervista direttamente dal microfono e ottenerne poi la trascrizione.

Dopo la verifica dei materiali l’applicazione aiuta a costruire la cronologia. L’IA propone eventi e citazioni, ma la decisione di includere una voce spetta alla commissione. I fattori critici vengono segnalati a parte.

Il blocco successivo riguarda le barriere di protezione e le cause. La commissione verifica le barriere preventive e di mitigazione e costruisce i due rami di partenza: perché si è verificato l’evento indesiderato e perché ha avuto proprio quelle conseguenze. Le cause proposte dall’IA restano ipotesi finché la commissione non le conferma.

Dopo le cause si definiscono le azioni: a quale causa si riferisce la misura, chi ne è responsabile, entro quando, quale risultato verificabile ci si attende, se serve una barriera temporanea, se la misura deve estendersi oltre la singola area.

Solo a quel punto si genera la bozza del rapporto. L’applicazione può assemblare una prima bozza in Word secondo la struttura della guida metodologica, includendo la cronologia, l’albero delle cause, le barriere, il registro dei materiali e gli allegati.

Vedi Prompt 2 — cronologia; Prompt 3 — contraddizioni e dati mancanti; Prompt 4 — barriere; Prompt 5 — albero delle cause; Prompt 6 — azioni; Prompt 7 — bozza del rapporto finale.

Cosa fa l’IA locale — e cosa non deve fare

Qui è importante non sopravvalutare l’automazione. L’IA legge a frammenti i testi verificati, propone la cronologia, le domande, le barriere, le ipotesi sulle cause e le possibili azioni. Può trovare una contraddizione tra due dichiarazioni scritte o accorgersi che nella cronologia manca un intervallo di tempo importante.

Ma una citazione da un documento conferma soltanto che quelle parole compaiono davvero nel materiale. Non dimostra che la testimonianza sia veritiera. Il testo riconosciuto può contenere errori. Uno schema può essere interpretato in modo sbagliato. Un nesso causale può rivelarsi solo un’ipotesi.

Per questo l’applicazione si fonda su un principio: l’IA propone, la commissione accetta, respinge o modifica. Una causa non diventa confermata in automatico. Responsabili e scadenze non li assegna il modello. La bozza in Word è appunto una prima bozza di lavoro, non un documento «pronto da firmare».

Questo è particolarmente importante perché il rapporto interno non sostituisce i documenti previsti dalla legge e dalle procedure stabilite. La responsabilità dell’indagine resta in capo alla commissione.

Vedi Prompt 9 — controllo della qualità, della riservatezza e dei limiti dell’automazione prima di usare il risultato.

La riservatezza è diventata parte dell’architettura, non un’istruzione a parte

Nelle indagini la questione della riservatezza non si può rimandare. La metodologia stessa classifica i materiali dell’indagine interna come documenti per uso interno e richiede espressamente di proteggere i dati personali nella creazione e nella trasmissione dei file.

Nella versione offline di prova i materiali del fascicolo, le trascrizioni, i risultati dell’analisi e il file Word restano sul computer. Il modello locale funziona tramite un indirizzo loopback e, una volta preparati i modelli necessari, la sessione di lavoro sul fascicolo può svolgersi senza alcun accesso a internet.

Ma anche qui non c’è nessuna magia. Lavorare in locale non significa anonimizzare in automatico. Se nel fascicolo si caricano nomi, cognomi e dati sanitari, questi resteranno su quel computer e negli allegati del fascicolo. Per questo servono le normali misure di sicurezza informatica: account protetto, diritti di accesso, regole di conservazione, backup e, se necessario, un ulteriore mascheramento.

In altre parole, la nostra evoluzione non si è conclusa con lo slogan «tutto offline, quindi tutto sicuro». È più corretto dirlo così: abbiamo eliminato l’invio superfluo di materiali all’esterno e abbiamo lasciato il controllo sui dati dove deve stare — all’interno dell’azienda.

Cosa usiamo oggi

Oggi di fatto abbiamo due flussi. Il primo è quello operativo: mascheriamo i materiali in locale, trasmettiamo la copia anonimizzata all’agente d’indagine configurato e poi smascheriamo in locale il risultato ottenuto. È proprio questo lo schema già utilizzabile nel lavoro reale.

Il secondo è quello di prova: un sistema interamente offline che trascrive da sé l’audio in locale, legge i materiali, aiuta a costruire la cronologia, le barriere e le cause e genera la prima bozza del rapporto. Funziona già, ma continuiamo a verificarlo e a migliorarlo. Per noi è una questione di principio: un progetto pilota non può essere spacciato per un sistema produttivo maturo solo perché si presenta bene.

Flusso operativo: strumento di mascheramento → agente IA d’indagine configurato → smascheramento.

Flusso di prova: postazione della commissione interamente locale → verifica e ulteriori iterazioni.

Il passo successivo: Fire, l’ambiente aziendale protetto

Parallelamente, il servizio IT del Gruppo sta sviluppando nell’ambiente aziendale Collab l’IA interna Fire. Per noi è il logico passo successivo: trasferire la logica metodologica dell’assistente della commissione in un ambiente aziendale protetto su server, dove non si è costretti a scegliere tra la potenza di un grande modello e i requisiti di riservatezza.

Non vediamo Fire come un «investigatore automatico», ma come un ulteriore ambiente in cui applicare lo stesso principio: i materiali restano all’interno di un’infrastruttura protetta, l’IA aiuta la commissione ad analizzare cronologia, barriere, contraddizioni e cause, e le decisioni continua a prenderle una persona.

Prima del trasferimento occorre verificare le capacità tecniche di Fire: gestione di documenti e audio, dimensione del contesto, controllo degli accessi, log, conservazione dei dati ed esportazione dei risultati. Anche qui, quindi, partiamo dalla metodologia e dalla protezione delle informazioni, non dal desiderio di usare a ogni costo l’ennesimo nuovo modello.

Guarda il video: il ciclo completo dell’indagine locale

In questo articolo ho scelto di proposito di non appesantire il testo con decine di schermate tutte uguali. Una registrazione dello schermo di tre minuti mostra meglio come gli elementi si collegano tra loro, cosa fa davvero la persona e cosa invece il programma.

Le schermate servono dove bisogna soffermarsi sull’architettura: tipi di materiali, cronologia, cause, azioni e documento Word finale. Il resto del meccanismo è meglio vederlo nel video, che trovate alla fine dell’articolo.

Dove si risparmia tempo

L’indagine su un incidente richiede comunque le persone: fare il sopralluogo, sentire i soggetti coinvolti, acquisire i documenti, discutere i fatti, prendere decisioni. Il senso del lavoro della commissione non si può automatizzare.

Ma si può eliminare buona parte della routine burocratica: la trascrizione a mano degli audio, il confronto delle dichiarazioni scritte, la ricerca manuale delle incongruenze temporali, il trasferimento delle citazioni nella cronologia, la prima mappatura delle barriere, la stesura dell’albero delle cause, la preparazione di un elenco provvisorio di misure e l’assemblaggio della prima bozza del rapporto.

E per me l’effetto principale non sta nel ridurre il numero di specialisti. Al contrario: se lo specialista dedica meno tempo al lavoro meccanico sui documenti, gli resta più tempo per ciò per cui l’indagine si fa davvero — parlare con le persone, lavorare sul campo, verificare le barriere e aiutare i responsabili a evitare che l’evento si ripeta.

Che cosa ne è uscito

In pochi anni il percorso è stato emblematico: agente cloud aperto → mascheramento manuale → strumento di mascheramento e smascheramento locale → trascrizione locale → sistema offline di prova → prossimo passo verso Fire, l’ambiente aziendale protetto.

Detto questo, lo strumento operativo di oggi non è la versione offline sperimentale, ma il flusso collaudato con mascheramento: i materiali originali restano da noi, all’agente va una versione anonimizzata e il ripristino avviene in locale. Il sistema offline lo stiamo testando e perfezionando passo dopo passo.

Il cambiamento più importante non è nemmeno tecnico. Abbiamo smesso di chiedere all’IA «di chi è la colpa?» e abbiamo cominciato a porre un’altra domanda: «quali dati mancano, quali barriere non hanno funzionato, perché non hanno funzionato e quali misure ridurranno davvero il rischio che si ripeta?»

È proprio in questo ruolo che l’IA è utile nelle indagini: non giudice né presidente della commissione, ma un secondo analista veloce che aiuta le persone ad approfondire i fatti.

E un’ultima cosa: non bisogna dimenticare l’intelligenza naturale

Più i modelli diventano potenti, più è importante non delegare loro il proprio pensiero. L’intelligenza artificiale è utile quando potenzia quella naturale: aiuta a vedere prima i collegamenti, a verificare un’ipotesi, a preparare una bozza e a liberare tempo per il dialogo con le persone e il lavoro sul campo.

Per questo, secondo me, la strada giusta è non essere semplici utenti di pulsanti preconfezionati, ma creatori di nuove soluzioni: capire la metodologia, definire l’architettura, verificare i risultati, correggere gli errori e crescere noi stessi insieme allo strumento.

L’IA va usata, ma la propria intelligenza naturale va esercitata e sviluppata altrettanto. E se questa combinazione aiuta a indagare più a fondo sugli eventi, a trarne insegnamenti migliori e a evitare che si ripetano, allora la tecnologia lavora davvero a favore della sicurezza.

I prompt dell’articolo

Flusso operativo con mascheramento → sistema offline di prova → prossimo passo verso Fire, l’ambiente aziendale protetto

Stato attuale: nel lavoro reale si usa il flusso «strumento di mascheramento locale → agente cloud configurato → smascheramento locale». Il sistema interamente offline è già stato sviluppato, ma è in fase di test e miglioramento. Fire è considerato la prossima fase: quella dell’ambiente aziendale protetto.

Prompt 1. L’attuale agente operativo: solo materiali anonimizzati

Collegamento con l’articolo: le sezioni «La terza versione» e «Cosa usiamo oggi». È il flusso operativo attualmente in uso dopo il mascheramento locale.

Sei l’assistente analitico della commissione d’indagine interna su un incidente in materia di salute e sicurezza sul lavoro e sicurezza industriale.

FLUSSO DI LAVORO:
I documenti originali vengono prima mascherati in locale. Ricevi solo copie anonimizzate. Dopo il tuo lavoro, il risultato viene smascherato in locale con una chiave e una password separate, che tu non possiedi.

IMPORTANTE:
- lavora solo con materiali anonimizzati in precedenza;
- non cercare di ricostruire nomi e cognomi, reparti, indirizzi o altri valori nascosti;
- non usare internet né fatti esterni, se non ti vengono forniti espressamente;
- non individuare colpevoli;
- non presentare un’ipotesi come fatto accertato;
- non sostituirti alla decisione della commissione.

Obiettivo: aiutare la commissione a strutturare i materiali e a verificare la completezza dell’indagine.

Per ogni conclusione distingui:
FACT — confermato direttamente dal materiale;
ASSUMPTION — supposizione fondata;
CONFLICT — contraddizione tra i materiali;
GAP — informazione mancante;
QUESTION — domanda a cui occorre dare risposta;
HYPOTHESIS — possibile causa che richiede conferma.

Procedura:
1. Redigi il registro dei materiali ricevuti.
2. Estrai solo i fatti verificabili, indicandone la fonte.
3. Redigi una cronologia preliminare.
4. Evidenzia contraddizioni e lacune.
5. Formula le domande aggiuntive per la commissione.
6. Dopo la conferma della cronologia, proponi l’analisi delle barriere.
7. Formula le cause solo come ipotesi, fino alla decisione della commissione.
8. Collega le azioni solo alle cause confermate.

In tutte le tabelle indica la fonte: numero del materiale, documento/file e una breve citazione o il punto esatto su cui si basa la conclusione.

Prompt 2. Cronologia degli eventi e fattori critici

Collegamento con l’articolo: la sezione sulla cronologia nell’agente operativo e nel sistema offline di prova.

Ti trasmetto i testi verificati dei materiali relativi all’incidente.

Genera una BOZZA di cronologia.

Regole:
1. Non aggiungere eventi che non compaiono nei materiali.
2. Se l’orario è esatto, indicalo come esatto.
3. Se l’orario è approssimativo, contrassegnalo come «indicativo».
4. Se due fonti riportano orari o sequenze diversi, non scegliere in silenzio una delle versioni; segnala CONFLICT.
5. Per ogni riga indica: data/ora; evento o condizione; fonte; stato FACT / ASSUMPTION / CONFLICT; perché è importante.
6. Proponi a parte un elenco di fattori critici: eventi/condizioni senza i quali l’evento indesiderato o la gravità delle conseguenze sarebbero stati, con ogni probabilità, diversi.
7. I fattori critici non vanno considerati approvati fino alla decisione della commissione.

Alla fine fornisci:
A. la bozza di cronologia;
B. l’elenco delle contraddizioni;
C. l’elenco dei dati mancanti;
D. la bozza dei fattori critici da discutere in commissione.

Prompt 3. Contraddizioni, lacune e piano delle interviste aggiuntive

Collegamento con l’articolo: le sezioni sulla pianificazione, sulla raccolta dei materiali e sul ruolo dell’IA come secondo analista.

Sulla base dei materiali e della bozza di cronologia, prepara un foglio di lavoro per la commissione.

Devi:
1. Trovare le contraddizioni tra dichiarazioni scritte, documenti, orari e dati tecnici.
2. Non interpretare una differenza di formulazione come una menzogna senza prove.
3. Per ogni contraddizione indicare: fonte A; fonte B; in che cosa consiste esattamente la differenza; cosa occorre verificare.
4. Formulare le domande per le interviste aggiuntive.
5. Le domande devono essere aperte e neutre, senza suggerire la risposta.
6. Elencare a parte i documenti, le misurazioni, le perizie, le foto o gli schemi che possono colmare la lacuna.
7. Indicare quali domande sono critiche per accertare le circostanze, le barriere di protezione, le cause e la gravità delle conseguenze.

Non concludere che una testimonianza sia inattendibile solo perché presenta una contraddizione.

Prompt 4. La logica delle barriere e il «bow-tie»

Collegamento con l’articolo: la sezione sulla logica delle barriere e sul passaggio alle cause.

Usa la cronologia e i fattori critici confermati dalla commissione.

Genera una BOZZA di analisi delle barriere.

1. Sorgente/i di pericolo.
2. Evento indesiderato.
3. Conseguenze.
4. Barriere preventive: quale barriera avrebbe dovuto prevenire l’evento/il contatto; se esisteva; se era disponibile; se veniva applicata; se ha funzionato; fonte di conferma.
5. Barriere di mitigazione: quale barriera avrebbe dovuto prevenire le conseguenze o ridurne la gravità; se esisteva; se ha funzionato; fonte di conferma.
6. Per ogni barriera assente o inefficace formula la domanda «Perché?».

Non definire automaticamente l’assenza di una barriera come causa radice.
Non inventare barriere che non compaiono nella metodologia, nei documenti o nella logica del processo tecnologico senza contrassegnarle come HYPOTHESIS.

Il risultato è una tabella da discutere in commissione, non una conclusione approvata.

Prompt 5. Albero delle cause e cause radice

Collegamento con l’articolo: la sezione «La metodologia è diventata più rigorosa» e il blocco sulle cause.

In ingresso:
- cronologia confermata;
- fattori critici;
- analisi delle barriere;
- decisioni della commissione sui fatti confermati.

Costruisci una BOZZA di albero delle cause.

Punto di partenza: «Evento indesiderato + conseguenze».
I primi due rami:
A. Perché si è verificato l’evento indesiderato?
B. Perché si sono avute queste conseguenze / perché la loro gravità è stata questa?

Poi:
1. Per ogni nodo chiedi «Perché?» tutte le volte necessarie per arrivare alla causa sistemica.
2. Collega ogni causa alla domanda da cui deriva.
3. Ogni fattore critico deve trovare riscontro nell’albero oppure essere spiegato a parte come escluso.
4. Non considerare causa radice un’azione/errore umano. Prosegui l’analisi: perché quell’azione è stata possibile o ritenuta accettabile.
5. Proponi una causa radice solo se descrive una carenza concreta del processo/sistema; può essere eliminata; rientra nell’ambito di controllo dell’azienda/del Gruppo; consente di proporre una misura concreta.
6. Sono vietate formulazioni generiche prive di spiegazione: «scarsa cultura», «imprudenza personale», «cattiva organizzazione», «carenze nella formazione».

Per ogni nodo:
- formulazione;
- tipo: immediata / intermedia / candidata a causa radice;
- fonti di conferma;
- fattori critici correlati;
- stato FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION.

Non confermare una causa radice al posto della commissione.

Prompt 6. Azioni correttive e preventive

Collegamento con l’articolo: la sezione sulle azioni e sul risparmio di tempo nella preparazione della prima bozza.

Usa solo le cause che la commissione ha deciso di includere nell’elenco per la definizione delle misure.

Per ogni causa proponi 2–4 possibili azioni.

Per ogni opzione indica:
- quale causa concreta elimina o quale barriera rafforza;
- tipo: tecnica / organizzativa / formazione / controllo / altro;
- risultato atteso verificabile;
- come verificarne l’efficacia;
- ambito di estensione: luogo dell’evento / siti analoghi / azienda / Gruppo;
- se serve una misura di protezione temporanea fino all’attuazione di quella definitiva;
- possibili rischi collaterali;
- quali dati servono per stabilire la scadenza e il responsabile.

Non indicare il nome del responsabile né una scadenza concreta senza una decisione della commissione.
Non proporre un’azione del tipo «effettuare un briefing di sicurezza straordinario» come soluzione universale, se non elimina la causa accertata.
Segnala a parte le azioni che si limitano a rafforzare i controlli ma non eliminano la causa radice.

Prompt 7. Bozza del rapporto finale secondo la metodologia

Collegamento con l’articolo: la sezione sulla generazione del file Word e sul principio «prima bozza, non documento da firmare».

Prepara una BOZZA di testo del rapporto interno basata esclusivamente sugli elementi approvati dalla commissione.

Usa:
- la scheda dell’incidente;
- la cronologia confermata;
- l’elenco dei fattori critici;
- l’analisi delle barriere approvata;
- l’albero delle cause definitivo;
- l’elenco approvato delle cause;
- le azioni concordate;
- il registro dei materiali.

Non includere come fatti nel testo finale ipotesi non confermate, versioni controverse non contrassegnate e conclusioni prive di fonte.

Struttura:
1. Informazioni sintetiche e circostanze.
2. Materiali e metodi di raccolta delle informazioni.
3. Cronologia.
4. Fattori critici.
5. Barriere di protezione.
6. Analisi delle cause.
7. Cause radice.
8. Azioni correttive e preventive.
9. Allegati / registro dei materiali.

Ove possibile, accanto a ogni conclusione rilevante mantieni il riferimento al materiale su cui si basa.
Nella parte superiore del documento indica: «BOZZA. Da verificare e approvare da parte della commissione».
Non formulare conclusioni sulla colpevolezza.

Prompt 8. Master prompt per il sistema offline di prova

Collegamento con l’articolo: la sezione «Il sistema offline esiste già — ora lo stiamo testando».

Non sono un programmatore. Aiutami a creare un’applicazione locale DI PROVA per l’indagine interna sugli incidenti secondo la metodologia aziendale. L’obiettivo di questa fase è un pilota con verifica della qualità, non la messa in produzione automatica.

Lavora passo dopo passo. A ogni passo:
1. spiega cosa facciamo e perché;
2. dammi una sola azione o un solo file/patch pronto;
3. attendi il mio risultato o una schermata;
4. verificalo;
5. solo dopo passa al passo successivo.

ARCHITETTURA DI DESTINAZIONE
- Windows 10/11;
- backend locale su 127.0.0.1 e interfaccia nel browser;
- dopo la preparazione una tantum dei modelli, lavoro sui materiali del fascicolo senza internet;
- prevedere il funzionamento su un computer di lavoro potente; per una macchina poco potente proporre un modello più leggero, senza nascondere il calo di qualità/velocità;
- archiviazione locale dei fascicoli;
- archivio del fascicolo con checksum;
- storico delle versioni;
- nessun invio obbligatorio di materiali ad API esterne.

MATERIALI
- DOCX: paragrafi, tabelle, intestazioni e piè di pagina;
- PDF con testo;
- PDF scansionati / immagini — riconoscimento locale;
- schemi / fotografie — conservare l’originale e proporre una descrizione solo come bozza;
- audio / video — trascrizione locale;
- registrazione dal microfono;
- inserimento e modifica manuali;
- contrassegno obbligatorio «verificato sull’originale» prima di usare il testo nell’analisi IA.

MODELLI LOCALI
- LLM tramite un motore locale (per esempio Ollama);
- modello vocale multilingue Whisper;
- se necessario, un modello vision locale;
- l’applicazione non deve scaricare modelli di nascosto durante l’indagine.

METODOLOGIA / FASI
1. Informazioni iniziali.
2. Piano della commissione.
3. Raccolta dei materiali.
4. Cronologia e fattori critici.
5. Barriere e cause.
6. Azioni.
7. Rapporto.

REGOLE PER L’IA
- L’IA si limita a proporre.
- Ogni conclusione conserva fonte e citazione.
- Distinguere FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS.
- Le cause sono ipotesi fino alla conferma della commissione.
- Il modello non assegna da sé responsabili e scadenze.
- La commissione deve poter accettare, respingere o modificare ogni proposta.
- Il file Word finale è una bozza modificabile.
- Il rapporto deve includere l’albero delle cause, le barriere, il registro e gli allegati.

SICUREZZA
- niente CDN né telemetria esterna;
- connessioni di rete dell’indagine solo in loopback;
- mostrare all’utente che lavorare in locale non equivale ad anonimizzare in automatico;
- non conservare segreti in chiaro nel codice lato client;
- prevedere l’eliminazione del fascicolo, il backup e il trasferimento.

Inizia dall’architettura delle cartelle, dal formato dei dati del fascicolo e dal modello delle minacce. Non scrivere codice finché non ti do conferma.

STATO PILOTA
- contrassegna esplicitamente la versione come «DI PROVA / PILOTA»;
- aggiungi un set di casi didattici di controllo;
- per ogni caso confronta il risultato dell’IA con le conclusioni della persona/della commissione;
- tieni un registro dei difetti riscontrati e delle iterazioni;
- non definire il sistema pronto per l’uso in produzione prima della conclusione dei test.

Prompt 9. Audit del sistema offline pilota

Collegamento con l’articolo: le sezioni sui limiti dell’automazione, sulla riservatezza e sull’attuale stato di prova.

Esegui un audit dell’applicazione finita e della bozza d’indagine prima di consegnarle alla commissione.

VERIFICA TECNICA
1. Ci sono connessioni di rete esterne durante il lavoro sul fascicolo?
2. Vengono usati CDN, font esterni, speech-to-text in cloud, API esterne?
3. Dove sono conservati i file originali, le trascrizioni, i modelli locali e i backup?
4. Cosa succede quando si elimina un fascicolo?
5. I documenti originali finiscono nei log di diagnostica?
6. Il contenuto del fascicolo viene inviato all’esterno in caso di errore?

VERIFICA METODOLOGICA
7. Tutte le conclusioni rilevanti hanno una fonte?
8. I fatti sono separati dalle ipotesi?
9. Tutti i fattori critici trovano riscontro nell’analisi delle cause?
10. Le azioni umane sono state indicate come causa radice senza analizzare le condizioni sistemiche?
11. Le azioni sono collegate a cause/barriere concrete?
12. Il modello ha assegnato responsabili e scadenze senza una decisione della commissione?
13. La bozza del rapporto viene presentata come documento approvato?

VERIFICA DELLA RISERVATEZZA
14. Quali dati personali/sanitari si trovano nel fascicolo locale?
15. Serve un ulteriore mascheramento per dimostrazioni, pubblicazione o trasmissione?
16. I nomi dei file e le schermate contengono nomi e cognomi superflui?

Presenta il risultato in una tabella:
Verifica | Stato | Rischio rilevato | Cosa correggere | Chi deve confermare.

Non correggere automaticamente le conclusioni di merito dell’indagine.

VERIFICA DEL LIVELLO DI MATURITÀ
17. Esiste un set di casi di controllo con i risultati del confronto?
18. Quali funzioni sono già stabili e quali restano sperimentali?
19. Quali errori/limiti devono essere eliminati prima dell’uso in produzione?
20. L’interfaccia crea la falsa impressione che il risultato dell’IA sia una decisione della commissione?

Come usare i prompt

• Prompt 1 — il flusso operativo di oggi: solo materiali anonimizzati in precedenza; la chiave di smascheramento non viene trasmessa all’agente.
• Prompt 2–7 — blocchi di lavoro metodologici, utilizzabili sia nell’agente attuale sia nel futuro ambiente locale/su server.
• Prompt 8 — creazione e ulteriore sviluppo del sistema di prova interamente offline.
• Prompt 9 — audit del pilota prima di estenderne l’impiego.

Il principio di fondo della serie resta lo stesso: prima proteggiamo i dati e definiamo la metodologia, poi automatizziamo. L’IA potenzia il lavoro della commissione, ma non fa venir meno il pensiero professionale, la verifica dei fatti e la responsabilità umana.