I log dei prompt sono una violazione in attesa di accadere

I log dei prompt sembrano innocui finché non li leggi.

Dal punto di vista dell’ingegneria, registrare i prompt è allettante. Aiuta a fare debug dei guasti. Aiuta a riprodurre i reclami. Aiuta a monitorare gli abusi. Aiuta a migliorare i prompt. Aiuta a rispondere alla domanda eterna: “Perché il modello ha fatto sembrare il prodotto come un tostapane infestato?”

Dal punto di vista della privacy, i log dei prompt sono intento grezzo. Possono contenere nomi di clienti, idee di campagne, fantasie personali, contesto medico, controversie legali, strategia di prodotto, nomi di persone reali, località e istruzioni collegate a immagini caricate. Nella generazione di immagini, i prompt spesso spiegano la parte sensibile che l’immagine finale accenna soltanto.

Una violazione dei log dei prompt può quindi essere peggiore di una violazione degli output. Gli output possono essere ambigui. I prompt spesso sono espliciti. Mostrano ciò che l’utente ha chiesto, ciò che cercava di nascondere, ciò che voleva cambiare e ciò che ha provato prima di arrivare alla versione accettabile.

Ecco perché “facciamo solo log di testo” non è rassicurante. Il testo può essere la mappa dell’immagine. Un prompt che dice “rimuovi il logo del concorrente dal mockup del packaging non ancora rilasciato” è sensibile dal punto di vista commerciale anche se non viene mai divulgato alcun file immagine. Un prompt che dice “rendi la mia foto del profilo meno stanca” è personale anche se l’output non viene mai memorizzato.

L’approccio più sicuro è separare il debug operativo dalla conservazione dei contenuti. Registra gli ID dei job, i tempi, le versioni del modello, i codici di errore, l’uso di token o crediti, gli eventi di coda e i metadati non relativi al contenuto. Quando la cattura del contenuto è davvero necessaria per abusi o supporto, rendila limitata, autorizzata, a tempo limitato e visibile nella policy.

Gli sviluppatori potrebbero obiettare che questo rende il debug più difficile. Lo fa. La privacy rende più difficile il debug pigro. Non è una tragedia; è un vincolo di progettazione. Crea una raccolta diagnostica esplicita e autorizzata dall’utente per i casi limite invece di conservare per sempre la cronologia privata dei prompt di tutti.

I team di sicurezza dovrebbero modellare le minacce ai log dei prompt come dati sensibili del cliente. Chi può interrogarli? Vengono copiati in analytics? Sono inclusi nei crash report? Vengono inviati a vendor di osservabilità? Sono ricercabili dal supporto? Vengono conservati più a lungo delle immagini stesse?

Se i prompt possono ricostruire un lavoro privato, non sono log innocui. Sono materiale per una violazione in attesa di un invito in calendario.

Ulteriori letture: Prompt history is product data, whether you call it that or not, The case for zero prompt history, e What an AI image API should never store.