Zero Data Retention ha reso OpenAI cieca agli abusi in più fasi

OpenAI ha creato Zero Data Retention affinché i clienti API idonei potessero impedire all'azienda di conservare i loro prompt o le risposte del modello una volta elaborata una richiesta, e questa promessa vale ancora oggi: nessuna revisione da parte del personale OpenAI, nessun uso per l'addestramento senza consenso esplicito. Il costo di questa promessa emerge sul fronte della sicurezza. Nell'annuncio del 19 agosto 2026, OpenAI dichiara apertamente che, man mano che i modelli assumono compiti agentivi più lunghi e complessi, i comportamenti più pericolosi - un attore malevolo che sonda le protezioni, si coordina su più account, maschera un attacco da ricerca legittima, o un agente che continua ad agire dopo aver ricevuto l'ordine di fermarsi - diventano visibili solo osservando più interazioni insieme, non all'interno di una sola.

I controlli di sicurezza compatibili con ZDR esistenti valutavano ogni interazione in isolamento, quindi non potevano cogliere per costruzione questo schema. OpenAI va oltre, notando che "alcuni recenti utilizzi di modelli di frontiera hanno richiesto ai clienti di permettere al proprio fornitore di IA di conservare contenuti sensibili per il monitoraggio della sicurezza" - una stoccata diretta, anche se senza nomi, verso rivali che hanno risolto il problema conservando più dati, non meno. Per una banca, un gruppo ospedaliero o uno studio legale vincolato da rigidi obblighi di gestione dei dati, quel compromesso non era mai stato accettabile, ed è esattamente questa la lacuna che Private Safety Processing dice di voler colmare.

La soluzione sposta i controlli di sicurezza dietro le chiavi del cliente

Private Safety Processing, ancora in anteprima al 19 agosto 2026, estende i controlli di sicurezza sulla singola interazione di OpenAI per individuare schemi tra interazioni correlate, senza dare al personale OpenAI accesso al contenuto sottostante del cliente. Il meccanismo funziona in due modi a seconda di dove risiede il contenuto. Se vive sull'infrastruttura del cliente in un vero schema ZDR, OpenAI non lo tocca mai. Se risiede su storage fornito da OpenAI, il contenuto viene cifrato con chiavi controllate dal cliente, e il personale OpenAI semplicemente non possiede quelle chiavi.

Quando il sistema individua un rischio, OpenAI non riceve il prompt segnalato, la risposta né il ragionamento dietro la segnalazione. Riceve solo, con le sue parole, "un segnale definito con precisione che indica il tipo di attività coinvolta" - sufficiente per decidere se serve un intervento, ma non sufficiente per leggere cosa sia realmente accaduto. I clienti possono indagare qualsiasi segnalazione o intervento con i propri sistemi, e possono condividere volontariamente maggiori informazioni con OpenAI solo se vogliono contestare una decisione o sostenere un'indagine - la divulgazione resta volontaria da parte del cliente, non automatica da parte di OpenAI.

Glean, Databricks, Abridge e Microsoft stanno già testando il sistema

Quattro organizzazioni nominate stanno già testando Private Safety Processing prima di un lancio più ampio: Glean, Databricks, Abridge e Microsoft. Sunil Agrawal, Chief Information Security Officer di Glean, ha offerto a OpenAI l'endorsement pubblico più netto finora: "Enterprise AI adoption depends solely on customer control of data, with no direct or derivative use beyond the chosen service. OpenAI's no-training commitment and ZDR give Glean confidence to build with OpenAI. As models become more capable, OpenAI shows safety can advance without compromising the privacy and control that sustain enterprise trust." Si tratta di un cliente enterprise che difende pubblicamente un sistema non ancora rilasciato.

Un'eccezione resta valida in ogni versione di questo design: OpenAI è legalmente obbligata a segnalare materiale di presunto abuso sessuale su minori, quindi le immagini segnalate per possibile CSAM continuano a essere conservate per revisione manuale e segnalazione anche negli schemi ZDR, esattamente come oggi. Private Safety Processing non tocca questa eccezione. OpenAI afferma che il lancio generale, insieme a un white paper tecnico che spieghi il meccanismo più a fondo, è previsto per settembre 2026 - ciò che verrà rilasciato il mese prossimo, plasmato nel frattempo dal feedback dei clienti, potrebbe differire da ciò che viene testato ora.

Il white paper di settembre è il vero test, non questo annuncio

Nessuno al di fuori di OpenAI ha verificato in modo indipendente le affermazioni su crittografia e controllo delle chiavi dietro Private Safety Processing, ed è proprio questa la lacuna che un team di compliance in Italia dovrebbe tenere aperta fino a settembre. Il "segnale definito con precisione" descritto da OpenAI è, per progettazione, opaco per il cliente che lo riceve - utile per decidere se agire su una segnalazione, ma non abbastanza dettagliato da soddisfare una revisione ai sensi dell'articolo 28 del GDPR o un revisore che chieda esattamente cosa sia stato dedotto dal contenuto cifrato e come. Fino a quando non arriverà il promesso white paper tecnico, la risposta onesta a "possiamo verificarlo" è no, non ancora.

L'annuncio arriva tre giorni dopo le dichiarazioni del CFO di OpenAI su una possibile quotazione in borsa nel 2027 e pochi giorni dopo l'espansione di ChatGPT Ads in Europa, e nel complesso il quadro mostra un'OpenAI che corteggia visibilmente la fiducia dei settori regolamentati prima di una crescita commerciale su scala maggiore. Questo non trasforma Private Safety Processing in una semplice operazione di marketing - l'elenco dei clienti e il meccanismo sono reali -, ma significa che l'onere della prova spetta al white paper tecnico, non a questo annuncio. Ogni affermazione di "zero data retention" da parte di un fornitore andrebbe letta oggi con una domanda in più: come, esattamente, gestisce il monitoraggio della sicurezza tra sessioni diverse.