Perché "Non addestriamo" non basta

“Non addestriamo sui tuoi dati” è una buona frase. È anche però non il pasto completo. È un singolo pisello su un piatto molto grande, leggermente sospetto.

L’addestramento è un rischio. Se un fornitore usa prompt dei clienti, immagini caricate o output per migliorare i modelli senza permesso, è ovviamente un problema. Ma i clienti di solito si preoccupano di una domanda più ampia: cosa succede ai miei contenuti dopo che li invio? L’addestramento è solo una possibile destinazione.

Il contenuto potrebbe essere conservato per il monitoraggio degli abusi. Potrebbe essere memorizzato come stato dell’applicazione. Potrebbe restare in un thread di conversazione finché non viene eliminato. Potrebbe essere messo in cache per le prestazioni. Potrebbe essere scritto nei log delle richieste. Potrebbe essere copiato in un report di errore. Potrebbe essere visibile al personale di supporto. Potrebbe essere salvato in una galleria dell’utente. Potrebbe essere instradato verso un altro fornitore la cui policy è completamente diversa. Potrebbe essere “non usato per l’addestramento” e comunque essere conservato abbastanza a lungo da far uscire lentamente dalla stanza un acquirente attento alla privacy.

Non è una sottigliezza teorica. Le principali piattaforme AI pubblicano tabelle dettagliate sulla conservazione perché il comportamento agli endpoint differisce. La documentazione sui controlli dei dati di OpenAI, ad esempio, distingue l’uso per l’addestramento, la conservazione per il monitoraggio degli abusi, la conservazione come stato dell’applicazione e l’idoneità alla Zero Data Retention tra endpoint. Gli endpoint immagine elencati lì non sono tutti identici tra ogni modello e condizione. Questa complessità non è malvagità, ma è complessità, e i team di prodotto non dovrebbero appiattirla in una sola frase rassicurante.

La documentazione della Google Gemini Enterprise Agent Platform fa un punto simile da un’altra prospettiva: separa le restrizioni sull’addestramento da scenari di conservazione come il monitoraggio degli abusi, il grounding, il logging richiesta-risposta, il ripristino di sessione e il caching. Anche qui, la lezione non è “tutti sono cattivi”. La lezione è “contano i dettagli”. La privacy è una tabella, non un’atmosfera.

Per i prodotti di immagini AI, questa distinzione si fa ancora più netta perché il materiale di partenza può essere così personale. Un prompt è sensibile. Un volto è ancora più sensibile. Un volto più un prompt più un output generato più un record di fatturazione più uno screenshot di supporto non è più “solo una chiamata API”. È un mini dossier creato per sbaglio, che è la cosa più da software immaginabile.

Una migliore copia sulla privacy dovrebbe rispondere a diverse domande semplici. Addestrate sui contenuti dei clienti? Conservate i prompt? Conservate le immagini sorgente? Conservate gli output generati? Ci sono eccezioni per sicurezza o legge? Il personale può vedere i contenuti? Inviate contenuti a fornitori esterni di immagini? Per quanto tempo esistono i file temporanei? Quali metadati restano dopo la generazione?

La posizione di Unexposed è intenzionalmente più ristretta e concreta: mantenere prompt, immagini sorgente, output generati e chiavi dentro infrastrutture controllate da Unexposed, eseguirli in sessioni di generazione a breve durata e conservare registri durevoli content-blind. Questo non significa “non esiste nulla da nessuna parte per sempre”, perché esistono comunque fatturazione e operazioni. Significa che il sistema durevole non dovrebbe diventare un museo di contenuti creativi con una migliore risposta agli incidenti.

Se la pagina privacy di un fornitore si ferma a “non addestriamo”, fai la domanda successiva. Poi quella dopo. Poi quella fastidiosa. Quella fastidiosa è di solito dove vive la verità sul prodotto, stanca e con in mano un file di log.

Ulteriore lettura: i controlli di conservazione dei dati di OpenAI, la documentazione sulla zero data retention di Google e l’archiviazione dei dati di Unexposed.