Cosa significa davvero il “Zero Data Retention”

“Zero data retention” suona meravigliosamente definitivo. Significa però cose diverse a seconda del provider, dell’endpoint, dello stato dell’account, della funzionalità e dell’elenco delle eccezioni. Naturalmente, è qui che inizia a spegnersi il divertimento.

Al minimo, i team dovrebbero separare quattro domande. I contenuti dei clienti vengono usati per l’addestramento del modello? I contenuti vengono conservati per il monitoraggio degli abusi? Lo stato dell’applicazione viene salvato per far funzionare la funzionalità? Gli input di immagini e file vengono trattati in modo diverso rispetto al testo?

La documentazione attuale di OpenAI sui controlli dei dati dell’API afferma che i dati dell’API non vengono usati per addestrare o migliorare i modelli di OpenAI a meno che il cliente non scelga di aderire. Descrive anche i log di monitoraggio degli abusi predefiniti, i controlli di retention come Modified Abuse Monitoring e Zero Data Retention per i clienti approvati idonei, lo stato dell’applicazione specifico per endpoint e le eccezioni per gli input di immagini/file per alcune verifiche di sicurezza.

La documentazione di Microsoft Foundry venduti da Azure sulla privacy dei dati usa una propria struttura. Dice che prompt e completions non sono disponibili per altri clienti, non sono disponibili per OpenAI o altri provider di modelli e non vengono usati per addestrare i modelli foundation senza permesso o istruzione. Descrive anche le feature memorizzate, il monitoraggio degli abusi, la geografia e i modi in cui i clienti approvati possono verificare quando l’archiviazione per il monitoraggio degli abusi è disattivata.

La lezione non è “provider A ok, provider B no”. La lezione è che ZDR è una storia di configurazione e idoneità, non uno slogan. Un endpoint potrebbe essere idoneo. Un altro potrebbe conservare lo stato dell’applicazione. Una funzionalità potrebbe mantenere fino alla cancellazione. Un’altra potrebbe conservare uno stato temporaneo per polling, caching, sicurezza o finestre di download.

I flussi di lavoro per immagini rendono tutto questo ancora più importante. La generazione di immagini, le modifiche, gli input di file, i video, i batch job e i flussi di lavoro stateful in stile assistenti possono avere comportamenti di archiviazione diversi. Una risposta di procurement copiata da un endpoint di text-completion potrebbe non rispondere alla domanda sugli upload di immagini.

Quando valuti un provider, chiedi la tabella noiosa. Endpoint. Uso per training. Monitoraggio degli abusi. Stato dell’applicazione. Retention dei file. Retention delle immagini. Revisione umana. Eccezioni di sicurezza. API di cancellazione. Regione. Subprocessori. Requisiti di idoneità per monitoraggio modificato o ZDR. Le tabelle noiose evitano incidenti entusiasmanti.

Per i prodotti in stile Unexposed, la promessa più pulita per il cliente non è semplicemente “il nostro provider ha ZDR”. È “il nostro prodotto è progettato per non conservare prompt o immagini dei clienti e il nostro provider instrada quella promessa per gli endpoint che usiamo”. La promessa a livello di prodotto conta perché i controlli del provider sono solo uno strato.

La zero data retention è preziosa. Non è però un timbro magico. Leggi il comportamento dell’endpoint o la frase farà quella cosa che le frasi amano fare: suonare meglio del sistema sottostante.

Approfondimenti: OpenAI API data controls, Microsoft Foundry data privacy e The case for zero prompt history.