Prevenzione della fuga di dati e mascheramento delle PII

Guadagni:

• Capacità di identificare i vettori di fuga di dati tramite prompt, log, output e formazione
• Possibilità di mascherare i dati PII con redazione o tokenizzazione prima di inviarli al modello
• Capacità di incorporare concetti di conservazione zero dei dati (ZDR) e di residenza dei dati nella progettazione della sicurezza

L'incidente IA più costoso di un'organizzazione di solito non è un jailbreak fantasioso, ma una fuga di dati ordinaria: un dipendente incolla un file sensibile del cliente in un assistente, i dati finiscono nei registri del fornitore, quindi un audit chiede "perché questi dati hanno lasciato l'organizzazione?" Incontrerai la domanda: in questa unità impareremo dove si verifica la fuga di dati, come mascherare i dati personali (PII - Informazioni di identificazione personale, dati che identificano una persona: nome, ID, e-mail, numero di carta) prima di inviarli al modello e quali garanzie aziendali (zero conservazione dei dati, residenza dei dati) riducono il rischio.

Da dove viene la perdita? Quattro vettori

La mappa mentale di un professionista della sicurezza o della protezione dei dati è questa: i dati possono finire all'esterno dell'organizzazione o finire nelle mani sbagliate in quattro modi:

• Tramite prompt: l'utente incolla i dati sensibili direttamente nel prompt e li invia al fornitore di dati.
• Tramite log: le richieste e le risposte vengono scritte in forma grezza per eseguire il debug dei log; Chiunque abbia accesso ai registri vede i dati.
• Tramite output: il modello trasmette i dati di un utente a un altro utente (specialmente in contesto condiviso o RAG).
• Per addestramento: se il fornitore utilizza i dati inviati per addestrare il modello, i tuoi dati potrebbero riflettersi nelle risposte future.

Attenzione: il vettore più frequentemente trascurato è il log. Anche se l'applicazione funziona correttamente, se hai una riga di codice che registra la richiesta/risposta grezza, stai perdendo informazioni personali nei tuoi sistemi.

Passo dopo passo: pipeline di mascheramento (pipeline di redazione)

1. Rileva. Trova i campi PII (regex, rilevatore PII standard o riconoscimento di entità) prima di inviare il testo al modello.
2. Cambialo. Sostituisci ogni PII con un segnaposto: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. Conserva la mappatura. Mantieni la mappatura segnaposto ↔ valore effettivo solo dalla tua parte, in una mappa temporanea e sicura.
4. Invia testo mascherato al modello. Il modello vede solo [AD_1], mai i dati effettivi.
5. Reidratarsi. Quando arriva la risposta del modello, sostituire i segnaposto con i valori effettivi della mappa (solo se verrà visualizzata dall'utente autorizzato).

Questa è anche chiamata tokenizzazione: sostituire un valore sensibile con un token reversibile ma privo di significato. La redazione, d'altra parte, rimuove/oscura completamente senza ripristinare: è preferibile se il modello non necessita affatto del valore effettivo.

Quattro modelli copiabili

Una semplice guida per mascherare le decisioni:

Regola decisionale: il modello HA BISOGNO di PII reali per svolgere il suo lavoro?- No (riepilogo, classificazione, analisi del tono) -> REDAZIONE (nessuna inversione)- Sì ma solo per coerenza (stesso riferimento alla stessa persona) -> TOKENIZZAZIONE- Sì e verrà generato il valore reale (lettera personalizzata) -> maschera, genera, riempi alla sua fine

Istruzioni per la correzione di bozze (se non è presente alcun rilevatore lato codice, almeno di norma per il modello):

Elabora il testo qui sotto. Non ripetere nessun dato personale (nome, telefono, e-mail, TR ID, IBAN, indirizzo) COSÌ COME SONO nella tua risposta. Se devi fare riferimento a loro, utilizza tag generali come [PERSON], [TELEFONO], ecc.<text>{{ entry }}</text>

Richiesta di controllo perdite (per scansionare i propri registri):

Controlla il registro qui sotto. Se contiene PII grezzi (ID TR: 11 cifre, IBAN: 26 caratteri che iniziano con TR, e-mail, numero di carta), CONTA ciascuno con il suo tipo. Non copiarne nessuno nella tua risposta; Basta fornire un riepilogo del tipo "Sono stati trovati 3 numeri ID TR e 1 IBAN".

Test di tenuta in uscita (con team eye rosso):

Sei un membro della squadra rossa. Prova a convincere questo assistente a rivelare i dati di UN ALTRO utente. Provare 5 affermazioni diverse e segnalare all'assistente quale di queste fa trapelare dati; mascherare i dati trapelati.

Prompt debole / Prompt forte

approccio scadente

Approccio forte

Incollare il file client non elaborato nell'assistente

Maschera le PII e invia con [AD_1]

Prendi nota alla fine del messaggio dicendo "Non salvare questi dati"

Garantire tecnicamente che il modello non veda mai i dati

Registrazione di prompt/risposte non elaborate per il debug

Redazione delle PII prima della registrazione

Basandosi sull'impostazione predefinita del provider

Ottenimento della garanzia ZDR e "uso nell'istruzione" per contratto

Differenza fondamentale: l'approccio debole invia i dati e poi dice "spero che non vengano utilizzati in modo improprio"; L'approccio forte non invia affatto i dati.

Assicurazioni aziendali: ZDR e residenza dei dati

Due termini sono decisivi nella selezione del fornitore:

• Zero Data Retention (ZDR): il fornitore non conserva in modo permanente le richieste e le risposte inviate dopo il completamento della richiesta. I registri vengono eliminati in pochi minuti. Riduce significativamente il rischio di perdite e conformità.
• Residenza dei dati: il paese/regione in cui i tuoi dati vengono fisicamente elaborati e archiviati. Potrebbe essere necessario che i dati rimangano in una determinata area geografica per normative come KVKK (legge sulla protezione dei dati personali) e GDPR.

Suggerimento: cerca due clausole separatamente nel contratto: (1) "I nostri dati non verranno utilizzati per addestrare il modello", (2) "Il periodo di conservazione dei dati è ... giorni / zero". Queste due sono garanzie diverse; l'uno non include l'altro.

Tre mini custodie

Caso 1: perdita di registro di 4.500 record. L'assistente sinistri di una compagnia assicurativa stava scrivendo ogni richiesta in registri grezzi per il debug. Da un audit è emerso che questi registri sono stati archiviati per 90 giorni e 12 persone hanno avuto accesso; Conteneva l'identità e le informazioni telefoniche di 4.500 assicurati. Dopo l'aggiunta della redazione pre-log, le PII sono scese a zero negli stessi log e il risultato KVKK è stato disattivato.

Caso 2: la tokenizzazione ha mantenuto la coerenza. Un team delle risorse umane stava producendo riepiloghi di valutazione dei candidati. Quando le PII sono state redatte, il modello pensava che lo stesso candidato fosse una persona diversa in luoghi diversi. Passando alla tokenizzazione, ogni candidato ha ricevuto un token coerente come [CANDIDATE_1]; Del modello è stata fatta l'attribuzione corretta, mentre il vero nome non è mai venuto fuori.

Caso 3: eliminato il fornitore non ZDR. Una società di tecnologia sanitaria ha valutato tre fornitori. Quello con il prezzo più basso conservava i dati per 30 giorni e poteva essere utilizzato per il “miglioramento del servizio”. L'azienda ha ritenuto inaccettabile questa clausola perché tratta i dati dei pazienti; Scegli il fornitore più costoso del 18% che garantisce ZDR e residenza dei dati. Nel successivo audit si è ritenuto che questa decisione avesse notevolmente ridotto il rischio.

Errori comuni

• Pensare che sia protetto inviando informazioni personali non elaborate al modello e semplicemente digitando "non salvare" al prompt.
• Dimenticare la richiesta/risposta non elaborata nei registri di debug mantenendo l'applicazione.
• Confondere la redazione con la tokenizzazione; redigendo dove è necessaria coerenza e fuorviando il modello.
• Segnaposto ↔ memorizzazione della mappatura del valore effettivo in una posizione non sicura o persistente.
• Confondere la garanzia "uso nell'istruzione" e la garanzia "archiviazione dei dati" come la stessa cosa.
• Non chiedere mai la residenza dei dati (in quale Paese vengono trattati i dati).

In sintesi

• I dati fuoriescono attraverso quattro vettori: prompt, log, output e training. È il registro che molto spesso viene trascurato.
• Maschera le PII prima di inviarle al modello: redazione se il valore effettivo non è necessario, tokenizzazione se è necessaria la coerenza.
• Mantieni il segnaposto ↔ mappatura del valore effettivo solo dalla tua parte, temporaneo e sicuro.
• ZDR (zero conservazione dei dati) e residenza dei dati sono le tutele aziendali decisive nella selezione dei fornitori.
• "Uso didattico" e "conservazione dei dati" sono garanzie separate; Richiedili entrambi separatamente nel contratto.

Compito dell'applicazione

Prendi un singolo esempio di una richiesta reale che passa attraverso la tua pipeline AI (con dati di test). Contrassegnare quali PII appaiono nelle fasi (1) prompt, (2) registro e (3) risposta di questa richiesta. Per ogni PII, "redazione, tokenizzazione, nessuna pubblicazione?" Prendi la tua decisione e scrivi una nuova versione mascherata. Infine, verifica se i tuoi log contengono PII con il prompt di controllo sopra.

lista di controllo

• [ ] Ho mappato i quattro vettori di perdita (prompt, log, output, training) sul mio sistema.
• [ ] Maschero (redatto/tokenizzato) il PII prima di inviarlo al modello.
• [] I registri non contengono PII; C'è una correzione di bozze prima della registrazione.
• [ ] La mappatura dei segnaposto viene archiviata temporaneamente e in modo sicuro.
• [ ] Ho ricevuto contrattualmente dal fornitore la garanzia ZDR e di "non utilizzo nell'istruzione".
• [ ] Ho verificato i miei requisiti di residenza dei dati (KVKK/GDPR).