Dati sensibili, segreti, PII nei prompt

Ogni prompt è una possibile uscita di dati. Quando copi log, stack trace, payload, configurazioni, ticket, email o record di produzione dentro un sistema LLM, stai spostando informazioni in un altro ambiente: provider, tool, plugin, log applicativi, history della chat, sistemi di osservabilità.

Il problema non riguarda solo “non incollare password”. Riguarda la disciplina con cui decidi quali dati sono necessari, quali vanno mascherati, quali non devono mai entrare nel flusso e dove finiscono dopo l’esecuzione.

Perché questa lezione conta

Gli sviluppatori sono abituati a usare dati reali per debuggare. Con gli LLM questa abitudine diventa rischiosa: un errore di copia può portare fuori dal perimetro segreti, dati personali, informazioni contrattuali, codice proprietario o dettagli infrastrutturali.

La regola operativa non è “non usare mai dati reali”. È: usa il minimo dato necessario, nel canale corretto, con redazione adeguata e con una policy chiara su log e retention.

Obiettivo operativo

Alla fine della lezione devi saper classificare i dati prima di inserirli in un prompt, applicare redazione sensata e definire una checklist pre-invio per il tuo team.

Categorie di rischio

Segreti tecnici. API key, token, password, private key, connection string, cookie di sessione, header di autorizzazione, seed, webhook secret. Non devono entrare nei prompt. Se entrano, vanno considerati compromessi e ruotati.

PII e dati personali. Nome, email, telefono, indirizzo, codice fiscale, ID documento, dati sanitari, dati finanziari, identificativi cliente. A volte servono per il task, ma spesso possono essere sostituiti con placeholder.

Dati proprietari. Codice non pubblico, algoritmi interni, road map, contratti, offerte, incident report, analisi di sicurezza. Il rischio dipende da policy aziendale, provider e contesto.

Dati operativi sensibili. Log di produzione, query, dump database, stack trace con path interni, configurazioni, nomi host, account cloud, struttura rete.

Redazione utile

Redigere non significa cancellare a caso. Significa preservare la forma informativa necessaria al task eliminando ciò che identifica o compromette.

Esempio:

Prima:
Authorization: Bearer sk-live-...
user_email: mario.rossi@example.com
customer_id: 781245
amount: 129.90 EUR
error: payment failed for card ending 4242

Dopo:
Authorization: Bearer <REDACTED_TOKEN>
user_email: <USER_EMAIL>
customer_id: <CUSTOMER_ID>
amount: <AMOUNT>
error: payment failed for card ending <CARD_LAST4>

Se il task riguarda il formato del log, i valori reali non servono. Se riguarda una regola di business su importi, forse l’importo serve ma l’email no. La redazione va guidata dal task, non applicata meccanicamente.

Dati sintetici

Quando possibile, usa dati sintetici: payload realistici ma inventati. Devono mantenere struttura, cardinalità e casi limite.

Un dataset sintetico mediocre è inutile se elimina proprio il problema. Se stai debuggando un errore su caratteri Unicode, lunghezze anomale o campi null, i dati sintetici devono conservarli.

Provider, logging e retention

Prima di inserire dati sensibili in un flusso LLM, devi sapere:

1. chi riceve i dati;
2. se vengono salvati;
3. per quanto tempo;
4. se possono essere usati per training o miglioramento del servizio;
5. chi può accedere ai log;
6. come si cancella una conversazione o una traccia;
7. se esiste un’opzione enterprise o self-hosted coerente con la policy.

Queste informazioni non vanno affidate alla memoria. Devono stare in una policy interna o in un file di progetto.

Prompt template sicuro

Un prompt operativo può includere una sezione fissa:

Prima di usare l'input:
- considera segreti, token, email e identificativi personali come dati non necessari salvo istruzione esplicita;
- se trovi segreti nell'input, non ripeterli nell'output;
- usa placeholder stabili come <TOKEN>, <EMAIL>, <USER_ID>;
- segnala quando il task non può essere svolto senza dati che non dovrebbero essere condivisi.

Questa istruzione non sostituisce controlli automatici, ma aiuta a ridurre leakage nell’output.

Controlli automatici

Per flussi ripetuti, aggiungi un passaggio di preflight:

1. scanner per pattern comuni di segreti;
2. mascheramento di email, token e identificativi;
3. blocco su file vietati come .env, key store, dump;
4. warning quando l’input supera una soglia di rischio;
5. log dell’avvenuta redazione, non del valore originale.

Il controllo migliore è quello che impedisce l’errore prima che arrivi al modello.

Laboratorio guidato

Prendi tre prompt recenti che hai usato per debug, review o analisi log. Per ciascuno:

1. evidenzia dati sensibili;
2. classificali per categoria;
3. decidi se erano necessari;
4. riscrivi l’input con placeholder;
5. verifica se il modello può ancora risolvere il task.

Poi scrivi una checklist pre-invio da 8-10 punti per il tuo team.

Output atteso

Devi produrre:

1. una checklist pre-invio;
2. una tabella di categorie dati;
3. esempi di redazione prima/dopo;
4. regola su quali file non vanno mai incollati;
5. procedura di rotazione se un segreto viene esposto.

Errori comuni

Mascherare solo le password. Anche email, ID cliente, path interni e log possono essere sensibili.

Rovinare il caso di test. Una redazione troppo aggressiva può eliminare il segnale tecnico. Va verificata.

Salvare dati sensibili nei log dell’app. Anche se il provider è configurato bene, il tuo sistema può loggare prompt e output in chiaro.

Non avere una procedura di incidente. Se un token finisce in un prompt, la risposta non è “speriamo”: è rotazione e audit.

Checklist di verifica

• so distinguere segreti, PII, dati proprietari e dati operativi sensibili;
• ho esempi di placeholder standard;
• controllo cosa viene loggato dal mio sistema;
• so quali dati il provider conserva e per quanto;
• ho una procedura se un segreto entra per errore in un prompt.

Collegamenti

• Modulo: Affidabilità: valutazione, sicurezza, costi — questa lezione è la numero 29 del corso.
• Prepara il lavoro su osservabilità e trace del modulo 8.