SAFE RFC: lo scambio di incidenti AI in stile aviazione di OSAA è una bozza aperta, non ancora un sistema

Il 4 agosto 2026, all'apertura di Black Hat USA a Las Vegas, la Linux Foundation ha pubblicato una Request for Comments per il gruppo di lavoro Shared AI Findings Exchange (SAFE) — una proposta affinché le organizzazioni segnalino incidenti di sicurezza legati all'IA e quasi-incidenti in un canale condiviso riservato, ne traggano insegnamento collettivamente e pubblichino controlli difensivi derivati da ciò che ha fallito. La bozza iniziale è stata sviluppata da contributori di Cisco, CrowdStrike, Hugging Face, NVIDIA e Red Hat, tra gli altri membri dell'alleanza, ha dichiarato la Linux Foundation nel suo annuncio. È stata aperta alla revisione della comunità tramite il repository GitHub dell'Open Secure AI Alliance lo stesso giorno. La voce non descrive alcun danno: è un documento di policy, registrato nell'archivio con un livello di gravità info e un livello di confidenza A, e il suo oggetto è un processo anziché un evento. Il livello di gravità, la valutazione di confidenza e l'elenco delle fonti del record si trovano in l'archivio degli incidenti IA, insieme alle voci registrate intorno ad esso.

La bozza chiede ai membri di riportare quattro cose e di ignorare il perché

Il testo di agosto è avaro di retorica e specifico sui fattori scatenanti. Sotto un titolo chiamato Reporting Compact, chiede ai membri di impegnarsi — come condizione di adesione — a segnalare un incidente quando vengono a conoscenza o sospettano ragionevolmente che un sistema di IA che gestiscono abbia fatto una delle quattro cose seguenti: abbia effettuato accesso, sfruttato, interrotto, utilizzato in modo improprio o modificato un sistema di terze parti senza autorizzazione; abbia causato un impatto su terze parti eludendo o aggirando i confini di sandbox, rete, identità, policy o strumenti; abbia effettuato accesso a informazioni riservate di terze parti senza il consenso del proprietario; oppure abbia continuato a sondare, accedere o modificare un target di produzione dopo che l'operatore sapeva, o sospettava ragionevolmente, che l'attività non era autorizzata o era al di fuori dell'ambito approvato.

Poi arriva la frase che fa la maggior parte del lavoro: «L'intenzione non determina se un evento sia segnalabile. Credere che un ambiente sia stato simulato può spiegare un incidente, ma non elimina l'obbligo di segnalarlo». Quella clausola sembra rivolta al caso in cui un sistema viene eseguito in quello che il suo operatore ritiene un ambiente di test sigillato e tratta l'infrastruttura live come parte dell'esercizio: la convinzione dell'operatore riguardo all'ambiente può spiegare l'evento, ma non elimina l'obbligo di segnalazione. La bozza chiede inoltre ai membri di segnalare i quasi incidenti, non solo gli eventi che hanno prodotto un danno confermato, e di fornire un'analisi preliminare del guasto dei controlli entro 30 giorni.

Il tempo: immediato, 72 ore, quattro giorni lavorativi, novanta giorni

La tabella delle notifiche della bozza è la cosa più concreta che contiene, e la prima riga non è affatto una scadenza: l'organizzazione direttamente interessata deve essere informata immediatamente. Ogni scadenza decorre dal momento in cui il membro viene a conoscenza di fatti che forniscono fondati motivi per sospettare un evento soggetto a notifica — non dal momento in cui si conclude un'indagine. La tabella sottostante è riprodotta dalla bozza del 4 agosto; la revisione di ottobre mantiene gli stessi intervalli.

Tre di quelle righe riguardano il fatto di informare altre persone, e quattro riguardano il fatto di informare SAFE stesso. La distinzione è importante perché il framework è esplicitamente non un regime di divulgazione: la bozza afferma che "queste tempistiche non sostituiscono alcun obbligo del fornitore di notificare alle parti interessate, ai clienti attraverso le migliori pratiche esistenti in materia di divulgazione coordinata delle vulnerabilità, né gli obblighi contrattuali e altri obblighi legali applicabili di notificare alle autorità di regolamentazione o alle forze dell'ordine". Ciò che SAFE aggiunge è un obbligo parallelo nei confronti di un organismo che non è un'autorità di regolamentazione — e un modello di divulgazione a tre livelli in cui solo l'ultimo livello, il rapporto sulla sicurezza pubblica, è destinato a essere ampiamente condivisibile.

Otto livelli di controllo ad agosto, undici a ottobre

Le revisioni sono strutturate attorno allo stack operativo piuttosto che attorno al modello in sé. La bozza di agosto elencava otto livelli e poneva una domanda per ciascuno: il modello riconosceva l'incertezza e le condizioni di arresto; le ipotesi di autorizzazione e ambientali erano esplicite; i classificatori, le approvazioni e i limiti d'azione funzionavano; le credenziali, i permessi e l'esecuzione erano vincolati; l'isolamento e i confini dei dati erano verificati in modo indipendente; gli operatori potevano rilevare e interrompere in tempo reale; i percorsi di escalation e le procedure di kill erano chiari; un partner cloud, di valutazione, dati o tooling invalidava i controlli presunti.

La revisione di ottobre, datata 21 ottobre 2026 e sottoposta al repository il giorno successivo, aggiunge tre livelli: il percorso di servizio, l’autorizzazione al momento dell’impegno e la composizione del flusso di lavoro attraverso una sequenza di azioni. Trasforma inoltre la revisione in una valutazione graduata con quattro risposte consentite — superato, non superato, prove insufficienti, non applicabile — e afferma nel proprio registro delle modifiche che tali constatazioni non stabiliscono la sicurezza generale del sistema né la conformità legale. Vale la pena leggere questa progressione come descrizione di ciò che gli autori hanno imparato a temere: non se il modello si sia comportato bene, ma se il modello che ha risposto fosse il modello configurato, se l’autorizzazione esistesse ancora quando l’azione è stata eseguita e se la sequenza nel suo complesso sia rimasta nell’ambito che l’ha avviata.

Aviazione, ma quale parte dell'aviazione?

La formulazione del documento stesso — un sistema modellato sull'Aviation Safety Reporting System della NASA — segue l'annuncio della Linux Foundation anziché la bozza. L'annuncio descrive l'ASRS come «un sistema di segnalazione volontario e confidenziale, progettato per analizzare e rispondere agli incidenti di volo in modo da consentire al settore di apprendere e migliorare». Né la bozza di agosto né la revisione di ottobre menzionano l'ASRS in alcun punto; la bozza afferma solo che SAFE «dovrebbe adottare le caratteristiche più forti dei sistemi confidenziali di segnalazione sulla sicurezza». Si tratta di una piccola differenza con una conseguenza pratica: l'annuncio stabilisce un'aspettativa a cui il testo non si impegna ancora.

L'analogia ha suscitato commenti all'interno dello stesso processo RFC. Una delle prime pull request, aperta il 5 agosto da un contributore che scrive a titolo personale, sostiene che «{{1}}l'analogia con l'ASRS ha un elemento istituzionale mancante{{/1}}» — che l'ASRS funziona in buona parte perché le segnalazioni sono ricevute, elaborate e de-identificate dalla NASA, «{{2}}una terza parte pubblica, non regolatoria e non commerciale—non dalla FAA in quanto regolatore e non dalle compagnie aeree le cui operazioni sono oggetto di segnalazione.{{/2}}» La pull request, che attinge anche al processo di governance di Internet del 1998, era ancora aperta il 30 ottobre. Se l'operatore di SAFE possa svolgere il ruolo della NASA è una questione di progettazione irrisolta anziché una funzionalità consolidata: il testo di ottobre colloca il gruppo di lavoro sotto la governance della Alliance stessa, con dichiarazione dei conflitti di interesse, astensione e una via di ricorso al Comitato direttivo della Alliance.

La copertura indipendente ha operato una seconda distinzione, più circoscritta. Infosecurity Magazine, nel suo resoconto del 6 agosto, ha rilevato che il post della Linux Foundation non menziona specificamente gli agenti AI: l'inquadramento agentico appartiene al post complementare di NVIDIA, che sostiene che "un agente AI non è solo un modello. È un sistema" ed elenca harness, sandbox, guardrail e strumenti di valutazione contribuiti dai membri dell'alleanza. I trigger della bozza, letti alla lettera, riguardano sistemi che agiscono al di fuori dell'autorizzazione; la proposta dell'annuncio, letta alla lettera, riguarda gli agenti.

Cosa hanno detto i commentatori su chi si fa carico del costo

Una delle obiezioni pubblicate più specifiche al testo così com'è scritto è venuta da un membro fondatore dell'alleanza, non da un critico esterno. Stephen Sargent, fondatore e chief technology officer di Avondale.AI, ha inviato via email una dichiarazione di posizione il 7 agosto — un giorno in cui il documento afferma che il team legale della Linux Foundation ne ha preso atto — e l'ha pubblicata il 9 agosto. Apre sostenendo la missione e poi sostiene che il patto non è scalabile in base alle dimensioni dell'organizzazione: "L'RFC non distingue tra un'organizzazione con 50.000 dipendenti e un piccolo team." Un resoconto entro quattro giorni lavorativi più un pacchetto forense conservato potrebbe, a suo giudizio, consumare più tempo del personale di quanto un piccolo operatore possa permettersi; la sua raccomandazione è un quadro a livelli, con resoconti riservati e pubblicazione ritardata o anonimizzata come impostazione predefinita sotto una soglia dimensionale.

Una seconda obiezione riguarda la divulgazione più che le scadenze: egli sostiene che «la divulgazione pubblica È una forma di applicazione» per i piccoli operatori, perché il rapporto di una grande impresa è una nota a piè di pagina e quello di una piccola impresa diventa il titolo, e chiede che la rendicontazione de-identificata sia il valore predefinito al di sotto di una soglia dimensionale. Una terza riguarda il quadro di revisione più che il tempo: il modello a otto livelli presuppone team aziendali segregati, quindi in una distribuzione gestita da una sola persona «l'operatore fa tutto» e un livello mancante viene letto come un fallimento dei controlli quando è semplicemente un modello operativo diverso. La sua quarta riguarda l'espressione «pratiche minime di interoperabilità e garanzia», che egli interpreta come un percorso dalla rendicontazione volontaria a strumenti di fatto obbligatori. La dichiarazione di posizione è il punto di vista di un membro, pubblicato da quel membro. L'annuncio del 4 agosto della Linux Foundation è precedente e non affronta la questione. Una successiva pull request, aperta il 5 ottobre e ancora aperta il 30 ottobre, propone un modello di evidenze per operatori senza un centro operativo di sicurezza — un riconoscimento che la preoccupazione è stata recepita, e un candidato più che una correzione adottata, con il suo autore che afferma che «non stabilisce l'adozione di SAFE né l'idoneità legale».

Cosa è cambiato tra il 4 agosto e il 30 ottobre

La cronologia del repository è il miglior documento disponibile su ciò che l’RFC ha effettivamente prodotto, ed è più leggibile di quanto suggerisca la copertura giornalistica. I primi commit sono stati effettuati il 3 agosto; la bozza e un readme ampliato sono stati commitati alle 00:14 e alle 00:19 UTC del 4 agosto. Poi il repository è rimasto inattivo per dieci settimane. Il 14 ottobre l’alleanza ha aggiunto uno statuto e un file dei membri e ha riscritto il readme per rendere il repository la sede del gruppo di lavoro SAFE; quel giorno sono stati registrati come presidenti ad interim Paul DiOrio di NVIDIA e Josh Boyer di Red Hat. Il 21 ottobre il gruppo di lavoro ha pubblicato SAFE v1, con un changelog la cui prima voce è che il testo «rimuove "proposto" dalla descrizione di SAFE» e lo identifica come gruppo di lavoro consolidato dell’Alliance.

Due cose relative a quello stato vanno tenute distinte. Il readme del repository ora riporta la riga «Stato: Approvato — Approvato dal Comitato direttivo», che è la cosa più vicina a una dichiarazione di ratifica nella documentazione pubblica; lo statuto, nello stesso repository, recita ancora «In fase di sviluppo. Lo statuto SAFE sarà pubblicato qui una volta approvato dal Comitato direttivo.» Il registro delle modifiche etichetta il testo di ottobre come «SAFE v1» e descrive cosa cambia, ma non dice chi lo abbia ratificato, con quale voto né in quale data. Un lettore che voglia sapere se SAFE sia ora una specifica approvata, oppure un gruppo di lavoro il cui statuto di governo è ancora non scritto, non otterrà una risposta chiara dai documenti.

Che cosa è stabilito e che cosa non lo è

• Stabilito: una Request for Comments per lo Shared AI Findings Exchange è stata pubblicata il 4 agosto 2026 — la Linux Foundation ha datato il proprio annuncio a quel giorno — e le organizzazioni indicate come contributori sono Cisco, CrowdStrike, Hugging Face, NVIDIA e Red Hat, citate insieme ad "altri membri della Open Secure AI Alliance".

• Stabilito: la bozza contiene un accordo di rendicontazione con quattro condizioni di attivazione, una tabella delle notifiche con scadenze dall'immediato a 90 giorni, un elenco di conservazione delle prove, un quadro di revisione a più livelli e un modello di divulgazione a tre livelli. Il testo completo è pubblico nel repository e anche la sua cronologia è pubblica.

• Stabilito, solo con attribuzione: la dimensione dell'alleanza — "più di 120 organizzazioni" — è una cifra fornita da NVIDIA stessa, ripetuta nel report di Infosecurity Magazine del 6 agosto. Nessuna delle coperture esaminate mostra un audit indipendente dei membri, e il file dei membri del repository elenca due contributori e due presidenti ad interim, non 120 organizzazioni.

• Non è stabilito: che qualcuno abbia presentato una segnalazione ai sensi del patto. La documentazione pubblica al 30 ottobre mostra commit, pull request e issue; non mostra un rapporto di incidente, un progetto pilota, un primo caso, una scadenza per i commenti, una regola di voto o una data di ratifica. Il quadro descrive un obbligo che i membri «accettano» come condizione di adesione, il che non equivale a un obbligo che qualcuno abbia già adempiuto.

• Controverso: se il confronto con ASRS sia valido senza un operatore pubblico neutrale, oggetto di obiezioni in una pull request aperta; se l'onere di rendicontazione sia proporzionato per i piccoli operatori, oggetto di obiezioni nella dichiarazione di posizione di un membro fondatore; e in che misura il quadro sia specifico degli agenti rispetto alla sicurezza generale dell'IA, una distinzione che il testo della Linux Foundation e quello di NVIDIA tracciano in modo diverso.

Niente di tutto ciò rende errata la documentazione, e la valutazione A dell’archivio è difendibile secondo i suoi stessi criteri: i documenti primari concordano tra loro su ciò che è stato pubblicato, quando e da chi, e la bozza è leggibile per intero. Ciò che la valutazione non può attestare è proprio la cosa che un lettore desidera di più: se il meccanismo funzioni. Su questo non vi sono prove né a favore né contro, perché il meccanismo non ha ancora avuto un caso.