Far analizzare i tuoi documenti a un'IA senza che se li inventi

Il 19 agosto 2026 il NIST ha pubblicato la bozza iniziale della Special Publication 1353, una guida rapida di nove pagine su come usare l'intelligenza artificiale generativa per analizzare e documentare la conformità al Cybersecurity Framework 2.0. La consultazione pubblica è aperta fino al 15 ottobre 2026 e riguarda, dice la scheda, la guida e i prompt: non i documenti dell'azienda immaginaria usata negli esempi.

Letta come documento di conformità interessa poche imprese italiane: il CSF non è obbligatorio qui, e la guida stessa si tiene stretta — le tre esercitazioni, scrive, «illustrate a possible approach» e non sono «prescriptive assessment or assurance methodologies». È una bozza anche nel senso materiale: a pagina 4 sono rimasti tre segnaposto «TBD».

Letta per come sono scritti i prompt, invece, è uno dei materiali più utili usciti quest'anno per chi deve far leggere documenti riservati a un modello linguistico e poi risponderne. Il problema è noto: il modello restituisce un testo plausibile, ordinato, con la terminologia giusta, che a occhio non si distingue da uno fondato sui documenti che gli hai dato. Il glossario del NIST lo dice senza giri di parole — l'allucinazione è «plausible but inaccurate AI output» che «requires expert review before use». La guida affronta il problema dove va affrontato: nel prompt.

Il prompt come specifica, non come domanda

Tutti gli esempi usano uno schema a sei campi chiamato CO-STAR: Context, Objective, Style, Tone, Audience, Response. Il contesto descrive lo scenario e i vincoli; l'obiettivo dice qual è il risultato atteso; stile e tono fissano il registro (tecnico, direzionale, da audit; neutro, oggettivo); il destinatario determina il livello di astrazione e la precisione dei termini; la risposta definisce il formato, fino alla colonna del foglio in cui va scritto cosa. Il NIST precisa che esistono altri schemi — cita CRAFT, RISEN, RTF, APE, CREATE — e che conviene scegliere quello adatto al caso, non quello di moda.

La differenza rispetto al modo in cui la maggior parte delle persone usa un assistente non sta nella sigla, ma nel fatto che un prompt così è un documento: si archivia, si riusa, lo si fa rileggere a un collega prima di eseguirlo, e se il risultato è sbagliato si capisce quale campo era scritto male.

Le quattro istruzioni che fanno il lavoro

Dentro quei prompt, quattro righe ricorrono identiche nelle esercitazioni sul profilo di stato attuale e su quello di stato obiettivo. Sono la parte da copiare, qualunque sia il documento che devi far analizzare.

La prima limita il materiale: «Use only the attached source materials for your analysis.» Serve a impedire che il modello colmi i vuoti con la conoscenza generale che ha del settore. Senza questo vincolo, un'analisi delle tue procedure diventa a tratti un'analisi delle procedure tipiche di un'azienda come la tua, e il confine fra le due non è visibile nel testo prodotto.

La seconda impone la tracciabilità: «Source-grounded and traceable. No fabrication.», rafforzata nell'obiettivo dalla richiesta di collegare ogni esito al requisito o alla risposta al rischio che lo determina «and cite them». È la riga che rende possibile la verifica a campione: prendi cinque affermazioni, apri le fonti citate, controlli. Senza citazioni puntuali l'unica verifica possibile è rileggere tutto, che è il lavoro che si voleva risparmiare.

La terza autorizza la risposta vuota: «If an outcome is not addressed in the sources, say so plainly.» Un modello interrogato su un punto di cui i documenti non parlano tende a produrre qualcosa comunque, perché è quello che gli si chiede implicitamente. Dirgli esplicitamente che «non risulta» è una risposta accettabile cambia il comportamento, e trasforma il silenzio delle fonti da rumore in informazione.

La quarta chiede al modello di dichiarare i propri limiti, sotto forma di una nota finale «Assumptions & Evidence Gaps». Nell'esercitazione sullo stato attuale deve elencare due cose: i punti dove le fonti erano «silent or thin», e i punti dove la risposta si appoggia a «documented process rather than observed practice». Quella seconda distinzione è esattamente quella che un revisore esperto fa per mestiere: la differenza fra ciò che la procedura prevede e ciò che le persone fanno. Chiederla in anticipo costa una riga di prompt e indirizza la verifica umana dove serve.

Mappature, provenienza, stato

C'è una seconda parte, più noiosa e più importante, su cosa fare del risultato. La guida avverte che le mappature prodotte con l'aiuto dell'IA dovrebbero conservare «identifiers, source context, provenance, and statuses», e spiega perché: per evitare che corrispondenze non supportate finiscano per essere usate senza la revisione o il contesto di chi ha competenza nel merito. Il glossario definisce anche il vocabolario degli stati: «Proposed / Derived mapping» sono etichette per mappature assistite dall'IA in attesa di validazione esperta.

Due altre avvertenze vanno nella stessa direzione. I dati di riferimento vanno controllati nella versione corrente prima di darli in pasto a un'analisi automatica: una mappatura su un framework superato è sbagliata in modo silenzioso. E l'output è datato — «reflects a point-in-time output», i risultati possono cambiare o variare. Sul file ci vanno quindi data, modello usato e stato: un'analisi senza queste tre informazioni, fra sei mesi, non si sa più come leggerla.

Spogliato del tema americano, lo schema diventa riusabile così com'è: per un raffronto fra procedure interne e registro dei trattamenti, per una prima ricognizione degli obblighi dell'articolo 26 del regolamento sull'IA su un sistema che si sta mettendo in uso, per un'analisi di scostamento rispetto a una norma tecnica. Cambiano il contesto e il formato della risposta; i quattro vincoli restano.

Contesto: analizzi i documenti allegati (procedure, verbali, registri)
          di un'azienda di [settore], [dimensione], soggetta a [requisiti].
Obiettivo: per ciascuna voce dell'elenco allegato, indicare cosa prevedono
          i documenti e cosa risulta effettivamente in atto, citando per
          ogni affermazione il documento e il paragrafo.
Stile:    fondato sulle fonti e tracciabile. Nessuna invenzione. Nessun
          punteggio di maturità. Nessun confronto con terzi.
Tono:     neutro, professionale, non prescrittivo.
Destinatario: responsabile IT e consulente esterno; useranno il risultato
          come bozza da verificare, non come esito.
Risposta: una riga per voce, nell'ordine dell'elenco. Se un punto non è
          trattato nelle fonti, scrivere "non risulta dalle fonti".
          Chiudere con "Assunzioni e lacune": dove le fonti sono scarse,
          dove ci si basa su procedura documentata e non su prassi
          osservata, cosa va verificato con una persona.

Il punto che la guida non copre

Le cautele del NIST sulla riservatezza esistono ma restano generali: verificare le impostazioni dello strumento — conservazione dei dati, addestramento, privilegi di accesso, clausole di riservatezza — seguire le politiche aziendali prima di inserire informazioni sensibili, usare strumenti autorizzati dal responsabile sicurezza e privacy, dare in ingresso solo documenti approvati. La guida dichiara essa stessa di non affrontare in modo completo le buone pratiche di sicurezza dell'IA.

Su questo l'AI Safety Initiative della Cloud Security Alliance ha pubblicato il 1° settembre una nota critica che vale la lettura, perché individua un problema strutturale e non un difetto di redazione: per produrre un'analisi credibile bisogna dare al modello politiche interne, risultati di audit, esiti di penetration test e appunti di colloqui che descrivono dove i controlli sono deboli. Non è un ingresso accessorio dell'esercizio, scrive la nota: è l'esercizio. Più l'output è utile, più l'input deve essere concentrato e sensibile. E «strumento autorizzato» è, nelle sue parole, un pavimento e non un controllo: non dice cosa l'autorizzazione debba valutare — se gli input siano conservati, per quanto, se possano alimentare l'addestramento di un modello condiviso.

Due osservazioni della nota non dipendono dal contesto americano. Una piattaforma di conformità tradizionale sta dentro il perimetro, mentre un modello raggiunto via web o API introduce per costruzione un terzo nel percorso dei dati, e nei prompt quel percorso non compare. E cronologia dei prompt e contenuti generati meritano lo stesso trattamento, in conservazione e accessi, delle prove di audit da cui derivano, invece di essere considerati scarto temporaneo dello strumento. La nota precisa, correttamente, che niente di tutto questo rende sbagliata la premessa della SP 1353: comprimere settimane di mappatura manuale è un obiettivo legittimo.

Cosa conviene fare

Prima di provare questo schema su documenti veri, la decisione da prendere non è tecnica: quali categorie di materiale possono uscire dal perimetro aziendale. Politiche e procedure generali sono una cosa, un rapporto di penetration test con le vulnerabilità aperte è un'altra, e gli appunti di un colloquio in cui qualcuno ha spiegato cosa non funziona sono un'altra ancora. Questa classificazione va fatta a freddo, una volta, e messa per iscritto.

Poi lo strumento. Un'interfaccia di livello consumer non è il posto dove far analizzare prove di audit: serve un contratto che escluda l'uso degli input per l'addestramento e dichiari tempi di conservazione, oppure un modello eseguito in casa. È una verifica documentale, non un'opinione: o la clausola c'è o non c'è, e si legge in dieci minuti.

Infine il risultato. Sul file dell'analisi vanno data, modello usato e stato — «bozza derivata da IA, in attesa di validazione» — e quello stato va tolto da una persona che ha controllato a campione le citazioni, non per anzianità del file. La cronologia dei prompt e le bozze generate vanno dove stanno i documenti da cui derivano, con gli stessi accessi e gli stessi tempi di conservazione. Chi usa il CSF o lavora con committenti che lo richiedono ha anche due settimane per mandare commenti al NIST: la consultazione chiude il 15 ottobre 2026.