Web scraping legale in Italia? Guida pratica al GDPR per aziende che usano API di scraping
Il web scraping è legale in Italia? Guida pratica al GDPR per aziende: dati personali e non, base giuridica, scelta del fornitore e checklist operativa.
La riunione è sempre la stessa: il team ha trovato il modo di raccogliere automaticamente dati dal web — prezzi dei concorrenti, annunci, recensioni — e qualcuno, di solito il più prudente della stanza, fa la domanda che congela il progetto: "ma si può fare, legalmente?"
Rispondiamo subito, perché la paralisi costa quanto l'imprudenza: sì, il web scraping è legale in Italia — non esiste una norma che lo vieti in sé — ma la liceità non sta nello strumento: sta in cosa raccogli e cosa ci fai. Raccogliere listini pubblici per un'analisi di mercato e raccogliere profili personali per ricontattare le persone sono la stessa tecnica e due situazioni giuridiche opposte. La bussola per orientarsi è più semplice di quanto i convegni facciano credere.
La distinzione che decide tutto: dati personali o no
Il GDPR — il regolamento europeo sulla protezione dei dati — si occupa di una cosa sola: i dati personali, cioè le informazioni riferibili a una persona identificabile. Tutto il resto è fuori dal suo perimetro.
Tradotto in pratiche aziendali:
- prezzi, schede prodotto, disponibilità, dati societari, bandi, normativa, contenuti editoriali: non sono dati personali. Il GDPR non è la tua preoccupazione principale — restano i termini d'uso dei siti e il buon senso tecnico, di cui sotto.
- nomi, email, profili social, recensioni firmate, annunci con recapiti: sono dati personali, e da qui in poi serve il ragionamento completo — base giuridica, finalità, minimizzazione.
La maggior parte dei progetti di scraping aziendali in Italia — monitoraggio concorrenza, ricerca bandi, analisi di mercato — vive interamente nella prima categoria. È bene saperlo prima di rinunciare a un progetto legittimo per eccesso di prudenza.
Quando si raccolgono dati personali: le tre domande
Se il progetto tocca la seconda categoria, la liceità si costruisce rispondendo per iscritto a tre domande:
Perché li raccogli? Serve una base giuridica: per i dati pubblicamente disponibili l'appiglio tipico è il legittimo interesse — che però va argomentato e bilanciato contro i diritti degli interessati, non semplicemente invocato. "Erano online" non è una base giuridica: è la premessa del problema, non la soluzione.
Ti serve tutto quello che stai prendendo? Il principio di minimizzazione è concreto: se l'analisi ti serve aggregata, i nomi non li devi proprio salvare. Ogni campo raccolto in più è rischio in più senza valore in più.
Per quanto lo tieni? Una retention definita ("i dati grezzi si cancellano dopo X giorni, restano gli aggregati") trasforma una raccolta indefinita in un trattamento documentabile.
Chi risponde a queste tre domande su una pagina ha fatto l'80% del lavoro che un'autorità o un cliente enterprise chiederebbe di vedere.
Il fornitore di API è parte della tua compliance
Punto spesso ignorato: se usi un'API di scraping o di ricerca, quel fornitore entra nella tua catena del trattamento — e le sue risposte diventano le tue responsabilità. Le domande da fargli prima del contratto:
- Dove risiedono ed elaborano i dati? Fornitore e infrastruttura in UE semplificano tutto; extra-UE significa trasferimenti internazionali da documentare.
- Che retention applica sui dati che transitano dai suoi sistemi?
- Firma un accordo di trattamento (DPA) quando il progetto tocca dati personali?
- Rispetta i limiti tecnici dei siti (robots, rate limiting) o promette di "aggirare tutto"? Chi ti promette l'aggiramento come servizio ti sta vendendo anche il rischio.
È il criterio con cui abbiamo costruito NestD API: infrastruttura e supporto italiani, limiti di spesa e comportamento documentato per ogni richiesta — perché per un'azienda la tracciabilità del "come" vale quanto il risultato.
La checklist prima di partire
Cinque righe da spuntare, progetto alla mano: (1) i dati raccolti sono personali o no — deciso guardando i campi, non a sensazione; (2) se sì, base giuridica scritta e bilanciata; (3) solo i campi necessari, con retention definita; (4) fornitore valutato su sede, retention e DPA; (5) rispetto dei limiti tecnici dei siti sorgente. Un pomeriggio di lavoro, una volta — e il progetto smette di essere una zona grigia.
Domande frequenti
Se i dati sono pubblici posso raccoglierli liberamente?
I dati non personali pubblici, in linea generale sì. I dati personali restano protetti dal GDPR anche quando sono pubblici: la pubblicità del dato non è un'autorizzazione al riuso per qualsiasi fine.
I termini d'uso di un sito possono vietare lo scraping?
Possono, ed è un piano diverso dal GDPR: è materia contrattuale. Il rischio tipico è il blocco tecnico o una contestazione civile, non una sanzione privacy. Valutazione caso per caso, con peso proporzionato al valore della fonte.
Serve il DPO per un progetto di scraping?
Se l'azienda ne ha uno, va coinvolto presto. Se non ne ha uno, per un progetto su dati non personali basta la checklist qui sopra; se i dati personali sono centrali e sistematici, è il momento di farsi affiancare da un professionista.
Cosa rischia concretamente chi sbaglia?
Per violazioni GDPR le sanzioni possono essere rilevanti, ma il rischio quotidiano più concreto è un altro: perdere un cliente enterprise perché non sai documentare da dove vengono i tuoi dati. La compliance, vista bene, è un argomento commerciale.
Scritto da NestD — Nord-Est Tech Development, studio di sviluppo software AI locale-first in Veneto.