Prima di premere invio: i dati che non dovrebbero mai entrare in un prompt

Serie "Alfabetizzazione AI per chi lavora" | Approfondimento privacy del pillar Description, framework 4D

La scena si ripete in quasi ogni azienda che ha iniziato a usare l'AI senza un metodo. Qualcuno riceve un'email da un cliente, la copia per intero (nome, cognome, numero di telefono, dettagli del contratto) e la incolla in ChatGPT con la richiesta "rispondi tu in modo professionale". Funziona. La risposta arriva, è ben scritta, il lavoro è fatto in trenta secondi. Il problema è invisibile: quei dati personali hanno appena lasciato l'azienda e sono entrati nell'infrastruttura di un fornitore terzo, spesso senza che nessuno abbia deciso in modo consapevole che potevano uscire.

Questo articolo riguarda esattamente quei trenta secondi. Cosa non dovrebbe mai finire dentro un prompt, perché non è solo una questione di prudenza ma di GDPR, e come si continua a usare l'AI senza creare un problema che oggi non si vede e che salta fuori al primo controllo.

Nell'episodio sulla Description, il secondo pilastro del framework 4D, avevo toccato questo punto in un paragrafo. Qui lo apro per intero, perché è la parte dell'alfabetizzazione AI che più guide ignorano. Sapere usare uno strumento include sapere cosa non dargli in pasto.

Un prompt non è una conversazione privata

Il primo malinteso da smontare è il modello mentale. Molti trattano la finestra di chat come uno spazio privato, simile a un appunto su un foglio o a una nota sul telefono. Non lo è.

Quando scrivi un prompt a un modello cloud (ChatGPT, Claude, Gemini, Copilot nella versione consumer) il testo lascia il tuo dispositivo, viaggia fino ai server del fornitore, viene elaborato e in molti casi conservato per un periodo. A seconda del piano e delle impostazioni, può essere usato per addestrare i modelli futuri. Tre cose accadono che con un foglio di carta non accadono: il dato esce dal tuo perimetro, viene conservato da qualcun altro, e potenzialmente viene riutilizzato.

Per un appunto personale non cambia niente. Per il nome di un cliente, lo stipendio di un dipendente o la diagnosi dentro un referto, cambia tutto. Stai trattando dati personali di terzi su un'infrastruttura che non controlli, e il GDPR ha qualcosa da dire su questo.

I dati che non dovrebbero mai entrare in un prompt

Ecco la lista pratica. Sono le categorie che, per default, vanno tenute fuori dai prompt che transitano su strumenti cloud condivisi, salvo che tu non abbia un contratto specifico che ne regola il trattamento (ci torno più avanti).

• Dati identificativi di persone fisiche: nomi e cognomi di clienti, dipendenti, fornitori, pazienti, assistiti. Anche un'email o un numero di telefono associato a una persona riconoscibile.
• Identificatori univoci: codici fiscali, numeri di carta d'identità, IBAN, partite IVA collegate a una persona fisica, numeri di pratica che permettono di risalire a qualcuno.
• Dati particolari (art. 9 GDPR): salute, vita sessuale, opinioni politiche, convinzioni religiose, appartenenza sindacale, origine etnica, dati biometrici e genetici. È la categoria più delicata in assoluto.
• Dati finanziari riconducibili a una persona o a un'azienda specifica: stipendi, fatture nominative, estratti conto, situazioni debitorie.
• Segreti aziendali e informazioni riservate: strategie non pubbliche, prezzi riservati, dettagli di trattative o acquisizioni, codice proprietario, credenziali e password.

La regola di sintesi è una sola: se un'informazione permette di identificare una persona, oppure farebbe danno (a qualcuno o alla tua azienda) se diventasse pubblica, non va in un prompt generico.

Perché è un problema GDPR, non solo prudenza

Qui serve precisione, senza allarmismo. Il punto non è che usare l'AI sia vietato. Il punto è che inserire dati personali di terzi in uno strumento cloud configura un trattamento di dati personali, e ogni trattamento ha delle regole. Tre elementi rendono la cosa concreta.

1. Ruoli. Nel momento in cui mandi i dati di un tuo cliente a un fornitore AI, quel fornitore diventa un responsabile del trattamento che agisce per tuo conto. Perché il rapporto sia regolare serve un accordo (un DPA, Data Processing Agreement) che stabilisca cosa il fornitore può e non può fare con quei dati. Senza, manca la base che regge il trasferimento.
2. Riutilizzo per training. Se il piano che usi prevede che le conversazioni alimentino l'addestramento, i dati del tuo cliente possono finire dentro un modello futuro. Difficile da revocare, quasi impossibile da tracciare. Per i dati di terzi è il rischio più grosso.
3. Trasferimento fuori dall'Unione Europea. Molti fornitori elaborano i dati su server extra-UE. Il GDPR consente questi trasferimenti solo a certe condizioni. Se non le verifichi, non sai se sei in regola.

Nessuno di questi tre punti è teorico: sono le prime domande che un'autorità di controllo farebbe in caso di verifica. E sono le stesse domande che l'Art. 4 dell'AI Act presuppone tu sappia farti. "Alfabetizzazione" non significa saper scrivere un buon prompt: significa capire cosa succede ai dati quando lo invii.

Vale la pena chiarire un equivoco diffuso: il problema non è l'AI in sé, è il canale. Lo stesso dato che non metteresti in un gruppo di lavoro su WhatsApp, o in un'email mandata al destinatario sbagliato, non va nemmeno in un prompt su uno strumento condiviso. L'AI non introduce un rischio nuovo, rende solo più facile commettere quello vecchio, perché la velocità con cui ottieni una risposta utile abbassa la guardia. È proprio quella comodità a meritare una regola esplicita, scritta una volta e applicata sempre, invece di una valutazione improvvisata ogni volta che apri la chat.

La regola operativa: anonimizzare prima di descrivere

La buona notizia è che nel 95% dei casi il modello non ha alcun bisogno dei dati identificativi per aiutarti. Ha bisogno del contesto, non del nome.

La tecnica si chiama pseudonimizzazione: sostituire i dati identificativi con descrizioni generiche prima di scrivere la richiesta. Qualche esempio concreto.

• "Il mio cliente Mario Rossi, partita IVA 0123, del settore edile" diventa "un cliente nel settore edile, microimpresa del Nord Italia".
• "Rispondi a questa email di Laura Bianchi che si lamenta del ritardo" diventa "rispondi a questa email di un cliente che lamenta un ritardo nella consegna", con il testo ripulito dai dati personali.
• "Analizza questo referto di un paziente" è invece un caso da non trattare affatto su strumenti consumer: è un dato sanitario, categoria particolare.

Per la qualità della risposta il risultato è identico, perché al modello serve sapere che è un cliente del settore edile arrabbiato per un ritardo, non come si chiama. La parte di valore (il tono, la struttura, l'argomentazione) non dipende dall'identità della persona.

Nei sistemi automatizzati questo principio diventa strutturale. In tutte le automazioni in produzione che elaborano informazioni su clienti, il layer di anonimizzazione è un passaggio del workflow, non una decisione presa a mano ogni volta. Il dato viene ripulito prima di raggiungere il modello, in automatico, perché affidarsi alla disciplina umana caso per caso non scala: prima o poi qualcuno dimentica.

Un esempio completo: dall'email grezza al prompt sicuro

Mettiamo insieme i pezzi su un caso realistico. Arriva questa email immaginaria: "Buongiorno, sono Giulia Ferrari, vi avevo ordinato il 3 marzo la fornitura per il mio negozio di Via Garibaldi 12 a Modena, ordine 4471, e non è ancora arrivata. Il mio numero è 333 1234567, vi prego di richiamarmi." Vuoi che l'AI ti aiuti a scrivere una risposta professionale.

La versione sbagliata è incollare l'email così com'è. In due righe contiene nome, indirizzo, numero di telefono e numero d'ordine: quattro dati personali.

La versione corretta separa il contesto dai dati. Al modello scrivi: "Sei l'assistente clienti di un'azienda di forniture B2B italiana. Un cliente segnala che un ordine effettuato circa due settimane fa non è ancora arrivato e chiede di essere ricontattato. Scrivi una risposta in italiano, tono cortese e diretto, che si scusa per il disagio, conferma che stiamo verificando con il corriere e dà un aggiornamento entro 48 ore. Massimo 120 parole, nessuna promessa di rimborso." Poi prendi la risposta e ci reinserisci tu, a mano, il nome e i riferimenti dell'ordine.

Il modello ha fatto il lavoro di scrittura senza vedere chi è la cliente, dove abita o che numero ha. Tu hai ottenuto lo stesso risultato. La differenza è che se domani qualcuno ti chiede dove sono finiti i dati di quel cliente, la risposta è "da nessuna parte fuori dall'azienda".

Dove finiscono davvero i tuoi prompt: le impostazioni che contano

Non tutti gli strumenti, e non tutti i piani, trattano i dati allo stesso modo. La differenza più importante è tra le versioni consumer e quelle business o API.

• Versioni consumer gratuite o personali: spesso, per default, le conversazioni possono essere usate per migliorare i modelli. Quasi sempre esiste un'impostazione per disattivare questo riutilizzo. Vale la pena trovarla e spegnerla, ma resta uno strumento pensato per uso personale, non per dati di terzi.
• Versioni business, team, enterprise o API: di norma offrono un DPA, garantiscono che i dati non vengano usati per il training e in alcuni casi prevedono la non conservazione (zero data retention). Sono queste le versioni adatte a un contesto professionale che tratta dati di clienti.

La cosa da fare oggi è una sola: aprire le impostazioni privacy dello strumento che usi, verificare se le tue conversazioni alimentano il training, e capire quale piano hai. Cinque minuti che cambiano il profilo di rischio. Se usi l'AI per lavoro su dati di clienti e sei ancora su un piano consumer senza DPA, quello è il primo gap di alfabetizzazione da chiudere.

Quando il dato non può uscire: l'opzione locale

C'è una categoria di dati che, anche con il miglior contratto, è meglio non far uscire affatto: referti medici, atti riservati, documenti coperti da segreto professionale, dati per cui un trasferimento sarebbe sproporzionato rispetto al beneficio.

Per questi casi esiste un'alternativa: i modelli che girano in locale, sulla propria macchina o su un server controllato, senza che il testo lasci mai il perimetro. Sono meno potenti dei modelli cloud di frontiera, ma per molti task (riassumere, riformulare, estrarre informazioni da un testo) bastano e avanzano. Il vantaggio è netto: il dato non esce, e il problema del trasferimento sparisce alla radice.

Non serve a tutto e non è per tutti. Per chi lavora in modo sistematico con dati che non possono uscire, sapere che questa opzione esiste fa parte dell'alfabetizzazione: la domanda giusta non è sempre "quale modello è più bravo", a volte è "questo dato può uscire da qui?".

La checklist dei 20 secondi

Prima di premere invio su un prompt che contiene informazioni reali, queste sono le domande da farsi. Con la pratica diventano automatiche e non rallentano il lavoro.

1. C'è un nome, un'email, un numero o un codice che identifica una persona reale? Se sì, toglilo o sostituiscilo.
2. C'è un dato sensibile (salute, opinioni, situazione economica personale)? Se sì, non va su uno strumento consumer.
3. C'è un'informazione che danneggerebbe l'azienda se diventasse pubblica? Se sì, valuta se serve davvero al modello.
4. So su quale piano sto lavorando e se le mie conversazioni vengono usate per il training? Se non lo so, verificalo prima.
5. Il modello ha davvero bisogno di questo dato per aiutarmi, o posso descrivere la situazione senza? Quasi sempre puoi.

Non è burocrazia. È la stessa attenzione che metteresti prima di inoltrare un'email riservata: un secondo per chiederti "a chi sto mandando questo?".

Dove si collega all'AI Act

Tutto questo non è un tema separato dalla compliance: è compliance. L'Art. 4 dell'AI Act impone l'alfabetizzazione AI dal 2 febbraio 2025 a chi usa sistemi di AI in modo professionale. Sapere quali dati non mettere in un prompt è una delle competenze più concrete che quell'obbligo ha in mente. I poteri di vigilanza diventano pienamente operativi dal 2 agosto 2026, la stessa data in cui scattano gli obblighi di trasparenza dell'Art. 50.

La trasparenza (dichiarare quando un contenuto è prodotto con l'AI) è il rovescio della stessa medaglia: usare l'AI in modo responsabile significa proteggere i dati che entrano e essere onesti sull'output che esce. Su come applico la trasparenza ai miei contenuti ho una pagina dedicata, se vuoi vedere un esempio concreto di disclosure. Niente vendita, solo come funziona il mio setup.

Attribuzione del framework

Framework AI Fluency (Delegation / Description / Discernment / Diligence): sviluppato da Prof. Rick Dakan (Ringling College of Art and Design) e Prof. Joseph Feller (University College Cork), in collaborazione con Anthropic PBC. Licenza CC BY-NC-SA 4.0. Questo articolo usa la struttura concettuale del framework con contenuto, esempi e analisi originali.