A partire dalla versione 1.1, CertiSigma Prudentia Suite è distribuita come **pacchetto
a due edizioni interoperabili**, aperte da un selettore di prodotto
comune (index.html nella cartella radice del pacchetto):

Italy / Switzerland — edizione in lingua italiana, con perimetro
giurisdizionale Italia, Svizzera, Europa/UE-SEE e cross-border
Svizzera↔Europa. È l'edizione descritta in questo manuale.
Europe / Switzerland — edizione in lingua inglese, con perimetro
Europa/UE-SEE, Svizzera e cross-border, dove l'Italia compare come
uno dei Paesi selezionabili nel catalogo UE/SEE e non come perimetro
dedicato.

Le due edizioni sono prodotti autonomi, non l'una la traduzione
dell'altra: hanno cataloghi, esempi ed enfasi giurisdizionale propri.
Condividono però una base tecnica comune — contenuta nella cartella
common/ del pacchetto — che mantiene allineati gli identificatori
macchina (schema, categorie, vettori, settori, mapping) tra le due
lingue, così che gli export prodotti da un'edizione restino
riconoscibili anche da un operatore che lavora sull'altra. Il
funzionamento di questo livello condiviso è descritto nel dettaglio nel
capitolo 5.

Questo manuale descrive in modo puntuale campi, etichette ed esempi
dell'edizione Italy / Switzerland. Un operatore che lavora
sull'edizione Europe / Switzerland troverà la stessa logica
operativa, con due differenze da tenere presenti: l'interfaccia e gli
esempi sono in inglese, e il perimetro giurisdizionale non prevede
l'Italia come opzione autonoma. Dove questa differenza è rilevante per
l'uso del modulo, il manuale la segnala esplicitamente.

CertiSigma Prudentia Suite parte da una premessa scomoda: anche un'organizzazione seria,
competente e diligente può subire un danno.

Questo punto deve essere chiaro fin dall'inizio della formazione. Una
violazione, una compromissione, una manipolazione, una fuga di dati, un
errore umano indotto o un abuso di strumenti legittimi possono colpire
anche realtà che hanno investito in sicurezza, compliance, procedure,
formazione, consulenti, strumenti di detection e attività di patching.

La trasformazione delle minacce rende sempre meno realistico immaginare
che un'organizzazione possa evitare ogni incidente. L'intelligenza
artificiale accelera la produzione di attacchi, varianti, messaggi
credibili, documenti falsi, interazioni personalizzate, script,
simulazioni e catene operative. Gli agenti software possono essere
manipolati, istruiti male, dirottati o indotti ad agire in modo diverso
da quello previsto. Strumenti nati per proteggere, testare o
diagnosticare sistemi possono essere riusati per violare, persistere,
confondere, estrarre o forzare.

Questa realtà non trasforma automaticamente l'organizzazione in
colpevole. Trasforma il modo in cui l'organizzazione deve prepararsi.

La domanda centrale diventa: quando qualcosa accadrà, saremo capaci di
riconoscerlo, contenerlo, ragionarci sopra, simulare scenari plausibili,
comunicare senza aggravare il danno e usare l'AI senza consegnarle più
informazioni del necessario?

La prevenzione resta essenziale, ma il suo significato cambia. Prevenire
non vuol dire più soltanto impedire ogni evento. Vuol dire anche evitare
che un evento possibile diventi ingestibile, che un dubbio diventi
panico, che un'ipotesi diventi dichiarazione, che una comunicazione
prematura diventi responsabilità aggiuntiva, che una richiesta all'AI
diventi esposizione inutile.

CertiSigma Prudentia Suite nasce dentro questa nuova postura: accettare che il danno può
arrivare e prepararsi a non peggiorarlo.

Per anni molte organizzazioni hanno ragionato come se la sicurezza fosse
soprattutto una questione di chiusura: chiudere vulnerabilità,
aggiornare sistemi, rafforzare credenziali, segmentare reti, formare
utenti, monitorare eventi e reagire agli alert.

Tutto questo resta necessario. Da solo, però, basta sempre meno.

Le minacce contemporanee agiscono contro i sistemi e, insieme, contro le
relazioni tra sistemi, persone, fornitori, strumenti automatici, agenti
software, procedure interne e canali di comunicazione. Un attacco può
presentarsi come richiesta plausibile, documento ben scritto, modifica
apparentemente autorizzata, comportamento anomalo ma non subito
classificabile, oppure catena di piccoli eventi che singolarmente
sembrano spiegabili.

L'intelligenza artificiale rende più fragile questa zona intermedia.
Permette di generare messaggi credibili, varianti rapide, istruzioni
operative, imitazioni di tono, codice, script, spiegazioni tecniche e
richieste personalizzate. Riduce il costo dell'inganno e aumenta la
velocità con cui un attore ostile può sperimentare.

In questo scenario, l'organizzazione può avere fatto molto e subire
comunque un impatto.

Il punto formativo è decisivo: CertiSigma Prudentia Suite non deve essere presentata come
uno strumento che promette invulnerabilità. Deve essere presentata come
uno strumento che aiuta a conservare lucidità quando l'invulnerabilità
non è più una promessa credibile.

Quando avviene una violazione, la reazione istintiva è cercare subito un
colpevole: un sistema rimasto indietro, un utente distratto, un
fornitore debole, una policy incompleta, un controllo mancato.

Questa ricerca può diventare necessaria. In alcuni casi emergono davvero
errori, omissioni, scelte discutibili o responsabilità precise. La
valutazione, però, deve avvenire attraverso evidenze, contesto,
ragionevolezza delle misure, tempi di reazione, qualità delle decisioni
e coerenza delle comunicazioni.

Un breach, da solo, dimostra che qualcosa è accaduto. La colpa richiede
ricostruzione.

Questa distinzione protegge l'organizzazione da due errori opposti:
negare troppo presto oppure confessare implicitamente ciò che non è
ancora stato accertato. Entrambi gli errori possono aggravare il caso.
Il primo mina credibilità e trasparenza; il secondo trasforma
l'incertezza in ammissione impropria.

CertiSigma Prudentia Suite assume una posizione operativa: prima si ricostruisce, poi si
qualifica; prima si distingue, poi si comunica; prima si misura ciò che
manca, poi si decide quanto dire e a chi.

L'operatore deve imparare a restare dentro questa sequenza anche quando
la pressione aumenta. La responsabilità non si governa nel panico. Si
governa lasciando tracce ordinate del ragionamento, delle evidenze
disponibili, dei limiti conoscitivi e delle validazioni richieste.

L'intelligenza artificiale non introduce soltanto nuovi attacchi. Cambia
scala, frequenza e forma degli attacchi possibili.

Un messaggio malevolo può essere personalizzato meglio. Un falso
documento può risultare coerente con lo stile dell'organizzazione.
Un'interazione può adattarsi al ruolo della persona che la riceve. Una
campagna può produrre molte varianti con costi minori. Uno strumento
tecnico può essere usato da soggetti meno esperti. Un agente software
può essere manipolato attraverso istruzioni, contesto o dati
apparentemente innocui.

Anche gli strumenti di sicurezza possono diventare ambigui. Tool nati
per testare, verificare, automatizzare, cercare vulnerabilità o simulare
comportamenti ostili possono essere riutilizzati per bucare, non solo
per sistemare. La distinzione tra uso difensivo e uso offensivo dipende
dal contesto, dall'intenzione e dalla catena operativa in cui lo
strumento viene inserito.

In parallelo, molte organizzazioni stanno introducendo AI e agenti
automatici nei processi quotidiani. Questi strumenti assistono,
sintetizzano, classificano, suggeriscono, preparano testi, interrogano
dati, collegano fonti, aiutano operatori e manager.

Questa simbiosi aumenta produttività e velocità, ma introduce una
responsabilità nuova: mediare ciò che viene comunicato all'AI.

Ogni prompt è una scelta di esposizione. Ogni documento caricato è una
scelta di perimetro. Ogni ipotesi formulata è una scelta di
rappresentazione. Ogni output generato richiede una decisione
successiva: usarlo, correggerlo, validarlo, limitarlo o scartarlo.

Prompt Builder nasce per questo: non per rendere l'AI onnisciente, ma
per rendere più controllata la richiesta che l'organizzazione le
rivolge.

La trasformazione delle minacce riguarda i sistemi e, in modo ancora più
delicato, gli esseri umani.

Per molto tempo le organizzazioni hanno formato le persone a riconoscere
segnali relativamente semplici: e-mail scritte male, traduzioni incerte,
domini sospetti, allegati improbabili, messaggi fuori tono, urgenze
formulate in modo rozzo, pagine bancarie graficamente approssimative.

Quei segnali restano utili quando compaiono. La nuova fase, però,
produce attacchi che spesso non li presentano.

Oggi un sito falso può essere più curato del sito vero. Una pagina di
login può riprodurre perfettamente linguaggio, grafica, flussi, colori,
avvisi, schermate e microtesti di una banca o di un fornitore. Una
e-mail fraudolenta può essere scritta nella lingua corretta, con tono
professionale, riferimenti plausibili e stile coerente con
l'organizzazione.

Il phishing ingenuo, riconoscibile perché contiene errori evidenti,
rappresenta solo una parte del problema. L'intelligenza artificiale
consente di produrre messaggi puliti, localizzati, convincenti, adattati
al destinatario e al contesto.

La formazione deve quindi cambiare bersaglio.

Una comunicazione scritta bene può essere sospetta.
Un sito perfetto può essere una replica ostile.
Una voce familiare può essere simulata.
Un volto riconoscibile può essere generato o manipolato.
Una richiesta plausibile può essere costruita proprio per sembrare
normale.

Una delle immagini più forti della nuova fase è quella del dirigente,
del presidente o dell'amministratore che appare in video e chiede a un
contabile, a un responsabile finanziario o a una funzione amministrativa
di eseguire bonifici urgenti e rilevanti. Il problema non riguarda
soltanto la falsità tecnica del video. Riguarda il fatto che
l'organizzazione deve essere pronta a non fondare una decisione
economica, legale o operativa sulla sola apparenza di autenticità.

La fiducia personale resta importante, ma da sola non può più bastare
come controllo.

Le minacce più efficaci spesso sembrano normali.

Una richiesta urgente può assomigliare a molte richieste urgenti già
ricevute.
Un cambio IBAN può inserirsi in una conversazione reale con un
fornitore.
Una pagina bancaria falsa può comparire nel momento in cui l'utente si
aspetta davvero di accedere alla banca.
Un messaggio del management può arrivare con tono coerente.
Un file può avere un nome plausibile.
Una richiesta MFA può apparire dentro un flusso ordinario di lavoro.
Un agente automatico può rispondere in modo apparentemente utile, ma
sulla base di istruzioni manipolate.

L'attacco non chiede sempre alla vittima di fare qualcosa di assurdo.
Spesso le chiede di fare qualcosa di compatibile con il suo ruolo.

Il contabile fa bonifici. L'HR gestisce documenti personali. Il legale
riceve bozze e allegati. L'IT apre ticket e verifica accessi. Il
customer care risponde a richieste. Il management chiede sintesi rapide.
Il fornitore manda aggiornamenti. Il consulente chiede materiali.

Quando l'attacco entra dentro azioni già normali, la difesa non può
basarsi soltanto sul sospetto individuale. Deve basarsi su procedure di
conferma, separazione dei canali, soglie di autorizzazione,
tracciabilità delle richieste, pause obbligatorie e diritto di dubitare.

Una buona organizzazione protegge chi si ferma a verificare.

La postura umana richiesta dalla nuova fase è questa: l'operatore deve
avere il diritto, e in certi casi il dovere, di dubitare anche davanti a
segnali apparentemente convincenti.

Dubitare significa impedire che urgenza, autorità, familiarità o
pressione emotiva sostituiscano una verifica.

Una richiesta economica anomala merita conferma su un canale
separato.
Una richiesta proveniente da una figura apicale richiede controlli
proporzionati proprio perché può produrre effetti rilevanti.
Una comunicazione perfetta va valutata anche per canale, contesto e
coerenza procedurale.
Un sito identico a quello conosciuto va verificato prima di inserire
credenziali o autorizzare operazioni.
Un video convincente non dovrebbe bastare per autorizzare un'azione
irreversibile.
Una risposta fluida dell'AI deve essere trattata come materiale da
verificare, non come decisione.

La formazione deve spostarsi dal riconoscimento dell'errore evidente al
governo della fiducia.

La vecchia domanda era: "vedo qualcosa di strano?".
La nuova domanda è: "*questa richiesta merita una verifica
indipendente anche se sembra normale?*".

Questo passaggio è decisivo, perché le minacce migliori sono costruite
proprio per apparire plausibili.

Molti attacchi funzionano perché comprimono il tempo.

Chiedono di agire subito, invocano riservatezza, usano l'autorità di una
persona importante, sfruttano la paura di creare un problema, fanno
sembrare la verifica un intralcio e presentano il dubbio come mancanza
di collaborazione.

L'organizzazione deve insegnare l'opposto: quando una richiesta è
urgente, importante, riservata e proveniente da una figura autorevole, i
controlli devono salire.

La pressione non è una ragione per saltare la procedura; è un indicatore
che la procedura serve.

Questo vale per pagamenti, accessi, condivisione di dati, apertura di
allegati, comunicazione di credenziali, caricamento di documenti in
strumenti AI, dichiarazioni verso l'esterno e ogni azione difficilmente
reversibile.

Una cultura matura non colpevolizza chi rallenta per verificare. Gli dà
permesso, metodo e copertura organizzativa.

La formula da insegnare agli operatori è semplice: se una richiesta è
troppo urgente per essere verificata, è proprio quella che deve essere
verificata.

Un'altra illusione da superare riguarda l'aggiornamento continuo.

In astratto, aggiornare è giusto. Applicare patch è necessario. Ridurre
la superficie di attacco resta una priorità.

Molte organizzazioni, però, vivono dentro vincoli materiali: sistemi
legacy, ambienti industriali, infrastrutture critiche, servizi
continuativi, dipendenze da fornitori, applicazioni che richiedono
riavvio, finestre di manutenzione limitate, contratti, procedure,
impatti operativi.

Alcuni sistemi non possono essere spenti in qualunque momento. Alcune
patch richiedono test, finestre autorizzate, rollback, coordinamento con
fornitori o valutazioni di continuità.

Alcune vulnerabilità restano temporaneamente aperte perché il costo di
un intervento immediato può produrre danni maggiori o perché
l'organizzazione deve preparare una mitigazione intermedia.

Questa situazione richiede disciplina, non fatalismo.

Quando la patch immediata non è praticabile, diventano essenziali
compensazione, priorità, contenimento, tracciabilità, comunicazione
interna e decisione documentata. Bisogna sapere chi decide, che cosa è
stato visto, quali sistemi sono coinvolti, quali mitigazioni temporanee
sono possibili, quali evidenze devono essere conservate, quali
comunicazioni devono essere evitate e quali scenari devono essere
simulati.

CertiSigma Prudentia Suite non sostituisce il lavoro tecnico. Aiuta a rendere più
ordinato il lavoro umano intorno al vincolo tecnico.

Se il danno può arrivare, simulare diventa una pratica fondamentale.

Una simulazione utile non mette in scena solo incidenti generici,
rassicuranti o già noti. Deve allenare l'organizzazione su schemi nuovi,
forme ibride, casi ambigui, eventi che non si presentano subito come
incidenti.

Una buona simulazione chiede che cosa accade se il primo segnale è
debole, se il fornitore non risponde, se l'AI interna ha ricevuto
informazioni non minimizzate, se il management chiede una sintesi prima
che i fatti siano chiari, se una comunicazione esterna viene preparata
troppo presto, se un tool difensivo viene usato contro l'organizzazione,
se un sistema vulnerabile non può essere riavviato, se l'evento non
rientra nelle categorie ordinarie della procedura.

Drill serve a questo: non a certificare che l'organizzazione è pronta,
ma a scoprire dove non lo è ancora.

Il valore dell'esercizio non sta nella tranquillità che produce. Sta
nelle frizioni che rivela. Se durante una simulazione emergono dubbi,
vuoti, ritardi, ruoli sovrapposti, escalation confuse o comunicazioni
premature, l'esercizio ha funzionato.

Ha mostrato prima ciò che altrimenti sarebbe emerso durante il danno
reale.

In molte organizzazioni l'AI è ormai trattata come uno strumento di
lavoro quotidiano. Si chiede all'AI di riassumere, classificare,
scrivere, riformulare, spiegare, confrontare, preparare bozze, generare
domande, produrre sintesi per il management o per funzioni tecniche.

Questo rende necessario un cambio di postura: comunicare qualcosa a
un'AI è già una decisione.

Quando un operatore inserisce informazioni in un LLM, sta scegliendo
quali dati esporre, quale contesto fornire, quali ipotesi rendere
disponibili, quali limiti dichiarare, quali elementi omettere e quale
tipo di risposta autorizzare. Anche quando lo strumento è aziendale,
integrato o apparentemente sicuro, resta necessario chiedersi se
l'informazione sia proporzionata rispetto allo scopo.

La domanda corretta non è soltanto come ottenere la risposta migliore
dall'AI. È come ottenere un aiuto utile comunicando il minimo
necessario, nel modo meno identificativo possibile e senza trasformare
l'output in una decisione automatica.

Prompt Builder nasce per mediare questo passaggio. Il suo scopo non è
rendere l'AI più informata possibile, ma rendere più controllata la
richiesta. Aiuta l'operatore a definire contesto, livello di certezza,
azioni già svolte, destinatario operativo, limiti dell'output, cautele e
informazioni da non inferire.

Questa mediazione diventa tanto più importante quanto più l'AI lavora in
simbiosi con l'azienda. Più l'AI entra nei processi, più occorre
governare ciò che le viene detto.

Uno strumento portatile è utile perché può essere aperto rapidamente,
anche fuori dai grandi ambienti aziendali, anche in una fase iniziale,
anche quando l'organizzazione vuole ragionare prima di caricare il caso
dentro un sistema centrale o condividere materiale con soggetti esterni.

Proprio questa portabilità richiede più disciplina.

L'operatore deve evitare di usare CertiSigma Prudentia Suite come deposito indistinto del
caso. La suite deve funzionare come camera di compensazione: entra solo
ciò che serve per capire il perimetro, individuare i vuoti, preparare
una richiesta esterna, costruire un esercizio o generare un prompt
controllato.

Quando il caso riguarda persone, clienti, dipendenti, fornitori, sistemi
identificabili o possibili violazioni, l'operatore deve preferire
descrizioni minimizzate, pseudonimizzate o astratte, salvo che un
dettaglio identificativo sia indispensabile alla decisione.

La presenza del vault cifrato migliora la protezione del salvataggio
locale. La responsabilità dell'operatore, però, resta intatta. La
cifratura non trasforma un dato inutile in un dato necessario, e la
passphrase non sostituisce il giudizio.

La regola formativa è questa: CertiSigma Prudentia Suite deve aiutare a ridurre il
materiale, non ad accumularlo.

La postura dell'operatore Prudentia può essere riassunta così: prima di
produrre un output, bisogna qualificare la situazione.

Questo vale in tutti e tre i moduli.

In Blindspot l'operatore cerca ciò che manca, ciò che è fragile, ciò che
potrebbe essere stato ignorato.

In Drill mette alla prova ruoli, tempi, decisioni e comunicazioni per
vedere dove la prontezza dichiarata si rompe.

In Prompt Builder costruisce una richiesta controllata, limitata,
verificabile, con un destinatario diretto chiaro: l'AI o il LLM.
L'eventuale riuso della risposta verso management, fornitori, autorità,
clienti o altri soggetti resta una decisione dell'operatore e
dell'organizzazione.

Questa postura è importante perché l'AI tende a colmare i vuoti. Se il
caso è ambiguo, produce continuità. Se mancano dati, formula ipotesi. Se
l'utente chiede sicurezza, spesso offre un tono sicuro. Nei contesti di
evidenza, sicurezza, incidenti, responsabilità e comunicazione, il tono
sicuro può diventare più pericoloso dell'incertezza dichiarata.

L'operatore deve quindi usare l'AI come interlocutore da vincolare, non
come autorità da seguire. Può chiedere aiuto per ordinare, distinguere,
elencare ipotesi, preparare domande, produrre bozze caute ed evidenziare
rischi. La qualificazione finale del fatto, la decisione normativa, la
comunicazione esterna e l'attribuzione di responsabilità restano fuori
dalla delega automatica.

In una situazione critica, il primo dovere dell'operatore è evitare di
peggiorare il caso.

Un caso peggiora quando vengono inviati dati non necessari a strumenti
esterni, quando un'ipotesi viene trattata come fatto, quando si
rassicura troppo presto, quando si comunica senza sapere chi deve
validare, quando si confonde un'anomalia tecnica con un incidente già
qualificato, quando si cancella o disperde evidenza, quando l'urgenza
spinge a saltare ruoli, responsabilità e cautele.

CertiSigma Prudentia Suite deve essere usata per ridurre questi errori. Non promette di
dire che cosa sia vero. Aiuta a costruire le condizioni minime perché
una decisione successiva sia più ordinata, più prudente e più
spiegabile.

Il linguaggio dell'operatore deve restare disciplinato.

Le formule più sane sono spesso:

"allo stato", "sulla base delle informazioni disponibili", "*da
confermare", "ipotesi", "evidenza mancante", "decisione
provvisoria", "validazione richiesta", "da non usare in
comunicazioni esterne senza revisione*".

Queste espressioni sono igiene operativa. Servono a proteggere
l'organizzazione dalla tentazione di sembrare più certa di quanto sia
davvero.

CertiSigma Prudentia Suite può essere usata su casi reali, su casi derivati da casi reali
o su scenari costruiti per esercizio. La distinzione è essenziale.

Un caso reale riguarda una situazione effettiva, con persone, sistemi,
dati, responsabilità e possibili conseguenze. Qui l'operatore deve
applicare la massima minimizzazione, evitare identificativi non
necessari, rispettare procedure interne, coinvolgere i ruoli competenti
e trattare ogni output come materiale provvisorio da validare.

Un caso derivato da un caso reale conserva la struttura del problema ma
rimuove o astrae elementi identificativi. È spesso il formato migliore
per formazione, confronto interno, simulazione e preparazione di
richieste verso strumenti esterni. Consente di lavorare sul ragionamento
senza esporre inutilmente il dossier.

Un caso di esercizio è costruito per allenare ruoli, tempi,
comunicazioni e decisioni. Serve a far emergere in modo sicuro ciò che
potrebbe non funzionare sotto pressione.

L'operatore competente sa scegliere il livello giusto. Porta un caso
reale completo solo quando è davvero necessario. Preferisce un caso
derivato quando l'obiettivo è ragionare, formare o simulare. Tratta
l'esercizio come allenamento, non come prova definitiva di conformità.

L'operatore Prudentia facilita una decisione migliore, senza diventare il
proprietario di tutte le decisioni.

Questo significa riconoscere i limiti del proprio ruolo. Un operatore
può preparare una mappa dei dubbi, un verbale di esercizio, una
richiesta controllata a un LLM, una sintesi delle evidenze mancanti, una
lista di validazioni necessarie. Quando entrano in gioco obblighi
legali, comunicazioni regolamentari, gestione tecnica dell'incidente,
rapporti con autorità, clienti, lavoratori, fornitori o management,
devono essere coinvolte le funzioni competenti.

La qualità dell'operatore non si misura dalla velocità con cui produce
un documento. Si misura dalla capacità di sapere quando fermarsi e
chiedere validazione.

Un buon operatore Prudentia lascia tracce comprensibili: che cosa era noto,
che cosa era incerto, quali dati sono stati esclusi, quale modulo è
stato usato, quale output è stato generato, quale parte è stata validata
e quale parte resta provvisoria.

Questa tracciabilità serve a difendersi dopo, ma soprattutto a non
perdere il filo durante.

CertiSigma Prudentia Suite nasce da tre esigenze collegate.

La prima è accettare che il danno può accadere anche in organizzazioni
diligenti. La prevenzione resta necessaria, ma non basta come unica
postura.

La seconda è simulare scenari nuovi, realistici, ibridi, in cui AI,
agenti, fornitori, strumenti tecnici, comunicazioni e vincoli operativi
si combinano in modi non sempre previsti dalle procedure tradizionali.

La terza è mediare il rapporto tra organizzazione e AI, evitando che la
ricerca di velocità produca esposizione inutile, inferenze indebite o
comunicazioni premature.

Blindspot aiuta a vedere ciò che manca prima di decidere.
Drill aiuta a simulare come il danno potrebbe svilupparsi.
Prompt Builder aiuta a formulare richieste controllate verso un'AI
o un LLM.

La suite non promette invulnerabilità. Promette qualcosa di più
realistico e, oggi, più utile: ridurre l'improvvisazione quando
l'invulnerabilità non è più credibile.

L'operatore deve entrare in CertiSigma Prudentia Suite con questa consapevolezza: il suo
compito non è dimostrare che l'organizzazione non subirà mai un danno.
Il suo compito è aiutare l'organizzazione a non essere impreparata
quando il danno, o il sospetto di danno, arriverà.

Questo significa allenarsi prima, ragionare meglio durante, comunicare
con più cautela e usare l'AI senza consegnarle più del necessario.

La sicurezza non è più solo evitare l'evento. È anche conservare
lucidità quando l'evento diventa possibile, probabile o già avvenuto.

L'operatore che usa bene CertiSigma Prudentia Suite non è quello che produce più testo. È
quello che produce meno confusione.

CertiSigma Prudentia Suite funziona localmente nel browser. Non richiede account,
autenticazione, server applicativi, database remoti o upload del caso
verso un servizio centrale.

Questa scelta architetturale è parte integrante della postura dello
strumento. La suite è pensata per essere portatile, verificabile e
utilizzabile in ambienti semplici: una copia locale del pacchetto può
essere aperta nel browser e usata anche senza connessione. L'operatore
può lavorare sul proprio computer, su una macchina dedicata, in una
stanza di crisi, durante una sessione formativa o in un contesto nel
quale non è opportuno inviare subito materiali a piattaforme esterne.

La portabilità, però, non deve essere confusa con leggerezza. Il fatto
che CertiSigma Prudentia Suite non carichi automaticamente dati su un server non rende
automaticamente innocuo ciò che l'operatore vi inserisce, salva o
esporta.

La protezione principale non è solo tecnica. È operativa.

Il pacchetto CertiSigma Prudentia Suite 1.1 non è un singolo strumento, ma **due
edizioni prodotto autonome** — Italy / Switzerland ed Europe /
Switzerland — più un piccolo livello tecnico condiviso. Prima di
aprire un modulo, l'operatore deve quindi compiere una scelta che nelle
versioni precedenti non esisteva: quale edizione aprire.

Estraendo il pacchetto, la cartella radice contiene:

index.html — il selettore di prodotto. Non è l'home di uno
strumento operativo: è una pagina di solo instradamento, che spiega
la differenza tra le due edizioni e porta l'operatore verso quella
corretta.
italy-switzerland/ — l'edizione italiana, con la propria home
(index.html di prodotto), i tre moduli, gli scenari e la
documentazione in italiano.
europe-switzerland/ — l'edizione inglese, con la stessa struttura
interna ma cataloghi, esempi e perimetro giurisdizionale propri.
common/ — una cartella tecnica minima, condivisa dalle due
edizioni: identificatori canonici, controlli di coerenza, fogli di
stile e il logo. Non contiene testo operativo, scenari o
documentazione: la coerenza linguistica e didattica resta interamente
dentro ciascuna edizione.

L'operatore non deve copiare, aprire o modificare common/
direttamente: è plumbing che le pagine di ciascuna edizione caricano da
sole. È sufficiente sapere che esiste, perché è la ragione per cui un
export prodotto in un'edizione resta riconoscibile nell'altra — il
meccanismo è descritto nel capitolo 5.

La regola pratica per l'operatore è semplice: **si apre sempre
un'edizione, non il pacchetto nel suo complesso**. Chi lavora
stabilmente in italiano su casi Italia/Svizzera apre e tiene come
segnalibro italy-switzerland/index.html, non il selettore radice. Il
selettore serve la prima volta, o quando serve ricordare quale edizione
sia coerente con un caso cross-border o con un interlocutore
anglofono.

Le due edizioni possono essere usate sullo stesso computer, anche nello
stesso browser, senza interferire tra loro: i salvataggi locali di
ciascuna edizione sono tenuti separati (si veda 2.3).

Per motivi di comodità, l'operatore può usare sia la copia contenuta
nello zip sia la copia non zippata pubblicata sul sito di distribuzione
del pacchetto, quando questa è resa disponibile dall'organizzazione che
mantiene CertiSigma Prudentia Suite.

Le due copie devono essere considerate equivalenti se il sito di
distribuzione espone gli stessi file statici del pacchetto zip e se le
pagine applicative funzionano nello stesso modo: nel browser, senza
inviare il contenuto del caso a un server.

In pratica, l'operatore può aprire la suite da una cartella locale
oppure da una versione statica pubblicata, purché sia chiaro un punto:
l'applicazione non deve comunicare il contenuto operativo del caso al
server. Il sito può servire i file HTML, CSS e JavaScript necessari ad
avviare lo strumento, ma il lavoro dell'operatore resta nel browser.

Questa distinzione è importante nella formazione. Aprire una pagina dal
sito di distribuzione non significa, da solo, caricare il dossier sul
sito. Significa ricevere il codice statico dello strumento. I dati
inseriti dall'operatore restano nella sessione locale del browser e, se
l'operatore decide di salvare, nel vault cifrato locale del browser.

Resta comunque buona pratica usare la copia zip locale quando il
contesto è particolarmente sensibile, quando non si vuole dipendere
dalla rete, quando si lavora in ambienti segregati o quando le policy
interne richiedono strumenti eseguiti da supporto locale.

Durante l'uso ordinario, CertiSigma Prudentia Suite lavora nella pagina aperta dal
browser. I dati inseriti dall'operatore servono a generare mappe,
scenari, verbali, prompt o esportazioni, ma non vengono trasmessi
automaticamente a un sistema remoto.

Il salvataggio locale, quando attivato, avviene nel browser attraverso
un vault cifrato protetto da passphrase. Questo consente di riprendere
un lavoro senza trasformare la suite in un sistema centrale di
conservazione documentale.

Il vault cifrato migliora la protezione del contenuto salvato, ma non
elimina le responsabilità di contesto. La passphrase deve essere scelta
e custodita con attenzione. Il dispositivo deve essere adeguato al tipo
di caso trattato. Il browser deve essere usato in modo coerente con le
policy dell'organizzazione. Una macchina condivisa, compromessa o non
governata resta un ambiente inadeguato per lavorare su casi sensibili.

La cifratura locale protegge il salvataggio nel browser. Non trasforma
il browser in un archivio ufficiale, non sostituisce i sistemi
documentali dell'organizzazione e non autorizza l'inserimento di dati
non necessari.

Ogni edizione salva il proprio vault sotto una chiave locale distinta.
Un vault salvato in italy-switzerland/ non è visibile, non viene
letto e non viene sovrascritto da europe-switzerland/, anche se
entrambe le edizioni vengono usate nello stesso browser. L'operatore
non deve fare nulla per ottenere questa separazione: è una proprietà
del pacchetto. Il pulsante "Pulisci localStorage", presente in ciascun
modulo, rimuove invece i salvataggi di entrambe le edizioni sulla
stessa macchina: è la funzione da usare quando si vuole liberare
completamente il browser, non quella da usare per "cambiare edizione"
lasciando intatto il lavoro sull'altra.

Il momento più delicato non è sempre l'inserimento dei dati. Spesso è
l'esportazione.

Un file esportato da CertiSigma Prudentia Suite può contenere molto più di quanto sembri:
lacune dell'organizzazione, ipotesi non verificate, criticità tecniche,
dubbi sulla catena decisionale, riferimenti a sistemi, ruoli, fornitori,
autorità, categorie di dati, tempi di reazione, comunicazioni previste o
punti deboli emersi durante un esercizio.

Anche quando il file non contiene nomi di persone o dati personali
evidenti, può restare sensibile. Una mappa dei blind spot può rivelare
dove l'organizzazione è fragile. Un verbale Drill può mostrare come
reagirebbe sotto pressione. Un prompt costruito per un LLM può contenere
informazioni sufficienti a ricostruire il perimetro di un caso. Un
confronto tra stati può rendere visibile ciò che era stato dimenticato,
aggiunto, corretto o lasciato incerto.

Per questo ogni export deve essere trattato come un dossier sensibile.

La regola operativa è semplice: prima di esportare, l'operatore deve
chiedersi chi leggerà il file, dove sarà conservato, per quanto tempo,
con quale livello di protezione, con quali limiti di circolazione e con
quale eventuale validazione.

Un export non è una stampa neutra. È una fotografia del ragionamento
dell'organizzazione in un momento dato.

Prima di esportare, l'operatore deve fare una verifica di
minimizzazione.

La domanda non è soltanto se il contenuto sia corretto. La domanda è se
tutto ciò che compare nel file sia necessario rispetto allo scopo.

Un file destinato alla formazione dovrebbe evitare riferimenti
identificativi reali, salvo che siano indispensabili e autorizzati. Un
file destinato al management dovrebbe distinguere chiaramente fatti,
ipotesi, decisioni provvisorie e validazioni mancanti. Un file destinato
a funzioni tecniche può contenere dettagli operativi maggiori, ma deve
essere gestito con controlli adeguati. Un file preparatorio per una
richiesta a un'AI deve escludere tutto ciò che non serve alla richiesta
stessa.

La minimizzazione non è un esercizio cosmetico. È una misura di
sicurezza.

Ridurre il contenuto non significa impoverire il lavoro. Significa
evitare che il dossier contenga elementi non necessari, riutilizzabili
fuori contesto o difficili da controllare una volta condivisi.

CertiSigma Prudentia Suite non decide dove conservare i file esportati. Questa decisione
appartiene all'organizzazione.

Proprio per questo l'operatore deve conoscere le regole interne
applicabili: cartelle autorizzate, repository documentali, sistemi di
ticketing, aree riservate, classificazioni, tempi di conservazione,
criteri di accesso, eventuale cifratura del file, divieti di invio
tramite canali personali o strumenti non approvati.

Un file esportato non dovrebbe restare nella cartella download come
copia dimenticata. Non dovrebbe essere inoltrato a gruppi ampi "*per
comodità*". Non dovrebbe essere caricato in strumenti AI, chat, sistemi
di traduzione o piattaforme esterne senza una scelta consapevole e
coerente con il contenuto.

La portabilità dello strumento facilita il lavoro. La governance del
file esportato resta indispensabile.

L'uso offline è preferibile quando il caso è sensibile, quando
l'ambiente di rete è incerto, quando si lavora in contesti di crisi o
quando l'organizzazione vuole ridurre al minimo ogni dipendenza esterna.

L'uso della copia pubblicata sul sito di distribuzione può essere
pratico in formazione, in revisione, in esercitazioni leggere o quando
si vuole accedere rapidamente alla versione corrente del pacchetto. In
questo caso l'operatore deve sapere che la pagina viene servita dal
sito, ma il contenuto inserito nella suite resta nel browser se
l'applicazione è distribuita come sito statico e non prevede upload.

Questa distinzione va spiegata con chiarezza agli operatori. Il punto
non è creare sfiducia verso la copia online. Il punto è scegliere
l'ambiente adeguato al tipo di lavoro.

Per casi reali, dossier sensibili o esercizi che riproducono criticità
concrete, la copia locale resta la scelta più prudente.

Quando CertiSigma Prudentia Suite viene usata per formazione, simulazione o
personalizzazione, l'operatore dovrebbe lavorare su copie del pacchetto
e dei file esportati.

Questo vale soprattutto per chi adatta scenari, testi, modelli o
cataloghi. La suite è distribuita in modo modificabile, ma la
modificabilità richiede metodo. È opportuno conservare una copia pulita
del pacchetto originale, creare una copia di lavoro, annotare le
modifiche principali e usare il validatore locale per controllare che la
struttura non sia stata rotta.

Questa disciplina evita di confondere il pacchetto base con una variante
interna, una prova o una versione parziale. Aiuta anche a distinguere
ciò che appartiene alla suite da ciò che è stato aggiunto
dall'organizzazione.

Per gli operatori può essere utile pensare a CertiSigma Prudentia Suite come a una
"stanza pulita" di ragionamento.

Nella stanza pulita entra solo ciò che serve.
Ciò che entra viene formulato con cautela.
Ciò che viene salvato è protetto ma non banalizzato.
Ciò che viene esportato viene trattato come dossier sensibile.
Ciò che viene mandato fuori dalla stanza richiede una decisione
ulteriore.

Questa immagine aiuta a evitare due errori opposti: considerare la suite
troppo rischiosa per qualunque uso, oppure considerarla sicura per
qualunque contenuto solo perché funziona localmente.

La postura corretta sta nel mezzo. CertiSigma Prudentia Suite riduce molte esposizioni
tipiche degli strumenti remoti, ma richiede un operatore capace di
minimizzare, custodire, esportare e condividere con disciplina.

CertiSigma Prudentia Suite è portatile perché funziona localmente nel browser, senza
account, server applicativi o upload del caso. Questa portabilità è un
vantaggio operativo: permette di lavorare rapidamente, anche su una
copia locale, anche senza connessione, anche prima di coinvolgere
sistemi esterni.

La portabilità, però, non elimina la responsabilità dell'operatore.

Il contenuto inserito resta da minimizzare.
Il vault cifrato resta da proteggere.
La passphrase resta da custodire.
Il file esportato resta da governare.
La copia online statica resta da comprendere nel suo funzionamento.
La condivisione resta una decisione organizzativa.

La formula da ricordare è questa: CertiSigma Prudentia Suite riduce l'esposizione
automatica, ma non sostituisce il giudizio operativo.

CertiSigma Prudentia Suite aiuta l'operatore a ragionare prima di produrre: mappa i punti
ciechi, costruisce simulazioni, genera verbali, prepara prompt
controllati e riduce l'esposizione verso strumenti esterni. Questa
postura diventa ancora più forte quando l'operatore capisce che ogni
file esportato è anche un oggetto digitale verificabile.

Un file non è soltanto un nome, un'icona o un allegato. È una sequenza
precisa di byte. Da quella sequenza può essere calcolata un'impronta
crittografica, cioè un hash. Nel caso più comune, SHA-256 produce un
digest che identifica in modo stabile quella specifica versione del
contenuto.

Il concetto è semplice: se il contenuto cambia, cambia anche l'hash. Una
modifica minima, una correzione, una rimozione, un'aggiunta o una
rigenerazione del file producono una impronta diversa.

Questa proprietà è fondamentale per chi lavora con CertiSigma Prudentia Suite. Un export
Blindspot, un verbale Drill, un prompt generato dal Prompt Builder, un
pacchetto custom o un set di materiali formativi possono essere
riconosciuti nel tempo attraverso la loro impronta.

L'hash non dice se il contenuto sia vero, completo, prudente, validato o
giuridicamente corretto. Dice una cosa più precisa: questa versione del
file corrisponde a questa impronta.

Per l'operatore Prudentia, questa distinzione è decisiva. L'hash non
sostituisce il giudizio, ma aiuta a stabilizzare gli oggetti del
giudizio.

Permette di dire: "questa era la versione esistente in quel momento"
oppure "questo file corrisponde a una versione già vista".

Chi usa CertiSigma Prudentia Suite dovrebbe prendere dimestichezza con strumenti di
hashing e inventario prima di usarli in modo probatorio, organizzativo o
formale. Questa attività non è svolta direttamente dai tre moduli
CertiSigma Prudentia Suite. È un livello complementare, utile quando gli export, i
verbali, i prompt o i pacchetti custom prodotti dalla suite devono
essere trattati come oggetti digitali verificabili.

CertiSigma Census è un CLI open source, distribuito come pacchetto
Python, pensato per inventariare file, calcolare hash, confrontare
manifest, verificare integrità, cercare duplicati, analizzare container
e, quando richiesto, attestare hash senza inviare il contenuto dei file.

La modalità più importante per la formazione iniziale è il dry-mode. In
dry-mode l'operatore calcola gli hash e osserva il comportamento dello
strumento senza attestare nulla. È il modo corretto per imparare, perché
permette di capire il perimetro dei file, le differenze tra versioni e
il significato dell'impronta digitale prima di fissare formalmente una
milestone.

Il dry-mode consente di capire:

quali file entrano nel perimetro;
quali file restano fuori;
quale hash corrisponde a quale contenuto;
che cosa cambia dopo una modifica;
che differenza c'è tra inventario locale e attestazione esterna.

Questa fase deve precedere ogni discorso sull'attestazione. L'operatore
deve prima imparare a vedere i file come oggetti verificabili. Solo dopo
può decidere se congelare una versione o attestare un hash.

La regola formativa è: prima si osserva, poi si decide.

Il primo esercizio deve essere molto semplice.

Il formatore prepara una cartella con tre file fittizi:

un export Blindspot;
un verbale Drill;
un prompt generato dal Prompt Builder.

Gli operatori eseguono una scansione in dry-mode e osservano gli hash
prodotti. Poi modificano una sola parola in uno dei file, salvano la
nuova versione e ripetono la scansione.

Il risultato è immediato: il file modificato produce un hash diverso.

Questo passaggio crea una comprensione concreta. L'impronta non riguarda
il titolo del documento, l'intenzione dell'autore o il contenuto "*più o
meno uguale*". Riguarda quella sequenza esatta di byte.

Il formatore può poi chiedere agli operatori di rinominare un file senza
modificarne il contenuto. L'esercizio mostra che il nome può cambiare
mentre il contenuto resta identico. Questo aiuta a distinguere tre
livelli:

il nome del file;
il percorso in cui il file si trova;
il contenuto effettivo del file.

CertiSigma Prudentia Suite lavora spesso su documenti delicati. Questa distinzione serve
perché l'occhio umano guarda il nome, mentre l'hash riconosce il
contenuto.

La formazione deve insistere su un punto: il nome del file non è una
garanzia.

Un file chiamato bozza.txt può contenere un prompt sensibile.
Un file chiamato materiale_formazione.pdf può contenere un caso
reale non abbastanza anonimizzato.
Un file chiamato backup_old.zip può contenere un verbale completo.
Un file chiamato note_interne.docx può contenere decisioni non
validate.
Un file chiamato test.json può essere un export Prudentia reale.

La cultura documentale tradizionale tende a fidarsi del nome, della
cartella e dell'estensione. L'hash sposta l'attenzione sul contenuto. Se
due file hanno contenuto identico, avranno la stessa impronta, anche
quando nomi, percorsi e contesti sembrano diversi.

Questa è una delle ragioni per cui Census è importante nel percorso Prudentia.
Aiuta l'operatore a vedere ciò che la nomenclatura nasconde.

La ricerca dei duplicati è una delle funzioni più importanti di Census
per la formazione degli operatori Prudentia.

Un duplicato di contenuto non è semplicemente un file con lo stesso
nome. È un file che contiene gli stessi byte di un altro file. Può
trovarsi in una cartella diversa, avere un nome diverso, sembrare
innocuo e appartenere a una storia documentale diversa. L'hash, però, lo
riconosce.

Molte crisi documentali nascono proprio da copie dimenticate.

Un export Prudentia può essere scaricato nella cartella Download, copiato sul
desktop, rinominato per una riunione, inserito in uno zip, mandato a un
collega, spostato in una cartella di progetto, salvato come allegato o
lasciato in una directory temporanea. Dopo qualche giorno, nessuno
ricorda più quale sia la versione valida e quali copie contengano ancora
ipotesi, lacune, criticità organizzative o dettagli che avrebbero dovuto
essere rimossi.

La ricerca dei duplicati serve a vedere queste copie.

Il suo valore non è solo tecnico. È organizzativo.

Trovare duplicati significa chiedere:

perché questa copia esiste?
chi l'ha creata?
serve ancora?
contiene dati reali o minimizzati?
è coerente con lo scopo dichiarato?
si trova nel luogo giusto?
è una copia di lavoro, una copia ufficiale o una copia dimenticata?
deve essere protetta, rimossa, archiviata, attestata o segnalata?

Un duplicato inatteso non prova automaticamente un abuso. Apre però una
domanda che prima era invisibile.

Un duplicato può essere legittimo. Le organizzazioni copiano file per
lavorare, revisionare, distribuire materiali, preparare riunioni,
conservare backup o costruire pacchetti di formazione.

Il rischio nasce quando la copia è inattesa, incoerente o dimenticata.

Una copia inattesa può mostrare che un file sensibile è uscito dal
perimetro previsto. Può rivelare che una versione non minimizzata
circola accanto alla versione ripulita. Può indicare che un dossier
esportato da Prudentia è rimasto in una cartella non governata. Può suggerire
che qualcuno stia spostando contenuti in silenzio, lasciandoli identici
ma cambiando nome o posizione.

Questo punto è molto importante: lo spostamento silenzioso di un
contenuto può passare inosservato quando si guarda solo il percorso del
file. La ricerca per hash permette invece di riconoscere lo stesso
contenuto anche se è stato rinominato.

Nel contesto Prudentia, i duplicati sono rilevanti in almeno quattro
situazioni:

dopo una simulazione, per capire dove sono finiti verbali ed export;
prima di distribuire materiali formativi, per evitare che contengano
casi reali;
durante la personalizzazione della suite, per controllare che file di
lavoro non entrino nel pacchetto;
in presenza di un sospetto incidente documentale, per capire se un
contenuto critico circola in più posizioni.

Il duplicato è una traccia, non una sentenza. L'operatore deve
qualificarlo.

Molti contenuti sensibili non circolano come file singoli. Circolano
dentro zip, bundle, pacchetti, export cumulativi, cartelle compresse o
archivi preparati per trasferimenti e revisioni.

Questo rende i duplicati ancora più insidiosi.

Un pacchetto di formazione può contenere per errore un export reale.
Uno zip chiamato materiali.zip può includere una vecchia versione
non anonimizzata.
Un archivio inviato per revisione può contenere sia il verbale
ripulito sia la bozza completa.
Un bundle custom della suite può trascinarsi dietro file di test non
destinati alla distribuzione.
Una cartella compressa può contenere copie identiche di un prompt già
approvato, ma in percorsi diversi.

Census include funzioni di analisi locale dei container. Questa capacità
è formativamente preziosa perché insegna agli operatori che la
superficie documentale non coincide con ciò che si vede aprendo una
cartella.

Anche gli archivi hanno un contenuto. Anche il contenuto degli archivi
può duplicare materiale critico. Anche un pacchetto apparentemente
innocuo può trasportare dossier, bozze, export o prompt che nessuno
pensava più di avere incluso.

Per CertiSigma Prudentia Suite questa è una lezione fondamentale: prima di distribuire un
pacchetto, bisogna sapere che cosa contiene davvero.

Il formatore dovrebbe proporre un esercizio specifico sui duplicati
prima di parlare di attestazione.

Si prepara una cartella con cinque elementi:

un verbale Drill fittizio;
una copia identica dello stesso verbale con nome innocuo;
un prompt esportato dal Prompt Builder;
una versione modificata del prompt;
uno zip che contiene una copia del verbale.

Gli operatori osservano prima i nomi dei file e provano a identificare
quali elementi sembrano sensibili. Poi usano Census per cercare
duplicati di contenuto.

A quel punto vedono che il nome non è il criterio affidabile. Il
contenuto identico emerge attraverso l'hash.

L'esercizio deve produrre tre apprendimenti:

un file critico può avere un nome innocuo;
una copia dimenticata può essere più pericolosa del file ufficiale;
cercare duplicati è un atto di controllo del perimetro, non una
semplice pulizia dello spazio disco.

La parte più importante dell'esercizio non è cancellare i duplicati. È
discuterli.

Ogni duplicato va qualificato:

copia legittima, copia inutile, copia pericolosa, copia da proteggere,
copia da archiviare, copia da rimuovere secondo procedura, copia da
includere in inventario o copia da portare all'attenzione del
responsabile.

Census deve diventare uno strumento per vedere, non un pulsante per
cancellare.

Trovare un duplicato apre una decisione. La decisione deve restare umana
e organizzativa.

L'operatore deve evitare due automatismi opposti: ignorare il duplicato
perché ha un nome innocuo oppure eliminarlo subito per ripulire.
Entrambe le reazioni possono danneggiare il caso. Una copia può essere
inutile, ma può anche essere rilevante per una ricostruzione. Può essere
pericolosa, ma può anche essere evidenza da conservare.

La risposta corretta è qualificare.

Il duplicato è autorizzato?
È necessario?
È coerente con la classificazione del contenuto?
È in una posizione appropriata?
È dentro un archivio destinato alla condivisione?
È una bozza non minimizzata?
È una copia di un file già attestato?
È parte di una catena di evidenza?
È stato creato da un processo noto o da uno spostamento non spiegato?

Solo dopo questa qualificazione si decide che cosa fare: mantenere,
spostare, proteggere, archiviare, attestare, rimuovere secondo procedura
o segnalare.

La ricerca dei duplicati trasforma il disordine documentale in una serie
di domande trattabili.

Dopo avere compreso hash e duplicati, l'operatore può capire meglio il
valore dell'inventario.

Un inventario è una fotografia locale di un perimetro documentale. Nel
contesto Prudentia può riguardare:

la cartella degli export di una simulazione;
i prompt approvati prima dell'uso con un LLM;
i verbali Drill chiusi;
i materiali formativi;
il pacchetto custom dell'organizzazione;
una cartella di lavoro da ripulire prima della distribuzione.

L'inventario risponde a una domanda semplice: che cosa avevamo in questo
perimetro?

Questa domanda è spesso sottovalutata. In una situazione di pressione,
le persone ricordano male, confondono versioni, cercano file con nomi
sbagliati, aprono copie non aggiornate o ricostruiscono a posteriori ciò
che avrebbero dovuto conservare.

Un inventario locale aiuta a stabilizzare il quadro.

Per l'operatore Prudentia, inventariare significa passare da una memoria
fragile a una base verificabile.

Il confronto serve a rispondere a una domanda diversa: questo file
corrisponde a qualcosa che conosciamo?

Può essere utile quando arriva un file sospetto, quando una copia viene
trovata in una cartella inattesa, quando un export viene restituito da
un collega, quando si recupera materiale da un archivio o quando si
vuole verificare se un documento corrisponde a una versione già
inventariata.

Nel contesto Prudentia, il confronto può aiutare a capire se:

un prompt ritrovato è quello approvato;
un verbale allegato a una mail è quello chiuso al termine della
simulazione;
un export in una cartella condivisa corrisponde a una versione
ufficiale;
un pacchetto custom distribuito agli operatori coincide con quello
validato;
un file apparentemente nuovo è in realtà una copia già nota.

Il confronto riduce l'ambiguità. Non risponde a tutte le domande, ma
chiarisce se due oggetti digitali coincidono oppure no.

L'integrità risponde a una terza domanda: ciò che avevamo è rimasto
uguale?

Questa funzione è utile quando l'organizzazione vuole controllare una
baseline. Una baseline può essere una cartella di materiali approvati,
un pacchetto custom, un set di export chiusi, una raccolta di prompt
validati o un insieme di file tecnici associati a una simulazione.

Il controllo di integrità permette di vedere se qualcosa è stato
aggiunto, rimosso o modificato rispetto alla fotografia precedente.

Nel contesto Prudentia, questa capacità è particolarmente utile prima di una
distribuzione o dopo una sessione di lavoro. Aiuta a evitare che
materiali non previsti entrino in un pacchetto, che un file validato
venga sostituito senza accorgersene, che una cartella di esercizio cambi
dopo la chiusura o che una versione custom perda coerenza rispetto alla
baseline.

L'integrità non serve a sostituire la revisione umana. Serve a far
emergere le differenze che la revisione umana potrebbe non vedere.

Dopo inventario, duplicati, confronto e integrità, l'operatore può
affrontare il tema dell'attestazione.

Il punto centrale è il confine hash-only.

Inviare un hash non equivale a caricare il contenuto del file. In un
flusso hash-only, il contenuto resta sul dispositivo o nel perimetro
dell'operatore; all'esterno viene trasmessa solo l'impronta
crittografica.

Questo confine è coerente con la filosofia Prudentia: ridurre l'esposizione
del contenuto e aumentare la disciplina dell'evidenza.

Census può calcolare gli hash dei file e, nei flussi che lo prevedono,
lavorare in logica hash-only senza trasferire il contenuto. ExistBefore,
nella sua interfaccia web, consente di attestare gratuitamente
l'esistenza di un file secondo il proprio flusso operativo.

Nella CertiSigma Prudentia Suite, il collegamento a ExistBefore va inteso come passaggio
esterno e intenzionale: la suite non attesta automaticamente il file e
non invia automaticamente il dossier. L'operatore esporta il file in
locale, decide se attestarlo e segue il flusso del servizio scelto,
facendo calcolare l'hash localmente dal browser e inviando solo il
digest.

Per l'operatore Prudentia, questa possibilità è importante. Una simulazione,
un verbale, un prompt o un pacchetto custom possono essere attestati
senza caricare il dossier.

Il contenuto resta presso l'organizzazione. L'impronta viene usata per
fissare l'esistenza di una versione.

Nel pacchetto CertiSigma Prudentia Suite può essere presente un link a ExistBefore per
consentire all'operatore di attestare gratuitamente l'esistenza di una
versione selezionata inviando solo l'hash.

https://existbefore.com/

Nel contesto Prudentia, l'operatore può usare questo flusso per attestare:

un verbale Drill chiuso al termine di una simulazione;
un export Blindspot prima di una riunione di validazione;
un prompt approvato prima dell'uso con un LLM;
una versione del pacchetto custom dell'organizzazione;
un set di materiali formativi prima della distribuzione.

Il valore non sta nel rendere pubblico il contenuto. Il valore sta nel
poter dimostrare che una certa impronta crittografica era stata fissata
in un certo momento.

La ricevuta va conservata insieme al file originale. Da sola, la
ricevuta non permette di leggere il contenuto e non basta a ricostruire
il documento. Per verificare, bisogna ricalcolare l'hash del file
originale e confrontarlo con il digest attestato.

La disciplina è semplice: file originale e ricevuta devono restare
collegati.

L'attestazione hash-only va spiegata con precisione.

Una attestazione può aiutare a dimostrare che una specifica sequenza di
byte esisteva in un certo momento. Nel contesto Prudentia, questo significa
che un verbale, un prompt, un export o un pacchetto custom esistevano in
quella versione.

Questa prova ha un valore reale, ma circoscritto.

Attestare un verbale Drill dimostra l'esistenza di quella versione,
non la prontezza dell'organizzazione.
Attestare una mappa Blindspot dimostra l'esistenza di quel file, non
l'identificazione completa di tutti i rischi.
Attestare un prompt dimostra l'esistenza di quella richiesta, non la
correttezza della risposta del LLM.
Attestare un pacchetto custom dimostra l'esistenza di quella
distribuzione, non la qualità della personalizzazione.

La formula da insegnare è: l'attestazione dice "questo file esisteva",
non "questo file aveva ragione".

Questa distinzione protegge da una falsa sicurezza. L'attestazione
stabilizza la versione; la valutazione resta umana, tecnica,
organizzativa o giuridica a seconda del caso.

L'errore da evitare è attestare tutto.

Troppe attestazioni producono rumore. Se ogni bozza, ogni prova, ogni
export intermedio e ogni variante viene attestata, l'organizzazione
rischia di perdere il senso delle milestone.

L'attestazione ha più valore quando riguarda versioni selezionate:

chiusura di una simulazione;
consegna di un verbale;
approvazione di un prompt;
congelamento di una versione custom;
deposito di un export prima di una decisione;
chiusura di un pacchetto formativo.

Il dry-mode resta la scelta corretta quando si sta imparando,
preparando, modificando, verificando, confrontando o cercando duplicati.
In questa fase si lavora localmente, si osservano gli hash, si capisce
come cambia il materiale e si corregge ciò che va corretto.

Il passaggio all'attestazione deve essere intenzionale.

Prima si lavora.
Poi si ripulisce.
Poi si minimizza.
Poi si qualifica il perimetro.
Poi si sceglie la milestone.
Solo dopo si attesta.

Per attestare una simulazione Prudentia in modo ordinato, il formatore può
insegnare una procedura in sette passaggi.

Primo: chiudere la sessione. Il verbale o l'export deve rappresentare un
momento preciso, non una bozza ancora aperta.

Secondo: rivedere il contenuto. Devono essere distinti fatti, ipotesi,
decisioni, validazioni mancanti e dati esclusi.

Terzo: minimizzare. Ogni dettaglio identificativo non necessario deve
essere rimosso o generalizzato, soprattutto se l'export nasce da un caso
reale o derivato.

Quarto: cercare duplicati. Prima di attestare, conviene verificare se
esistono copie identiche in cartelle inattese, archivi o pacchetti
destinati alla condivisione.

Quinto: salvare il file in una cartella controllata. Il nome deve essere
comprensibile, ma non rivelare più del necessario.

Sesto: attestare solo l'hash tramite ExistBefore oppure usare un flusso
CertiSigma equivalente, quando previsto. Il contenuto non deve essere
caricato se l'obiettivo è una attestazione hash-only.

Settimo: conservare insieme file originale e ricevuta. La ricevuta serve
solo se in futuro si dispone del file da verificare.

Questa procedura aiuta a evitare che una simulazione importante resti
dispersa tra download, allegati, copie rinominate e versioni non
distinguibili.

Prompt Builder merita una cautela specifica.

Quando l'organizzazione prepara una richiesta verso un LLM in un
contesto sensibile, può essere utile conservare la prova della versione
effettivamente approvata prima dell'invio. Questo aiuta a ricostruire
che cosa è stato chiesto all'AI, quali limiti erano stati imposti, quali
informazioni erano state incluse, quali esclusioni erano state formulate
e quale livello di certezza era stato dichiarato.

L'attestazione del prompt non richiede di rendere pubblico il prompt.
Richiede solo di attestare l'hash del file che contiene la richiesta
approvata, se si usa un servizio hash-only.

Il valore operativo è chiaro: se più tardi emerge una risposta
problematica dell'AI, l'organizzazione può distinguere tra tre livelli:

la richiesta approvata;
la risposta generata;
l'eventuale riuso umano della risposta.

Questa distinzione è coerente con la postura Prudentia. L'AI è destinatario
diretto della richiesta; l'eventuale uso verso terzi resta decisione
dell'operatore e dell'organizzazione.

Attestare il prompt approvato può aiutare a dimostrare che non è stata
usata una versione diversa, più identificativa, meno cauta o meno
controllata. Il limite resta chiaro: l'attestazione prova l'esistenza
del prompt, non la sua adeguatezza.

CertiSigma Prudentia Suite è modificabile e personalizzabile. Un'organizzazione può
adattare testi, scenari, cataloghi, esempi, modalità formative,
riferimenti interni e materiali di supporto.

Quando una versione custom viene usata in formazione o in produzione
interna, può essere utile attestare il pacchetto distribuito agli
operatori.

In questo caso l'oggetto da attestare non è un singolo export, ma lo zip
o il bundle della versione custom. Si può calcolare l'hash del pacchetto
e, quando opportuno, attestarlo. In questo modo l'organizzazione può
ricostruire quale versione degli strumenti era in uso durante una
sessione o in un certo periodo.

Prima di attestare un pacchetto custom, però, la ricerca dei duplicati e
l'analisi dei container diventano particolarmente importanti. Il
pacchetto non deve contenere file di lavoro, casi reali, export non
minimizzati, bozze, prompt sensibili o materiali lasciati per errore.

Qui il rapporto tra gli strumenti è chiaro.

Il validatore locale controlla la coerenza della suite.
Census aiuta a vedere contenuti, duplicati, integrità e pacchetti.
L'attestazione fissa l'esistenza di una versione selezionata.

Validazione, inventario e attestazione non sono la stessa cosa. Insieme,
però, costruiscono una governance minima della versione.

Census ed CertiSigma Prudentia Suite non fanno lo stesso lavoro.

CertiSigma Prudentia Suite guida il ragionamento operativo: blind spot, simulazioni,
verbali, prompt, minimizzazione, confronto dichiarativo e postura verso
l'AI.

Census lavora sugli oggetti digitali: file, hash, inventari, duplicati,
container, manifest, confronti, integrità, pacchetti di evidenza e
attestazioni.

Nel manuale operatori Prudentia non serve insegnare tutto Census. Serve
insegnare il minimo che rende l'operatore alfabetizzato:

un file ha un hash;
un hash cambia se il file cambia;
due file con nomi diversi possono avere lo stesso contenuto;
un duplicato inatteso è una domanda operativa;
un archivio può contenere copie sensibili;
un inventario fotografa un perimetro;
un confronto dice se qualcosa corrisponde;
un controllo di integrità dice se una baseline è cambiata;
un'attestazione hash-only può fissare l'esistenza di una versione
senza caricare il contenuto.

Questa alfabetizzazione è sufficiente per usare meglio CertiSigma Prudentia Suite.

Chi gestisce release, CI/CD, SBOM, log sealing, trust surface o processi
tecnici potrà approfondire autonomamente Census come strumento
specialistico.

L'operatore Prudentia deve solo conoscere il ponte, non padroneggiare tutto
l'ecosistema.

L'hash è potente, ma richiede cautele.

Un hash non deve essere trattato come un segreto. Se il contenuto è
breve, prevedibile o tratto da un insieme ristretto di possibilità,
qualcuno potrebbe calcolare gli hash delle possibili alternative e
confrontarli.

Questo rischio cambia molto a seconda dell'oggetto. L'hash di un file
complesso, unico e sufficientemente ricco è diverso dall'hash di una
frase breve, di un codice standard, di un identificativo prevedibile o
di una risposta sì/no.

L'operatore deve evitare di attestare stringhe brevi sensibili come se
l'hash le rendesse invisibili. Quando serve attestare materiale
sensibile, è preferibile attestare un file strutturato e conservato
internamente, con un contenuto non banale e un contesto documentale
chiaro.

Un'altra cautela riguarda metadati, nomi e ricevute. Anche quando un
flusso hash-only non carica il contenuto del file, l'operatore deve
capire quale file conserva, quale ricevuta produce, dove la salva e
quali informazioni restano nel proprio ambiente locale.

La regola è: hash-only è un confine forte, ma va compreso.

L'attestazione può diventare anche uno strumento di comunicazione
interna.

Dire "abbiamo un verbale" è meno preciso di dire "*abbiamo chiuso il
verbale della simulazione, conservato il file originale e attestato
l'hash della versione finale*". Questa frase non trasforma il verbale in
verità assoluta, ma mostra metodo.

Il management non deve essere sommerso di dettagli crittografici. Deve
capire la funzione: l'organizzazione ha fissato una versione e potrà
riconoscerla in futuro.

La comunicazione interna deve evitare parole eccessive come
"certificato", "garantito", "blindato", "prova definitiva",
quando non sono tecnicamente e giuridicamente appropriate. È più
corretto parlare di prova di esistenza, impronta crittografica,
ricevuta, versione congelata, verifica di integrità, confronto o
baseline.

L'operatore formato deve saper usare parole misurate. Anche
l'attestazione richiede postura.

Il formatore può chiudere questo capitolo con un esercizio pratico in
cinque tempi.

Nel primo tempo, gli operatori generano un export Prudentia fittizio e usano
Census in dry-mode per calcolarne l'hash. Poi modificano una frase e
osservano che l'hash cambia.

Nel secondo tempo, il formatore introduce copie identiche con nomi
diversi. Gli operatori cercano duplicati e discutono quali copie siano
legittime, inutili, pericolose o da proteggere.

Nel terzo tempo, il formatore inserisce una copia del verbale dentro uno
zip. Gli operatori imparano che un contenuto sensibile può essere
nascosto dentro un archivio apparentemente innocuo.

Nel quarto tempo, gli operatori preparano un verbale Drill fittizio, lo
minimizzano, lo salvano come versione chiusa e discutono se abbia senso
attestarlo. Il formatore deve far emergere la differenza tra bozza,
versione di lavoro e milestone.

Nel quinto tempo, gli operatori usano ExistBefore su un file non
sensibile di prova. Osservano che il browser calcola l'hash localmente,
che viene inviato solo il digest e che la ricevuta deve essere
conservata con il file originale.

L'esercizio deve concludersi con tre domande:

quali contenuti abbiamo scoperto che non erano evidenti dal nome?
quali copie meritano una decisione organizzativa?
quali file, nel nostro processo, meritano davvero di essere congelati?

CertiSigma Prudentia Suite aiuta a ragionare. Census aiuta a vedere i file come oggetti
verificabili. ExistBefore consente, quando opportuno, di attestare
gratuitamente l'esistenza di una versione inviando solo l'hash.

Il punto centrale non è attestare tutto. È costruire disciplina.

Prima si capisce l'hash.
Poi si lavora in dry-mode.
Poi si cercano duplicati e contenuti nascosti.
Poi si verifica che il perimetro sia pulito.
Poi si controlla l'integrità delle baseline importanti.
Poi si sceglie che cosa merita davvero di essere attestato.

Questi strumenti condividono una filosofia: ridurre l'esposizione del
contenuto e aumentare la disciplina dell'evidenza.

La formula finale è questa: il nome racconta una storia, l'hash
riconosce il contenuto.

CertiSigma Prudentia Suite nasce con una scelta precisa: essere aperta, modificabile,
ispezionabile e riutilizzabile.

Questa scelta non è decorativa. È parte della postura di sicurezza.

La cultura della sicurezza non può limitarsi a chiedere strumenti più
potenti, dashboard più ricche, automazioni più veloci o report più
eleganti. Deve anche chiedere una cosa più scomoda: gli strumenti che
usiamo per fare sicurezza sono a loro volta verificabili?

Un operatore che usa strumenti chiusi deve fidarsi di ciò che lo
strumento dichiara. Un operatore che usa strumenti aperti può invece far
leggere, controllare, testare, modificare e validare il codice, i
modelli, gli scenari, i testi e i flussi.

Questa differenza è importante perché gli strumenti di sicurezza non
sono neutrali. Possono contenere assunzioni sbagliate, logiche opache,
eccessi di raccolta, automatismi rischiosi, vecchi schemi mentali,
dipendenze fragili o promesse troppo ampie.

Uno strumento di sicurezza deve aiutare a ridurre il rischio. Per farlo,
deve essere esso stesso esposto a controllo.

CertiSigma Prudentia Suite e il CLI Census appartengono a questa cultura: strumenti
aperti, leggibili, modificabili, testabili e migliorabili. L'apertura
non garantisce automaticamente la sicurezza, ma rende possibile la
verifica. E la verifica è una delle forme più concrete della fiducia.

Il fatto che CertiSigma Prudentia Suite sia aperta e distribuita con una licenza
permissiva non significa che ogni modifica sia automaticamente buona.

L'apertura aumenta la possibilità di adattamento. Richiede, però,
metodo.

Chi modifica scenari, testi, modelli, prompt, esempi o cataloghi deve
sapere che sta intervenendo su uno strumento che guida decisioni
delicate. Una piccola modifica linguistica può cambiare la postura
dell'operatore. Uno scenario mal costruito può addestrare persone a
ignorare un rischio. Un prompt troppo aggressivo può spingere a esporre
più dati del necessario. Un esempio troppo rassicurante può banalizzare
una situazione reale.

Per questo l'apertura deve essere accompagnata da disciplina.

La regola è: modificare sì, ma sapendo che cosa si sta modificando.

Ogni versione adattata dovrebbe essere provata, validata, documentata e,
quando opportuno, attestata come versione chiusa. Il validatore locale
serve proprio a questo: consente a chi interviene sulla suite di
controllare che la struttura non sia stata rotta.

Census può aiutare a inventariare il pacchetto, individuare
duplicati, verificare che non siano entrati file impropri e congelare la
versione distribuita.

ExistBefore può essere usato, quando serve, per attestare
l'esistenza della versione senza caricarne il contenuto.

L'apertura dà libertà. Il metodo trasforma quella libertà in
affidabilità.

La trasformazione delle minacce rende sempre più importante la sicurezza
degli strumenti usati per fare sicurezza.

Molti strumenti nati per difendere possono essere riutilizzati per
attaccare. Framework di test, scanner, ambienti di automazione, agenti,
script, modelli di analisi e strumenti di audit possono essere combinati
in modi offensivi. Questa ambiguità non riguarda solo il software.
Riguarda anche i processi, i modelli decisionali e i contenuti
formativi.

Uno scenario di training può diventare obsoleto.
Un prompt può suggerire una comunicazione troppo estesa.
Un modello può incoraggiare l'invio di dati a strumenti esterni.
Un pacchetto custom può contenere esempi reali lasciati per errore.
Un tool di inventario può essere usato senza comprenderne il
perimetro.

Il codice aperto non elimina questi rischi, ma li rende discutibili.
Consente a sviluppatori, revisori, operatori, formatori e organizzazioni
di leggere ciò che lo strumento fa, capire come ragiona, proporre
correzioni, rimuovere eccessi, adattare scenari e verificare che la
versione distribuita corrisponda a quella attesa.

In un ecosistema chiuso, l'utente spesso può solo usare o non usare. In
un ecosistema aperto, può anche capire, correggere e contribuire.

Questa è una forma di sicurezza.

CertiSigma Prudentia Suite è pensata per essere riutilizzata e adattata. La licenza CC BY
consente di condividere, modificare e costruire versioni derivate,
mantenendo l'attribuzione.

Nel contesto formativo, questo ha un valore particolare. Le
organizzazioni vivono casi, esercizi, vincoli, errori, pressioni e
scenari che nessun progettista centrale può prevedere interamente. Un
ospedale vede problemi diversi da una banca. Un ente pubblico ha
frizioni diverse da un fornitore industriale. Una piccola organizzazione
vive vincoli diversi da una infrastruttura critica. Un consulente vede
pattern trasversali che una singola organizzazione può non vedere.

Se ogni esperienza resta chiusa, il progetto migliora lentamente. Se
invece le esperienze vengono trasformate in scenari condivisibili, il
progetto diventa un ecosistema.

La licenza aperta consente proprio questo: prendere la suite, provarla,
adattarla, costruire nuovi scenari, migliorare testi, creare esercizi e
restituire al progetto integrazioni nate dall'esperienza.

Naturalmente, la restituzione deve essere fatta con cautela. Uno
scenario derivato da un caso reale deve essere anonimizzato,
minimizzato, astratto e ripulito da dettagli che permettano di
identificare persone, organizzazioni, fornitori, sistemi, vulnerabilità
operative o eventi non pubblici.

L'obiettivo non è condividere dossier. È condividere apprendimento.

Una suite come Prudentia diventa più utile quando viene provata su molti
scenari.

Un solo scenario insegna poco. Molti scenari mostrano pattern.

L'operatore e il formatore dovrebbero sperimentare casi diversi:

un dubbio iniziale senza evidenze complete;
un fornitore che risponde in modo ambiguo;
un sistema vulnerabile che non può essere riavviato;
una richiesta urgente del management;
un prompt da inviare a un LLM con dati da minimizzare;
un messaggio apparentemente autentico ma sospetto;
una simulazione di bonifico fraudolento tramite video deepfake;
un export dimenticato in una cartella non governata;
un pacchetto formativo che contiene per errore materiale sensibile;
un incidente che non rientra nelle categorie ordinarie della
procedura.

Provare molti scenari serve a capire dove lo strumento aiuta, dove è
troppo generico, dove manca una domanda, dove un testo è ambiguo, dove
un operatore interpreta male una sezione, dove un output rischia di
essere troppo assertivo.

Ogni prova ben condotta produce informazione sullo strumento stesso.

Questa è la logica dell'ecosistema: la suite non migliora solo perché
viene sviluppata; migliora perché viene usata, stressata, discussa e
corretta.

Durante la formazione, gli operatori dovrebbero imparare a salvare non
soltanto l'output finale, ma anche gli scenari costruiti.

Uno scenario ben costruito è un bene formativo. Può essere riusato,
confrontato, migliorato, adattato ad altri settori, trasformato in
esercizio, inserito in una versione custom o proposto come contributo al
progetto.

Salvare scenari significa conservare memoria dell'esperienza. Significa
evitare che una buona simulazione resti solo nella testa del
facilitatore o nel verbale di una singola sessione. Significa costruire
una libreria di casi plausibili, sempre più aderente alla realtà
dell'organizzazione.

La regola operativa è semplice: quando uno scenario funziona, va
raccolto.

Funziona uno scenario che fa emergere decisioni difficili.
Funziona uno scenario che mostra un ruolo mancante.
Funziona uno scenario che rivela una comunicazione prematura.
Funziona uno scenario che obbliga a distinguere fatti e ipotesi.
Funziona uno scenario che costringe a minimizzare prima di usare
l'AI.
Funziona uno scenario che mostra un duplicato documentale inatteso.
Funziona uno scenario che rende visibile un vincolo tecnico reale.

Uno scenario riuscito non è quello che conferma che tutto va bene. È
quello che produce apprendimento.

La licenza aperta permette una cosa preziosa: gli scenari sviluppati
dagli operatori possono diventare contributi al progetto, quando sono
adeguatamente ripuliti e concessi con la stessa logica aperta.

Questo passaggio va incoraggiato.

Un'organizzazione che sviluppa uno scenario utile può decidere di
mantenerlo interno, se contiene elementi specifici o sensibili. Può però
anche trasformarlo in scenario generalizzato e condividerlo come
integrazione derivante dall'esperienza.

La trasformazione richiede metodo.

Bisogna rimuovere nomi di persone, aziende, fornitori, sistemi,
prodotti, indirizzi, date specifiche, importi riconoscibili, riferimenti
contrattuali, vulnerabilità puntuali e dettagli che possano ricondurre a
un caso reale. Bisogna conservare invece la struttura del problema: il
tipo di pressione, il vincolo operativo, il punto cieco, il ruolo
coinvolto, l'errore plausibile, la sequenza di decisioni, la cautela
verso l'AI, la domanda formativa.

In questo modo, un caso reale diventa conoscenza riutilizzabile senza
diventare esposizione.

Concedere scenari al progetto significa contribuire alla sicurezza
collettiva. Significa aiutare altri operatori a prepararsi su situazioni
che potrebbero incontrare. Significa trasformare esperienza privata in
apprendimento comune.

La formula è: togliere il dossier, lasciare il pattern.

Un progetto aperto cresce bene quando riceve contributi prudenti.

La prudenza non riguarda solo la riservatezza. Riguarda anche la
qualità.

Uno scenario proposto al progetto dovrebbe essere comprensibile,
realistico, minimizzato, utilizzabile in formazione e coerente con la
postura Prudentia. Dovrebbe evitare spettacolarizzazione, linguaggio
allarmistico, attribuzioni non necessarie, soluzioni preconfezionate e
dettagli tecnici che spostano l'esercizio verso istruzioni operative
offensive.

Un buon scenario non deve insegnare come attaccare. Deve insegnare come
ragionare quando un attacco, un abuso, una manipolazione o un dubbio
diventano plausibili.

Un'integrazione utile può riguardare:

un nuovo scenario Drill;
una nuova famiglia di blind spot;
una formulazione migliore per un prompt;
un esempio di minimizzazione;
una variante settoriale;
una scheda facilitatore;
una checklist di export;
un esercizio su duplicati e attestazione;
una traduzione migliorata;
una nota su un vincolo organizzativo ricorrente.

Ogni contributo dovrebbe essere pensato come materiale che altri
potranno leggere, adattare e migliorare. L'ecosistema aperto non vive di
versioni definitive. Vive di versioni migliorabili.

Chi customizza CertiSigma Prudentia Suite deve assumersi una responsabilità precisa:
provare la propria versione prima di usarla con operatori o casi reali.

Una versione custom può introdurre valore, ma anche errori. Può
migliorare la lingua, adattare settori, integrare scenari, semplificare
istruzioni, aggiungere esempi. Può anche rompere un mapping, duplicare
un identificativo, creare incoerenze tra home, documentazione e moduli,
lasciare dentro file di test, indebolire una cautela o cambiare il senso
di una funzione.

Per questo ogni versione custom dovrebbe passare almeno da quattro
controlli:

controllo funzionale, aprendo i moduli nel browser;
controllo di coerenza, leggendo testi, link, nomi e promesse;
controllo tecnico, usando il validatore locale;
controllo documentale, usando Census per inventariare il pacchetto,
cercare duplicati e verificare che non siano inclusi file impropri.

Quando la versione è stabile, l'organizzazione può decidere di
conservarne l'hash o attestarlo come milestone.

Questo processo non deve essere percepito come burocrazia. È la
conseguenza naturale dell'apertura. Chi può modificare deve anche poter
verificare.

La sicurezza non è solo acquisto di strumenti. È manutenzione comune.

Un ecosistema aperto rende questa manutenzione più visibile. Chi usa lo
strumento può trovare un errore, proporre una correzione, migliorare una
frase, aggiungere uno scenario, tradurre una sezione, rafforzare una
cautela, segnalare un'ambiguità, validare una modifica o costruire un
pacchetto settoriale.

Questa logica è particolarmente adatta alla fase attuale, perché le
minacce cambiano troppo rapidamente per essere coperte solo da manuali
statici. Gli schemi generati o potenziati dall'AI, le manipolazioni di
agenti, i deepfake, i duplicati documentali, gli strumenti difensivi
riusati in modo offensivo e i vincoli dei sistemi non aggiornabili
quotidianamente richiedono aggiornamento continuo.

La risposta non può essere soltanto centralizzata. Serve una rete di
esperienza.

CertiSigma Prudentia Suite, Census ed eventuali strumenti di attestazione hash-only
formano un piccolo ecosistema perché coprono tre livelli:

ragionamento operativo;
verifica degli oggetti digitali;
prova minima di esistenza delle versioni.

Ogni organizzazione che usa, prova, adatta e restituisce scenari
rafforza questo ecosistema.

CertiSigma Prudentia Suite mette a disposizione, nella cartella dev/, uno strumento di
verifica pensato per chi modifica, traduce, adatta o estende il
pacchetto.

Il file dev/validate.html non è una funzione destinata all'uso ordinario
degli operatori durante un caso. È uno strumento di manutenzione. Serve
a chi interviene sulla suite per controllare che la versione modificata
resti coerente.

Questa distinzione è importante. CertiSigma Prudentia Suite è aperta, modificabile e
distribuita con una licenza che consente adattamenti. Ma proprio perché
può essere modificata, deve offrire anche un modo semplice per
accorgersi di errori introdotti durante la modifica.

Il validatore locale risponde a questa esigenza.

L'operatore tecnico, il formatore avanzato o l'organizzazione che
personalizza il pacchetto può aprire dev/validate.html nel browser,
dalla stessa copia locale della suite. Lo strumento carica i modelli, i
cataloghi, gli scenari e gli schemi interni, poi esegue una serie di
controlli automatici.

Il validatore verifica, tra le altre cose:

• che i modelli principali siano caricati;

• che gli schemi attesi siano presenti;

• che i cataloghi non siano vuoti;

• che gli identificatori siano coerenti con il contratto canonico

condiviso in common/ (vettori, categorie di dati, complicanti,
timing, scala);

• che i settori dichiarati dai preset e dalle categorie di dati

corrispondano ai settori del contratto canonico;

• che i framework normativi usati dal modello locale rispettino

l'insieme obbligatorio e non escano da quello consentito — un
modello può aggiungere un framework giurisdizionale in più
rispetto al nucleo comune (è il caso di "Italia" nell'edizione
Italy/Switzerland), ma non può ometterne uno obbligatorio né
inventarne uno fuori contratto;

• che i preset di scenario coincidano campo per campo (settore,

vettore, categoria dati, timing, scala, complicanti) con la
versione canonica;

• che i passaggi della timeline Drill (clock steps) siano coerenti

con quelli canonici;

• che i mapping tra Blindspot e Drill siano risolvibili;

• che gli scenari puntino a regole, vettori o complicanti esistenti;

• che Prompt Builder mantenga gli schemi correnti;

• che le chiavi di salvataggio locale siano coerenti e distinte tra

le due edizioni del pacchetto;

• che il catalogo autorità richiami Paesi presenti;

• che non siano rimaste incoerenze evidenti tra modelli, scenari e

struttura.

Questo perimetro esteso è ciò che rende il validatore uno strumento di
verifica dell'interoperabilità, non solo della coerenza interna di
una singola edizione: un controllo che passa su entrambe le edizioni è
una garanzia concreta che i rispettivi export restano leggibili l'uno
dall'altro. Il capitolo 5 spiega come questo contratto condiviso è
costruito e a cosa serve nel lavoro quotidiano dell'operatore.

Il risultato viene presentato come un resoconto con esiti OK, WARN e
FAIL.

Un esito OK indica che il controllo è passato.
Un esito WARN segnala una condizione da leggere con attenzione, ma non
necessariamente bloccante.
Un esito FAIL indica una rottura o una incoerenza da correggere prima
di distribuire la versione.

Questo strumento non sostituisce il test umano nel browser. Una versione
può superare il validatore e avere comunque un testo poco chiaro, una
promessa sbagliata, una pagina troppo pesante o una scelta didattica
discutibile. Il validatore controlla la coerenza strutturale;
l'operatore e il formatore devono controllare il senso.

La regola pratica è quindi doppia:

prima si usa il validatore per capire se la struttura regge;
poi si prova la suite come la userà davvero un operatore.

Il validatore è particolarmente utile dopo modifiche a:

• scenari Drill;

• scenario pack Blindspot;

• mapping tra moduli;

• cataloghi del Prompt Builder;

• autorità e Paesi;

• chiavi di salvataggio;

• versioni linguistiche;

• pacchetti custom;

• testi che richiamano funzioni o moduli.

La presenza di dev/validate.html rafforza la logica aperta di CertiSigma Prudentia Suite.
Il progetto non dice soltanto "puoi modificare". Dice anche: "*puoi
controllare se la modifica ha rotto qualcosa*".

Questa è una componente essenziale della sicurezza degli strumenti di
sicurezza. Un ecosistema aperto deve rendere possibile la verifica, non
chiedere fiducia cieca.

La formula da ricordare è questa: se personalizzi CertiSigma Prudentia Suite, valida
prima di distribuire.

L'operatore che contribuisce al progetto deve assumere una postura
diversa da quella dell'utente occasionale.

L'utente usa lo strumento per risolvere un bisogno immediato.
Il contributore si chiede se l'esperienza generata può aiutare altri.

Questa domanda cambia il modo di lavorare. Il contributore salva
scenari, annota dove lo strumento è stato utile, segnala dove ha creato
confusione, distingue tra caso reale e pattern generalizzabile, prepara
versioni ripulite, evita di condividere dettagli sensibili e concede il
materiale in modo coerente con la licenza aperta.

Il contributore non deve raccontare tutto. Deve estrarre ciò che è
riutilizzabile.

Un buon contributo non espone l'organizzazione che lo ha generato.
Espone un problema in forma utile.

La forza di CertiSigma Prudentia Suite non sta solo nei suoi tre moduli. Sta
nell'ecosistema che può crescere intorno a essi.

CertiSigma Prudentia Suite è aperta e riutilizzabile. Census è open source. Gli strumenti
hash-only consentono di attestare versioni selezionate senza caricare il
contenuto. Il validatore locale permette di controllare le modifiche. La
licenza aperta consente di adattare e restituire scenari.

Questa combinazione costruisce una cultura diversa: gli strumenti di
sicurezza devono essere a loro volta verificabili, gli scenari devono
essere provati e salvati, le versioni custom devono essere controllate,
e l'esperienza utile dovrebbe poter tornare al progetto come
integrazione condivisa.

La formula finale è questa: usare CertiSigma Prudentia Suite è utile; provarla è meglio;
migliorarla e restituire scenari prudentemente generalizzati rafforza
tutti.

CertiSigma Prudentia Suite può essere usata come strumento locale, aperto nel browser,
senza account, server applicativi o upload del caso. Questa è la sua
forma più immediata. Ma la sua architettura guarda anche a una
prospettiva più ampia: trasformare il lavoro dell'operatore in oggetti
strutturati, leggibili, salvabili, confrontabili e riutilizzabili.

Gli export JSON non sono semplici allegati tecnici. Sono
rappresentazioni strutturate di un ragionamento operativo: quali
categorie sono state selezionate, quali vincoli sono stati indicati,
quali ruoli entrano in gioco, quale scenario è stato costruito, quale
richiesta verso un'AI è stata preparata, quale stato precedente può
essere confrontato con uno stato successivo.

Questa impostazione rende possibile una cosa importante: CertiSigma Prudentia Suite può
diventare un linguaggio comune tra moduli, versioni linguistiche,
organizzazioni e soggetti differenti.

Un operatore può partire da Blindspot per far emergere lacune. Da quelle
lacune può derivare un esercizio Drill. Dal caso o dall'esercizio può
costruire una richiesta controllata verso un LLM con Prompt Builder.

A partire dalla versione 1.1 questa continuità non è più solo un
orizzonte di design: è una proprietà verificabile del pacchetto. Le due
edizioni interoperabili del prodotto — Italy / Switzerland ed Europe /
Switzerland, presentate nel capitolo 2 — condividono un **contratto
macchina canonico**, mantenuto in una cartella tecnica comune
(common/) e verificato automaticamente a ogni caricamento delle
pagine. Un JSON esportato da un'edizione può quindi essere riconosciuto
dall'altra: le etichette che l'operatore legge cambiano lingua, gli
identificatori che il sistema usa per riconoscere vettori, categorie,
settori e scenari restano gli stessi.

L'obiettivo non è creare un grande sistema centrale. L'obiettivo è
permettere a strumenti locali e portatili — e, oggi concretamente, a
due prodotti linguistici distinti — di parlare tra loro.

Il JSON salvato dalla suite contiene dati organizzati secondo schemi.
Questo significa che le informazioni non sono soltanto testo libero, ma
campi, valori, identificatori, categorie e relazioni.

Questa differenza è decisiva.

Un testo libero può essere letto da una persona, ma è difficile da
confrontare automaticamente. Un JSON strutturato può essere letto da una
persona e, allo stesso tempo, interpretato da un modulo, validato da uno
schema, confrontato con un altro stato, trasformato in esercizio,
importato in una versione diversa o usato come base per una richiesta
controllata.

Nel contesto Prudentia, la struttura consente tre passaggi:

salvare il lavoro in una forma riutilizzabile;
confrontare versioni, stati o configurazioni;
rendere possibile l'interoperabilità tra moduli, lingue e versioni
future.

Questo rafforza il ruolo dell'operatore. L'operatore non produce
soltanto un documento; produce un oggetto ordinato che può essere
riletto, verificato, minimizzato, condiviso o trasformato con maggiore
controllo.

Per rendere interoperabili versioni in lingue diverse, CertiSigma Prudentia Suite deve
distinguere tra etichetta visibile e significato interno.

L'etichetta è ciò che l'operatore legge: una voce in italiano, inglese,
francese, tedesco o in un'altra lingua. Il significato interno, invece,
deve restare stabile: un identificatore tecnico, una categoria, un
codice o una chiave che non cambia a ogni traduzione.

Questo principio è fondamentale.

Se una voce viene tradotta, il suo testo cambia. Se il suo
identificatore resta stabile, il JSON continua a essere leggibile da
un'altra versione della suite. Una versione italiana e una versione
inglese possono mostrare parole diverse all'operatore, ma riconoscere lo
stesso valore interno.

Questa separazione consente di costruire interoperabilità reale tra
versioni linguistiche.

Un caso preparato in italiano può essere importato, letto o trasformato
da una versione in un'altra lingua, purché gli identificatori restino
coerenti. Un esercizio Drill può essere condiviso tra team
internazionali. Un prompt può essere preparato in una lingua e poi
adattato a un'altra senza perdere le coordinate operative del caso.

La lingua serve all'operatore. L'identificatore serve
all'interoperabilità.

Un esempio concreto, verificabile aprendo un modulo Drill in ciascuna
edizione: il campo Settore mostra all'operatore italiano la voce
"Sanità / assistenza" e all'operatore inglese la voce "Healthcare /
care". Sono etichette diverse. Entrambe corrispondono, nel JSON
esportato, allo stesso identificatore canonico sector_healthcare. Lo
stesso vale per i preset di scenario, le categorie di dati, i vettori
di rischio e i passaggi della timeline: ciò che cambia è sempre e solo
il testo mostrato, mai la chiave salvata nell'export.

Questo principio ha un'eccezione dichiarata, non un'incoerenza: il
perimetro giurisdizionale. L'edizione Italy / Switzerland riconosce un
identificatore it (Italia come giurisdizione autonoma) che l'edizione
Europe / Switzerland non usa, perché in quest'ultima l'Italia è solo
uno dei Paesi selezionabili nel catalogo Europa/UE-SEE. Il contratto
canonico tratta questo caso in modo esplicito, distinguendo un nucleo
di framework giurisdizionali obbligatorio (comune a entrambe le
edizioni) da un insieme più ampio di framework consentiti, in cui
un'edizione può includere un identificatore aggiuntivo senza rompere la
compatibilità con l'altra. Il paragrafo 5.9 riprende questo punto in
dettaglio.

Nel contesto Prudentia, la tokenizzazione non va intesa come oscuramento
magico o anonimizzazione automatica. Va intesa come disciplina di
rappresentazione.

Tokenizzare significa sostituire elementi variabili, sensibili o
identificativi con riferimenti controllati, coerenti e riutilizzabili.

Invece di scrivere il nome reale di un fornitore, si può usare
FORNITORE_A.
Invece di indicare una persona, si può usare DIPENDENTE_1 o
RESPONSABILE_FINANZA.
Invece di nominare un sistema reale, si può usare
SISTEMA_CRITICO_1.
Invece di indicare una banca, si può usare BANCA_OPERATIVA.
Invece di riportare un'autorità specifica quando non serve, si può
indicare la categoria o la giurisdizione.

Questa pratica ha due vantaggi.

Il primo è la minimizzazione. Il caso può essere discusso, simulato o
trasformato senza esporre più del necessario.

Il secondo è l'interoperabilità. Un caso tokenizzato è più facile da
condividere tra moduli, lingue, team o organizzazioni, perché conserva
la struttura del problema riducendo il peso degli identificativi reali.

La tokenizzazione non deve servire a nascondere responsabilità o
alterare il senso del caso. Deve servire a separare il pattern operativo
dal dossier identificativo.

La formula è: togliere l'identità quando non serve, conservare la
struttura quando serve a decidere.

La minimizzazione non è solo una cautela privacy. È anche una condizione
di collaborazione.

Due enti possono avere bisogno di confrontarsi su uno schema di rischio
senza condividere l'intero dossier. Due controllori di Paesi diversi
possono discutere una dinamica comune senza esporre subito dati
identificativi. Un fornitore e un cliente possono simulare una catena di
risposta senza scambiarsi tutti i dettagli interni. Un gruppo
multinazionale può far lavorare team locali su versioni linguistiche
diverse, mantenendo coordinate comuni.

In questi casi, il JSON strutturato e tokenizzato può diventare un
ponte.

La collaborazione tra enti richiede sempre accordi, basi giuridiche,
procedure, autorizzazioni e perimetri chiari. CertiSigma Prudentia Suite non sostituisce
queste condizioni. Aiuta però a preparare materiali più ordinati, più
minimizzati e più comprensibili.

La collaborazione migliora quando il materiale condiviso non è un
dossier grezzo, ma una rappresentazione controllata del problema.

CertiSigma Prudentia Suite è composta da moduli diversi, ma il ragionamento che li
attraversa è continuo.

Blindspot serve a individuare lacune, omissioni, fragilità e domande non
ancora poste.

Drill serve a trasformare un rischio o una lacuna in esercizio,
simulando pressioni, tempi, ruoli, complicazioni e decisioni.

Prompt Builder serve a costruire una richiesta controllata verso un
AI/LLM, mantenendo chiari contesto, livello di certezza, destinatario
diretto, limiti dell'output e cautele informative.

L'interoperabilità tra moduli permette di non ricominciare ogni volta da
zero.

Una lacuna emersa in Blindspot può suggerire uno scenario Drill.
Una simulazione Drill può produrre un verbale o un caso da usare per
una richiesta AI controllata.
Un prompt costruito nel Prompt Builder può essere salvato e
confrontato con una versione successiva.
Un caso corrente può essere confrontato con un salvataggio precedente
per capire che cosa è cambiato, che cosa è stato aggiunto e che cosa
resta incerto.

Questa continuità riduce dispersione e perdita di contesto. Il
ragionamento operativo non resta intrappolato in una pagina, ma può
diventare percorso.

La prospettiva più interessante riguarda l'interoperabilità tra enti
differenti.

In molti casi, un evento o una simulazione non resta dentro una sola
organizzazione. Può coinvolgere fornitori, clienti, consulenti,
autorità, gruppi societari, controllori, enti pubblici, partner tecnici
o soggetti in Paesi diversi.

La collaborazione tra questi soggetti è spesso difficile perché ciascuno
usa strumenti, lingue, procedure e categorie diverse. Anche quando tutti
vogliono collaborare, manca un formato comune per descrivere il caso
senza esporre troppo.

CertiSigma Prudentia Suite può contribuire a questo problema con oggetti JSON strutturati
e minimizzati.

Un ente può condividere uno scenario tokenizzato.
Un altro può importarlo, tradurlo o adattarlo.
Un controllore può chiedere una versione ridotta di una simulazione.
Due team in Paesi diversi possono confrontare le rispettive letture
dello stesso pattern.
Un gruppo internazionale può costruire scenari comuni mantenendo
differenze locali di lingua e autorità.

Ogni condivisione richiede valutazione. La presenza di un formato
strutturato, però, aiuta a costruire scambi più sobri, meno ambigui e
più controllabili.

Prompt Builder contiene già una logica utile per questa prospettiva:
nella parte di interrogazione AI sono stati censiti molti enti,
autorità, destinatari e ruoli rilevanti.

Questa scelta non trasforma la suite in un elenco esaustivo né in un
consulente normativo. Serve a dare all'operatore una grammatica più
ordinata per formulare richieste.

Quando l'operatore prepara un prompt, non deve limitarsi a dire "*scrivi
una comunicazione" o "prepara una risposta*". Deve chiarire a quale
tipo di interlocutore sta pensando, quale ruolo deve avere l'AI, quale
livello di dettaglio è adeguato, quali autorità o soggetti possono
essere rilevanti, quali elementi devono restare esclusi e quale
validazione sarà necessaria.

La presenza di enti e autorità censiti aiuta a evitare formulazioni
troppo vaghe. Aiuta anche a costruire versioni future più interoperabili
tra giurisdizioni e lingue.

Un caso può coinvolgere autorità diverse a seconda del Paese. Una
richiesta può dover essere riformulata in modo diverso se il
destinatario finale potenziale è un management interno, un DPO, un
regolatore, un fornitore, un auditor, un soggetto pubblico o un team
tecnico. Il JSON può conservare queste coordinate in modo più stabile di
un testo libero.

Questa è una delle basi dell'interoperabilità: tradurre parole non
basta; bisogna riconoscere ruoli.

L'interoperabilità diventa particolarmente rilevante quando più
controllori, enti o soggetti regolati operano in Paesi differenti.

In questi casi, la difficoltà non è soltanto linguistica. Cambiano
autorità, procedure, soglie, tempi, categorie, prassi documentali e
sensibilità organizzative. Tuttavia, molti pattern operativi restano
comparabili: una catena di fornitura, un uso improprio di credenziali,
una richiesta fraudolenta, una comunicazione AI troppo ricca, un ritardo
di escalation, una patch non immediata, una simulazione di crisi, una
duplicazione documentale, una risposta a management o autorità.

Un formato strutturato consente di separare ciò che è comune da ciò che
è locale.

Il pattern può essere condiviso.
La lingua può cambiare.
Le autorità possono essere mappate.
I dettagli identificativi possono essere tokenizzati.
Le decisioni locali possono restare nel perimetro dell'ente che le
prende.

Questo è particolarmente utile nella formazione congiunta. Due enti di
Paesi diversi possono lavorare sullo stesso scenario e confrontare come
cambiano responsabilità, tempi, comunicazioni e cautele. Il valore non
sta nell'uniformare tutto, ma nel rendere confrontabile ciò che
altrimenti resterebbe disperso.

Il pacchetto CertiSigma Prudentia Suite applica questo principio anche al proprio
contratto tecnico, non solo al ragionamento dell'operatore. I framework
normativi riconosciuti dal sistema sono divisi in due insiemi: un
nucleo obbligatorio, identico in entrambe le edizioni (Europa/UE-SEE
e Svizzera), e un insieme consentito, che ogni edizione può
estendere senza rompere la compatibilità con l'altra. L'edizione Italy
/ Switzerland estende l'insieme consentito con l'Italia come
giurisdizione autonoma, coerente con la propria utenza. L'edizione
Europe / Switzerland non lo fa, e tratta l'Italia come un Paese fra gli
altri nel catalogo autorità europeo. Nessuna delle due estensioni è più
"corretta": sono estensioni locali legittime sopra un nucleo comune, e
il validatore locale (capitolo 4) verifica che restino tali — cioè che
un'edizione non ometta un framework obbligatorio né introduca un
framework arbitrario fuori contratto.

Tokenizzazione, hash e attestazione sono tre livelli diversi.

La tokenizzazione serve a rappresentare un caso riducendo o sostituendo
elementi identificativi. È una tecnica di minimizzazione e struttura.

L'hash serve a riconoscere una versione esatta di un file. È una
impronta del contenuto.

L'attestazione serve a fissare che un certo hash esisteva in un certo
momento. È una prova minima di esistenza.

Nel percorso Prudentia questi tre livelli possono lavorare insieme.

Prima si tokenizza il caso per ridurre esposizione e renderlo più
condivisibile.
Poi si salva il JSON o l'export come file.
Poi si calcola l'hash per riconoscere quella versione.
Infine, se la versione rappresenta una milestone, si può attestare
l'hash.

Questa sequenza è potente perché conserva riservatezza e tracciabilità.

Il contenuto reale resta governato dall'organizzazione. La versione
tokenizzata può circolare con più prudenza. L'hash consente di
riconoscerla. L'attestazione può dimostrare che quella versione esisteva
in un certo momento.

Ogni livello ha un limite. La tokenizzazione non autorizza condivisioni
indiscriminate. L'hash non prova la qualità del contenuto.
L'attestazione non prova la correttezza del ragionamento. Insieme, però,
creano una disciplina più solida della semplice circolazione di file
nominati a mano.

Una tentazione da evitare è pensare che interoperabilità significhi
creare un grande database centrale.

CertiSigma Prudentia Suite segue una logica diversa. L'interoperabilità può nascere anche
da strumenti locali, file strutturati, identificatori stabili, export
verificabili e scambi intenzionali.

L'organizzazione può lavorare localmente.
Può esportare solo ciò che serve.
Può tokenizzare ciò che non deve essere identificativo.
Può condividere un JSON con un altro ente solo quando esiste una
ragione.
Può attestare l'hash senza caricare il contenuto.
Può mantenere separati dossier reale, scenario derivato e materiale
formativo.

Questa è un'interoperabilità sobria. Non forza la concentrazione dei
dati, non trasforma ogni caso in una registrazione centrale e non impone
che tutti usino la stessa infrastruttura.

Permette piuttosto a strumenti e soggetti diversi di riconoscere
strutture comuni quando serve.

Il pacchetto stesso è la dimostrazione più diretta di questo principio.
Il livello condiviso common/ (capitolo 2) non è un server, non è un
registro, non è un punto di raccolta dati: è un piccolo insieme di file
statici — identificatori canonici, controlli di coerenza, fogli di
stile — caricato localmente da ciascuna edizione al momento
dell'apertura della pagina, esattamente come qualsiasi altro asset
dell'applicazione. Le due edizioni restano prodotti separati,
scaricabili, modificabili e distribuibili indipendentemente; ciò che
condividono è la grammatica con cui riconoscono i rispettivi export,
non un'infrastruttura comune di esecuzione.

La prospettiva multilingue è particolarmente importante per un progetto
aperto.

Se le versioni linguistiche della suite condividono identificatori
stabili, gli scenari possono essere tradotti, confrontati e migliorati
senza perdere coerenza. Un contributo nato in una lingua può essere
adattato in un'altra. Un esercizio costruito in un Paese può diventare
materiale formativo in un altro. Un modulo custom può mantenere
compatibilità con la grammatica comune del progetto.

Questo crea una comunità di pratica.

La comunità non condivide necessariamente dossier reali. Condivide
pattern, scenari, categorie, cautele, esempi, mapping, miglioramenti
linguistici e modelli di collaborazione.

La lingua locale rende lo strumento usabile dagli operatori. La
struttura comune rende il contributo riutilizzabile da altri.

L'interoperabilità richiede strutture stabili. Per questo CertiSigma Prudentia Suite
include nella cartella dev/ uno strumento di verifica locale:
dev/validate.html.

Il validatore non è un modulo operativo da usare durante un caso. È uno
strumento di manutenzione per chi modifica, traduce, adatta o estende il
pacchetto.

Può essere aperto nel browser dalla stessa copia locale della suite. Una
volta avviato, carica modelli, cataloghi, scenari, schemi e mapping
interni, poi esegue controlli automatici sulla coerenza della versione.

L'elenco completo dei controlli eseguiti è riportato nel paragrafo 4.11.
Ai fini dell'interoperabilità, il punto da tenere a mente è che una
parte di questi controlli confronta esplicitamente il modello locale
dell'edizione aperta con il contratto canonico condiviso in
common/: settori, vettori, categorie di dati, preset di scenario,
passaggi della timeline e framework normativi. Il validatore distingue
un'estensione legittima (un'edizione che aggiunge un framework
consentito, come l'Italia nell'edizione Italy / Switzerland) da una
rottura del contratto (un identificatore mancante, alterato o inventato
fuori perimetro).

Il risultato viene presentato come resoconto con esiti OK, WARN e
FAIL.

OK indica che il controllo è passato.
WARN segnala una condizione da leggere con attenzione, ma non
necessariamente bloccante.
FAIL indica una rottura o una incoerenza da correggere prima di
distribuire la versione.

Questo strumento è particolarmente importante per l'interoperabilità. Un
JSON può parlare con altri moduli o versioni solo se le coordinate
interne restano leggibili. Una versione linguistica può funzionare
davvero solo se le etichette cambiano senza rompere identificatori,
mapping, schemi e cataloghi. Un pacchetto custom può essere condiviso
solo se la struttura resta coerente.

Il validatore controlla la struttura. L'operatore e il formatore
controllano il senso.

Una versione può superare il validatore e avere comunque testi poco
chiari, istruzioni troppo dense, esempi sbilanciati o scelte didattiche
discutibili. Per questo la verifica locale deve essere accompagnata dal
test umano nel browser.

La regola è semplice: ogni versione custom o linguistica dovrebbe essere
validata localmente prima di essere usata, condivisa, distribuita o
attestata.

Quando un'organizzazione modifica CertiSigma Prudentia Suite, produce una variante.
Questa variante può riguardare testi, scenari, cataloghi, autorità,
traduzioni, esempi, prompt, modelli formativi o riferimenti interni.

Una variante custom deve essere trattata come un oggetto governato.

Prima va provata nel browser.
Poi va validata con dev/validate.html.
Poi va inventariata, se necessario, con strumenti come Census.
Poi vanno cercati duplicati e file impropri.
Poi, se rappresenta una milestone, può essere salvata, hashata e
attestata.

Questa sequenza aiuta a evitare tre errori.

Il primo errore è distribuire una versione che funziona "a vista" ma
ha mapping rotti o identificatori incoerenti.

Il secondo errore è includere nel pacchetto file di lavoro, export
reali, bozze, prompt sensibili o materiali non destinati alla
distribuzione.

Il terzo errore è attestare una versione prima di averla davvero
controllata.

Il validatore locale si colloca quindi prima dell'attestazione. Aiuta a
rispondere alla domanda: la struttura regge?

Census e gli strumenti hash-only rispondono ad altre domande: quali file
contiene il pacchetto? Ci sono duplicati? Questa versione è rimasta
uguale? Questo hash esisteva in un certo momento?

Validazione, inventario, integrità e attestazione sono funzioni diverse.
Insieme rendono più affidabile una versione custom.

L'interoperabilità porta valore, ma introduce rischi.

Un JSON strutturato può sembrare più innocuo di un documento narrativo,
ma contenere informazioni sensibili. Un campo tecnico può rivelare un
sistema, un ruolo, una giurisdizione o una criticità. Una tokenizzazione
incompleta può lasciare elementi riconoscibili. Una traduzione può
cambiare sfumature operative. Una mappatura tra autorità può essere
interpretata come indicazione normativa anche quando serve solo a
orientare la richiesta. Una condivisione tra enti può diventare troppo
ampia se non viene governata.

Per questo l'operatore deve applicare le stesse cautele già viste:

minimizzare;
tokenizzare quando possibile;
separare caso reale, caso derivato e caso di esercizio;
validare prima di condividere;
distinguere struttura tecnica e decisione organizzativa;
conservare traccia delle versioni;
evitare che l'interoperabilità diventi automatismo.

La regola è: interoperabile non significa condivisibile senza
valutazione.

Il formatore può proporre un esercizio in cinque tempi.

Nel primo tempo, gli operatori costruiscono un caso semplice in Prompt
Builder e lo esportano come JSON. Devono identificare quali campi sono
contenuto operativo, quali sono coordinate, quali sono potenzialmente
sensibili e quali potrebbero essere tradotti senza cambiare significato.

Nel secondo tempo, gli operatori tokenizzano il caso: sostituiscono nomi
reali o elementi identificativi con ruoli, categorie o riferimenti
controllati.

Nel terzo tempo, gli operatori immaginano che lo stesso JSON debba
essere letto da un ente partner in un altro Paese. Devono chiedersi che
cosa può restare, che cosa va rimosso, che cosa va spiegato, quali
autorità o interlocutori cambiano e quali coordinate restano comuni.

Nel quarto tempo, gli operatori calcolano l'hash della versione
tokenizzata e discutono se abbia senso attestarla come milestone di
esercizio.

Nel quinto tempo, il formatore mostra dev/validate.html su una copia
modificata della suite. Gli operatori osservano la differenza tra una
modifica che cambia soltanto un'etichetta visibile e una modifica che
rompe un identificatore, un mapping o un catalogo.

L'obiettivo non è produrre un file perfetto. È imparare a vedere il JSON
come oggetto operativo: traducibile, verificabile, minimizzabile,
interoperabile, ma sempre sensibile.

L'interoperabilità è una delle prospettive più importanti di CertiSigma Prudentia Suite.

I JSON salvati dal sistema possono diventare oggetti di lavoro
condivisibili tra moduli, lingue, versioni e organizzazioni. La
tokenizzazione permette di separare pattern e dossier. Gli
identificatori stabili consentono a versioni linguistiche diverse di
riconoscere le stesse coordinate operative. La presenza di enti,
autorità e ruoli già censiti nel Prompt Builder prepara una grammatica
più ordinata per collaborazioni tra soggetti e Paesi diversi.

Questa prospettiva deve essere governata con prudenza. Interoperabilità
non significa centralizzazione, condivisione automatica o perdita di
controllo. Significa costruire oggetti strutturati che possono parlare
tra loro quando l'organizzazione decide che è opportuno.

Il validatore locale in dev/ rafforza questa prospettiva: chi
modifica o traduce la suite può controllare che la struttura resti
coerente prima di distribuire la propria versione.

La formula finale è questa: tradurre le parole è utile; rendere
interoperabile il ragionamento è molto più potente.

Blindspot è il modulo di readiness evidenziale: esplora le mancanze
di evidenze, ruoli, controlli e ownership, e le rende visibili quando
c'è ancora margine per agire.

Parte dalla normalità, non dalla crisi. Può muovere da una richiesta di
evidenze, da una revisione interna, da un controllo su un fornitore o da
un dubbio su accessi, log, backup, token, agenti AI o dipendenze opache.
Mette l'organizzazione davanti a ciò che oggi non saprebbe dimostrare in
modo ordinato - e lo fa in un contesto sicuro, senza aumentare la
pressione informativa.

In Blindspot un "non lo so" è un risultato prezioso. Il punto cieco
emerge quando c'è ancora tempo per assegnare un responsabile, cercare
una prova, verificare un processo o trasformare la lacuna in
esercitazione. Blindspot mostra dove l'organizzazione non saprebbe
rispondere bene: non tanto per mancanza di una policy, quanto per
mancanza di una prova disponibile, di una responsabilità chiara o di una
capacità di ricostruzione.

Cosa cerca Blindspot

Blindspot cerca le fragilità operative che diventano visibili quando
qualcuno chiede evidenze, andando oltre le sole vulnerabilità tecniche.

Una fragilità può essere una prova che dovrebbe esistere ma non è
reperibile, un owner non chiaro, una dipendenza da un fornitore esterno
mai mappata, un log che esiste ma non è esportabile, un processo che
vive nella memoria di una persona e non in una procedura. Può essere un
token ancora attivo, un account dimenticato, un connettore OAuth non
governato, un agente AI con permessi eccessivi, un backup mai testato in
ripristino.

Spesso il punto cieco non è un errore ma una zona grigia: tutti pensano
che qualcun altro possieda l'evidenza, e nessuno lo sa davvero.
Blindspot fa emergere queste zone prima che diventino incidenti,
contestazioni o risposte affrettate.

Come lavora Blindspot

Blindspot lavora per domande guidate. Accompagna l'utente dentro aree di
attenzione precise - evidenze, accessi, log, fornitori, processi,
responsabilità, dati, strumenti AI, automazioni, continuità operativa -
invece di chiedere un racconto libero.

Il modulo raccoglie uno snapshot organizzativo: non una fotografia
perfetta, ma una base di ragionamento su cosa sappiamo, cosa non
sappiamo, quali controlli possiamo dimostrare, quali ruoli sono chiari e
quali dipendenze restano opache.

Le risposte producono rilievi. Un rilievo è una domanda emersa con forza
sufficiente da meritare attenzione, non una condanna né una non
conformità automatica. Per esempio: «non è chiaro chi possieda
l'evidenza del test di ripristino»; oppure «il fornitore gestisce un
asset critico, ma il contratto non chiarisce tempi e canali di
notifica»; oppure «un'integrazione AI o OAuth potrebbe continuare ad
avere accesso dopo un cambio organizzativo».

L'output di Blindspot

L'output di Blindspot è pratico e azionabile. Va oltre l'etichetta
"rischio alto" o "rischio medio" e aiuta a capire cosa manca e che
tipo di azione serve.

Un buon output distingue quattro elementi: il punto cieco, l'evidenza
attesa, l'owner mancante o incerto e la possibile conseguenza operativa.
Se manca un log, il tema non è solo tecnico: durante un evento non si
potrà ricostruire bene cosa è successo. Se manca un owner, non è solo
organizzativo: durante una richiesta urgente nessuno saprà chi deve
rispondere. Se manca una clausola o un canale col fornitore, non è solo
contrattuale: durante una crisi si perderà tempo.

Blindspot produce quindi materiale utile per una discussione interna,
per un piano di miglioramento, per una richiesta di chiarimento a un
fornitore o per alimentare un'esercitazione Drill.

Blindspot come seme per Drill

Il passaggio più potente è che un punto cieco diventa un esercizio.
Quando una lacuna è abbastanza rilevante, Blindspot la trasforma in un
seed per Drill.

Se Blindspot mostra che non è chiaro dove vivano i log di accesso, Drill
può simulare un dubbio accesso non autorizzato. Se emerge una dipendenza
opaca da un fornitore SaaS, Drill può simulare una richiesta urgente del
cliente o un'anomalia comunicata dal fornitore. Se il tema riguarda
agenti AI, token o automazioni, Drill può creare uno scenario in cui
bisogna capire chi può revocare cosa, con quali prove e in quali tempi.

Come lavora tecnicamente Blindspot

Blindspot combina risposte dell'utente, sonde e regole preventive. Le
sonde sono domande strutturate; le regole trasformano combinazioni di
risposte in rilievi. Il risultato è una lettura dei punti ciechi,
offerta come base di ragionamento e non come diagnosi assoluta.

Il modulo produce un registro/piano e, quando opportuno, un seed per
Drill. Il seed non è un lungo documento narrativo: è un pacchetto
strutturato con le informazioni minime per far partire uno scenario
coerente. Blindspot è così, insieme, un modulo di scoperta e un
generatore di materiale per esercitazione.

Interoperabilità Blindspot → Drill

Blindspot esporta un seed pronto per Drill. Il seed trasporta, quando
disponibili, l'ID del rilievo Blindspot, il finding di origine, il
vettore Drill suggerito, il complicante Drill suggerito, una traccia
privacy/cyber, la giurisdizione e un percorso suggerito sotto
scenarios/drill/seeds/.

Drill importa questo seed e avvia uno scenario coerente. Se il seed
contiene un vettore o un complicante che non esiste più nel modello
Drill, l'app mostra un avviso e ripiega su una generazione coerente.
Così un aggiornamento del modello non rompe l'esercitazione: il seed
orienta, non comanda ciecamente.

Il valore concettuale è chiaro. Un punto cieco non resta un'annotazione:
diventa esercizio. Se manca una prova sui log, si costruisce uno
scenario in cui quei log servono. Se l'ownership è incerta, si
costruisce uno scenario in cui bisogna decidere chi risponde. Se un
fornitore è opaco, si simula una richiesta urgente di chiarimenti.

L'operatore deve usare Blindspot per far emergere ciò che
l'organizzazione non saprebbe dimostrare in modo ordinato.

Il modulo non serve a "dare un voto" alla sicurezza. Serve a produrre
una conversazione più precisa su evidenze, responsabilità, asset,
fornitori, log, backup, token, agenti AI, automazioni e continuità.

L'operatore deve imparare soprattutto tre posture.

La prima è accettare il valore del "non sappiamo". In Blindspot, una
risposta incerta non è un fallimento della sessione. È il materiale
stesso della sessione. Se nessuno sa dove si trova una prova, chi è
l'owner o se un token è ancora attivo, il modulo sta già producendo
valore.

La seconda è distinguere dichiarazione ed evidenza. Una persona può dire
che un controllo esiste. Blindspot chiede se quel controllo è
dimostrabile, localizzabile, esportabile, aggiornato e riferibile a un
owner.

La terza è trasformare la lacuna in azione. Il punto cieco deve
diventare decisione, owner, scadenza, evidenza attesa oppure seed per
Drill.

La frase da tenere davanti durante l'uso è questa: Blindspot non cerca
colpe, cerca prove mancanti prima che servano davvero.

Blindspot va usato quando l'organizzazione sente una domanda di
evidenza, anche prima di un incidente.

È particolarmente utile quando:

un cliente chiede prove su sicurezza, backup, logging, fornitori o
incident response;
il management chiede se l'organizzazione sarebbe pronta davanti a un
evento cyber o data breach;
un fornitore critico cambia condizioni, limita log, modifica
subfornitori o non chiarisce l'exit plan;
emerge un dubbio su API key, token, OAuth, webhook, account tecnici o
agenti AI;
un reparto usa strumenti AI, note taker o automazioni senza piena
governance;
si vuole preparare un'esercitazione Drill partendo da fragilità
reali;
si vuole capire se un controllo dichiarato è anche dimostrabile;
si sta preparando una revisione interna, una richiesta al fornitore o
una discussione con DPO, CISO, legal, compliance o management.

Blindspot è meno adatto quando l'organizzazione ha già un incidente in
pieno corso e ha bisogno di triage tecnico immediato. In quel caso può
servire dopo, per ricostruire lacune e miglioramenti, oppure prima, se
l'evento è ancora un dubbio e non una crisi qualificata.

Prima di aprire ESR-BLINDSPOT.html, l'operatore deve preparare il
contesto minimo.

Serve decidere su quale perimetro si lavora. Può essere un reparto, un
servizio, un fornitore, una famiglia di strumenti AI, un processo di
offboarding, un insieme di backup, una richiesta di un cliente, una
revisione interna o una simulazione.

Serve decidere se il caso è reale, derivato o di esercizio.

Nel caso reale, l'operatore deve minimizzare ogni riferimento
identificativo. L'organizzazione può essere descritta in modo generico,
il fornitore può diventare FORNITORE_A, il sistema può diventare
SISTEMA_CRITICO_1, la persona può diventare DIPENDENTE_1 o
OWNER_IT.

Nel caso derivato, l'operatore conserva la struttura del problema e
rimuove gli elementi identificativi.

Nel caso di esercizio, l'operatore può usare scenari fittizi, baseline
demo o scenario pack incorporati.

Serve anche decidere come verranno gestiti gli output. L'export cifrato
è la modalità consigliata per trasferire un dossier Blindspot. Gli
export TXT, JSON e CSV in chiaro sono disponibili, ma il modulo stesso
avverte che possono descrivere debolezze reali, owner, fornitori, token,
log mancanti e decisioni non dimostrate.

L'operatore può aprire Blindspot dalla home di prodotto
italy-switzerland/index.html oppure direttamente da
italy-switzerland/ESR-BLINDSPOT.html. Questa home è distinta dal
selettore radice del pacchetto (paragrafo 2.1bis): il selettore serve a
scegliere l'edizione, la home di prodotto è il punto di ingresso
ordinario una volta scelta.

In alto trova il titolo Blindspot e una descrizione sintetica:

Blindspot fa emergere ciò che manca prima che condizioni il giudizio.
Non valuta la sicurezza dichiarata; aiuta a distinguere evidenze
disponibili, evidenze mancanti, ownership incerte e decisioni non ancora
dimostrate.

Questa frase è la bussola dell'intero modulo.

Subito sotto compare una nota di perimetro. L'operatore deve leggerla
sempre, soprattutto in formazione:

Blindspot supporta la readiness evidenziale. Non è audit, SoA, gap
analysis, pentest o certificazione. Può lavorare su casi reali o
simulati, ma gli output distinguono ciò che è noto, mancante, dichiarato
o da validare.

Il formatore deve fermarsi qui e chiarire un punto: se l'operatore usa
Blindspot per dire "siamo conformi" o "siamo non conformi", lo sta
usando male. Se lo usa per dire "*queste evidenze ci sono, queste
mancano, questi owner sono incerti, queste decisioni vanno prese*", lo
sta usando correttamente.

La prima parte operativa contiene i campi che definiscono il contesto
del caso.

Scenario

Il campo Scenario permette di scegliere uno scenario dal catalogo. Lo
scenario determina quali sonde verranno attivate. Non è una
classificazione definitiva del caso; è un modo per iniziare con un set
coerente di domande.

Gli scenari incorporati coprono, tra gli altri:

Revisione uso AI nei reparti;
Revisione API key e segreti;
Verifica backup e continuità;
Richiesta board su resilienza operativa;
Supply chain ICT critica;
Cliente enterprise chiede evidenze entro venerdì;
Help desk e reset MFA;
Readiness interna su evidenze e controlli;
Preparazione NIS2 readiness;
Offboarding di ex dipendente critico;
Revisione fornitore SaaS critico;
Shadow AI nel reparto HR.

L'operatore deve scegliere lo scenario più vicino alla domanda
operativa, non quello più drammatico. Se il tema riguarda un ex
dipendente con automazioni e token, lo scenario adatto è
Offboarding di ex dipendente critico. Se il problema riguarda un
cliente che chiede prove, è più adatto
Cliente enterprise chiede evidenze entro venerdì. Se la domanda
riguarda AI nei reparti, si sceglie Revisione uso AI nei reparti o
Shadow AI nel reparto HR.

Label caso / intervento

Il campo Label caso / intervento serve a dare un nome interno alla
sessione.

Non deve contenere informazioni inutilmente identificative. Un buon
label può essere:

Q3 readiness fornitori SaaS;
esercizio backup e log;
review AI HR tokenizzata;
offboarding automazioni - caso derivato;
richiesta evidenze cliente enterprise.

Un label debole o rischioso è quello che contiene nomi reali, importi,
riferimenti contrattuali sensibili o dettagli che non servono. Il nome
del caso può finire negli export o nel metadata dell'operazione cifrata;
va quindi scelto con disciplina.

Organizzazione

Il campo Organizzazione è opzionale e va usato solo se non
identificativo o se l'uso del nome è appropriato nel contesto.

In formazione conviene lasciarlo vuoto o usare formule come
organizzazione demo, ente pubblico simulato,
azienda SaaS fittizia, controllore A.

In un caso reale, l'operatore deve valutare se il nome
dell'organizzazione sia necessario. Spesso non lo è, soprattutto se il
dossier dovrà essere esportato, attestato, condiviso o usato come base
per un prompt.

Settore

Il campo Settore aiuta il modulo a contestualizzare la lettura.

Le opzioni disponibili sono:

non specificato;
generico / organizzazione;
sanitario;
scuola / formazione;
ente pubblico / servizio pubblico;
SaaS / software house;
e-commerce;
servizio essenziale o importante / NIS2.

Il settore incide sulla lettura di alcuni livelli. Per esempio, se il
settore è sanitario oppure "servizio essenziale o importante / NIS2",
alcune aree opache possono diventare più esposte perché il contesto
operativo è più sensibile.

Il modulo non produce una valutazione legale automatica, ma usa il
contesto per alzare l'attenzione dove la lacuna può avere impatti
maggiori.

Queste etichette sono la versione italiana di un set di identificatori
condivisi con l'edizione Europe / Switzerland (paragrafo 5.3):
"sanitario" corrisponde a sector_healthcare, "e-commerce" a
sector_ecommerce, e così per gli altri valori. Un rilievo tokenizzato
per settore resta quindi riconoscibile anche se letto, in fase di
confronto, da un operatore che lavora sull'edizione inglese.

Uso AI / automazioni

Il campo Uso AI/automazioni chiede quanto l'organizzazione usa AI,
agenti, note taker, workflow o automazioni.

Le opzioni sono:

non so;
assente;
limitato;
diffuso.

La risposta non so è utile quando nessuno ha una visione affidabile.
Non va corretta "a sentimento". Se l'operatore non sa se reparti,
fornitori o team usano note taker, strumenti di generazione, workflow
no-code, agenti o app OAuth, deve lasciare emergere quella incertezza.

La risposta diffuso deve spingere l'operatore a guardare con
attenzione le sonde su owner, kill switch, prompt/log, note taker, OAuth
shadow e ricostruibilità delle azioni degli agenti.

Dati personali

Il campo Dati personali chiede se il perimetro coinvolge dati
personali.

Le opzioni sono:

non so;
sì;
no.

La risposta non so è già un punto di attenzione. In molti casi
l'organizzazione non sa se log, prompt, trascrizioni, ticket,
esportazioni, note taker o workflow contengano dati personali. Blindspot
serve proprio a rendere visibile questa zona.

La risposta sì può alzare il livello di alcuni rilievi, soprattutto
quando la lacuna riguarda token, AI o backup. L'operatore deve
intenderlo come un invito alla prudenza, non come determinazione
automatica di violazione.

Perimetro seed Prudentia Drill

Il campo Perimetro seed Prudentia Drill indica la giurisdizione di
ragionamento da portare nei seed generati per Drill.

Le opzioni sono:

Europa / UE-SEE;
Italia;
Svizzera;
Cross-border Svizzera ↔ Europa.

Questa scelta è utile quando un rilievo Blindspot viene trasformato in
scenario Drill. Il seed trasporta anche questa coordinata, così
l'esercitazione successiva nasce già orientata al perimetro scelto.

L'operatore deve scegliere il perimetro più coerente con la simulazione.
Se l'organizzazione lavora tra Svizzera e UE, il cross-border è spesso
più adatto. Se il caso riguarda solo una funzione italiana, si può
scegliere Italia. Se il punto è europeo ma lo Stato specifico non è
ancora chiaro, Europa / UE-SEE è una scelta prudente.

L'opzione Italia è specifica dell'edizione Italy / Switzerland.
Nell'edizione Europe / Switzerland questo campo offre solo Europa /
UE-SEE, Svizzera e cross-border; l'Italia resta selezionabile come
Paese all'interno del perimetro europeo, non come perimetro a sé
(paragrafo 5.3).

Blindspot offre tre modi principali per iniziare.

Avviare dal punto cieco

Il primo percorso è Parti dal punto cieco.

L'operatore sceglie uno scenario nel campo Scenario e clicca
Avvia il percorso.

Questa è la via più semplice quando si vuole iniziare da una domanda
operativa. Il modulo prende lo scenario selezionato, carica le regole
collegate e genera le sonde da compilare.

Il formatore deve far notare che "Avvia il percorso" non produce
subito il risultato. Produce le domande. Il risultato arriverà solo dopo
la compilazione e il click su Genera Exposure Register.

Caricare uno scenario pronto

La seconda via è Oppure carica uno scenario pronto.

Qui l'operatore usa il menu Scenario pack e clicca
Carica scenario scelto.

Gli scenario pack sono già inclusi nel catalogo
scenarios/blindspot/. Non serve cercare file, non serve un
server, non serve una connessione. Il catalogo è caricato localmente
come parte del pacchetto.

Questa via è utile in formazione, perché il formatore può far partire
tutti dallo stesso scenario. È utile anche quando l'organizzazione ha
aggiunto scenari custom e vuole renderli disponibili come pacchetti
incorporati.

Caricare la baseline demo

Il pulsante Carica baseline demo importa una baseline dimostrativa.

La baseline demo serve a vedere come una baseline precedente può
precompilare risposte e riferimenti. Non deve essere confusa con la
situazione reale dell'organizzazione. In aula è utile per mostrare il
flusso completo senza dover costruire subito una baseline da zero.

La sezione Importa file esterni o riprendi una sessione contiene
funzioni avanzate.

Importa scenario pack JSON

Questo pulsante permette di importare uno scenario pack esterno.

Il file deve avere lo schema atteso
ESR_BLINDSPOT_SCENARIO_PACK_SCHEMA. Se lo schema non è corretto, il
modulo lo rifiuta.

Questa funzione serve quando un'organizzazione o un formatore ha creato
scenari propri fuori dal catalogo incorporato.

Importa baseline JSON

Questo pulsante importa una baseline di readiness evidenziale.

La baseline deve avere schema ESR_BLINDSPOT_ISMS_BASELINE_SCHEMA. Una
baseline contiene valori collegati alle regole Blindspot e può essere
usata per precompilare le sonde.

L'operatore deve trattare una baseline come dossier sensibile. Può
indicare controlli non provati, owner incerti, evidenze mancanti,
dipendenze da fornitori e criticità organizzative.

Importa resoconto JSON/TXT

Questa funzione importa un resoconto Blindspot precedente.

Il modulo riconosce i JSON esportati e, nel caso di TXT, cerca il blocco
macchina compreso tra:

== ESR-BLINDSPOT MACHINE DATA ==
== END ESR-BLINDSPOT MACHINE DATA ==

Questo significa che anche un export TXT può contenere dati strutturati
reimportabili. L'operatore deve quindi trattare il TXT come file
sensibile, anche se sembra un semplice resoconto leggibile.

Importa dossier cifrato

Questa funzione importa un dossier cifrato.

L'operatore deve inserire la passphrase corretta nel campo
Passphrase dossier. Se la passphrase è errata o il file non è
valido, il modulo non può decifrare il contenuto.

Questa è la modalità consigliata quando si trasferisce un dossier
Blindspot tra browser, dispositivi o operatori autorizzati.

Blindspot include una sezione per il vault cifrato locale.

I campi sono:

Passphrase dossier;
Conferma passphrase;
checkbox autosalva nel vault cifrato;
Mostra passphrase;
Salva vault cifrato;
Ripristina vault;
Cancella vault;
Pulisci localStorage;
Nuovo caso.

La passphrase deve avere almeno 12 caratteri. Il modulo non salva la
passphrase e non può recuperarla. Se viene persa, il vault cifrato non è
recuperabile.

Autosalva nel vault cifrato

La checkbox autosalva nel vault cifrato attiva il salvataggio
locale cifrato nel browser.

Quando viene usata per la prima volta, il modulo chiede conferma. Il
messaggio chiarisce che il browser conserverà solo un envelope cifrato,
che la passphrase non viene salvata e che conviene usare una sola
sessione attiva alla volta per evitare sovrascritture.

Questa funzione è utile quando l'operatore sta lavorando a una sessione
che potrebbe richiedere pause. Il vault non deve però essere trattato
come archivio ufficiale. È un salvataggio locale cifrato, non un sistema
documentale.

Salva vault cifrato

Il pulsante Salva vault cifrato forza un salvataggio manuale nel
vault.

Va usato dopo passaggi significativi: dopo aver compilato le sonde, dopo
aver generato i rilievi, dopo aver assegnato decisioni e owner, dopo
aver costruito il piano.

Ripristina vault

Il pulsante Ripristina vault decifra il vault nel browser e
ripristina la sessione.

Serve quando l'operatore riapre il modulo e vuole continuare il lavoro
salvato. Richiede la stessa passphrase usata per salvare.

Cancella vault

Il pulsante Cancella vault rimuove dal browser il vault cifrato del
caso e, nella versione attuale, anche il vault locale della
struttura/profilo salvato da Prompt Builder. La sessione corrente resta
visibile finché non viene pulita, chiusa o sostituita.

Va usato quando si lavora su macchina non dedicata, quando il lavoro è
stato esportato e non deve restare localmente, oppure quando si vuole
eliminare anche la struttura locale conservata dal modulo. L'operazione
riguarda il salvataggio locale cifrato nel browser, non gli eventuali
file già esportati.

Pulisci localStorage

Il pulsante Pulisci localStorage rimuove tutti i dati locali Prudentia
Suite da quel browser.

È più ampio di Cancella vault: riguarda la suite nel suo complesso,
non solo il caso Blindspot. Va usato con attenzione, perché l'operazione
non è reversibile.

Nuovo caso

Il pulsante Nuovo caso azzera contesto, baseline in memoria, rilievi
correnti e vault locale di questa sessione.

L'operatore deve usarlo quando vuole ricominciare da zero. Il modulo
chiede conferma, perché l'operazione cancella dati sensibili in memoria
locale.

Il pulsante Percorso readiness snapshot apre un percorso opzionale
e leggero.

La schermata stessa chiarisce il perimetro: non è uno Statement of
Applicability, non è audit e non è gap analysis. Serve a creare o
aggiornare una baseline di readiness evidenziale. I valori inseriti
precompilano le sonde Blindspot e aiutano a rendere visibili le evidenze
mancanti.

Questa funzione va usata quando l'organizzazione vuole preparare una
base prima della sessione principale o aggiornare una baseline
periodica.

Campi generali dello snapshot

Il pannello chiede:

Nome baseline;
Owner baseline;
Perimetro / unità;
Prossimo riesame.

Il nome baseline deve essere chiaro ma prudente. Esempi:

readiness snapshot AI e token Q3;
baseline fornitori SaaS;
snapshot backup e logging;
baseline demo formazione.

L'owner baseline è la persona o funzione che risponde dell'aggiornamento
dello snapshot. Può essere CISO, DPO, IT manager, responsabile
compliance, responsabile del servizio, facilitatore della sessione.

Il perimetro deve dire a che cosa si riferisce la baseline: servizi
SaaS, reparto HR, backup, CRM, fornitori ICT, workflow AI, help desk,
log API.

Il prossimo riesame serve a evitare che la baseline diventi un documento
morto. Blindspot ragiona su readiness evidenziale; la readiness
invecchia rapidamente.

Campi dello snapshot per ciascun controllo

Per ogni voce, il modulo mostra:

label del controllo;
stato;
owner;
evidenza / riferimento;
note.

Gli stati disponibili sono:

Non interrogato;
Evidenza disponibile;
Evidenza parziale;
Evidenza vecchia;
Controllo dichiarato ma non provato;
Owner incerto;
Dipendenza da fornitore;
Non sappiamo;
Non applicabile motivato.

L'operatore deve compilare lo snapshot con la stessa disciplina usata
nelle sonde. Evidenza disponibile va scelta solo quando l'evidenza
esiste, è localizzabile e può essere richiamata.
Controllo dichiarato ma non provato va scelto quando qualcuno dice che
il controllo esiste ma non c'è una prova disponibile. Owner incerto va
scelto quando più funzioni sembrano coinvolte ma nessuna risponde
davvero. Dipendenza da fornitore va scelto quando l'evidenza o il
controllo dipende da un soggetto esterno.

Salvare ed esportare lo snapshot

Il pulsante Salva snapshot nella baseline salva i valori nello stato
interno del modulo. Da quel momento le sonde useranno quei valori come
precompilazione.

Il pulsante Export readiness snapshot JSON esporta la baseline in
chiaro. Il modulo avverte che si tratta di un file sensibile.

Il pulsante Export snapshot cifrato esporta la baseline cifrata. È la
scelta preferibile quando lo snapshot deve essere trasferito o
conservato fuori dalla sessione.

Il pulsante Chiudi chiude il pannello senza trasformare lo snapshot in
audit o documento di conformità.

Dopo aver scelto scenario e contesto, l'operatore clicca
Avvia il percorso.

Il modulo genera un elenco di sonde. Ogni sonda corrisponde a una regola
preventiva del modello Blindspot.

Ogni sonda mostra:

la superficie, per esempio identity, tokens, ai, logging,
suppliers, backup, continuity, incident_readiness;
il livello default, per esempio Opaco, Esposto,
Critico preventivo, Presidiato ma non provato;
la domanda guida;
i campi di risposta.

La superficie aiuta a capire l'area del problema. Il livello default
aiuta a capire la gravità preventiva della lacuna se la risposta
conferma opacità o mancanza. La domanda guida è il cuore della sonda.

Per ogni sonda l'operatore compila cinque campi:

Risposta;
Owner;
Asset/processo/fornitore;
Evidenza;
Note.

Risposta

Il campo Risposta contiene le opzioni principali.

Non sappiamo va usato quando l'organizzazione non ha una risposta
affidabile. È una risposta legittima e spesso molto utile. Genera un
rilievo.

Evidenza disponibile va usato solo quando l'evidenza esiste, è
localizzabile e può essere indicata. Questa risposta non genera rilievo,
perché il modulo assume che la prova sia presente.

Evidenza parziale va usato quando qualcosa esiste ma non basta:
documento incompleto, log non esportabile, prova non aggiornata,
evidenza limitata a un sistema, procedura non coperta, informazione non
verificata.

Evidenza vecchia va usato quando la prova esiste ma non è recente o
non è più affidabile per il perimetro corrente. Un restore test di anni
prima, una lista token non aggiornata o una vecchia revisione del
fornitore rientrano in questa categoria.

Owner incerto va usato quando nessuna funzione risponde chiaramente
del controllo, della prova o della decisione. Anche questa risposta
genera rilievo.

Dipendenza da fornitore va usato quando la prova, il log, la notifica,
il controllo o la continuità dipendono da un fornitore, subfornitore,
SaaS, cloud provider, consulente o altro soggetto esterno. Il punto non
è accusare il fornitore, ma rendere visibile la dipendenza.

Controllo dichiarato ma non provato va usato quando l'organizzazione
crede che il controllo esista, ma non sa produrre evidenza. È una delle
risposte più importanti in Blindspot, perché distingue governance
dichiarata e readiness dimostrabile.

Non applicabile motivato va usato solo se la sonda davvero non
riguarda il perimetro. Deve essere motivato nelle note. Come
Evidenza disponibile, questa risposta non genera rilievo.

Owner

Il campo Owner indica chi dovrebbe rispondere della prova, del
controllo o della decisione.

Può essere una persona, un ruolo o una funzione. In formazione e nei
casi derivati è meglio usare ruoli: IT operations, DPO, CISO,
responsabile HR, service owner, vendor manager, legal,
help desk lead.

Se l'owner non è noto, non bisogna inventarlo. È meglio lasciare
emergere l'incertezza e usare la risposta Owner incerto.

Asset/processo/fornitore

Questo campo serve a localizzare il punto cieco.

Può contenere un asset tecnico, un processo, un reparto, una
piattaforma, un fornitore o un servizio. Esempi:

CRM SaaS;
workflow onboarding;
backup sistema documentale;
FORNITORE_A;
note taker riunioni HR;
API integrazione fatturazione;
help desk reset MFA.

Il campo deve essere specifico abbastanza da rendere l'azione successiva
possibile, ma non più identificativo del necessario.

Evidenza

Il campo Evidenza deve indicare dove si trova, o dove dovrebbe
trovarsi, la prova.

Esempi:

contratto fornitore, sezione incident notification;
ticket restore test 2026-05;
export log SIEM;
registro API key;
policy offboarding;
verbale esercitazione IR;
screenshot console admin;
documento non trovato.

Se la prova manca, si può scrivere non localizzata, non disponibile,
da chiedere al fornitore, solo dichiarata, non esportabile.

Note

Il campo Note serve a precisare senza trasformare ipotesi in fatti.

Buone note sono:

il team IT ritiene che il log esista, ma non è stato esportato durante la sessione;
il contratto menziona incident notification ma non indica SLA operativo;
il fornitore dichiara restore test, evidenza non ricevuta;
possibile presenza dati personali nei prompt, da verificare;
owner indicato informalmente, nessuna responsabilità formalizzata.

Note deboli sono quelle assertive senza prova: tutto ok, sicuro,
grave, colpa del fornitore, compliance non rispettata. Blindspot
lavora meglio quando la nota separa osservazione, ipotesi e azione.

Dopo aver compilato le sonde, l'operatore clicca
Genera Exposure Register.

Il modulo legge tutte le risposte. Per ogni sonda:

se la risposta è Evidenza disponibile, il modulo non genera rilievo;
se la risposta è Non applicabile motivato, il modulo non genera
rilievo;
negli altri casi genera un rilievo.

Il rilievo riceve un identificativo progressivo: EXP-001, EXP-002,
EXP-003 e così via.

Ogni rilievo contiene:

ID;
finding;
livello;
stato evidenza;
sonda di origine;
decisione;
owner azione;
scadenza;
evidenza attesa;
eventuale scenario Prudentia Drill;
eventuale motivo di override.

Il modulo non dice "questo è un incidente" e non dice "*questa è una
violazione*". Dice: questa lacuna merita attenzione.

I livelli principali sono:

Controllato;
Presidiato ma non provato;
Opaco;
Esposto;
Critico preventivo.

Presidiato ma non provato indica che qualcosa probabilmente esiste, ma
non è stato dimostrato in modo sufficiente.

Opaco indica una zona poco chiara: responsabilità, evidenza, catena,
logica o dipendenza non sono abbastanza visibili.

Esposto indica una lacuna che può avere conseguenze operative
rilevanti.

Critico preventivo indica una fragilità che può diventare molto
difficile da gestire durante un evento, soprattutto su token, AI,
backup, identità non umane o sistemi critici.

Il modulo può alzare il livello in base al contesto. Se sono coinvolti
dati personali, settore sanitario o servizio essenziale/importante,
alcune opacità vengono trattate con maggiore severità. Questo non è un
giudizio legale automatico; è una regola di prudenza.

L'operatore può modificare il livello nel campo Livello, ma deve
compilare Motivo override quando cambia la valutazione proposta.
Questo è importante: l'override non deve essere un modo per far apparire
il caso meno problematico. Deve essere una decisione spiegabile.

Ogni rilievo contiene il campo Decisione.

Le opzioni operative includono:

da decidere;
mitigare entro 7 giorni;
mitigare entro 30 giorni;
inserire nel piano 90 giorni;
sospendere accesso/token/workflow;
chiedere evidenza al fornitore;
aggiornare contratto;
programmare test.

L'operatore deve scegliere una decisione coerente con il rilievo.

Se il tema è un token non censito o un workflow AI non interrompibile,
può essere appropriato sospendere accesso/token/workflow oppure
mitigare entro 7 giorni.

Se il problema è una clausola fornitore debole, può essere appropriato
chiedere evidenza al fornitore o aggiornare contratto.

Se il punto è un restore test vecchio, può essere appropriato
programmare test.

Se il tema è strutturale ma non immediato, può essere appropriato
inserire nel piano 90 giorni.

La decisione deve essere accompagnata da Owner azione, Scadenza ed
Evidenza attesa. Senza questi tre elementi, il rilievo resta
conversazione.

Owner azione indica chi deve fare o coordinare il passo successivo.
Può essere diverso dall'owner della sonda. Per esempio, la sonda può
riguardare un fornitore, ma l'azione può essere assegnata al vendor
manager o al legal.

Scadenza indica quando l'azione deve essere completata o riesaminata.
Può essere una data, una finestra o una milestone: entro 7 giorni,
prima del board, entro prossimo comitato sicurezza, 30/09/2026.

Evidenza attesa indica che cosa deve esistere alla fine dell'azione.
Questo campo è fondamentale. Blindspot non deve generare "*fare
qualcosa", ma "produrre o recuperare una prova*".

Esempi di evidenza attesa:

registro aggiornato API key e owner;
export log accessi ultimi 90 giorni;
verbale restore test con esito e tempi;
clausola fornitore su notifica incidente;
lista app OAuth autorizzate;
procedura kill switch agente AI;
messaggio interno preallarme validato;
mappa escalation UE/SEE-Svizzera.

Dopo aver rivisto i rilievi, l'operatore clicca Genera piano 7/30/90.

Il modulo costruisce un piano diviso in tre finestre:

7 giorni;
30 giorni;
90 giorni.

La logica è semplice. I rilievi Critico preventivo e quelli con
decisione collegata ai 7 giorni entrano nel blocco 7 giorni. I rilievi
Esposto e quelli con decisione collegata ai 30 giorni entrano nel
blocco 30 giorni. Gli altri finiscono nel blocco 90 giorni, salvo
decisioni diverse.

Il piano mostra per ciascun rilievo:

rilievo e livello;
azione;
owner;
evidenza.

Il formatore deve spiegare che il piano non è una roadmap completa di
sicurezza. È una lista di azioni evidenziali prioritarie. Serve a
evitare che i rilievi restino in un registro senza seguito.

Se un rilievo è derivabile in Drill, Blindspot mostra il pulsante
Export seed Prudentia Drill.

Il seed è un file JSON pensato per avviare uno scenario Drill coerente
con il punto cieco emerso.

Il seed contiene:

schema ESR_DRILL_SEED_SCHEMA;
source ESR_BLINDSPOT;
versione;
ID del rilievo Blindspot;
finding di origine;
vettore Drill suggerito;
complicante Drill suggerito;
traccia privacy/cyber;
giurisdizione;
percorso suggerito sotto scenarios/drill/seeds/;
nota d'uso.

Il browser non scrive automaticamente nella cartella
scenarios/drill/seeds/. Scarica il file. L'operatore può poi
salvarlo manualmente nella cartella suggerita, se sta lavorando sul
pacchetto estratto.

Il seed è utile quando il rilievo merita esercitazione. Per esempio:

log di accesso non chiari → scenario di dubbio accesso non
autorizzato;
owner escalation incerto → scenario con richiesta urgente di
decisione;
fornitore opaco → scenario con indisponibilità o ritardo di notifica;
agente AI senza kill switch → scenario in cui bisogna sospendere
un'automazione;
backup non testato → scenario con richiesta di ripristino sotto
pressione.

Il seed non è un verdetto. Orienta il modulo Drill.

Blindspot permette diversi export.

Export dossier cifrato

Il pulsante Export dossier cifrato produce un file JSON cifrato.

Questa è la modalità consigliata per trasferire il dossier Blindspot.
Richiede passphrase e conferma passphrase. Il file esportato può essere
importato con Importa dossier cifrato.

L'operatore deve usare una passphrase robusta, conservarla separatamente
e trasmetterla con canale adeguato se il dossier deve essere condiviso.

Export TXT in chiaro

Il pulsante Export TXT in chiaro produce un resoconto leggibile.

Prima dell'export, il modulo mostra un avviso: il file può descrivere
debolezze reali, owner, fornitori, token, log mancanti e decisioni non
dimostrate. La modalità consigliata per trasferire dossier Blindspot è
l'export cifrato.

Il TXT contiene anche dati macchina reimportabili. Va quindi trattato
come dossier sensibile, non come semplice nota.

Export JSON in chiaro

Il pulsante Export JSON in chiaro produce un file strutturato.

È utile per interoperabilità, analisi, reimportazione o uso tecnico.
Proprio perché strutturato, può contenere molte coordinate del caso. Va
gestito con attenzione.

Export CSV in chiaro

Il pulsante Export CSV in chiaro produce una tabella dei rilievi.

È utile per lavorare su decisioni, owner, scadenze e piano. Può però
rendere molto visibili le lacune dell'organizzazione. Va conservato e
condiviso con lo stesso livello di cautela degli altri export.

Export baseline

Il pulsante Export baseline esporta la baseline corrente.

Va usato quando si vuole conservare o trasferire lo snapshot di
readiness evidenziale. Anche qui, la baseline può contenere informazioni
sensibili.

Stampa

Il pulsante Stampa manda la pagina in stampa.

L'operatore deve ricordare che la stampa può produrre copie cartacee o
PDF locali. Anche il PDF generato dal sistema operativo va trattato come
export sensibile.

Vicino ai comandi di piano ed export compare l'opzione
includi baseline completa.

Se non viene selezionata, l'export contiene solo il sottoinsieme di
baseline toccato dallo scenario corrente. Questo riduce il contenuto
esportato e segue la logica di minimizzazione.

Se viene selezionata, l'export include la baseline completa.

L'operatore deve selezionare questa opzione solo quando serve davvero.
Una baseline completa può rivelare molte più informazioni della sessione
corrente: aree non discusse, controlli vecchi, owner incerti, dipendenze
da fornitori, evidenze mancanti.

La regola è: esportare il sottoinsieme quando basta; includere la
baseline completa solo con una ragione.

L'Exposure Register non è una lista di colpe. È una lista di punti che
possono esporre l'organizzazione se qualcuno chiede evidenze, se arriva
un incidente, se un fornitore non risponde, se il management chiede una
sintesi, se una decisione deve essere presa sotto pressione.

Ogni rilievo va letto con quattro domande:

qual è il punto cieco?
quale evidenza ci aspettiamo?
chi deve produrla, confermarla o chiederla?
che cosa succede se serve durante un evento reale?

L'operatore deve evitare due errori.

Il primo è minimizzare il rilievo perché "in pratica lo sappiamo".
Blindspot chiede evidenza, non sensazione.

Il secondo è drammatizzare il rilievo come se fosse già un incidente. Un
punto cieco è un invito all'azione, non una condanna.

L'esempio più utile per la formazione è Revisione uso AI nei reparti.

Contesto

Il DPO o il management chiedono evidenze su agenti, note taker, prompt,
log e workflow.

L'operatore compila:

Label caso / intervento: review AI reparti - caso demo;
Organizzazione: vuoto oppure organizzazione demo;
Settore: generico / organizzazione oppure settore coerente;
Uso AI/automazioni: diffuso se l'organizzazione usa strumenti AI
in più reparti;
Dati personali: non so o sì, a seconda del perimetro;
Perimetro seed Prudentia Drill: Europa / UE-SEE o altro perimetro
coerente.

Poi clicca Avvia il percorso.

Sonde tipiche

Il modulo può chiedere:

chi è l'owner dell'agente AI o del workflow e chi può sospenderlo;
come si spegne l'automazione in emergenza;
dove sono conservati prompt, output e log AI;
quali riunioni o sportelli vengono trascritti da note taker AI;
chi approva app OAuth, connettori SaaS e integrazioni AI;
se è possibile ricostruire cosa ha fatto un agente AI o un workflow.

Compilazione prudente

Se l'organizzazione sa che alcuni reparti usano AI, ma non ha un
registro, la risposta corretta a molte sonde sarà Non sappiamo,
Controllo dichiarato ma non provato o Owner incerto.

Nel campo Owner, l'operatore può scrivere da assegnare, DPO?,
IT?, HR?, oppure lasciare visibile l'incertezza.

Nel campo Asset/processo/fornitore, può indicare
note taker riunioni HR, workflow sintesi ticket,
strumenti AI reparto marketing, connettori documentali.

Nel campo Evidenza, può scrivere registro non disponibile,
policy AI in bozza, log non localizzati, da verificare con IT.

Nel campo Note, può precisare:
uso dichiarato dai reparti, assente inventario centralizzato.

Rilievi attesi

L'Exposure Register potrebbe generare rilievi come:

agente AI senza owner operativo;
automazione non interrompibile;
prompt/log AI non governati o non localizzati;
trascrizione AI non presidiata;
OAuth shadow access;
azioni agente non ricostruibili.

L'operatore assegna decisioni:

mitigare entro 7 giorni per kill switch assente su workflow
critico;
mitigare entro 30 giorni per inventario prompt/log;
chiedere evidenza al fornitore se retention e localizzazione
dipendono da un provider;
programmare test se bisogna verificare sospensione dell'automazione.

Poi genera il piano 7/30/90 ed eventualmente esporta seed Drill per
esercitare lo scenario.

Lo scenario Offboarding di ex dipendente critico è utile perché
mostra identità non umane, token e automazioni.

Domanda operativa

Un ex dipendente aveva creato automazioni, OAuth, API key o workflow
no-code. L'organizzazione vuole sapere se l'offboarding ha revocato
anche questi accessi.

Compilazione

Uso AI/automazioni: limitato o diffuso;
Dati personali: non so o sì;
Settore: coerente con l'organizzazione;
Perimetro seed: giurisdizione di esercizio.

Le sonde possono riguardare:

offboarding di OAuth, API key, webhook e workflow;
inventario token e account tecnici;
rotazione API key;
approvazione app OAuth;
webhook attivi;
kill switch automazioni.

Risposte tipiche

Se l'organizzazione revoca l'account umano ma non sa cosa succede a
token e workflow, la risposta deve essere
Controllo dichiarato ma non provato o Non sappiamo.

Se esiste una lista di API key ma non è aggiornata, si sceglie
Evidenza vecchia.

Se il controllo è in mano a un fornitore SaaS, si sceglie
Dipendenza da fornitore.

Azioni

I rilievi possono portare a:

sospendere token o workflow;
ruotare API key critiche;
inventariare app OAuth;
identificare owner per ogni integrazione;
creare procedura offboarding per identità non umane;
esercitare in Drill un caso di accesso persistente dopo uscita di un
dipendente.

Questo scenario insegna una cosa fondamentale: l'identità da revocare
non è più solo la persona. Sono anche le sue automazioni.

Questo scenario simula una pressione molto realistica.

Un cliente strategico chiede prove su sicurezza, fornitori, accessi,
backup, logging e incident response entro pochi giorni.

Blindspot serve a evitare una risposta affrettata e troppo rassicurante.

Compilazione

L'operatore seleziona lo scenario, inserisce un label come
richiesta evidenze cliente enterprise - demo, evita nomi reali del
cliente e compila contesto e perimetro.

Le sonde possono riguardare log fornitore, tempi di notifica, restore
test, retention log, playbook testato, escalation.

Lettura

Se il restore test esiste ma è vecchio, si usa Evidenza vecchia.

Se il fornitore dichiara log ma non garantisce tempi o formato, si usa
Controllo dichiarato ma non provato o Dipendenza da fornitore.

Se il playbook non è stato testato, si usa Evidenza vecchia o
Presidiato ma non provato, secondo la situazione.

Output utile

L'Exposure Register può diventare base per una risposta interna al
management:

quali evidenze sono pronte;
quali richiedono recupero;
quali dipendono da fornitori;
quali non vanno promesse al cliente senza verifica;
quali azioni possono essere prese entro 7 o 30 giorni.

La formazione deve chiarire che Blindspot non serve a scrivere
direttamente la risposta al cliente. Serve a evitare che la risposta
prometta prove che l'organizzazione non possiede.

Il primo errore è scegliere Evidenza disponibile quando l'evidenza è
solo ricordata. Una policy citata a memoria non è evidenza disponibile.
Un log che "dovrebbe esserci" non è evidenza disponibile. Un contratto
che nessuno ha aperto durante la sessione non è evidenza disponibile.

Il secondo errore è riempire tutti i campi con testi generici. Scrivere
IT, sistema, documenti, da vedere aiuta poco. Meglio indicare un
ruolo, un asset o una prova concreta, anche se tokenizzati.

Il terzo errore è usare Non applicabile motivato per evitare un
rilievo. Questa opzione va usata solo quando il perimetro è davvero
escluso e la motivazione è scritta nelle note.

Il quarto errore è abbassare manualmente i livelli senza motivo. Se il
livello viene modificato, il campo Motivo override deve spiegare
perché.

Il quinto errore è esportare in chiaro per comodità. Gli export in
chiaro sono utili, ma devono essere una scelta consapevole. Il dossier
cifrato è la modalità più coerente con casi reali o derivati.

Il sesto errore è generare il registro e fermarsi lì. Blindspot produce
valore quando i rilievi diventano decisioni, owner, scadenze, evidenze
attese o esercitazioni Drill.

Il formatore deve evitare di trasformare Blindspot in una checklist
meccanica.

La sessione dovrebbe seguire questo ritmo:

prima si spiega il perimetro;
poi si sceglie lo scenario;
poi si compila il contesto;
poi si avviano le sonde;
poi si risponde con disciplina;
poi si genera l'Exposure Register;
poi si rilegge ogni rilievo;
poi si assegnano decisioni, owner e scadenze;
poi si genera il piano;
poi si decide che cosa esportare, cifrare, attestare o trasformare in
Drill.

Durante la compilazione, il formatore deve proteggere il valore del
dubbio. Se un partecipante dice "non lo so", il formatore non deve
forzare una risposta. Deve chiedere: "chi lo saprebbe?", "*dove
dovrebbe trovarsi la prova?", "in quanto tempo potremmo averla?*",
"se servisse in emergenza, chi la produrrebbe?".

Queste domande sono più importanti del click.

L'operatore non deve leggere il JavaScript per usare Blindspot.
Tuttavia, in formazione avanzata può essere utile spiegare che il modulo
funziona con una logica semplice e verificabile.

Il file assets/data/ESR-BLINDSPOT-model.js contiene le regole e le
sonde. Ogni regola ha:

un id;
una surface;
una probe;
un finding;
un defaultLevel;
un mapping.

Questo significa che le domande non sono generate in modo opaco da un
modello AI. Sono sonde dichiarate nel pacchetto.

Il file scenarios/blindspot/ESR-BLINDSPOT-scenarios.js contiene
gli scenario pack. Ogni scenario indica quali regole attivare.

Il file assets/data/ESR-INTEROP-model.js contiene il contratto di
interoperabilità tra Blindspot e Drill. Qui si decide come un rilievo
Blindspot può diventare seed Drill.

Il file assets/js/ESR-BLINDSPOT.js contiene la logica applicativa:
legge il contesto, mostra le sonde, raccoglie risposte, genera rilievi,
costruisce piani, esporta file e gestisce il vault cifrato.

Questa struttura è importante per la cultura operativa. Blindspot non è
una scatola nera che inventa giudizi. È un modulo dichiarativo e
modificabile: scenari, sonde e mapping possono essere letti, validati e
adattati.

Chi modifica Blindspot deve sapere dove intervenire.

Per aggiungere o modificare sonde e regole si lavora su
assets/data/ESR-BLINDSPOT-model.js.

Per aggiungere scenari si lavora su
scenarios/blindspot/ESR-BLINDSPOT-scenarios.js.

Per modificare l'interoperabilità verso Drill si lavora su
assets/data/ESR-INTEROP-model.js.

Ogni modifica deve poi essere verificata con il validatore locale
dev/validate.html.

Una personalizzazione prudente deve rispettare alcune regole:

gli ID devono restare stabili e coerenti;
le sonde devono cercare evidenze, non colpe;
i finding devono essere formulati come rilievi operativi;
i livelli devono restare proporzionati;
gli scenari devono essere realistici ma non offensivi;
i casi reali devono essere generalizzati prima di diventare scenario
condivisibile;
i mapping verso Drill devono orientare, non comandare ciecamente.

La personalizzazione più utile nasce dall'esperienza: se durante una
sessione emerge un punto cieco ricorrente non coperto dal modello, può
diventare una nuova sonda o un nuovo scenario.

Prima di chiudere la sessione, l'operatore deve verificare:

il label del caso è prudente e non eccessivamente identificativo;
il settore, l'uso AI, i dati personali e il perimetro seed sono
coerenti;
le risposte Evidenza disponibile sono supportate da riferimenti
concreti;
le risposte Non applicabile motivato hanno una motivazione;
i rilievi sono stati riletti e non accettati meccanicamente;
gli override di livello hanno un motivo;
ogni rilievo importante ha decisione, owner, scadenza ed evidenza
attesa;
il piano 7/30/90 è stato generato e letto;
i seed Drill sono stati esportati solo per rilievi da esercitare;
l'export cifrato è stato preferito quando il dossier è sensibile;
gli export in chiaro sono stati trattati come dossier di sicurezza;
il vault locale è stato salvato o cancellato secondo il contesto;
eventuali file esportati sono stati collocati in una cartella
controllata;
eventuali hash o attestazioni riguardano solo versioni davvero chiuse.

Blindspot è il modulo che insegna all'organizzazione a vedere prima ciò
che altrimenti emergerebbe troppo tardi.

Il suo valore non sta nel produrre un registro lungo. Sta nel
trasformare l'incertezza in domande verificabili, le domande in rilievi,
i rilievi in azioni, e le azioni in evidenze attese o esercitazioni
Drill.

Un operatore formato deve uscire da Blindspot con cinque risultati:

sapere che cosa manca;
sapere chi dovrebbe occuparsene;
sapere quale prova serve;
sapere entro quando agire;
sapere quale punto cieco merita di diventare simulazione.

La formula finale è questa: un "non lo so" detto in Blindspot è molto
meno costoso di un "non lo sappiamo" detto durante una crisi.

Drill esercita una risposta organizzativa e osserva come
l'organizzazione decide, documenta e comunica. Può partire da scenari
simulati, da casi reali opportunamente astratti o da un seed generato da
Blindspot.

È una tabletop exercise, un'esercitazione a tavolino. Può essere usata
anche per ragionare su un caso reale, ma non sostituisce gestione
formale dell'incidente, analisi forense, valutazioni legali o procedure
interne. Il centro non è recitare una crisi, ma osservare il metodo. Chi
decide? Chi documenta? Quali evidenze vengono preservate? Quali ruoli
vengono coinvolti? Quando entra il DPO? Quando entra il legale? Quando
si chiede al fornitore? Quando una comunicazione è prematura? Quando
un'ipotesi viene scambiata per un fatto?

Drill parte da scenari pronti, da casi costruiti internamente o da un
seed generato da Blindspot. Una lacuna sulle evidenze si trasforma in
una simulazione su accesso non autorizzato, backup non verificato,
fornitore opaco, token dimenticato, output AI condiviso in modo
improprio o richiesta urgente del cliente.

Perché serve una simulazione

Molte organizzazioni scoprono i propri problemi solo durante un evento
reale, quando il costo dell'apprendimento è alto: si decide sotto
pressione, si comunica troppo presto, si coinvolgono tardi le persone
giuste, si confondono fatti e ipotesi, si perde traccia di chi ha deciso
cosa.

Drill sposta questo apprendimento a monte dell'evento. Non evita ogni
incidente, ma riduce la probabilità che l'organizzazione risponda nel
modo peggiore. L'obiettivo non è dimostrare che tutti sono perfetti: è
osservare dove il processo si rompe - chi non sa cosa fare, quali
evidenze mancano, quali canali non sono chiari, quali decisioni restano
sospese.

Un esercizio riuscito non è quello in cui tutto fila liscio, ma quello
in cui emergono le fragilità giuste, senza danni reali.

La struttura di uno scenario Drill

Uno scenario Drill è una pressione costruita, non un racconto generico.

Di solito contiene un evento iniziale, un perimetro, alcuni ruoli, un
set di vincoli, dati o asset potenzialmente coinvolti, informazioni
incomplete, complicanti e domande di debrief. Il facilitatore può far
avanzare il tempo - prime ore, giornata, giorni successivi, revisione
finale - e ogni fase cambia le domande.

All'inizio si capisce cosa è noto e cosa è solo sospetto. Poi si decide
chi coordina, chi documenta, chi conserva le evidenze, chi parla con il
fornitore, chi valuta la privacy, chi gestisce il legale, chi informa la
direzione. Più avanti si valuta se e quando comunicare, quali verifiche
sono sufficienti, quali decisioni vanno motivate e quali informazioni
non devono uscire.

La forza di Drill è che non chiede solo «qual è la risposta corretta?».
Chiede «come ci arrivate?».

Ruoli e decisioni

In un evento reale la competenza tecnica non basta: servono ruoli
chiari. Un responsabile IT sa quali log guardare, ma non decide da solo
se comunicare a un cliente. Un DPO orienta la valutazione privacy, ma ha
bisogno di fatti tecnici. Un avvocato valuta obblighi e contratti, ma
deve sapere cosa è successo e cosa è solo ipotizzato. La direzione
prende decisioni, e dovrebbe farlo su un quadro chiaro, non su
impressioni confuse.

Drill rende visibile questo intreccio. Mostra se i ruoli sono davvero
attivabili, se esiste un responsabile della documentazione, se le
decisioni vengono registrate, se i fornitori hanno canali e tempi
definiti, se la comunicazione interna è controllata. L'esercitazione non
cerca un colpevole: verifica se il sistema organizzativo regge.

Evidenze e debrief

Il debrief è uno degli aspetti più importanti di Drill. Finito lo
scenario, oltre a raccontare come è andata, si chiede cosa è mancato.

Quale evidenza sarebbe servita? Chi avrebbe dovuto averla? Quanto tempo
è stato perso per capire chi decideva? Quale ipotesi è stata trattata
come fatto? Quale comunicazione sarebbe stata prematura? Quale fornitore
ha un ruolo non abbastanza governato? Quale registro, policy, log,
contratto o procedura non ha retto alla prova?

Il debrief trasforma l'esercizio in miglioramento. È ciò che fa di Drill
uno strumento di readiness e non solo una simulazione interessante.

Gli scenari pronti e gli scenari estesi

Drill parte dagli scenari pronti per essere subito operativo, e cresce
da lì. Ogni organizzazione ha superfici diverse: fornitori, dati, ruoli,
strumenti AI e pressioni diversi.

Per questo Drill si alimenta da Blindspot e, in prospettiva, anche da
Prompt Builder. Blindspot fornisce i punti ciechi; Prompt Builder può
produrre una traccia strutturata per trasformare una richiesta o un
dubbio in scenario. Il risultato è una catena virtuosa: si vede una
lacuna, la si mette sotto pressione, si osserva la risposta, si migliora
il processo.

Come lavora tecnicamente Drill

Drill usa un modello di scenario che può avere vettori, dati,
complicanti, ruoli, tempi, scale, domande del facilitatore e criteri di
debriefing.

Il modulo genera una sessione da preset, da selezioni dell'utente o da
seed importato da Blindspot. Durante l'esercitazione l'utente segue un
clock, annota decisioni, osserva evidenze, produce un verbale e usa il
debrief per trasformare lo scenario in azioni correttive. Drill non
simula tecnicamente un attacco: simula la capacità organizzativa di
rispondere a una pressione.

Interoperabilità Blindspot → Drill

Blindspot esporta un seed pronto per Drill. Il seed trasporta, quando
disponibili, l'ID del rilievo Blindspot, il finding di origine, il
vettore Drill suggerito, il complicante Drill suggerito, una traccia
privacy/cyber, la giurisdizione e un percorso suggerito sotto
scenarios/drill/seeds/.

Drill importa questo seed e avvia uno scenario coerente. Se il seed
contiene un vettore o un complicante che non esiste più nel modello
Drill, l'app mostra un avviso e ripiega su una generazione coerente.
Così un aggiornamento del modello non rompe l'esercitazione: il seed
orienta, non comanda ciecamente.

Il valore concettuale è chiaro. Un punto cieco non resta un'annotazione:
diventa esercizio. Se manca una prova sui log, si costruisce uno
scenario in cui quei log servono. Se l'ownership è incerta, si
costruisce uno scenario in cui bisogna decidere chi risponde. Se un
fornitore è opaco, si simula una richiesta urgente di chiarimenti.

L'operatore deve usare Drill per allenare il comportamento
dell'organizzazione sotto pressione.

Drill non è il modulo con cui si "risolve" un incidente. È il modulo
con cui si osserva se l'organizzazione sa:

rallentare senza paralizzarsi;
distinguere fatti, ipotesi e mancanze;
attivare ruoli sostitutivi quando manca una persona chiave;
documentare decisioni provvisorie;
preservare evidenze;
chiedere log a fornitori;
valutare rischio per le persone;
evitare comunicazioni premature;
separare pista privacy e pista cyber;
trasformare l'esercizio in piano di miglioramento.

La postura corretta è questa: durante Drill non si cerca la risposta
perfetta. Si cerca il controllo.

Controllo significa sapere chi decide, chi esegue, chi documenta, quali
evidenze servono, che cosa non è ancora noto e quali parole non devono
essere usate fuori dalla stanza.

Il formatore deve ripetere questa idea più volte: un esercizio Drill
riuscito non è quello in cui il team appare brillante. È quello in cui
il team scopre, senza danno reale, dove si sarebbe bloccato.

Drill va usato quando l'organizzazione vuole mettere alla prova una
risposta, non solo descriverla.

È particolarmente utile quando:

un punto cieco emerso in Blindspot merita una simulazione;
un fornitore critico non ha canali o tempi di risposta chiari;
una procedura di incident response esiste ma non è mai stata provata;
il management chiede "siamo pronti?";
il DPO o il legale vogliono capire come arriverebbero i fatti;
il team IT vuole verificare se log, backup, token e accessi sono davvero
governati;
l'organizzazione usa AI, agenti, workflow, note taker o automazioni e
vuole simulare un abuso;
si vuole allenare una comunicazione interna o esterna prudente;
si vuole trasformare una lacuna in azioni 4/24h e piano 7/30/90;
si vuole produrre un verbale di esercitazione da conservare come
evidenza formativa.

Drill può essere usato anche su casi reali o derivati da casi reali, se
gestito da operatori competenti e con cautele informative. In quel caso
il caso deve essere minimizzato, tokenizzato o astratto quando
possibile. Il modulo non deve diventare il luogo dove riversare l'intero
dossier reale.

Prima di aprire ESR-DRILL.html, il facilitatore deve decidere quattro
cose.

La prima è il tipo di sessione: demo, formazione, esercitazione interna,
caso derivato o ragionamento su caso reale.

La seconda è chi vede che cosa. Drill prevede due viste: Team e
Facilitatore. La vista Team non anticipa le iniezioni. La vista
Facilitatore mostra scaletta, domande guida e punti chiave. In
un'esercitazione vera, il team non dovrebbe vedere la scaletta
riservata.

La terza è il perimetro informativo. Prima della sessione bisogna
stabilire se si useranno dati fittizi, dati tokenizzati o informazioni
reali. Se si usano elementi reali, il facilitatore deve ridurre ciò che
non serve: nomi, importi, dettagli contrattuali, nomi di fornitori,
sistemi riconoscibili, persone coinvolte.

La quarta è la gestione degli output. Il verbale Drill può contenere
debolezze reali, decisioni provvisorie, ruoli mancanti, incertezze su
notifiche, lacune contrattuali, carenze di log, criticità AI o punti non
ancora validati. Va trattato come documento sensibile.

L'operatore apre Drill dalla home di prodotto
(italy-switzerland/index.html) oppure direttamente da
italy-switzerland/ESR-DRILL.html. Come per Blindspot, questa home è
distinta dal selettore radice del pacchetto (paragrafo 2.1bis).

In alto trova il titolo Drill e una descrizione sintetica:

Drill simula una pressione controllata: un dubbio, una violazione, un
incidente o una richiesta urgente. L'obiettivo è allenare decisioni,
evidenze, ruoli e comunicazioni, non produrre una diagnosi automatica.

Subito sotto compare una nota di perimetro:

È una tabletop exercise. Può lavorare su casi reali, simulati o derivati
da casi reali se gestiti con cautela. Non sostituisce incidente formale,
DPO, legale, forense o procedure interne.

Questa nota va letta in aula. È la barriera contro due usi sbagliati:
trattare Drill come gioco, oppure trattarlo come sistema ufficiale di
incident management.

Drill è serio, ma resta un esercizio di risposta. Se durante una
sessione emergono elementi reali di incidente, si deve passare alle
procedure interne.

La schermata iniziale offre due vie principali.

La prima è Parti da uno scenario controllato. Qui l'operatore sceglie
scenario, settore, profilo, intensità, stile, giurisdizione, traccia
cyber e vista. Il modulo costruisce una pressione controllata senza
importare file.

La seconda è Oppure carica uno scenario pronto o derivato. Qui
l'operatore può caricare uno scenario dal catalogo, un seed Blindspot,
un TXT esportato, un seed JSON o un dossier cifrato.

La differenza è formativa.

Lo scenario controllato è utile quando si vuole costruire una sessione
nuova.
Lo scenario pronto è utile quando il formatore vuole far partire tutti
da una traccia già preparata.
Il seed Blindspot è utile quando si vuole esercitare una lacuna emersa
prima.
Il TXT importato è utile quando si vuole riprendere una sessione
esportata.
Il dossier cifrato è utile quando si vuole trasferire una sessione
sensibile tra ambienti autorizzati.

Il campo Scenario guidato è il primo controllo del percorso
controllato.

Le opzioni disponibili sono:

Casuale - pesca vettore, dati, scala e complicazioni;
Sanità - dispositivo smarrito con dati clinici;
E-commerce - chiave API esposta e accessi al CRM;
Servizi HR/payroll - violazione presso fornitore cloud;
Ente pubblico / servizio pubblico - agente AI su pratiche e cartelle;
Azienda SaaS - agente AI con accesso a mail e CRM;
Supply chain critica (NIS2 UE/SEE / UFCS) - data sharing o servizio impattato;
Identità federata / SSO - accesso multi-servizio compromesso.

Queste opzioni non sono "casi legali". Sono preset per costruire
pressione organizzativa.

Casuale è utile in aula quando si vuole mostrare la varietà del
modello. Per una sessione seria, però, il facilitatore dovrebbe
scegliere uno scenario coerente con il perimetro dell'organizzazione.

Sanità allena categorie particolari di dati, rischio per persone e
urgenza di ricostruzione.

E-commerce porta su API key, CRM, accessi, profilazione, phishing
mirato e scala ampia.

Servizi HR/payroll mette sotto pressione fornitore, dati dipendenti,
contratti, log e responsabilità.

Ente pubblico / servizio pubblico è utile per agenti AI, pratiche,
protocolli e documenti amministrativi.

Azienda SaaS porta su agenti AI, mail, CRM, connettori e accessi
persistenti.

Supply chain critica allena la doppia pista: privacy e cyber, con
attenzione a NIS2, UFCS e dipendenze da soggetti terzi.

Identità federata / SSO costringe a guardare oltre la password:
sessioni, token, app enterprise, trust, gruppi e servizi collegati.

Il campo Settore adatta il contesto.

Le opzioni sono:

Generico / multisettore;
Sanità / assistenza;
E-commerce / negozio online;
Servizi professionali / HR / legale;
Ente pubblico / servizio pubblico;
Scuola / ente di formazione;
Azienda digitale / SaaS / servizi cloud.

Il settore non determina da solo obblighi o conclusioni. Serve a
orientare dati, ruoli, esempi e pressione.

Il facilitatore deve scegliere il settore più utile all'apprendimento,
non quello più grave. Se la sessione riguarda HR, si scelga
Servizi professionali / HR / legale. Se riguarda un sistema scolastico
o studenti, si scelga Scuola / ente di formazione. Se il punto è un
servizio cloud o un agente con accesso a CRM e mail,
Azienda digitale / SaaS / servizi cloud sarà più coerente.

Il campo Profilo scenario determina il tipo di minaccia o pressione.

Le opzioni sono:

Misto - classico + moderno;
Classico - incidenti tradizionali;
AI / automazioni / agenti;
Estremo verosimile - raro ma plausibile.

Misto è spesso il profilo più didattico, perché combina incidenti
tradizionali e superfici moderne.

Classico è utile per ransomware, phishing, dispositivo smarrito, invio
errato, esposizione repository, insider o fornitore.

AI / automazioni / agenti porta il team su prompt injection, shadow
AI, app OAuth, workflow no-code, agenti browser, token, note taker e
retention dei prompt.

Estremo verosimile serve a simulare condizioni rare ma plausibili,
come deepfake helpdesk, pressione video, richiesta fraudolenta
credibile, o concatenazione tra phishing generativo e accessi federati.

Il formatore deve usare Estremo verosimile con cautela. Non serve a
spettacolarizzare. Serve a mostrare che il falso può apparire credibile.

Il campo Intensità stabilisce quante complicazioni verranno inserite.

Le opzioni sono:

Base - solo l'incidente;
Realistica - 1 complicazione;
Difficile - 2 complicazioni;
Stress test - 3 complicazioni.

L'intensità è una leva didattica.

Base è utile per onboarding o primo uso del modulo. Il team si
concentra su decisione iniziale, ruoli, registro, rischio e piano.

Realistica aggiunge una complicazione e costringe il team a
rivalutare.

Difficile crea più pressione e mostra se la catena decisionale regge.

Stress test va usato solo con un gruppo maturo. Tre complicazioni
possono produrre rumore se il team non ha ancora capito il metodo.

La regola del formatore è: aumentare intensità solo quando il team
riesce a documentare, non quando riesce a parlare molto.

Il campo Stile facilitazione determina il tono della sessione.

Le opzioni sono:

Didattico - spiega il perché;
Audit - evidenze e responsabilità;
Crisi - pressione e reputazione.

Didattico è adatto alla formazione iniziale. Il facilitatore si ferma
spesso, chiede perché, chiarisce concetti e trasforma ogni dubbio in
apprendimento.

Audit spinge su evidenze, owner, registro, documentazione e
responsabilità. È utile quando l'organizzazione vuole capire che cosa
saprebbe dimostrare.

Crisi introduce pressione reputazionale e decisionale. È utile per
management, comunicazione, direzione e sessioni mature.

Lo stile non cambia la natura del modulo. Cambia il modo in cui il
facilitatore conduce la conversazione.

Il campo Giurisdizione orienta la cornice privacy/cyber.

Le opzioni sono:

Europa / UE-SEE - GDPR (+ NIS2 se applicabile);
Italia - applicazione nazionale UE (Garante / ACN);
Svizzera - LPD svizzera (+ obbligo UFCS);
Cross-border Svizzera ↔ Europa - confronto.

Questa scelta è centrale perché la pressione temporale cambia.

Nel quadro UE/GDPR, il modulo ricorda la finestra di 72 ore dalla
conoscenza della violazione, se la notifica all'autorità è dovuta. In
Svizzera, la LPD non fissa un termine in ore: la notifica all'IFPDT
avviene quanto prima quando ricorrono le condizioni. Sulla pista cyber,
il modulo distingue NIS2 UE/SEE, applicazioni nazionali e UFCS svizzero.

Il formatore deve chiarire che il modulo non decide l'obbligo di
notifica. Allena il team a non dimenticare la pressione regolatoria e a
distinguere privacy, cyber e perimetro soggettivo.

La quarta opzione, Italia, è specifica dell'edizione Italy /
Switzerland ed è tra i framework che il contratto canonico condiviso
classifica come "consentiti" ma non obbligatori (paragrafo 5.9).
L'edizione Europe / Switzerland non la propone come giurisdizione
autonoma: un caso italiano viene lì impostato scegliendo Europa /
UE-SEE e indicando l'Italia come Paese di riferimento. Il valore
salvato nell'export resta comunque riconoscibile da entrambe le
edizioni.

Italia non deve diventare default automatico se il caso è europeo. Si
usa quando lo Stato membro rilevante è effettivamente l'Italia.

Cross-border Svizzera ↔ Europa è utile quando un gruppo, un
fornitore o una catena di servizi coinvolge entrambi i quadri.

Il campo Traccia cyber contiene due opzioni:

Solo violazione dati personali;
Possibile incidente cyber / infrastruttura o servizio critico.

Questa scelta non significa che l'incidente sia già qualificato cyber.
Significa che l'esercitazione vuole allenare anche quel dubbio.

Se si seleziona Possibile incidente cyber, il modulo mostra anche
pressione e scadenze relative a early warning o segnalazioni cyber,
secondo il perimetro. Mostra anche un avviso: l'obbligo cyber non
riguarda tutti; si applica a soggetti, infrastrutture, servizi e settori
specifici. Il modulo serve ad allenare il dubbio cyber-regolatorio, non
a presumere l'obbligo.

Il formatore deve usare questa traccia quando il caso riguarda
continuità, supply chain ICT, infrastrutture, servizi importanti, data
sharing critico, identità federata, connettori o fornitori rilevanti.

Il campo Vista esercitazione contiene due opzioni:

Team - niente anticipazioni;
Facilitatore - mostra scaletta e punti chiave.

La vista Team è quella ordinaria per i partecipanti. Non mostra la
scaletta riservata.

La vista Facilitatore mostra il pannello riservato con:

obiettivo sessione;
scheda ruoli minimi;
traccia verbale;
vettore;
iniezioni previste;
domande guida;
decision support;
eventuale punto cyber.

Il facilitatore deve evitare di proiettare la vista riservata ai
partecipanti. La scaletta serve a guidare la pressione senza anticipare
le risposte.

In aula si può mostrare la vista facilitatore dopo l'esercizio, durante
il debrief, per far capire come la sessione era stata costruita.

Dopo aver scelto i campi, l'operatore clicca Avvia simulazione.

Il modulo costruisce lo scenario. Se è stato scelto un preset, usa i
valori collegati. Se è stato scelto Casuale, seleziona vettore,
categoria dati, tempistica, scala e complicazioni coerenti con profilo e
intensità. Se è stato caricato un seed Blindspot, il seed può orientare
vettore e complicante.

Dopo il click, compaiono i pannelli principali:

scenario;
ruoli;
registro breach;
valutazione rischio;
azioni prioritarie 4/24h;
clock e iniezioni;
debrief;
verbale ed export.

Il clock parte da T+00:00.

Il pulsante principale diventa Rivela prossima iniezione, salvo
scenari senza complicazioni, in cui diventa Vai al debriefing.

Il brief scenario mostra le coordinate della simulazione.

Contiene:

vettore;
dati coinvolti;
scala;
tempistica;
giurisdizione;
traccia cyber;
richiesta al team.

Il vettore descrive la superficie dell'evento: ransomware, phishing,
smarrimento, invio errato, fornitore, shadow AI, agente browser, prompt
injection, OAuth, workflow, API key, deepfake helpdesk, identità
federata, data space/API.

La categoria dati orienta la valutazione del rischio per le persone:
dati comuni, contatti, sanitari, bancari, credenziali, dipendenti,
minori, log, prompt/log, profilazione o altri insiemi.

La scala indica l'ampiezza: poche persone, centinaia, migliaia, solo
personale interno, catena di fornitura o numero ignoto.

La tempistica mette pressione: lunedì mattina, fine settimana, ritardo
già accumulato, segnalazione da terzi, fuori orario.

Il formatore deve chiedere al team di leggere il brief e rispondere a
una domanda: che cosa sappiamo davvero adesso?

Se il team inizia subito a concludere, il facilitatore deve riportarlo
al metodo: quali fatti, quali ipotesi, quali evidenze mancanti?

Il pannello ruoli mostra la catena minima di risposta.

I ruoli previsti dal modello sono:

Crisis lead;
Security / IT / forense;
Privacy / DPO / compliance;
Legale / HR;
Comunicazione;
Vendor / supply chain owner;
AI / automazioni;
Regulatory liaison.

Per ciascun ruolo il modulo chiede di indicare:

ruolo decisionale;
ruolo operativo;
note.

La distinzione tra decisionale e operativo è fondamentale.

Il ruolo decisionale indica chi decide o approva.
Il ruolo operativo indica chi esegue, raccoglie evidenze, contatta
soggetti, fa verifiche o prepara materiali.

Per esempio, sul ruolo Security / IT / forense, il decisionale può
essere CISO o IT manager, mentre l'operativo può essere SOC,
amministratore sistema, fornitore MDR, team forense.

Sul ruolo Privacy / DPO / compliance, il decisionale può essere
titolare / direzione con DPO, mentre l'operativo può essere
privacy office.

Sul ruolo AI / automazioni, il decisionale può essere
service owner, mentre l'operativo può essere IT app owner,
business owner workflow, admin SaaS.

Il campo note serve a registrare sostituti, dubbi, assenze, deleghe
mancanti o evidenze attese.

Una sessione Drill deve far emergere se questi ruoli esistono davvero o
se vengono inventati durante l'esercizio.

Se la vista scelta è Facilitatore, il modulo mostra un pannello
riservato.

Il pannello contiene una scaletta.

Obiettivo sessione

L'obiettivo dichiarato è far emergere ruoli mancanti, evidenze non
disponibili, decisioni non firmate e differenza tra contenimento
tecnico, valutazione privacy e possibile valutazione cyber.

Il facilitatore deve usare questo obiettivo come controllo: se la
discussione diventa troppo tecnica o troppo narrativa, si torna a ruoli,
evidenze, decisioni e differenza tra privacy/cyber.

Scheda ruoli minimi

La scheda elenca i ruoli e chiede, per ciascuno, decisione, esecuzione,
sostituto e prova attesa.

Il facilitatore deve chiedere sempre: se questa persona non c'è, chi
decide? Se questo fornitore non risponde, chi scala? Se questo owner non
sa, chi recupera la prova?

Traccia verbale

La traccia indica che il verbale deve contenere:

decisione T+00:00 con motivazione;
evidenze richieste e owner assegnati;
per ogni iniezione: decisione, rischio persone, notifica privacy,
eventuale pista cyber;
azioni 4/24h;
gap 7/30/90;
lezioni apprese.

Questa è la struttura minima che il facilitatore deve proteggere. Un
esercizio senza verbale è una conversazione, non una simulazione
governata.

Domande guida

Per ogni complicazione, il pannello può mostrare una domanda guida.
Esempi:

se il team dà per scontato il ripristino, chiedere se è mai stato
testato un restore;
se si concentra solo sul recupero dei file, chiedere se i dati sono
usciti;
se revoca solo utenti umani, chiedere che cosa succede agli agenti;
se afferma che nulla è stato letto, chiedere come lo dimostra senza log
esportabili;
se si fida di voce o video, chiedere quale procedura avrebbe fermato la
richiesta;
se cita solo un'autorità nazionale, chiedere se il perimetro è europeo,
svizzero o entrambi.

Il facilitatore non deve dare le risposte. Deve usare le domande per
spingere il team a motivare.

Il pannello Allenamento alla documentazione interna è uno dei più
importanti.

Il modulo chiede di compilare:

Data / ora conoscenza;
Fonte segnalazione;
Descrizione sintetica;
Categorie di dati;
Categorie interessati;
Effetti possibili;
Misure adottate;
Decisione notifica privacy;
Decisione cyber;
Motivazione della decisione.

Il testo del modulo chiarisce che bisogna compilare anche con
informazioni provvisorie. L'obiettivo non è la perfezione, ma rendere
tracciabile che cosa si sa, che cosa non si sa e perché si decide.

Data / ora conoscenza

Questo campo non è la data certa dell'attacco. È il momento in cui
l'organizzazione ha conoscenza o consapevolezza iniziale del fatto da
valutare.

Se l'inizio è incerto, va scritto. Esempio:

Segnalazione ricevuta il 12/07/2026 ore 09:20; origine evento non ancora determinata.

Il formatore deve impedire al team di inventare una data di inizio
precisa solo per rendere ordinato il registro.

Fonte segnalazione

La fonte può essere:

utente;
fornitore;
alert EDR;
cliente;
autorità;
SOC;
help desk;
giornalista;
partner;
sistema interno;
segnalazione anonima.

La fonte condiziona il livello di certezza. Una segnalazione del
fornitore, un alert tecnico e un reclamo cliente richiedono verifiche
diverse.

Descrizione sintetica

Qui si scrive che cosa sembra accaduto.

Una buona descrizione separa fatto e ipotesi:

Un utente segnala accesso non riconosciuto alla mailbox. È stato osservato inoltro automatico verso indirizzo esterno. Non è ancora noto se siano stati scaricati allegati.

Una descrizione debole dice:

Account hackerato, dati rubati.

La prima è utilizzabile; la seconda anticipa conclusioni.

Categorie di dati

Il campo deve indicare le categorie potenzialmente coinvolte:
anagrafici, sanitari, credenziali, log, dati HR, minori, documenti, dati
finanziari, prompt, trascrizioni, CRM, dati clienti.

Se non si sa, si scrive da verificare, non una categoria rassicurante
inventata.

Categorie interessati

Qui si indicano le persone potenzialmente coinvolte: clienti,
dipendenti, pazienti, studenti, fornitori, utenti SaaS, amministratori,
candidati, minori.

La categoria degli interessati incide sul ragionamento di rischio.

Effetti possibili

Il modulo suggerisce esempi: frode, phishing mirato, furto identità,
danno reputazionale, perdita di riservatezza.

Il facilitatore deve chiedere: quale danno concreto per le persone è
plausibile, sulla base dei dati e del contesto?

Misure adottate

Questo campo non deve contenere intenzioni. Deve contenere misure già
avviate o decise:

sessioni revocate;
password resettate;
token disattivati;
mailbox controllata;
workflow sospeso;
log richiesti;
fornitore contattato;
snapshot preservato;
backup verificato;
comunicazione interna preparata.

Se la misura è solo proposta, va distinta.

Decisione notifica privacy

Le opzioni sono:

Da valutare;
Non dovuta, motivare;
Notifica autorità;
Autorità + comunicazione interessati.

Questa scelta non è una consulenza legale. Serve ad allenare la
motivazione della decisione.

Se si seleziona Non dovuta, motivare, la motivazione deve essere
solida. Non basta "pochi dati" o "non sembra grave". Bisogna
indicare misure, esposizione, dati, interessati e incertezze.

Decisione cyber

Il campo cambia in base alla giurisdizione e alla traccia cyber. Può
riguardare NIS2 UE, NIS2 Italia, UFCS Svizzera o una combinazione
UE/SEE-UFCS.

Le opzioni includono:

Non applicabile / ignoto;
Da valutare;
Early warning / segnalazione 24h;
Notifica o completamento successivo.

Il formatore deve chiarire che la pista cyber è parallela, non
sostitutiva della privacy. Un evento può non essere una violazione di
dati personali ma essere rilevante cyber; oppure può essere rilevante
privacy senza rientrare in un obbligo cyber.

Motivazione della decisione

Questo è il campo più importante del registro.

Qui si deve scrivere perché si notifica, perché non si notifica, perché
si rimanda, quali incertezze restano, quali fonti mancano, quali
aggiornamenti sono attesi.

Una buona motivazione può essere:

Al momento accesso plausibile ma non provato. Log richiesti al fornitore. Dati potenzialmente coinvolti: credenziali e CRM clienti. Decisione privacy da rivalutare entro 4 ore dopo ricezione log. Pista cyber da valutare per dipendenza SaaS critica.

Una motivazione debole è:

Da vedere.

Il pannello Pressione temporale mostra un promemoria visivo.

Nel quadro europeo/GDPR, la finestra delle 72 ore parte dalla conoscenza
della violazione, se la notifica all'autorità è dovuta. In Svizzera, la
LPD non usa una finestra fissa in ore, ma richiede notifica quanto prima
quando ricorrono le condizioni.

Se la traccia cyber è attiva, il modulo mostra anche la pressione 24h
per early warning o segnalazione, secondo il quadro applicabile.

Il clock avanza con le iniezioni. A ogni passo, il tempo residuo viene
aggiornato.

Il formatore deve usare questo pannello per insegnare una cosa: il tempo
non serve a spaventare, serve a disciplinare.

Sotto pressione il team deve evitare due errori:

comunicare troppo presto;
aspettare troppo senza documentare perché.

Il registro serve a tenere traccia della motivazione anche quando la
decisione resta provvisoria.

Il campo Decisione iniziale T+00:00 appare prima delle iniezioni.

Il modulo chiede di scrivere la prima decisione concreta prima di vedere
le complicazioni: contenimento, ruoli attivati, evidenze richieste e
dubbio principale.

Questo è un passaggio didattico molto importante.

Il team deve prendere una decisione con informazioni incomplete. Non può
aspettare di sapere tutto. Deve decidere che cosa fare ora senza
trasformare l'ipotesi in fatto.

Una buona decisione iniziale contiene:

apertura registro interno;
nomina crisis lead;
attivazione IT/security, DPO/privacy, legal se opportuno;
preservazione log;
revoca o sospensione provvisoria di accessi sospetti;
richiesta evidenze al fornitore;
indicazione del dubbio principale.

Esempio:

Apriamo registro interno, nominiamo crisis lead, preserviamo log mailbox e SSO, sospendiamo sessioni sospette, chiediamo al fornitore export accessi ultime 72 ore, attiviamo DPO e IT. Dubbio principale: accesso potenziale o esfiltrazione confermata?

Una decisione iniziale debole è:

Aspettiamo di capire.

Aspettare può essere una scelta, ma deve essere motivata e accompagnata
da misure di preservazione.

Il pannello Valutazione qualitativa del rischio per le persone non è
un calcolatore automatico.

Serve a motivare se il rischio resta basso, medio o elevato.

I campi sono:

Tipo di dati;
Volume / scala;
Esposizione;
Capacità di mitigazione;
Conseguenze plausibili;
Sintesi rischio;
Motivazione sintetica.

Tipo di dati

Le opzioni includono:

dati comuni isolati;
dati finanziari / identità;
dati particolari o giudiziari;
credenziali, token o sessioni attive;
dati su minori o soggetti vulnerabili.

Il tipo di dati non decide da solo il rischio. Lo orienta.

Volume / scala

Le opzioni includono pochi interessati, centinaia, migliaia/numero
ignoto, catena di fornitura o connettori multipli.

Il numero ignoto non deve essere trattato come numero basso. Spesso
l'incertezza aumenta la cautela.

Esposizione

Le opzioni distinguono accesso potenziale, accesso plausibile,
esfiltrazione o invio confermato, uso abusivo già osservato.

Il facilitatore deve chiedere sempre: come lo sappiamo? Quale log, quale
evidenza, quale fonte?

Capacità di mitigazione

Le opzioni includono misure forti già efficaci, misure parziali, log
insufficienti o incertezza alta, mitigazione tardiva o non dimostrabile.

Questo campo è centrale. Se non si può dimostrare che la mitigazione ha
funzionato, la valutazione del rischio deve restare prudente.

Conseguenze plausibili

Il modulo chiede di valutare disagio limitato, phishing mirato, frode,
furto identità, danno economico, danno reputazionale, discriminazione o
vulnerabilità personale.

Il focus è sulle persone, non solo sui sistemi.

Sintesi rischio

Le opzioni sono basso, medio, elevato o da valutare.

Il rischio elevato è la soglia più delicata: in ottica GDPR può far
scattare anche la comunicazione agli interessati; in ottica LPD svizzera
è la condizione stessa per la notifica all'IFPDT.

Il team deve motivare la scelta nel campo Motivazione sintetica.

La motivazione deve dire quali elementi pesano di più e quali incertezze
restano.

Il pannello Prime misure operative da verificare contiene una
checklist.

Il modulo dice: spuntate solo ciò che è stato davvero deciso o avviato.
Le azioni mancanti diventano materiale per il piano di miglioramento.

Le azioni sono:

Revoca sessioni e token;
Force reset password / MFA;
Controllo mailbox;
Sospensione agenti/workflow;
Richiesta log al fornitore;
Preservazione evidenze;
Verifica backup/restore;
Preparazione notifiche.

Revoca sessioni e token

Riguarda account utente, OAuth, API key, connettori e agenti.

Il formatore deve chiedere: avete revocato solo la password o anche
sessioni, refresh token, app OAuth, trust e agenti?

Force reset password / MFA

Riguarda password, MFA, regole help desk e accessi privilegiati.

Non basta dire "reset password". Bisogna capire se MFA è stato
compromesso, se il reset è forzato, se le regole help desk sono state
manipolate.

Controllo mailbox

Riguarda regole di inoltro, accessi anomali, email inviate o scaricate.

È cruciale negli scenari phishing, SSO, help desk e deepfake.

Sospensione agenti/workflow

Riguarda kill switch per automazioni, note taker, app AI e workflow
no-code.

Questo è uno dei punti più moderni del modulo. Se il team non sa chi può
sospendere un agente o un workflow, l'esercizio deve farlo emergere.

Richiesta log al fornitore

Riguarda accessi, export, retention, subfornitori e finestre temporali.

Il facilitatore deve chiedere se il contratto o il DPA prevedono tempi,
formato e cooperazione.

Preservazione evidenze

Riguarda snapshot, log, hash, timeline, ticket e comunicazioni.

Questa azione è essenziale: contenere senza distruggere evidenza.

Verifica backup/restore

Riguarda copia pulita, offline o immutabile, e test di ripristino.

Il team deve distinguere backup esistente e restore testato.

Preparazione notifiche

Riguarda privacy, interessati, cyber e comunicazione interna.

Il modulo ricorda esplicitamente autorità UE/SEE competente, autorità
nazionale se rilevante, IFPDT, NIS2 UE/UFCS se applicabile.

La notifica non va fatta automaticamente. Va preparata perché il tempo
può essere corto.

Note operative 4/24 ore

Il campo Note operative 4/24 ore serve a scrivere chi fa cosa entro
poche ore.

Una buona nota distingue 4 ore e 24 ore.

Esempio:

Entro 4h: revoca sessioni sospette, richiesta log fornitore, snapshot mailbox, nomina owner comunicazione. Entro 24h: prima valutazione rischio, bozza registro, decisione su notifica privacy, verifica perimetro cyber.

Il pulsante Rivela prossima iniezione fa avanzare lo scenario.

Ogni iniezione rappresenta una complicazione. Il clock cambia da
T+00:00 a step successivi, per esempio T+00:30, T+03:00,
T+20:00, T+60:00.

Ogni iniezione mostra:

codice INJ-01, INJ-02, ecc.;
tempo;
titolo della complicazione;
situazione;
domanda al team;
campo decisione del team;
rivalutazione rischio persone;
decisione notifica privacy;
decisione cyber;
motivazione.

Il formatore deve evitare che il team tratti l'iniezione come "*nuovo
capitolo narrativo*". Ogni iniezione deve produrre decisione, owner,
evidenza e motivazione.

Quando appare una iniezione, il team deve leggere prima la situazione e
poi rispondere nel campo Decisione del team.

Una buona decisione deve contenere:

azione;
owner;
tempo;
evidenza attesa;
motivazione;
cosa resta incerto.

Esempio:

Chiediamo entro 2 ore al fornitore log accessi/export ultimi 14 giorni, subfornitori coinvolti e retention. Owner: vendor manager con supporto IT. Fino a ricezione log, manteniamo rischio da valutare e non escludiamo esfiltrazione.

Una decisione debole dice:

Chiediamo chiarimenti.

Dopo la decisione, il team compila:

Rischio persone: basso, medio, elevato o da valutare;
Notifica privacy: non dovuta, autorità, interessati, autorità +
interessati, da valutare;
Cyber: opzione coerente con NIS2/UFCS o non applicabile;
Perché cambia o non cambia la valutazione?.

Il campo motivazione deve spiegare il ragionamento. Non deve ripetere la
selezione.

Le complicazioni del modello includono scenari classici e moderni.

Backup compromesso

Domanda guida: avete mai testato un restore? Esiste una copia offline o
immutabile? Chi la custodisce?

Questa iniezione serve a distinguere backup dichiarato e ripristino
dimostrabile.

Esfiltrazione confermata

Domanda guida: se i dati sono usciti, come cambia il rischio per le
persone?

Questa iniezione sposta il team dal sistema alla conseguenza: phishing
mirato, frode, furto identità, danno economico, vulnerabilità.

Attacco iniziato da settimane

Domanda guida: come fate a sapere quando è iniziato? Che cosa scrivete
nel registro se non lo sapete con certezza?

Questa iniezione allena incertezza e timeline.

Coinvolgimento fornitore

Domanda guida: quel soggetto è processor/responsabile, titolare
autonomo, fornitore ICT, subfornitore? Che cosa dice il contratto su
log, tempi, Paesi e cooperazione?

Questa iniezione mostra che il fornitore non è solo "terzo tecnico".

Persona chiave irreperibile

Domanda guida: chi decide al suo posto adesso?

Serve a testare deleghe, sostituti e ruoli reali.

Pressione reputazionale

Domanda guida: chi parla a nome vostro e per quale perimetro? Qual è la
frase minima vera?

Serve a impedire comunicazioni premature.

Agente ancora attivo

Domanda guida: dov'è il kill switch, chi può premerlo e in quanti
minuti?

Serve a portare l'esercizio nel mondo AI/automazioni.

Permessi eccessivi

Domanda guida: il connettore vedeva solo i dati previsti? Chi ha
approvato quei permessi?

Serve a far emergere overpermissioning e OAuth shadow.

Log mancanti

Domanda guida: come dimostrate che nulla è stato letto senza log
esportabili?

Serve a distinguere assenza di prova e prova di assenza.

Retention e training AI

Domanda guida: cancellato dove, presso quale entità e in quale
giurisdizione? Che cosa dicono termini, DPA, retention, training e
subfornitori?

Serve a evitare risposte troppo semplici su strumenti AI.

Deepfake pressure

Domanda guida: quale procedura avrebbe fermato la richiesta anche se
sembrava autentica?

Serve ad allenare il diritto operativo di dubitare.

Quando le iniezioni sono finite, il pulsante porta al debriefing.

Il debriefing mostra alcuni principi e lezioni generate dal modello in
base allo scenario.

Il primo principio è che la notifica all'autorità non dipende dalla
categoria astratta del dato, ma dal rischio concreto per i diritti e le
libertà delle persone. Anche quando non si notifica, la violazione va
documentata nel registro interno, con fatti, effetti e misure adottate.

Il debriefing mostra anche il quadro normativo attivo: UE/SEE, Italia,
Svizzera o cross-border. Se la Svizzera è coinvolta, ricorda anche la
documentazione interna della violazione.

Il debriefing non chiude la valutazione. Serve a guidare la discussione
finale.

Il facilitatore deve chiedere:

che cosa abbiamo deciso troppo presto?
quale evidenza mancava?
quale ruolo non era chiaro?
quale comunicazione sarebbe stata rischiosa?
quale fornitore non era governato?
quale automazione non aveva owner?
quale decisione resta da validare fuori dall'esercizio?

Il pannello Piano di miglioramento post-esercitazione contiene tre
righe.

Per ogni riga si compila:

Gap / vulnerabilità;
Owner;
Scadenza.

Il modulo dice: il vero risultato non è "abbiamo risposto bene", ma la
lista delle fragilità emerse.

Il facilitatore deve evitare gap generici.

Un gap debole è:

migliorare comunicazione.

Un gap utile è:

assenza messaggio interno prevalidato per impedire comunicazioni non coordinate nelle prime 4 ore.

Un altro gap utile è:

nessun owner definito per sospensione agenti AI e workflow no-code.

Ogni gap deve avere owner e scadenza. Senza questi elementi, il piano
non è un piano.

Il pannello Lezioni apprese libere permette di registrare osservazioni
che non entrano bene nel piano gap/owner/scadenza.

I campi sono:

Osservazione / lezione;
Impatto;
Nota.

Questa sezione è utile per registrare blocchi, discussioni difficili,
intuizioni operative ed errori utili.

Esempi:

Il team ha confuso accesso potenziale ed esfiltrazione confermata;
Il management chiedeva una frase esterna prima della verifica log;
Il fornitore unico non ha un referente alternativo fuori orario;
Nessuno sapeva se i prompt AI sono conservati o usati per training;
Il team IT ha gestito bene la revoca sessioni, ma non gli agenti OAuth.

Il campo Impatto può indicare basso, medio o alto. La nota può
spiegare se la lezione deve diventare scenario, policy, training o
modifica procedurale.

Il pulsante Scarica verbale in chiaro (.txt) genera il verbale
della sessione.

Il file si chiama esr-drill-verbale.txt.

Prima dell'export, il modulo può mostrare un avviso se ci sono campi
vuoti, molte selezioni ancora da valutare, nessuna azione prioritaria
spuntata o contenuti marcati come demo.

Questo avviso non impedisce l'export. Serve a evitare che l'operatore
scarichi un verbale incompleto senza accorgersene.

Il verbale contiene:

avviso su natura e limiti del documento;
configurazione;
scenario;
decisione iniziale;
registro breach strutturato;
checklist rischio elevato;
azioni prioritarie 4/24h;
catena minima di risposta;
iniezioni e decisioni;
punti del debriefing;
piano di miglioramento;
lezioni apprese;
link per attestazione esterna;
blocco machine data reimportabile.

Il verbale è in chiaro. Deve essere trattato come documento di sicurezza
riservato.

Il verbale TXT contiene un blocco macchina compreso tra:

== ESR-DRILL MACHINE DATA ==
== END ESR-DRILL MACHINE DATA ==

Questo blocco contiene la rappresentazione strutturata della sessione.
Permette di reimportare il TXT in Drill.

Il formatore deve spiegare che un TXT non è solo testo leggibile. Può
contenere dati strutturati sufficienti a ripristinare una sessione.

Per questo il TXT va gestito con la stessa cautela del JSON.

Il pulsante Export dossier cifrato produce un file cifrato.

Richiede Passphrase dossier e Conferma passphrase. La passphrase
deve avere almeno 12 caratteri. Il modulo non la salva e non la può
recuperare.

Questa modalità è consigliata quando il dossier deve essere trasferito o
conservato fuori dalla sessione.

Il dossier cifrato può essere reimportato con Importa dossier cifrato,
inserendo la passphrase corretta.

La cifratura protegge il contenuto del file, ma non elimina la
responsabilità di conservarlo in una posizione adeguata.

Drill consente anche export GRC/SOAR JSON in chiaro e
GRC/SOAR CSV in chiaro.

Questi export non sono template ufficiali MITRE, DORA, NIS2 o di
autorità nazionali. Sono output operativi di supporto, da validare prima
di qualunque import in GRC/SOAR o sistema tecnico.

Il JSON GRC/SOAR contiene:

schema export;
versione;
configurazione;
scenario;
registro breach;
valutazione rischio;
contesto regolatorio;
reporting workbench NIS2/DORA candidate;
mapping MITRE ATT&CK candidato;
iniezioni;
azioni prioritarie;
piano di miglioramento;
lezioni apprese;
machine data.

Il mapping MITRE è indicativo. Gli ID tecnici devono essere validati
contro i modelli e le tassonomie correnti prima di uso operativo.

Il CSV è una sintesi tabellare. È comodo, ma rende molto visibili
scenario, rischio, azioni e gap. Va gestito come file sensibile.

Il pulsante Stampa verbale manda la pagina in stampa.

Il facilitatore deve ricordare che la stampa può produrre carta o PDF.
Entrambi sono export. Se contengono una simulazione realistica, gap,
owner, decisioni o dati tokenizzati ma riconoscibili, devono essere
conservati e condivisi con cautela.

Stampare non è un'azione neutra.

Il pannello Attestazione esterna del verbale contiene il link
Attesta il TXT su ExistBefore.

Il testo del modulo chiarisce che dopo aver scaricato il verbale TXT è
possibile attestarlo esternamente caricandolo sul servizio indicato.
L'attestazione non sostituisce la valutazione legale o privacy; è un
passaggio esterno per documentare l'esistenza del file generato secondo
le modalità del servizio scelto.

Nel percorso formativo, il facilitatore deve collegare questa funzione
al capitolo su hash e attestazione minima.

L'operatore può attestare il verbale finale di una simulazione
selezionata, non ogni bozza.

La sequenza prudente è:

chiudere la sessione;
rileggere il verbale;
minimizzare elementi non necessari;
scaricare TXT o esportare dossier;
selezionare la versione finale;
attestare solo se rappresenta una milestone;
conservare insieme file e ricevuta.

L'attestazione prova l'esistenza di una versione. Non prova che la
simulazione sia stata ben condotta o che le decisioni siano corrette.

Nel pannello Oppure carica uno scenario pronto o derivato, il menu
Scenario Prudentia Drill contiene scenari incorporati:

A - Sanità;
B - SaaS con agente AI persistente;
C - Ente pubblico con agente AI;
D - Impresa e fornitore cloud con log mancanti;
E - Cross-border Svizzera / Europa;
F - Deepfake helpdesk / OAuth;
G - Shadow AI e dati personali;
H - Phishing generativo post-esfiltrazione.

Il pulsante Carica scenario scelto importa il verbale dimostrativo e
ripristina la sessione.

Gli scenari sono fittizi o astratti. Contengono marcature demo. Il
modulo mostra un avviso quando carica contenuti dimostrativi.

Questa funzione è molto utile per formazione, onboarding e confronto tra
gruppi. Tutti partono dallo stesso scenario, ma le decisioni possono
divergere.

Il facilitatore deve evitare che i partecipanti trattino lo scenario
demo come fatto reale. Il suo valore è allenare metodo.

Il pulsante Prova seed Blindspot carica un seed dimostrativo se
presente nel catalogo.

Serve a mostrare il passaggio Blindspot → Drill.

Un seed Blindspot non contiene una simulazione completa. Contiene
coordinate che orientano Drill: vettore, complicante, finding di
origine, giurisdizione, traccia privacy/cyber e riferimento al rilievo.

Quando Drill applica un seed, se il vettore o il complicante sono
riconosciuti, li usa. Se non li riconosce, mostra un avviso e ripiega su
generazione coerente.

Il messaggio formativo è importante: il seed orienta, non comanda
ciecamente.

Il facilitatore può usare questa funzione per mostrare come un punto
cieco su log, owner, fornitore, agenti AI o token diventa simulazione.

Il pulsante Importa TXT esportato permette di caricare un verbale TXT
già esportato.

Il modulo cerca il blocco machine data. Se lo trova, ripristina la
sessione.

Questa funzione serve quando si vuole riprendere una esercitazione,
rivedere un verbale, completare campi mancanti o mostrare in aula una
sessione precedente.

Il file TXT deve essere gestito con cautela perché può contenere tutto
il contenuto dell'esercizio.

Il pulsante Importa seed Blindspot JSON permette di importare
un seed generato da Blindspot.

Questo è il flusso più importante di interoperabilità tra moduli.

L'operatore esporta un seed dal rilievo Blindspot, poi lo importa in
Drill. Drill costruisce uno scenario coerente con il punto cieco.

Esempi:

Blindspot rileva log non esportabili → Drill simula richiesta di
ricostruzione accessi.
Blindspot rileva owner incerto → Drill simula decisione urgente senza
persona chiave.
Blindspot rileva fornitore opaco → Drill simula ritardo di risposta del
fornitore.
Blindspot rileva agente AI senza kill switch → Drill simula automazione
persistente.
Blindspot rileva token non censiti → Drill simula accesso persistente
dopo offboarding.

Il seed deve essere trattato come file sensibile se deriva da un caso
reale o da una lacuna reale.

Il pulsante Importa dossier cifrato importa una sessione cifrata
esportata da Drill.

Richiede la passphrase corretta.

Questo flusso è consigliabile quando si deve trasferire una sessione tra
operatori autorizzati o tra browser, evitando export in chiaro.

Se la passphrase è errata, il contenuto non viene ripristinato. La suite
non recupera passphrase dimenticate.

Drill include una sezione di salvataggio locale cifrato.

I campi e pulsanti sono:

Passphrase dossier;
Conferma passphrase;
checkbox Autosalva nel vault cifrato;
Mostra passphrase;
Salva vault cifrato;
Ripristina vault;
Cancella vault;
Pulisci localStorage;
Nuova esercitazione.

Passphrase dossier

Serve per export cifrato, import cifrato e vault.

Deve avere almeno 12 caratteri. Va custodita con attenzione. La suite
non la salva.

Autosalva nel vault cifrato

Se attivato, salva automaticamente la sessione nel browser, cifrata con
la passphrase.

È utile durante esercitazioni lunghe. Va usato con prudenza su macchine
condivise.

Salva vault cifrato

Forza il salvataggio manuale della sessione nel vault locale.

Va usato dopo momenti importanti: avvio scenario, iniezioni, debrief,
piano.

Ripristina vault

Ripristina la sessione salvata nel browser, se la passphrase è corretta.

Cancella vault

Rimuove il vault Drill dal browser.

Pulisci localStorage

Rimuove i dati locali CertiSigma Prudentia Suite dal browser. È più ampio di
Cancella vault e va usato con consapevolezza.

Nuova esercitazione

Azzera la sessione corrente e permette di ripartire. Prima di usarlo, il
facilitatore deve decidere se esportare o salvare ciò che serve.

Questo scenario è particolarmente adatto alla formazione moderna.

Contesto

Un'azienda SaaS usa un agente AI con accesso a mail, CRM o repository.
Emergono segnali di uso improprio, accessi persistenti o output
condivisi in modo non governato.

Scelte iniziali

Il facilitatore può scegliere:

Scenario guidato: Azienda SaaS - agente AI con accesso a mail e CRM;
Settore: Azienda digitale / SaaS / servizi cloud;
Profilo: AI / automazioni / agenti;
Intensità: Difficile - 2 complicazioni;
Stile: Didattico oppure Audit;
Giurisdizione: Europa / UE-SEE o cross-border, secondo contesto;
Traccia cyber: Possibile incidente cyber / infrastruttura o servizio
critico;
Vista: Team per i partecipanti, Facilitatore per chi conduce.

Decisione iniziale

Una buona decisione T+00:00 può essere:

Apriamo registro interno, nominiamo crisis lead, sospendiamo temporaneamente l’agente AI coinvolto, preserviamo log di accesso e prompt, chiediamo export al fornitore SaaS, attiviamo IT/security e DPO. Dubbio principale: accesso improprio o esfiltrazione/riuso di dati?

Iniezioni probabili

Il modulo può introdurre complicazioni come:

agente ancora attivo;
permessi eccessivi;
esfiltrazione;
phishing generativo;
log mancanti;
false comfort da output AI.

Debrief

Il facilitatore deve chiedere:

chi poteva spegnere l'agente?
quali log esistono?
i prompt sono conservati?
i dati sono usati per training o retention?
il connettore aveva permessi minimi?
chi decide se comunicare agli interessati?
chi valuta pista cyber?

Questo scenario mostra che l'incidente AI non è solo "uso di un tool":
è catena di accessi, dati, log, permessi, fornitori e decisioni.

Questo scenario allena la postura umana.

Contesto

Un attore ostile usa voce, video o messaggio credibile per convincere
help desk o amministrazione a fare una modifica, autorizzare un reset,
concedere accesso o approvare una app OAuth.

Scelte iniziali

Scenario guidato: Casuale oppure identità federata/SSO;
Profilo: Estremo verosimile - raro ma plausibile;
Settore: SaaS, servizi professionali o generico;
Intensità: Realistica o Difficile;
Stile: Crisi;
Traccia cyber: Possibile incidente cyber.

Decisione iniziale

La decisione deve includere canale fuori banda, blocco procedura,
preservazione log help desk, verifica modifiche recenti, revoca
token/app autorizzate e comunicazione interna.

Punti da far emergere

Il facilitatore deve chiedere:

quale procedura avrebbe fermato la richiesta anche se sembrava
autentica?
il help desk può rifiutare una richiesta apparentemente del presidente?
esiste doppia conferma su canale separato?
chi approva app OAuth e reset MFA?
quali log dimostrano chi ha fatto cosa?
chi comunica internamente che video, voce e urgenza non bastano?

Questo scenario insegna che la fiducia personale non è più controllo
sufficiente.

Questo scenario è utile per supply chain e contratti.

Contesto

Un fornitore cloud segnala un problema, ma non fornisce log completi.
L'organizzazione deve decidere se e come valutare rischio, notifica e
pista cyber.

Scelte iniziali

Scenario guidato: Servizi HR/payroll oppure Supply chain critica;
Settore: Servizi professionali / HR / legale o SaaS;
Profilo: Misto;
Intensità: Difficile;
Stile: Audit;
Giurisdizione: Europa / UE-SEE o cross-border;
Traccia cyber: Possibile incidente cyber.

Punti da far emergere

Il facilitatore deve chiedere:

il fornitore è processor/responsabile, titolare autonomo o fornitore
ICT?
il contratto dice entro quanto deve dare log?
quali subfornitori sono coinvolti?
dove sono i dati?
quanto pesa l'assenza di log sulla valutazione del rischio?
che cosa si può comunicare senza log?
chi valuta NIS2 o UFCS?

Questo scenario insegna che la dipendenza da fornitore non è una scusa.
È un elemento da governare.

Il primo errore è trattare Drill come teatro. Se la sessione diventa
racconto drammatico ma non produce decisioni, owner, evidenze e gap, non
ha funzionato.

Il secondo errore è lasciare parlare solo IT. La risposta a un evento
coinvolge sicurezza, privacy, legale, comunicazione, management,
fornitori e spesso AI/automazioni.

Il terzo errore è compilare il registro a posteriori, dopo aver discusso
tutto. Il registro va compilato durante la pressione, perché serve a
mostrare come si ragiona con informazioni incomplete.

Il quarto errore è rispondere alle iniezioni con frasi generiche. Ogni
iniezione deve produrre decisione, owner, evidenza e motivazione.

Il quinto errore è confondere notifica privacy e pista cyber. Possono
essere collegate, ma non sono la stessa decisione.

Il sesto errore è esportare il verbale in chiaro e lasciarlo nella
cartella Download. Il verbale può contenere fragilità reali.

Il settimo errore è attestare un verbale ancora pieno di bozze, dati
inutili o informazioni non minimizzate. L'attestazione va fatta solo su
milestone selezionate.

Il formatore deve preparare la sessione in modo diverso a seconda del
pubblico.

Con operatori nuovi, conviene usare scenario pronto, vista team,
intensità base o realistica, stile didattico.

Con operatori esperti, si può usare seed Blindspot, intensità difficile,
stile audit o crisi.

Con management, il focus deve essere decisioni, comunicazioni, owner,
tempi e frasi minime vere.

Con IT/security, il focus deve essere log, contenimento, revoca,
preservazione evidenze, fornitore, timeline.

Con DPO/legal/compliance, il focus deve essere registro, rischio
persone, notifica, motivazione, autorità e comunicazione agli
interessati.

Con team AI/automazioni, il focus deve essere agenti, workflow, OAuth,
prompt/log, retention, permessi e kill switch.

Il ritmo consigliato è:

spiegare perimetro e limiti;
scegliere scenario;
compilare ruoli;
scrivere decisione T+00:00;
compilare registro iniziale;
valutare rischio iniziale;
spuntare prime misure;
rivelare iniezioni una alla volta;
rivalutare dopo ogni iniezione;
aprire debrief;
compilare piano;
esportare verbale o dossier;
decidere eventuale attestazione;
pulire o salvare vault secondo contesto.

Il formatore deve proteggere il tempo. Drill non deve diventare una
riunione senza fine.

L'operatore non deve leggere il codice per usare Drill. Però, in
formazione avanzata, è utile sapere che il modulo è costruito su dati
dichiarati.

Il file assets/data/ESR-DRILL-model.js contiene:

vettori;
categorie di dati;
complicanti;
tempi;
scale;
ruoli;
preset;
riferimenti regolatori;
domande del facilitatore;
step del clock.

Questo significa che gli scenari non sono inventati da una AI durante
l'uso. Sono combinazioni controllate di elementi dichiarati nel
pacchetto.

Il file scenarios/drill/ESR-DRILL-scenarios.js contiene gli scenari
dimostrativi incorporati.

Il file assets/js/ESR-DRILL.js contiene la logica applicativa:
costruisce scenari, rivela iniezioni, gestisce clock, registro, rischio,
azioni, debrief, export, import, vault cifrato e GRC/SOAR export.

Il file assets/data/ESR-INTEROP-model.js contiene il contratto che
permette a Blindspot di orientare Drill.

Questa struttura rende Drill ispezionabile e modificabile. Chi vuole
aggiungere scenari o adattare il modulo può lavorare sui dati e poi
usare il validatore locale.

Chi modifica Drill deve sapere dove intervenire.

Per aggiungere vettori, dati, complicanti, ruoli, preset o domande del
facilitatore si lavora su assets/data/ESR-DRILL-model.js.

Per aggiungere scenari pronti si lavora su
scenarios/drill/ESR-DRILL-scenarios.js.

Per modificare il mapping da Blindspot si lavora su
assets/data/ESR-INTEROP-model.js.

Ogni modifica deve essere provata nel browser e verificata con
dev/validate.html.

Una personalizzazione prudente deve rispettare alcune regole:

gli scenari devono allenare decisioni, non fornire istruzioni
offensive;
i complicanti devono creare pressione plausibile, non spettacolo;
le domande guida devono spingere a evidenze, owner e motivazione;
i preset devono restare coerenti con settore, dati, scala e
giurisdizione;
gli scenari derivati da casi reali devono essere minimizzati e
astratti;
i file demo non devono contenere dati reali;
gli export di prova non devono finire nel pacchetto distribuito.

Uno scenario Drill utile nasce da una frizione reale: un ruolo mancante,
un fornitore opaco, una comunicazione prematura, un log non disponibile,
un agente senza kill switch, una procedura che funziona solo se una
persona è presente.

Prima di chiudere una sessione Drill, l'operatore deve verificare:

lo scenario era fittizio, derivato o reale e il verbale lo rende
chiaro;
il perimetro informativo è stato minimizzato;
la vista facilitatore non è stata mostrata al team durante l'esercizio,
salvo scelta didattica;
la decisione T+00:00 è compilata;
i ruoli hanno decisionale, operativo e note;
il registro breach distingue fatti, ipotesi e incertezze;
la valutazione rischio persone ha motivazione;
le azioni 4/24h spuntate sono davvero avviate o decise;
ogni iniezione ha decisione, rischio, notifica, cyber e motivazione;
il debrief è stato letto e discusso;
il piano di miglioramento contiene gap, owner e scadenza;
le lezioni apprese sono state scritte;
l'export scelto è coerente con la sensibilità del caso;
il TXT in chiaro non resta in Download senza governo;
il dossier cifrato usa passphrase custodita;
eventuale attestazione riguarda una versione chiusa;
il vault locale è stato salvato o cancellato secondo contesto;
i file esportati sono stati inventariati o spostati in cartella
controllata.

Drill è il modulo che trasforma un rischio, un dubbio o un punto cieco
in esercizio.

Il suo valore non sta nella simulazione in sé. Sta nel metodo che la
simulazione rende visibile.

Un operatore formato deve uscire da Drill con cinque risultati:

una decisione iniziale motivata;
una catena di ruoli più chiara;
un registro breach compilato con incertezze dichiarate;
un piano di miglioramento con owner e scadenze;
un verbale gestito come dossier sensibile.

La formula finale è questa: Drill non chiede se l'organizzazione sa
raccontare una crisi. Chiede se sa decidere, documentare e comunicare
quando la crisi è ancora piena di zone grigie.

Prompt Builder costruisce richieste non identificative da sottoporre
a una AI o a un LLM. La richiesta generata va all'AI; il possibile uso
successivo dell'output può riguardare un consulente, un avvocato, un
tecnico, un DPO, un fornitore, un auditor, il management o altri
interlocutori, ma quel riuso resta una decisione dell'operatore.

Nasce da un'esigenza professionale ricorrente: anche l'operatore esperto
può voler usare una AI o un LLM per ottenere una griglia, una bozza, un
controllo di coerenza o un elenco di cautele. Il valore di Prompt
Builder è nel come: aiuta a chiarire scopo, perimetro, ipotesi, fatti
disponibili e livello di dettaglio necessario prima di sottoporre una
richiesta al sistema.

Prompt Builder incanala invece di vietare. Guida a formulare una
richiesta di alto livello, proporzionata e non identificativa, che
separa ciò che è dichiarato da ciò che deve ancora essere verificato. Il
principio è netto: fermati, classifica, costruisci la richiesta.

Prompt Builder dà un ponte affidabile verso il supporto esterno, ma il
ponte passa prima dalla richiesta all'AI/LLM. Le valutazioni formali
restano nelle mani di chi le deve fare - avvocato, DPO, CISO, incident
responder, consulente tecnico - e Prompt Builder le rende più efficaci
arrivando con una domanda già ordinata e con un output da valutare prima
di qualsiasi uso successivo.

Prompt Builder offre due percorsi di costruzione e una funzione
contestuale. Costruisci il caso è il percorso ordinario per
costruire una richiesta non identificativa. Vai all'essenziale è il
percorso minimo per evitare una risposta impulsiva. Confronta stati
non è un ingresso autonomo: confronta la compilazione corrente con un
salvataggio precedente dello stesso caso e genera un nuovo prompt
orientato al delta.

CertiSigma Prudentia Suite potrebbe sembrare una suite a due movimenti: scoprire i punti
ciechi con Blindspot ed esercitarli con Drill. Nella pratica emerge però
un terzo bisogno, tipico del lavoro specialistico: usare un supporto
esterno, spesso AI/LLM, senza trasferire il caso reale in modo
eccedente. Prompt Builder governa esattamente quel passaggio.

Il valore sta nel modo in cui la richiesta viene formulata. Nella fase
iniziale è facile raccontare troppo, confondere fatti e ipotesi,
coinvolgere il destinatario sbagliato, anticipare conclusioni o
trasformare un dubbio in un caso già qualificato. Prompt Builder
rallenta quel passaggio e lo trasforma in una richiesta leggibile e
proporzionata.

Il modulo costruisce richieste che separano bisogno di supporto,
contesto dichiarato, limiti della richiesta, ipotesi e informazioni
mancanti. Dice al destinatario: aiutami a ragionare per categorie, senza
trarre conclusioni definitive e senza dedurre elementi che non ho
dichiarato. Il risultato è che l'operatore chiede aiuto proteggendo il
caso reale e ottenendo comunque una risposta utile.

La frase formativa da ripetere è questa: Prompt Builder non serve a
ottenere una risposta più veloce; serve a formulare una domanda meno
pericolosa.

L'operatore deve usare Prompt Builder per mediare il rapporto tra
organizzazione e AI.

Il modulo non serve a "fare scrivere tutto a ChatGPT" o a produrre
automaticamente comunicazioni da inviare. Serve a costruire una
richiesta ordinata da sottoporre a un LLM, a una AI autorizzata o, in
alcuni casi, a un supporto professionale umano, mantenendo chiari
perimetro, incertezze, limiti, scopo, destinatario diretto e validazioni
necessarie.

L'operatore deve uscire dalla formazione con cinque capacità.

Prima: saper distinguere struttura del soggetto e caso corrente. Il
fatto che un'organizzazione tratti normalmente dati sanitari, contratti
o log non significa che quei dati siano coinvolti nel caso corrente.

Seconda: saper dichiarare l'incertezza. Un campo lasciato vuoto non
entra nel prompt; una scelta "Non noto" o "Da verificare" entra
invece come incertezza dichiarata.

Terza: saper scegliere il tipo di richiesta. Un inquadramento
preliminare, un brief professionale, una richiesta tecnica, una nota
management, un Q&A per customer care e una richiesta a fornitore sono
oggetti diversi.

Quarta: saper generare un prompt senza trasformarlo in output finale. Il
prompt generato è una richiesta. La risposta AI ottenuta dopo l'uso deve
essere letta, verificata, validata ed eventualmente riformulata.

Quinta: saper usare Confronta stati solo quando esiste un caso
precedente e uno stato corrente. Il confronto non prova che un'azione
sia stata svolta; mostra differenze e aiuta a costruire una nuova
richiesta.

La postura corretta è: Prompt Builder governa l'ingresso verso l'AI, non
l'uscita verso il mondo.

Prompt Builder va usato quando l'operatore sta per chiedere aiuto a una
AI o a un LLM e sente il rischio di esporre troppo, chiedere male o
ricevere una risposta troppo assertiva.

È particolarmente utile quando:

serve un primo inquadramento prudente di una situazione confusa;
un team vuole chiedere a un LLM una griglia di analisi senza caricare il
dossier reale;
bisogna preparare una richiesta tecnica interna;
serve un brief non identificativo per avvocato, DPO o consulente;
il management chiede una sintesi e l'operatore vuole evitare conclusioni
premature;
bisogna preparare una comunicazione a soggetti interessati, dipendenti,
clienti o pubblico;
occorre chiedere chiarimenti a un fornitore senza formulare accuse
improprie;
si vuole costruire un decision log o una traccia di verbale;
è emerso un possibile uso improprio di AI esterne;
si vuole aggiornare un prompt precedente dopo nuove verifiche;
bisogna confrontare uno stato corrente con un salvataggio precedente
dello stesso caso.

Prompt Builder è meno adatto quando l'operatore vuole una decisione
definitiva. Le decisioni restano alle funzioni competenti: legale, DPO,
CISO, incident responder, management, fornitore, auditor o altra
funzione responsabile.

Prima di aprire ESR-PROMPT-BUILDER.html, l'operatore deve fare tre
scelte.

La prima è scegliere il livello di astrazione. Si lavora su caso reale,
caso derivato o scenario di esercizio? Nel caso reale, l'operatore deve
minimizzare: niente nomi inutili, niente dettagli identificativi, niente
documenti integrali, niente dati personali non necessari. Nel caso
derivato, mantiene la struttura del problema e rimuove gli elementi
identificativi. Nel caso di esercizio, usa dati fittizi.

La seconda è decidere che cosa si vuole ottenere dall'AI. Una richiesta
vaga come "dimmi cosa fare" espone a risposte troppo ampie. È meglio
chiedere: "aiutami a distinguere fatti, ipotesi e verifiche mancanti",
oppure "prepara una traccia di domande per il fornitore", oppure
"*aiutami a costruire una nota prudente per management con decisioni da
validare*".

La terza è decidere che cosa non deve uscire. Prima ancora di compilare,
l'operatore dovrebbe sapere quali elementi restano fuori: nomi, importi,
identificativi di persone, credenziali, dettagli di vulnerabilità, nomi
reali di fornitori, screenshot, log grezzi, contratti o comunicazioni
interne non necessarie.

La domanda iniziale non è "che cosa posso dare all'AI?". È "*qual è il
minimo che l'AI deve sapere per aiutarmi senza prendere il posto
dell'organizzazione?*".

L'operatore apre Prompt Builder dalla home di prodotto
(italy-switzerland/index.html) oppure direttamente da
italy-switzerland/ESR-PROMPT-BUILDER.html, distinta dal selettore
radice del pacchetto (paragrafo 2.1bis).

In alto trova tre card di modalità:

Caso corrente - Costruisci il caso;
Funzione contestuale - Confronta stati;
Modalità rapida - Vai all’essenziale.

Questa barra è già una lezione di metodo.

Costruisci il caso è il percorso ordinario. Serve quando l'operatore
vuole costruire una richiesta completa, selezionando struttura, stato,
tempi, richiesta operativa, sistemi, soggetti, informazioni, azioni e
validazioni.

Confronta stati è una funzione contestuale. Ha senso solo dopo avere
compilato o caricato il caso corrente e dopo avere importato un
salvataggio precedente dello stesso caso. Non è un prodotto autonomo.
Non serve se manca lo stato precedente.

Vai all’essenziale è la modalità rapida. Serve quando il caso è
confuso, c'è pressione e l'operatore rischia di chiedere troppo o male.
Usa poche domande e può produrre anche solo un inquadramento minimo se
non ci sono elementi sufficienti.

Sotto la modebar compare una riga di stato. Nel percorso completo dice:

Caso corrente attivo: compila solo ciò che vuoi dichiarare. Il prompt conterrà i dati dichiarati e le assenze sostanziali rilevanti.

Il formatore deve fermarsi qui. Questa riga spiega tutto: il modulo non
riempie i vuoti per plausibilità. Il prompt nasce da ciò che l'operatore
dichiara.

La prima sezione visibile nel percorso completo è Caricamento.

Contiene:

Carica caso JSON in chiaro;
Importa caso cifrato;
Pulisci caso corrente;
file input nascosti per JSON e dossier cifrato;
riga di stato del caso.

Carica caso JSON in chiaro

Questo pulsante importa un caso ordinario esportato in precedenza.

È utile quando l'operatore vuole riprendere una compilazione, lavorare
su una versione precedente o usare il confronto contestuale.

Un caso JSON in chiaro è un dossier sensibile. Può contenere struttura
del soggetto, caso corrente, selezioni, autorità già attivate,
annotazioni, prompt generato e dati macchina. Va conservato e condiviso
con cautela.

Importa caso cifrato

Questo pulsante importa un caso cifrato.

Richiede la passphrase corretta nella sezione Passphrase e vault.
È la modalità preferibile quando il caso è sensibile e deve essere
trasferito tra browser, operatori o dispositivi autorizzati.

Pulisci caso corrente

Questo pulsante rimuove il caso caricato o compilato e riporta il modulo
a uno stato nuovo. Va usato quando si vuole ricominciare, oppure quando
si cambia perimetro e si vuole evitare contaminazione tra casi.

Il formatore deve insistere su un punto: caricare un caso non significa
validarlo. Significa ripristinare uno stato di compilazione. L'operatore
deve sempre rileggerlo.

La sezione Passphrase e vault contiene:

Passphrase dossier;
Conferma passphrase;
Mostra passphrase.

Questi campi servono per import/export cifrato, vault della struttura e
vault del caso.

La passphrase deve avere almeno 12 caratteri. La suite non la salva e
non può recuperarla. Se la passphrase viene persa, il dossier cifrato e
il vault non sono recuperabili.

Il pulsante Mostra passphrase aiuta a verificare che non ci siano
errori di battitura. Va usato con prudenza, evitando di mostrare la
passphrase durante proiezioni o sessioni condivise.

La sezione vault è importante perché Prompt Builder salva due oggetti
diversi:

la struttura riusabile del soggetto;
il caso corrente.

La struttura può essere salvata per precompilare futuri casi. Il caso
corrente contiene invece la situazione specifica e richiede maggiore
cautela.

La sezione Chi è coinvolto descrive la struttura stabile o riusabile
del soggetto.

È una parte delicata perché può essere confusa con il caso corrente. Il
formatore deve chiarire subito: questa sezione dice chi è il soggetto,
quali asset tratta normalmente, quale perimetro usa e che tipo di
organizzazione è. Non dice automaticamente che quei dati o asset siano
coinvolti nel caso attuale.

Carica struttura presente nel browser

Il pulsante Carica struttura presente nel browser compare quando
esiste una struttura salvata localmente nel vault del browser.

Serve per precompilare la parte riusabile. Non carica un caso
precedente. Carica solo il profilo del soggetto.

Questa distinzione è decisiva: struttura e caso restano separati.

Etichetta interna della struttura

Il campo Etichetta interna della struttura serve a dare un nome al
profilo.

Esempi buoni:

struttura generica società operativa;
profilo ente pubblico demo;
profilo fornitore SaaS tokenizzato;
struttura gruppo CH-EU - versione formazione.

Esempi da evitare:

nomi completi non necessari;
codici cliente;
riferimenti contrattuali;
nomi di persone;
formule che rendono identificabile un caso reale.

Questa etichetta può comparire nei file esportati. Va quindi scelta con
lo stesso criterio usato per i label di Blindspot e Drill.

Perimetro

Il campo Perimetro contiene:

vuoto;
Europa / UE-SEE;
Italia - applicazione nazionale UE;
Svizzera;
Cross-border Svizzera/Europa;
Non noto / da verificare.

Il perimetro non genera automaticamente conclusioni. Orienta il
linguaggio e le cautele.

Se l'operatore sceglie Europa / UE-SEE, deve selezionare il Paese
europeo di riferimento se già noto, oppure lasciare
Non indicato / da determinare.

Se sceglie Italia, il Paese viene precompilato perché noto.

Se sceglie Svizzera, il Paese viene precompilato come Svizzera.

Se sceglie Cross-border Svizzera/Europa, il lato svizzero è noto e
il lato europeo resta selezionabile o non indicato.

La regola formativa è: il perimetro indica il contesto di ragionamento,
non prova automaticamente obblighi o autorità competenti.

Come già osservato per Blindspot e Drill, l'opzione Italia è
un'estensione propria dell'edizione Italy / Switzerland. L'edizione
Europe / Switzerland propone qui solo Europa / UE-SEE, Svizzera,
cross-border e "non noto"; un caso italiano vi si imposta scegliendo
Europa / UE-SEE e indicando l'Italia nel campo Paese che segue.

Nazione / Paese di riferimento

Il campo Nazione / Paese di riferimento usa il catalogo Paesi della
suite.

Serve a dare maggiore precisione al perimetro. Il catalogo include Paesi
UE/SEE, Svizzera e Regno Unito.

L'operatore deve scegliere il Paese solo se è ragionevole farlo. Se non
è chiaro, è meglio lasciare Non indicato / da determinare o usare
Non noto / da verificare nel perimetro.

Paese europeo / UE-SEE coinvolto

Questo campo compare nel perimetro cross-border. Serve a indicare il
lato europeo del caso quando il caso coinvolge Svizzera e UE/SEE.

Esempio: un fornitore svizzero tratta dati o servizi per un cliente
italiano; oppure un gruppo con entità svizzera e stabilimento europeo
deve preparare una richiesta AI prudente.

Il campo non serve a moltiplicare le autorità. Serve a rendere visibile
la dimensione cross-border.

Tipo organizzazione

Le opzioni includono:

Impresa operativa;
Studio professionale;
Consulente;
Fornitore IT / SaaS;
Ente pubblico o partecipato;
Soggetto sanitario;
Soggetto finanziario;
Scuola / formazione;
Associazione / fondazione;
Altro;
Non noto / da verificare.

Il tipo di organizzazione orienta il linguaggio. Non dimostra il
coinvolgimento di specifiche categorie di dati.

Se l'organizzazione è un soggetto sanitario, il prompt può adottare
cautele coerenti con un contesto sensibile. Questo non significa che
dati sanitari siano coinvolti nel caso corrente. L'operatore dovrà
dichiararlo nella sezione del caso, se rilevante.

Maturità

Le opzioni sono:

vuoto;
Base;
Intermedia;
Strutturata;
Non nota.

La maturità aiuta il prompt a calibrare il livello di dettaglio e i
prossimi passi.

Base suggerisce che il destinatario dovrà offrire passaggi più guidati
e meno presupposti.
Intermedia indica un'organizzazione con alcuni presidi ma non
pienamente consolidati.
Strutturata indica che possono esistere ruoli, procedure e registri
già presenti.
Non nota è preferibile quando l'operatore non ha elementi.

La maturità non deve essere usata come giudizio reputazionale. È una
coordinata operativa.

Dati, sistemi e asset normalmente trattati o gestiti

Il pannello Dettagli opzionali della struttura contiene una griglia di
asset e dati normalmente trattati o gestiti.

Le opzioni includono:

dati clienti;
dati dipendenti;
dati utenti finali;
dati di contatto;
dati economici;
dati sanitari;
dati particolari;
dati giudiziari;
credenziali;
token;
log;
documenti contrattuali;
segreti commerciali;
codice sorgente;
dataset AI;
contenuti caricati da clienti;
sistemi critici;
infrastrutture cloud;
servizi affidati a fornitori esterni.

Questa lista descrive ciò che il soggetto tratta normalmente. Non va
usata per dire che quei dati sono coinvolti nel caso.

Il formatore deve proporre un esempio:

Un'azienda SaaS può trattare normalmente codice sorgente, dati clienti,
log e infrastruttura cloud. Se il caso riguarda una comunicazione
commerciale errata, non bisogna dedurre che codice sorgente o log siano
coinvolti. La struttura orienta; il caso dichiara.

Salva struttura in vault cifrato

Il pulsante Salva struttura in vault cifrato salva localmente il
profilo della struttura.

Serve quando si vuole riutilizzare lo stesso soggetto in più casi. La
struttura viene conservata nel browser come envelope cifrato, protetto
da passphrase.

Va usato su dispositivi adeguati e con passphrase custodita. La
struttura può contenere comunque informazioni sensibili su asset,
maturità e perimetro.

La sezione Momento dell’azione descrive lo stato del caso corrente.

Stato di certezza sul perimetro

Le opzioni sono:

vuoto;
Perimetro non accertato;
Perimetro parziale;
Perimetro abbastanza delimitato.

Questa è una delle selezioni più importanti del modulo.

Perimetro non accertato indica che il caso è ancora molto incerto. Il
prompt dovrà chiedere domande essenziali e impedire conclusioni.

Perimetro parziale indica che alcuni elementi sono noti, ma mancano
parti rilevanti.

Perimetro abbastanza delimitato indica che l'operatore ha abbastanza
elementi per preparare una richiesta mirata.

Il formatore deve insegnare a non scegliere
Perimetro abbastanza delimitato per sentirsi più sicuri. Se mancano
sistemi, dati, interessati, tempi, accessi o evidenze, il perimetro
resta parziale o non accertato.

Azioni già compiute

La griglia delle azioni già compiute include:

ruoli interni già allertati;
management / CDA già informato;
autorità o canale istituzionale già allertato;
comunicazione obbligatoria già inviata;
soggetti interessati già avvisati;
fornitore già contattato;
comunicazione pubblica già uscita;
customer care / front office già attivato.

Queste voci vanno selezionate solo se l'azione è realmente avvenuta.

Il modulo non deduce azioni compiute dal confronto tra stati.
L'operatore deve dichiararle. Questa disciplina evita che un elemento
sparito da una compilazione venga interpretato come risolto.

Autorità o canali istituzionali già attivati

Il Prompt Builder contiene un catalogo dichiarativo di Paesi e
autorità/canali istituzionali. Il catalogo serve a indicare ciò che
l'utente dichiara già attivato o contattato. Non è una raccomandazione
automatica di notifica.

Questa sezione può mostrare autorità di protezione dati, canali
cyber/CSIRT e vigilanza settoriale, secondo Paese e categoria.

L'operatore deve selezionare un'autorità solo se esiste già una
segnalazione, notifica, interlocuzione o canale attivato. Se il caso
riguarda l'Italia, per esempio, la presenza di Garante, ACN o autorità
finanziarie nel catalogo non significa che vadano contattate. Significa
che possono essere dichiarate se già attivate nel caso.

Annotazioni su autorità, canali o interlocuzioni

Il campo libero permette di aggiungere note astratte.

Esempi:

ticket aperto presso canale tecnico del fornitore;
interlocuzione informale interna con DPO;
nessuna autorità ancora attivata;
canale settoriale da verificare;
management informato con nota cautelativa.

Le annotazioni entrano nel prompt con la formula Considera anche che:.
Devono quindi essere prudenti e non identificative.

La sezione Distanza temporale chiarisce quando si colloca il caso.

I campi sono:

Tempo dall’evento, se noto;
Tempo dalla scoperta o segnalazione;
Tempo da eventuale prima comunicazione già effettuata;
Pressione temporale o esterna.

Tempo dall'evento, se noto

Le opzioni sono:

vuoto;
meno di 24 ore;
24--72 ore;
più di 72 ore;
settimane;
non noto.

Questo campo riguarda il tempo dall'evento ipotizzato o conosciuto.

Se l'evento non è certo, l'operatore deve scegliere Non noto o
lasciare vuoto, non inventare una data. La differenza tra evento e
scoperta è fondamentale.

Tempo dalla scoperta o segnalazione

Le opzioni sono analoghe: meno di 24 ore, 24--72 ore, più di 72 ore,
settimane, non noto.

Questo campo riguarda il momento in cui l'organizzazione ha ricevuto un
segnale o ha avuto conoscenza operativa del problema.

È spesso più importante del tempo dall'evento, perché molte valutazioni
organizzative e regolatorie partono dalla conoscenza o consapevolezza.

Tempo da eventuale prima comunicazione già effettuata

Le opzioni includono:

Non applicabile / nessuna comunicazione;
meno di 24 ore;
24--72 ore;
più di 72 ore;
non noto.

Questo campo serve quando c'è già stata una comunicazione a clienti,
utenti, dipendenti, autorità, management, pubblico o fornitore.

Se nessuna comunicazione è uscita, è meglio dichiararlo. Se una
comunicazione è uscita ma non è chiaro quando o a chi, si usa Non noto
e si spiega nelle note.

Pressione temporale o esterna

Le opzioni sono:

nessuna pressione immediata;
scadenza o pressione interna;
scadenza normativa percepita;
richiesta da cliente/utente;
richiesta da autorità o canale istituzionale;
pressione stampa/reputazione;
pressione operativa.

Questa scelta cambia il tono del prompt. Una richiesta sotto pressione
reputazionale richiede cautele diverse da una revisione preventiva. Una
richiesta da cliente richiede un linguaggio diverso da una richiesta
tecnica interna.

Il formatore deve chiarire che scadenza normativa percepita non
significa che l'obbligo esista. Significa che il team percepisce una
pressione e chiede supporto per non agire a caso.

La sezione Richiesta operativa è il cuore della costruzione del
prompt.

Che cosa devi preparare adesso?

Le opzioni includono:

Inquadramento preliminare;
Richiesta interna tecnica;
Brief per avvocato / DPO / consulente;
Nota per CDA / management;
Prima comunicazione a soggetti interessati;
Follow-up a soggetti già avvisati;
Holding statement / comunicato pubblico;
Q&A per customer care / portavoce;
Richiesta a fornitore;
Aggiornamento ad autorità;
Decision log / traccia di verbale;
Comunicazione interna.

Questa selezione modifica in modo sostanziale il prompt.

Inquadramento preliminare serve quando il caso è ancora confuso.
Chiede alla AI di mappare segnali, domande essenziali e condizioni che
farebbero cambiare ramo operativo.

Richiesta interna tecnica serve quando l'operatore deve chiedere a
IT/security una spiegazione verificabile.

Brief per avvocato / DPO / consulente serve a preparare una richiesta
professionale non identificativa, con domande e profili da verificare.

Nota per CDA / management serve a costruire una sintesi direzionale
con stato, opzioni, decisioni e validazioni necessarie.

Prima comunicazione a soggetti interessati e Follow-up richiedono
massima cautela: il prompt dovrà separare fatti dichiarati, elementi in
verifica e azioni prudenziali.

Holding statement / comunicato pubblico deve mantenere un
messaggio minimo sostenibile, senza dettagli tecnici inutili, ammissioni
non accertate o promesse non deliberate.

Q&A customer care serve a distinguere risposte consentite, risposte da
evitare e casi da scalare.

Richiesta a fornitore deve essere ferma ma non accusatoria: chiede
evidenze, tempi, log, misure e chiarimenti.

Aggiornamento ad autorità va usato solo quando esiste già un canale o
una logica di aggiornamento da trattare con funzioni competenti.

Decision log serve a generare una traccia compilabile di decisioni,
motivazioni, owner ed evidenze.

Comunicazione interna serve a dire ai team cosa fare, cosa non fare e
quali canali usare.

Sotto il campo, il modulo mostra un'anteprima dell'orientamento
dell'output. L'operatore deve leggerla sempre: è il primo controllo di
coerenza.

Destinazione d'uso dell'output

Le opzioni includono:

soggetti interessati / potenzialmente esposti;
soggetti non ancora avvisati;
soggetti già avvisati;
CDA / management;
team tecnico / security;
fornitore / outsourcer;
autorità / canale istituzionale;
stampa / pubblico;
customer care / front office;
dipendenti / team interni;
professionista / consulente;
altro.

Questa scelta non cambia il destinatario diretto del prompt: il
destinatario diretto resta l'AI o il LLM a cui l'operatore sottoporrà la
richiesta. Indica invece l'uso potenziale dell'output che l'operatore
potrebbe fare dopo valutazione umana.

Questa distinzione è centrale.

Se l'operatore seleziona Autorità / canale istituzionale, Prompt
Builder non sta notificando un'autorità e non decide che la notifica sia
dovuta. Sta preparando una richiesta all'AI per aiutare l'operatore a
costruire materiale che, dopo validazione, potrebbe essere utile in quel
contesto.

Se seleziona Fornitore, il prompt non scrive automaticamente al
fornitore. Chiede all'AI di aiutare a preparare una richiesta prudente e
proporzionata.

La sezione Dettagli minimi della richiesta contiene quattro campi
liberi.

Questi campi sono il luogo in cui l'operatore può migliorare molto la
qualità del prompt oppure rovinarla inserendo troppo. Vanno compilati
con disciplina.

Fatti dichiarati o elementi osservati

Qui si inserisce ciò che è stato osservato, dichiarato o ricevuto.

Esempi buoni:

Un fornitore SaaS ha segnalato un’anomalia di accesso. Non sono ancora disponibili log esportabili.

È stata individuata una regola di inoltro non riconosciuta su una mailbox condivisa.

Un reparto ha usato strumenti AI per sintetizzare documenti interni; non è ancora noto se contenessero dati personali.

Un cliente chiede evidenze su logging, backup e tempi di notifica entro venerdì.

La regola è: scrivere fatti minimi, non dossier completi.

Informazioni mancanti o ancora in verifica

Questo campo è uno dei più importanti.

Serve a dichiarare ciò che non si sa ancora. Esempi:

Non è noto se vi sia stata consultazione o esportazione di dati.
Non è chiaro quali log siano disponibili presso il fornitore.
Il numero di soggetti potenzialmente coinvolti è da verificare.
Non è noto se l’output AI sia stato riutilizzato in documenti esterni.
Manca conferma sul Paese di trattamento e sui subfornitori.

Il campo impedisce alla AI di riempire i vuoti. Se una informazione
manca, va detta come mancante.

Comunicazioni precedenti, se rilevanti

Qui si indica se qualcosa è già stato comunicato.

Esempi:

È stata inviata una nota interna cautelativa al management, senza indicare dati o conclusioni.

Il fornitore è stato contattato con richiesta di log e timeline.

Un primo avviso ai clienti è stato discusso ma non inviato.

È uscita una comunicazione pubblica preliminare; serve evitare incoerenze nel follow-up.

Questo campo è importante per follow-up, aggiornamenti e coerenza. Va
compilato senza incollare testi reali se non necessario.

Domanda AI o obiettivo specifico

Qui l'operatore deve dire che cosa vuole dal LLM.

Esempi:

Aiutami a costruire una lista di domande tecniche da inviare al fornitore.

Prepara una traccia per il DPO distinguendo fatti, ipotesi e verifiche mancanti.

Aiutami a preparare una nota per management con decisioni da validare e frasi da evitare.

Genera un Q&A prudente per customer care, con risposte consentite e casi da scalare.

Aiutami a valutare quali elementi servono prima di decidere se comunicare agli interessati.

Una domanda debole è:

Dimmi cosa dobbiamo fare.

Prompt Builder è più efficace quando l'obiettivo è concreto e limitato.

Sotto i campi liberi compaiono griglie di selezione multiple:

sistemi, canali o asset potenzialmente coinvolti;
soggetti potenzialmente coinvolti;
tipi di informazioni o contenuti;
azioni possibili o attese dai destinatari;
ruoli di validazione richiesti.

Queste griglie arricchiscono il prompt, ma vanno usate con prudenza.

Sistemi, canali o asset potenzialmente coinvolti

Le opzioni includono:

casella email / posta condivisa;
chat interna / collaborazione;
repository documentale;
CRM;
gestionale HR;
ERP / contabilità / amministrazione;
ticketing;
sito web / CMS;
account o workspace AI;
piattaforma AI / API AI;
storage cloud;
infrastruttura cloud;
identity / access management;
endpoint / laptop;
sistema di rete o sicurezza;
log / monitoring;
backup / recovery;
piattaforma fornitore;
servizio esternalizzato;
processo operativo o commerciale;
disponibilità di servizio;
non noto;
altro.

Questa griglia descrive il caso corrente, non la struttura generale. Va
selezionato solo ciò che è potenzialmente coinvolto nel caso.

Se il dubbio riguarda una mailbox, non serve selezionare CRM o cloud
solo perché l'organizzazione li usa. Se il tema è un agente AI con
accesso a CRM e mail, allora si selezionano account AI, CRM, mailbox e
identity/access.

Soggetti potenzialmente coinvolti

Le opzioni includono:

clienti;
dipendenti;
fornitori;
utenti finali;
minori;
pazienti;
candidati;
partner commerciali;
soggetti pubblici;
non noto.

Anche qui l'operatore deve selezionare solo categorie plausibili nel
caso. La presenza di dati clienti nella struttura non implica clienti
coinvolti nel caso.

Tipi di informazioni o contenuti

Le opzioni includono:

dati di contatto;
dati economici;
dati HR;
dati sanitari;
dati particolari;
dati giudiziari;
credenziali;
token;
log;
documenti contrattuali;
segreti commerciali;
codice sorgente;
dati di localizzazione;
dataset AI;
contenuti caricati da utenti;
non noto.

Se il tipo di contenuto è incerto, è meglio selezionare Non noto o
dichiararlo nel campo informazioni mancanti. Se si sa che potrebbero
essere coinvolti token o credenziali, va indicato perché cambia le
cautele e le azioni attese.

Azioni possibili o attese dai destinatari

Le opzioni includono:

bloccare o sostituire carta;
cambiare password;
revocare token / credenziali;
monitorare movimenti o accessi;
contattare banca o provider;
usare solo canali ufficiali;
non rispondere a messaggi sospetti;
fornire chiarimenti o evidenze;
autorizzare una decisione;
attendere aggiornamento ufficiale;
altro.

Questa griglia è utile quando si prepara una comunicazione o un Q&A.
Aiuta la AI a proporre azioni proporzionate e non generiche.

L'operatore deve evitare azioni non deliberate. Se l'organizzazione non
ha deciso di far cambiare password a tutti, non va selezionato come
azione attesa.

Ruoli di validazione richiesti

Le opzioni includono:

avvocato / legale;
DPO / privacy;
IT / security;
comunicazione;
customer care;
management / CDA;
procurement / vendor management;
responsabile processo;
fornitore;
HR;
assicuratore / broker.

Questa griglia serve a dichiarare chi deve validare, rivedere o
contribuire prima di usare l'output.

Il prompt generato deve ricordare che l'output AI non è una decisione
finale. Se la richiesta riguarda una comunicazione a soggetti
interessati, serviranno probabilmente DPO/privacy, legale, comunicazione
e management. Se riguarda una richiesta tecnica al fornitore, serviranno
IT/security, procurement/vendor management e forse legale.

La sezione Regole di risposta contiene:

Lingua di output;
Specifica lingua di output;
Livello output.

Lingua di output

Le opzioni sono:

italiano;
inglese;
altra.

Se si sceglie Altra, compare il campo Specifica lingua di output,
dove l'operatore può scrivere per esempio francese, tedesco, spagnolo.

La lingua scelta riguarda l'output che l'AI dovrà produrre. Non cambia
la lingua del modulo.

Livello output

Le opzioni includono:

vuoto;
essenziale;
operativo;
dettagliato;
direzionale;
tecnico;
privacy/legal oriented.

La scelta del livello deve corrispondere alla destinazione d'uso.

Essenziale è utile sotto pressione, quando serve evitare teoria.

Operativo è utile quando si vogliono passi concreti, owner, verifiche
e cautele.

Dettagliato è utile per analisi o preparazione interna, ma va usato
con cautela se il caso è sensibile: più dettaglio può significare più
esposizione.

Direzionale è adatto a management e CDA.

Tecnico è adatto a IT/security, fornitore tecnico o richieste di log.

Privacy/legal oriented è adatto a DPO, privacy, legale o
consulente, ma non sostituisce il loro parere.

Quando il percorso completo è compilato, l'operatore clicca
Genera richiesta.

Il modulo costruisce una richiesta testuale.

Il prompt generato contiene, in modo variabile:

ruolo richiesto alla AI;
scopo della richiesta;
struttura del soggetto, se dichiarata;
contesto del caso corrente;
fatti dichiarati;
informazioni mancanti;
autorità o canali già attivati, se dichiarati;
distanze temporali;
pressione;
richiesta operativa;
destinazione d'uso dell'output;
sistemi, soggetti, informazioni e azioni selezionate;
ruoli di validazione;
cautele anti-inferenza;
formato e livello della risposta attesa.

Il modulo non genera sempre lo stesso testo. Modifica orientamento,
vincoli e prossimi passi in base alle selezioni.

Se mancano informazioni sostanziali, produce un inquadramento rapido. Se
emerge uso non chiarito di AI esterne, produce domande specifiche su
strumento, scopo, account, tempi, output riutilizzati e verifiche
successive. Se il destinatario d'uso è un avvocato, il testo cambia
rispetto a una richiesta per un tecnico o per un fornitore.

Il formatore deve far leggere l'output prima di copiarlo. La generazione
non è la fine del lavoro; è il primo controllo qualità.

Il pannello Richiesta costruita mostra il risultato.

Contiene:

Copia;
Esporta TXT;
Esporta JSON in chiaro;
Esporta JSON cifrato;
Svuota output.

Copia

Il pulsante Copia copia il prompt negli appunti.

Questa è l'azione più delicata, perché dopo la copia l'operatore può
incollarlo in un LLM o in altro strumento. Prima di copiare deve leggere
il prompt e chiedersi:

contiene nomi inutili?
contiene dati personali?
contiene identificativi di sistemi reali non necessari?
contiene ipotesi presentate come fatti?
chiede alla AI una decisione che spetta all'organizzazione?
indica ruoli di validazione?
dice che cosa resta incerto?

La regola è: copiare solo dopo revisione.

Esporta TXT

Esporta il prompt come file di testo.

È utile per conservarlo, farlo validare o attestarlo come versione
approvata prima dell'uso con un LLM. Il TXT può contenere informazioni
sensibili e va governato.

Esporta JSON in chiaro

Esporta il risultato strutturato.

È utile per interoperabilità, reimportazione, tracciabilità o confronto.
Essendo strutturato, può contenere molto più del testo visibile.

Esporta JSON cifrato

Esporta il risultato in forma cifrata.

È la scelta più prudente per dossier sensibili o prompt che contengono
dettagli del caso.

Svuota output

Pulisce il risultato generato dalla pagina.

Svuotare output non cancella necessariamente il caso compilato o il
vault. Serve solo a rimuovere il risultato visibile.

Sotto il risultato, Prompt Builder contiene un pannello
Prompt Show - Origine delle righe generate.

Il pulsante Mostra traccia di generazione apre la traccia. Il pulsante
Copia traccia la copia.

La traccia mostra origine, condizione e testo generato per ogni blocco
del prompt. Serve a capire perché il prompt contiene una riga o una
sezione.

Questo è uno strumento formativo molto potente.

Il formatore deve usarlo per mostrare che il prompt non nasce da una
magia. Ogni blocco ha un'origine:

utente;
motore;
struttura;
caso;
richiesta;
output;
cautele;
confronto.

La traccia aiuta a rispondere a domande come:

questa frase deriva da una selezione dell'utente o da una cautela del
motore?
perché compare la nota sul perimetro non qualificato?
perché il prompt chiede di non dedurre obblighi?
perché sono comparsi ruoli di validazione?
quale campo ha prodotto questa sezione?

Prompt Show è anche un controllo anti-inferenza. Se l'operatore vede una
riga che non dovrebbe esserci, può tornare ai campi e correggere la
selezione. Se una cautela è generata dal motore, può capirne la
condizione.

La traccia stessa può essere sensibile perché rivela la struttura della
richiesta. Va trattata con la stessa cautela del prompt.

Il modulo chiude con un promemoria:

Usa il prompt come traccia metodologica: completa solo ciò che serve, nel canale appropriato.

Questa frase deve essere spiegata.

Il prompt generato non va necessariamente copiato così com'è.
L'operatore può ridurlo, adattarlo, togliere dettagli, sostituire token,
cambiare formulazioni, aggiungere limiti o farlo validare.

Il canale appropriato dipende dal caso. Un LLM pubblico, un LLM
aziendale autorizzato, uno strumento interno, un consulente umano o una
riunione tecnica hanno rischi diversi.

Prompt Builder riduce l'esposizione automatica, ma non decide quale
canale sia autorizzato.

La modalità Vai all’essenziale è il percorso rapido.

Serve quando l'operatore ha poco tempo, il caso è confuso o c'è il
rischio di chiedere all'AI una risposta impulsiva.

I campi sono ridotti:

perimetro;
nazione / Paese di riferimento;
Paese europeo / UE-SEE coinvolto, se rilevante;
tipo organizzazione;
area prevalente;
autorità o canali già attivati;
annotazioni su autorità o canali;
cosa è successo;
quale uso della risposta AI devi preparare;
lingua di output;
specifica lingua di output;
annotazioni rapide sul problema.

Area prevalente

Le opzioni includono:

privacy;
cyber;
AI;
fornitore;
audit / evidenze;
comunicazione;
non noto.

Questa scelta orienta la richiesta minima.

Cosa è successo?

Il campo Cosa è successo? usa le categorie del problema:

possibile data breach;
incidente cyber o anomalia tecnica;
errore umano;
condivisione impropria di documento;
accesso non autorizzato o dubbio accesso;
perdita, alterazione o indisponibilità di dati;
problema con fornitore esterno;
richiesta di audit o evidenze;
contestazione cliente o controparte;
comunicazione da preparare;
dubbio su uso di AI;
documenti già inseriti in AI esterne;
non so ancora come inquadrarlo.

Se l'operatore non sa, deve scegliere Non so ancora come inquadrarlo.
È molto meglio che forzare una categoria.

Quale uso della risposta AI devi preparare?

Questo campo usa la lista dei destinatari/usi:

consulente privacy;
DPO;
avvocato;
tecnico IT;
fornitore;
management;
team operativo;
auditor;
assicuratore o broker cyber;
consulente;
non noto;
altro.

Anche qui, il destinatario diretto della richiesta resta l'AI/LLM. Il
campo indica l'uso che l'operatore potrebbe fare della risposta dopo
valutazione.

Annotazioni rapide sul problema

Il campo deve contenere una descrizione generica e di alto livello. Non
è il luogo dove incollare documenti, log, email o testi integrali.

Esempio buono:

Un fornitore ha segnalato un’anomalia. Non è ancora chiaro se ci sia stato accesso a dati. Serve capire quali domande fare prima di comunicare.

Esempio rischioso:

incollare la mail integrale del fornitore, con nomi, timestamp, account,
IP, allegati e identificativi.

Prepara richiesta essenziale

Il pulsante Prepara richiesta essenziale genera il prompt rapido.

La qualità della modalità rapida sta anche nel suo comportamento quando
mancano input sostanziali. Se l'operatore lascia tutto vuoto o quasi
vuoto, il modulo non inventa un incidente, non presume un data breach e
non costruisce un piano operativo. Produce invece una richiesta di
inquadramento rapido.

Questa è una scelta progettuale importante: quando non c'è un caso,
Prompt Builder non finge che ci sia.

Vai all’essenziale va usato in tre situazioni.

Prima situazione: l'operatore ha pochissimo tempo e vuole evitare di
buttare il caso in un LLM senza metodo.

Seconda situazione: il caso è ancora troppo confuso per il percorso
completo. In questo caso la richiesta essenziale può chiedere alla AI di
aiutare a classificare i primi segnali.

Terza situazione: l'operatore deve preparare una prima domanda, non una
bozza finale.

Il formatore deve chiarire che la modalità rapida non è inferiore. È
semplicemente più stretta. Funziona bene se l'obiettivo è fermare
l'impulso e ottenere una griglia minima.

Confronta stati è una funzione interna del Prompt Builder.

Ha senso solo quando esistono due elementi:

uno stato precedente salvato come caso JSON ordinario o dossier
cifrato;
uno stato corrente compilato nel percorso Costruisci il caso.

Il confronto non parte da home e non sostituisce il percorso completo.
Serve a leggere l'evoluzione di un caso.

Salvataggio di partenza

Nel pannello Stato precedente - Salvataggio di partenza,
l'operatore può:

importare stato JSON in chiaro;
importare stato cifrato.

Il file precedente deve essere un caso ordinario salvato dal Prompt
Builder. La modalità Vai all’essenziale resta volatile: non usa
caricamento, salvataggio o confronto di casi.

Una volta caricato lo stato precedente, il modulo mostra una sintesi.

Compilazione attuale

Nel pannello Stato corrente - Compilazione attuale, l'operatore
clicca Aggiorna anteprima caso corrente.

Il secondo termine del confronto non è un altro file. È lo stato attuale
compilato nella pagina.

Questo evita un uso improprio: non si stanno confrontando due archivi
astratti, ma un salvataggio precedente con ciò che l'operatore dichiara
ora.

Azioni compiute dichiarate

Il campo Azioni compiute dichiarate è cruciale.

Il modulo non deduce che un'azione sia stata fatta solo perché qualcosa
è cambiato tra stato precedente e stato attuale. Se prima era
selezionato fornitore e ora non lo è più, questo non significa che il
problema fornitore sia risolto.

Solo ciò che l'operatore scrive qui viene trattato come azione
dichiarata.

Esempi:

coinvolto referente tecnico interno;
sospesa comunicazione esterna;
richiesto chiarimento al fornitore;
revocati token indicati dal team IT;
aggiornata nota al management.

Ogni voce può essere una riga.

Riscontri o cambiamenti emersi

Il campo Riscontri o cambiamenti emersi serve a descrivere cosa si è
appreso.

Esempi:

chiarita una categoria di rischio;
emersa nuova verifica su retention AI;
ridimensionata ipotesi di esfiltrazione;
confermata assenza di log esportabili;
identificato owner del processo.

Anche qui, il campo serve a dichiarare, non a far dedurre.

Confronta stati non è una funzione di audit automatico e non
ricostruisce da sola ciò che è accaduto. Lavora sulle differenze tra ciò
che era stato salvato e ciò che l'operatore dichiara ora nella pagina.
Le differenze aiutano a formulare una nuova richiesta più ordinata, ma
non dimostrano, da sole, che una verifica, una bonifica o una decisione
siano state effettivamente eseguite.

Il campo Che cosa deve produrre il confronto? contiene sei opzioni.

Confronto neutro precedente/corrente

Produce una lettura neutra delle differenze.

È utile quando l'operatore vuole capire che cosa è cambiato senza
chiedere piani, comunicazioni o stress test.

Ricava azioni fatte e prossimi passi

Produce una lettura operativa: azioni dichiarate come svolte, azioni
ancora aperte, verifiche mancanti, ruoli competenti e prossimi passaggi
proporzionati.

Va usato quando l'operatore ha compilato bene il campo azioni compiute.

Trova buchi, incoerenze e rischi residui

Produce uno stress test del delta.

È utile quando si teme che il caso sia stato semplificato troppo presto,
che una differenza sia stata interpretata come chiusura, o che una
risposta AI precedente abbia prodotto false sicurezze.

Genera un piano operativo aggiornato

Produce un piano aggiornato sulla base dello stato corrente e del
confronto.

Va usato quando l'obiettivo è decidere prossimi passi, owner e
verifiche.

Prepara una comunicazione prudente

Produce una richiesta orientata a comunicazione prudente.

Va usato solo se la comunicazione è realmente un obiettivo e se sono
chiari destinatario, incertezze e validazioni.

Aggiorna una risposta LLM precedente

Questa opzione usa, se compilati, il riferimento e il testo della
risposta LLM precedente.

La risposta LLM precedente non viene trattata come verità, evidenza o
cronologia. È solo un testo da rivalutare, confermare, correggere o
superare alla luce dello stato corrente.

I campi sono:

Riferimento alla risposta LLM precedente opzionale;
Risposta LLM precedente opzionale.

Il riferimento può essere astratto:

risposta del 1 luglio;
chat interna;
versione sintetica;
output LLM n. 2;
bozza precedente.

Nel campo risposta si può incollare il testo o una sintesi astratta.
L'operatore deve evitare di incollare dati reali non necessari.

La funzione è utile quando una risposta AI precedente era troppo
assertiva, incompleta, superata o da aggiornare.

Il modulo impone una cautela: quel testo non è cronologia e non è prova.
È materiale da rivedere.

Il pulsante Genera confronto operativo si abilita quando sono presenti
stato precedente e stato corrente.

Il risultato ha due livelli:

brief interno di confronto;
prompt esterno copiabile orientato all'obiettivo scelto.

Il brief interno aiuta l'operatore a leggere:

che cosa è nuovo;
che cosa resta;
che cosa non è più presente;
che cosa è stato dichiarato come fatto nel mezzo;
quali riscontri sono emersi;
quali cautele restano.

Il prompt esterno è la richiesta che l'operatore può sottoporre a un LLM
dopo revisione.

Il formatore deve insegnare una regola: il confronto è uno strumento di
continuità decisionale, non una prova di avanzamento. Le differenze
documentali mostrano cambiamenti nello stato dichiarato. Le azioni
compiute devono essere dichiarate e, fuori dal modulo, supportate da
evidenze.

Nel percorso completo compare la sezione Salvataggio e generazione.

Contiene:

Nome file caso;
Export caso cifrato;
Export JSON in chiaro;
Salva vault cifrato;
Ripristina vault;
Cancella vault;
Genera richiesta;
Pulisci caso corrente.

Nome file caso

Il campo Nome file caso permette di scegliere il nome del file.

Esempi buoni:

caso-fornitore-hr-prima-valutazione;
prompt-management-dubbio-ai;
richiesta-tecnica-log-saas;
confronto-fase-2-tokenizzato.

Esempi da evitare:

nomi di persone;
nomi reali di clienti o fornitori;
descrizioni accusatorie;
frasi come data-breach-confermato quando il caso è solo dubbio;
identificativi contrattuali non necessari.

Export caso cifrato

Esporta il caso corrente in forma cifrata.

È la modalità più coerente con casi reali o derivati. Richiede
passphrase e conferma.

Export JSON in chiaro

Esporta il caso ordinario in chiaro.

È utile per interoperabilità, confronto, revisione o lavoro tecnico. Va
trattato come dossier sensibile.

Salva vault cifrato

Salva il caso corrente nel vault cifrato locale del browser.

Serve per riprendere il lavoro. Non è archivio ufficiale.

Ripristina vault

Ripristina il caso corrente dal vault locale, usando la passphrase
corretta.

Cancella vault

Rimuove il vault del caso dal browser.

Va usato quando si lavora su macchina non dedicata o quando il lavoro è
stato esportato e non deve restare localmente.

Genera richiesta

Costruisce il prompt.

Pulisci caso corrente

Azzera la compilazione corrente. Prima di usarlo, l'operatore deve
decidere se esportare o salvare ciò che serve.

Uno dei principi che rendono affidabile Prompt Builder è la disciplina
anti-inferenza.

Il prompt dice solo ciò che l'operatore ha dichiarato, e nulla di più.

Le categorie della struttura e del problema orientano il linguaggio, non
dimostrano cosa sia successo. Se la struttura indica
soggetto sanitario, questo non implica che siano coinvolti dati
sanitari o pazienti. Se il perimetro è Europa/UE-SEE, Italia, Svizzera o
cross-border, questo non implica un obbligo transfrontaliero o una
doppia notifica. Se il tema selezionato è
dubbio accesso non autorizzato, questo non implica un accesso
accertato. Se l'utente indica un fornitore come possibile fattore,
questo non implica che il fornitore sia responsabile.

La richiesta generata ricorda al destinatario di non completare il
quadro per plausibilità.

Se una categoria è lasciata vuota, non compare nel prompt. Se invece
l'utente sceglie Non noto o Da verificare, quel dubbio entra come
informazione dichiarata.

Questa regola è preziosa perché molte risposte sbagliate nascono da
inferenze troppo veloci. Le AI esterne e anche i consulenti sotto
pressione tendono a riempire i vuoti. Prompt Builder impedisce al prompt
di invitarli a farlo.

Nel percorso completo, Prompt Builder usa stato, urgenza e chiarezza dei
fatti per determinare una postura operativa.

La postura può essere:

contenimento AI;
incidente attivo;
revisione post-evento;
richiesta ricevuta da terzi;
preparazione o diagnosi;
ambiguità dei fatti;
default prudente.

Se emerge un possibile uso improprio di AI esterne, la priorità è
contenere ulteriori invii e ricostruire per categorie cosa potrebbe
essere stato condiviso.

Se siamo nelle prime ore di un possibile incidente, la priorità è
preservare evidenze, individuare chi decide e sospendere comunicazioni
esterne non necessarie.

Se si tratta di revisione a posteriori, la priorità è ricostruire la
timeline, distinguere ciò che si sapeva allora da ciò che si sa ora e
individuare cosa è mancato.

Se si tratta di preparazione, l'output lavora su lacune, ownership e
scenari, senza suonare come emergenza.

Se i fatti sono sospetti o contraddittori, il modulo aggiunge un
vincolo: trattare gli elementi disponibili come ipotesi da confermare e
non agire né comunicare su elementi non confermati.

La postura operativa è ciò che impedisce al prompt di avere sempre lo
stesso tono.

Uno dei casi in cui Prompt Builder dà il meglio è l'uso non chiarito di
AI esterne.

Il problema non è solo "qualcuno ha usato l'AI". Il problema è capire:

quale strumento è stato usato;
con quale account;
per quale scopo;
quali dati o documenti sono stati inseriti;
quali output sono stati generati;
se gli output sono stati riutilizzati in email, ticket, documenti o
decisioni;
se esistono policy note;
chi deve essere informato internamente;
quali misure di contenimento sono proporzionate.

Prompt Builder non trasforma il dubbio in condanna. Offre una
ricostruzione ordinata, per categorie.

Questa parte è centrale per la governance AI. Le organizzazioni non
perdono informazioni soltanto quando subiscono incidenti. Possono
perderle anche quando, durante un dubbio o una crisi, qualcuno cerca
aiuto in modo disordinato.

Il formatore può proporre un esempio:

Un dipendente ha caricato documenti in un LLM per farsi aiutare a
rispondere a un cliente. Non è chiaro se i documenti contenessero dati
personali o segreti commerciali. Prompt Builder non deve generare una
notifica o una comunicazione. Deve generare una richiesta che aiuti a
ricostruire per categorie: strumento, account, scopo, contenuto, output,
riuso, policy, contenimento.

Questo esempio è molto utile perché mostra la differenza tra richiesta
ferma e accusa.

Contesto

Un fornitore SaaS ha segnalato un'anomalia, ma non ha fornito log
completi. L'organizzazione deve preparare una richiesta di chiarimenti
da far validare internamente.

Compilazione

Nella struttura:

perimetro: Europa / UE-SEE o cross-border se coerente;
tipo organizzazione: impresa operativa o altro;
maturità: intermedia o non nota;
asset normalmente gestiti: dati clienti, log, servizi affidati a
fornitori esterni.

Nel caso corrente:

stato di certezza: perimetro parziale;
azioni già compiute: fornitore già contattato, se vero;
tempo dalla scoperta: meno di 24 ore o 24--72 ore;
pressione: richiesta da cliente/utente o pressione operativa;
richiesta operativa: richiesta a fornitore;
destinazione d'uso: fornitore / outsourcer.

Nei dettagli:

fatti dichiarati:
Il fornitore ha segnalato un’anomalia tecnica. Non sono ancora disponibili log esportabili.
informazioni mancanti:
Non è noto se vi sia stato accesso, consultazione, esportazione o coinvolgimento di subfornitori.
domanda AI:
Aiutami a preparare una richiesta ferma ma non accusatoria per ottenere evidenze, timeline, log, misure e prossimi aggiornamenti.

Asset:

piattaforma fornitore;
servizio esternalizzato;
log / monitoring;
eventualmente CRM o cloud storage.

Ruoli validazione:

IT / security;
procurement / vendor management;
legale;
DPO/privacy se dati personali plausibili.

Output atteso

Il prompt deve chiedere all'AI di produrre una richiesta strutturata al
fornitore, con domande su:

timeline;
perimetro;
log disponibili;
formato di export;
subfornitori;
misure adottate;
retention;
impatto sui dati;
prossimo aggiornamento;
referente operativo.

La richiesta non deve dire che il fornitore è responsabile. Deve
chiedere ciò che serve per valutare.

Contesto

Il management chiede una sintesi. Il caso è ancora incerto.

Compilazione

Richiesta operativa: Nota per CDA / management.

Destinazione d'uso: CDA / management.

Livello output: Direzionale.

Fatti dichiarati:

È stato rilevato un dubbio accesso su un sistema condiviso. Il team tecnico sta verificando log e sessioni. Non è ancora confermata esfiltrazione.

Informazioni mancanti:

Mancano conferma su dati consultati, soggetti coinvolti, durata dell’accesso e perimetro del fornitore.

Domanda AI:

Prepara una nota sintetica per management che distingua stato attuale, incertezze, decisioni richieste, validazioni necessarie e frasi da evitare.

Ruoli validazione:

management / CDA;
IT / security;
DPO / privacy;
legale;
comunicazione.

Output atteso

Il prompt deve chiedere una nota che eviti due errori: rassicurare
troppo presto e allarmare senza base.

Il management deve ricevere decisioni possibili, non conclusioni
inventate.

Questa è una delle richieste più delicate.

Contesto

L'organizzazione valuta una prima comunicazione a soggetti
potenzialmente coinvolti, ma alcuni fatti sono ancora in verifica.

Compilazione

Richiesta operativa: Prima comunicazione a soggetti interessati.

Destinazione d'uso: Soggetti interessati / potenzialmente esposti
oppure Soggetti non ancora avvisati.

Livello output: Essenziale o Privacy/legal oriented.

Stato di certezza: Perimetro parziale o
Perimetro abbastanza delimitato, secondo il caso.

Fatti dichiarati: solo elementi sostenibili.

Informazioni mancanti: tutto ciò che resta da chiarire.

Azioni attese dai destinatari: selezionare solo azioni già deliberate,
per esempio cambiare password o usare solo canali ufficiali.

Ruoli validazione:

DPO / privacy;
avvocato / legale;
comunicazione;
customer care;
management.

Output atteso

Il prompt deve chiedere una bozza prudente che distingua:

che cosa è noto;
che cosa è in verifica;
che cosa il destinatario può fare;
quali canali usare;
quali frasi evitare;
quale validazione serve prima dell'invio.

Il formatore deve chiarire che la bozza generata da un LLM non va
inviata direttamente. È materiale da validare.

Contesto

Un reparto ha usato un LLM esterno per sintetizzare documenti. Non è
chiaro cosa sia stato caricato e se l'output sia stato riutilizzato.

Compilazione

Perimetro: scegliere il contesto appropriato.

Tipo organizzazione: coerente.

Uso del caso:

stato di certezza: Perimetro non accertato o Perimetro parziale;
problema: Documenti già inseriti in AI esterne o
Dubbio su uso di AI;
area: AI;
richiesta operativa: Inquadramento preliminare oppure
Brief per avvocato / DPO / consulente;
destinazione d'uso: professionista / consulente, DPO, team tecnico o
management.

Fatti dichiarati:

Alcuni documenti interni potrebbero essere stati inseriti in un LLM esterno per ottenere una sintesi. Non è ancora noto quali documenti siano stati caricati.

Informazioni mancanti:

Non sono noti strumento, account usato, data, contenuti caricati, impostazioni retention/training, output generati e riuso dell’output.

Domanda AI:

Aiutami a costruire una griglia di ricostruzione e contenimento senza presupporre violazione, distinguendo domande da fare, evidenze da cercare, ruoli da coinvolgere e cautele informative.

Output atteso

Il prompt deve chiedere una ricostruzione per categorie, non una
conclusione.

Domande chiave:

quale strumento;
quale account;
quali documenti;
quali categorie di informazioni;
quali output;
quale riuso;
quali policy;
quali misure di contenimento;
quali ruoli interni.

Questo esempio mostra la ragione stessa di Prompt Builder: evitare che,
nel tentativo di capire un uso improprio di AI, si consegnino altri dati
a un'altra AI.

Contesto

Il team ha generato un primo prompt, ottenuto una risposta AI e poi
svolto alcune verifiche. Ora vuole aggiornare la richiesta.

Passo 1: caricare o compilare lo stato corrente

L'operatore apre Costruisci il caso e compila lo stato aggiornato.

Se esiste un caso salvato, lo importa. Poi aggiorna campi, azioni, dati,
asset, informazioni mancanti e comunicazioni precedenti.

Passo 2: aprire Confronta stati

L'operatore passa a Confronta stati.

Importa lo stato precedente JSON o cifrato.

Clicca Aggiorna anteprima caso corrente.

Passo 3: dichiarare azioni e riscontri

Nel campo azioni compiute:

richiesti log al fornitore;
coinvolto DPO;
sospesa bozza comunicazione esterna;
ricevuta conferma su assenza esfiltrazione, da validare.

Nel campo riscontri:

log parziali ricevuti;
perimetro dati ridotto a clienti di un servizio;
resta incerta retention dei prompt AI.

Passo 4: scegliere obiettivo

Se l'obiettivo è aggiornare la risposta AI precedente, scegliere
Aggiorna una risposta LLM precedente e inserire una sintesi astratta
della risposta.

Se l'obiettivo è trovare rischi residui, scegliere
Trova buchi, incoerenze e rischi residui.

Passo 5: generare confronto

Il risultato deve aiutare a non ripartire da zero e a evitare false
chiusure.

Il formatore deve chiedere: quali differenze sono solo documentali?
Quali azioni sono dichiarate? Quali prove le supportano fuori dal
modulo?

Il primo errore è incollare il caso reale nei campi liberi. Prompt
Builder serve a minimizzare, non a diventare un deposito del dossier.

Il secondo errore è confondere struttura e caso. Gli asset normalmente
trattati dall'organizzazione non sono automaticamente coinvolti
nell'evento.

Il terzo errore è scegliere categorie per eccesso. Ogni selezione entra
nel ragionamento del prompt. Se non serve, resta fuori.

Il quarto errore è lasciare vuoto ciò che invece è un'incertezza
rilevante. Un campo vuoto non entra nel prompt; Non noto o una nota
sulle informazioni mancanti sì.

Il quinto errore è usare Destinazione d’uso dell’output come se fosse
invio automatico al destinatario. Il prompt va all'AI. Ogni riuso
successivo resta decisione umana e organizzativa.

Il sesto errore è copiare l'output senza leggere Prompt Show. La traccia
di generazione aiuta a capire perché il prompt contiene certe righe.

Il settimo errore è usare Confronta stati senza uno stato precedente
significativo. Il confronto serve alla continuità, non a creare
artificialmente un prodotto.

L'ottavo errore è trattare una risposta AI precedente come evidenza. Nel
modulo è solo testo da rivalutare.

Il nono errore è esportare JSON o TXT in chiaro e lasciarli nella
cartella Download. Gli export possono contenere informazioni sensibili
anche se non contengono nomi.

Il decimo errore è salvare una struttura nel vault e dimenticare che
anche la struttura può rivelare asset, maturità, perimetro e categorie
normalmente trattate.

Il formatore deve impostare la sessione come esercizio di
minimizzazione.

Il ritmo consigliato è:

spiegare la differenza tra struttura e caso;
scegliere una modalità;
compilare solo campi necessari;
dichiarare incertezze invece di mascherarle;
selezionare richiesta operativa e destinazione d'uso;
compilare fatti, mancanze e obiettivo specifico;
scegliere asset, soggetti, informazioni e ruoli solo se pertinenti;
generare la richiesta;
leggere output e Prompt Show;
rimuovere ciò che espone troppo;
decidere se copiare, esportare o cifrare;
discutere quale canale AI sarebbe appropriato;
eventualmente attestare il prompt approvato come milestone.

Durante l'esercizio, il formatore deve fare domande semplici:

questa informazione serve davvero all'AI?
questo campo descrive il caso o la struttura?
questa selezione è nota o solo plausibile?
questa frase trasforma un dubbio in fatto?
chi deve validare la risposta prima di usarla?
quale parte dell'output non va riutilizzata verso terzi?
se dovessimo attestare il prompt, quale versione sarebbe quella
chiusa?

Prompt Builder deve insegnare un gesto: togliere prima di chiedere.

L'operatore non deve leggere il codice per usare Prompt Builder. In
formazione avanzata, però, è utile mostrare che il modulo è dichiarativo
e ispezionabile.

Il file assets/data/ESR-PROMPT-BUILDER-model.js contiene:

schemi;
versione;
chiavi vault;
nomi file;
perimetri;
tipi di organizzazione;
asset e dati della struttura;
maturità;
stati di certezza;
azioni compiute;
distanze temporali;
pressioni;
richieste operative;
destinazioni d'uso;
ruoli di validazione;
azioni attese;
sistemi e asset del caso;
soggetti;
tipi di informazione;
lingue;
destinatari rapidi;
livelli output;
aree rapide;
tipi di problema.

Il file assets/data/ESR-AUTHORITIES-model.js contiene Paesi e
autorità/canali istituzionali. Il commento iniziale chiarisce l'uso
previsto: mostrare opzioni selezionabili, non suggerire automaticamente
notifiche.

Il file assets/js/ESR-PROMPT-BUILDER.js contiene la logica
applicativa: modebar, caricamento, vault, generazione del percorso
completo, Vai all'essenziale, Confronta stati, Prompt Show, export,
import e pulizia.

Questa struttura è importante perché il prompt non è generato da una AI
nascosta. È costruito da cataloghi, selezioni e micro-template locali.

Il modulo è aperto: chi lo modifica può leggere quali categorie
esistono, come vengono usate e quali cautele vengono inserite.

Prompt Builder è il modulo più sensibile da personalizzare, perché
cambia il modo in cui l'organizzazione chiede aiuto all'AI.

Chi modifica il modulo deve sapere dove intervenire.

Per cataloghi, richieste operative, asset, ruoli, lingue e livelli si
lavora su assets/data/ESR-PROMPT-BUILDER-model.js.

Per autorità e Paesi si lavora su
assets/data/ESR-AUTHORITIES-model.js.

Per logica di generazione, Confronta stati, Prompt Show, import/export e
vault si lavora su assets/js/ESR-PROMPT-BUILDER.js.

Ogni modifica deve essere verificata con dev/validate.html e provata
nel browser.

Una personalizzazione prudente deve rispettare alcune regole:

le nuove opzioni devono ridurre ambiguità, non aumentarla;
le etichette visibili possono essere tradotte, ma gli identificatori
devono restare stabili se si vuole interoperabilità;
i nuovi prompt devono mantenere anti-inferenza;
i destinatari devono restare destinazioni d'uso dell'output, non
destinatari automatici del messaggio;
le autorità devono restare catalogo dichiarativo, non raccomandazione
automatica;
le modalità rapide devono restare sobrie;
Confronta stati deve restare funzione contestuale;
gli export devono continuare a distinguere chiaro e cifrato;
Prompt Show deve restare uno strumento di verifica della generazione.

La personalizzazione più utile nasce dall'esperienza: un tipo di
richiesta ricorrente, una cautela mancata, una destinazione d'uso
frequente, un ruolo di validazione non previsto, una lingua, una
categoria di asset, una formula più prudente.

Prima di copiare o esportare un prompt, l'operatore deve verificare:

il prompt contiene solo ciò che serve;
nomi reali e identificativi non necessari sono stati rimossi o
tokenizzati;
la struttura del soggetto non viene confusa con il caso corrente;
le incertezze rilevanti sono dichiarate;
i campi vuoti non hanno prodotto deduzioni;
la richiesta operativa è coerente con l'obiettivo;
la destinazione d'uso dell'output è corretta;
i ruoli di validazione sono presenti;
la risposta richiesta all'AI non sostituisce decisioni professionali;
le autorità selezionate sono solo quelle già attivate o dichiarate;
il livello di dettaglio non espone troppo;
Prompt Show non rivela righe inattese;
l'output è stato letto prima della copia;
il canale AI scelto è autorizzato;
eventuale export è cifrato se sensibile;
eventuale attestazione riguarda una versione approvata, non una bozza.

Prompt Builder è il modulo che protegge il passaggio più facile da
sottovalutare: il momento in cui l'organizzazione chiede aiuto all'AI.

Il suo valore non sta nel produrre testi eleganti. Sta nel costruire
richieste proporzionate, minimizzate e verificabili.

Un operatore formato deve uscire da Prompt Builder con cinque risultati:

una richiesta chiara;
un perimetro dichiarato;
incertezze visibili;
validazioni necessarie;
un prompt che può essere usato senza consegnare più del necessario.

La formula finale è questa: Prompt Builder non chiede all'AI di sapere
di più; insegna all'operatore a dire meglio, e meno.

**
**