Dati personali e GDPR per il vibe coder

Il GDPR non è un fastidio burocratico: è il vincolo che decide cosa puoi raccogliere, dove può vivere, chi lo può vedere, quando va cancellato. Ignorarlo nei prototipi che diventano produzione è esposizione reale a sanzioni e danno reputazionale. Per il vibe coder, GDPR si traduce in 5-7 decisioni progettuali che incidono sull’architettura.

Nota importante: questa lezione fornisce una panoramica operativa per orientarsi. Non è consulenza legale. Per applicazioni che trattano dati personali su scala significativa, dati sensibili (sanitari, finanziari, di minori), o per app destinate al mercato, consulta un DPO o un avvocato specializzato in privacy.

Perché questa lezione conta

Il modello AI non conosce il tuo regime legale. Genera codice che logga email, salva dati di test reali, integra analytics senza consenso. Scelte che in prototipo passano inosservate, in produzione sono rischio. Sapere quali decisioni emergono dal GDPR — e prenderle a freddo, in fase di specifica — evita refactor costosi e rischi legali.

Obiettivo operativo

Alla fine devi saper:

1. distinguere dati personali, sensibili, anonimi, pseudonimi;
2. applicare i principi base GDPR al design di un’app;
3. riconoscere quando serve coinvolgere figure competenti (DPO, avvocato).

Nucleo della lezione

1. Categorie di dati

Dato personale (Art. 4 GDPR): qualsiasi informazione riguardante una persona fisica identificata o identificabile.

Esempi: nome, email, indirizzo IP, foto, IDFA/AAID, data di nascita, posizione GPS, voce, qualsiasi identificativo univoco. Anche un combinazione di dati apparentemente innocui (CAP + età + genere) può identificare.

Dato sensibile / categoria particolare (Art. 9): origine razziale/etnica, opinioni politiche, religione, salute, vita sessuale, dati genetici/biometrici, sindacati. Trattamento richiede base legale specifica + cautele rafforzate.

Dato anonimo: impossibile risalire alla persona, anche con sforzi. Fuori scope GDPR. Difficile da raggiungere veramente — anonimizzazione fatta male è ancora pseudonimizzazione.

Dato pseudonimo: identificativo sostituito ma con possibilità di re-identificare (es. user_id al posto di email, ma user_id mappabile via tabella separata). Ancora dato personale.

Per il vibe coder: la maggior parte di ciò che maneggi è personale o pseudonimo. Tratta come tale fino a prova contraria.

2. Principi base

Sei principi (Art. 5):

• Liceità, correttezza, trasparenza: c’è una base legale (consenso, contratto, obbligo legale, interesse legittimo, ecc.). L’utente sa cosa accade.
• Limitazione finalità: dati raccolti per uno scopo specifico, non riusabili per altro senza consenso.
• Minimizzazione: solo ciò che serve. Niente raccolta “per ogni evenienza”.
• Esattezza: dati corretti e aggiornati.
• Limitazione conservazione: cancellazione dopo periodo definito.
• Integrità e riservatezza: protezione adeguata (crittografia, accessi controllati).

Diritti dell’interessato (Artt. 15-22):

• accesso (cosa avete su di me);
• rettifica;
• cancellazione (diritto all’oblio);
• limitazione del trattamento;
• portabilità (export in formato leggibile);
• opposizione.

Per ogni dato che raccogli, devi essere in grado di:

• spiegarne la finalità;
• mostrarlo all’utente che lo richiede;
• correggerlo se sbagliato;
• cancellarlo su richiesta;
• esportarlo in formato leggibile.

3. Rischi pratici nei prototipi

Cinque trappole comuni nei progetti vibe coding:

Log con dati personali: console.log("Utente ", email, "ha acquistato"). Email finisce in log file, in servizio terzo (Sentry, Datadog), accessibile a chi vede log.

Database demo riempiti con dati reali: testi una feature usando email/nomi reali di amici. Se DB di sviluppo è meno protetto, exposure.

Analytics senza consenso: GA, Hotjar, Microsoft Clarity caricati al primo accesso senza banner. Indirizzo IP raccolto = dato personale = base legale richiesta.

Cookie tecnici vs di profilazione: tecnici (sessione, lingua) non richiedono consenso. Profilazione, marketing, statistici terze parti sì. Distinzione operativa per il banner cookie.

Trasferimenti extra-UE: usi servizi USA (Vercel, AWS, Google, OpenAI). Devi valutare il regime di trasferimento (SCC, adequacy decision dopo Schrems II + Data Privacy Framework UE-USA dal 2023). Per progetti seri: DPA firmati con i provider.

4. Quando coinvolgere esperti

Casi in cui non basta autodidattica:

• Dati sensibili: salute, opinioni politiche, religione, biometria. Sempre.
• Pubblicazione su scala: app per centinaia/migliaia di utenti.
• B2B con clausole specifiche: contratti che richiedono privacy policy specifica, DPA, certificazioni.
• Trasferimenti complessi: extra-UE, multipli, fra subprocessori.
• Incident: se hai un data breach (anche solo sospetto), parla con DPO/avvocato entro 72h.

Per piccolo MVP personale o B2B con 5 utenti: linee guida basic + privacy policy templata + cookie banner. Per oltre, professionista.

Procedura pratica

Per nuovo progetto:

1. Mappa dati: cosa raccogli, da chi, per quale scopo.
2. Classifica: personale / sensibile / pseudonimo / non personale.
3. Per ognuno: base legale, periodo di conservazione, chi può accedere.
4. Minimizza: cosa puoi NON raccogliere?
5. Documenta: privacy policy + interna (registro trattamenti se >250 dipendenti, ma utile anche se piccoli).
6. Implementa diritti: endpoint export, cancellazione, modifica.
7. Banner cookie: distingue tecnici da altro, blocca scripts non essenziali fino a consenso.
8. DPA con fornitori: Vercel, AWS, Stripe, ecc. hanno DPA standard; firmali.

Per ogni feature nuova: chiediti “qualche dato personale entra qui? in che modo?”.

Laboratorio guidato

Mappa dati per app capstone (es: app to-do condivise fra coppia).

• Email: personale → login, notifiche → contratto → conservata fino a cancellazione account → accessibile solo lato server.
• Nome: personale → display in UI → contratto → fino a cancellazione → server.
• Password (hash): personale → auth → contratto → fino a cancellazione → server.
• Task content: personale (se identifica) → funzionalità → contratto → fino a cancellazione → server, mostrata solo ai membri couple.
• IP address (log): personale → sicurezza, debug → interesse legittimo → 30-90 giorni → solo admin.
• Analytics: personale → statistiche → consenso → 14 mesi (default GA) → solo admin aggregato.

Decisioni emergenti:

• analytics senza consenso = violazione → cookie banner;
• IP in log per 90 giorni = scrivere in privacy policy;
• task content visibile solo ai membri = controllo accesso server-side, non solo UI;
• cancellazione account → cancella user + tasks + sessions, esporta opzionalmente prima.

Output atteso

Tabella mappa dati per il tuo progetto + decisioni implementative emergenti. Documento docs/privacy.md con elenco trattamenti, base legale, conservazione, accessi.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: ragionare sui dati personali fin dalla specifica, senza delegare all’AI decisioni legali o organizzative. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Dati personali, dati sensibili, finalità, base giuridica, minimizzazione, conservazione e cancellazione.
• Rischi pratici nei prototipi: log con email, database demo riempiti con dati reali, analytics non dichiarati.
• Quando serve coinvolgere figure competenti: privacy policy, trattamento dati, contratti con fornitori, trasferimenti extra UE.

3. Applicazione: svolgi il laboratorio: mappare i dati raccolti da una app capstone e segnare per ciascuno finalità, necessità e durata. L’output da ottenere è: una scheda privacy preliminare che evidenzia dati da evitare, ridurre o proteggere meglio.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• so distinguere dato personale, sensibile, anonimo, pseudonimo;
• ho mappa dati per il mio progetto principale;
• per ogni dato so finalità, base legale, periodo conservazione;
• implemento export e cancellazione richiesti dai diritti;
• banner cookie distingue tecnici da altri;
• niente dati reali in DB di sviluppo.

Errori comuni

“Sono un piccolo progetto, GDPR non si applica”. Si applica anche a progetto da 1 utente, se quel utente è UE.

Privacy policy copiata da altri progetti. Rispecchia trattamenti loro, non i tuoi. Pericoloso.

Banner cookie “accetta tutto” senza opzione granulare. Non conforme. Rischio sanzione.

Email/IP nei log senza scadenza. Conservazione indefinita = violazione minimizzazione.

Dati reali in DB di test. Se test DB compromesso, dati personali esposti.

Niente DPA con fornitori. Vercel, OpenAI, Stripe forniscono DPA. Vanno firmati.

Analytics caricati prima di consenso. Pixel cariato = trattamento iniziato. Blocca prima.

Cancellazione “soft” senza cancellare davvero. Dati restano accessibili. Diritto all’oblio violato.

Prompt di lavoro

Aiutami a fare audit GDPR per la mia app: [descrizione]

Dati che raccolgo (lista):
[email, nome, IP, ...]

Servizi terzi che utilizzo:
[Vercel, Supabase, Stripe, GA, ...]

Ambito utenti: [solo IT / EU / globale]

Per ognuno dei dati:

1. Categoria (personale / sensibile / pseudonimo).
2. Suggerimento finalità tipica.
3. Suggerimento base legale tipica (consenso / contratto / interesse legittimo).
4. Periodo conservazione tipico.

Per ognuno dei servizi terzi:

1. Trasferimento dati extra-UE? Quale regime?
2. DPA standard del fornitore — è sufficiente o servono accordi aggiuntivi?

Output:
- tabella dati
- tabella servizi
- 5 azioni prioritarie da implementare
- segnalazione di temi che richiedono parere legale (NON una consulenza legale, indicazione di rischio)

Disclaimer chiaro che NON è consulenza legale.

Esercizio finale

Apri il tuo progetto principale. Per ogni servizio terzo che usa dati utente, verifica: hai accettato il DPA del fornitore? Trovi nella tua privacy policy il riferimento? Sei consapevole di dove i dati finiscono geograficamente? Spesso una di queste tre risposte è “no”. Quel “no” è dove inizia la non conformità. Sistema o consulta esperto.