Web scraping legale per aziende: GDPR, robots.txt e banche dati

Raccogliere dati dal web in modo automatico può essere molto utile a un'azienda: monitorare i listini dei concorrenti, tenere aggiornato un catalogo, seguire bandi e pubblicazioni, alimentare un report. Ma "è pubblico, quindi posso prenderlo" non è un criterio sufficiente. In Italia e nell'Unione Europea entrano in gioco almeno quattro piani diversi: la protezione dei dati personali, le condizioni d'uso del sito, i diritti sulle banche dati e il comportamento tecnico verso il server che si interroga.

Questa guida mette in fila le domande da porsi prima di partire, con una checklist finale.

Nota: questo articolo è informativo e non costituisce consulenza legale. Per un progetto concreto, soprattutto se coinvolge dati personali, fate valutare il caso a un legale o al vostro DPO.

1. Prima domanda: che dati raccogliete?

La distinzione più importante è tra dati che riguardano persone e dati che non le riguardano.

• Dati non personali: prezzi, disponibilità, caratteristiche tecniche dei prodotti, orari, testi di bandi. Qui il GDPR in genere non entra in gioco, mentre restano gli altri piani (condizioni d'uso, banche dati, carico sul server).
• Dati personali: nomi, email, numeri di telefono, profili, recensioni firmate, foto. Qui si applica il Regolamento (UE) 2016/679 (GDPR), anche se i dati sono liberamente visibili online.

Il punto che si dimentica più spesso è proprio questo: un dato personale pubblicato su un sito resta un dato personale. Il fatto che sia accessibile non dà automaticamente il diritto di raccoglierlo, copiarlo in un database e usarlo per altri scopi.

2. Se ci sono dati personali: GDPR

Se il progetto tocca dati personali, servono risposte chiare ad alcune domande che derivano direttamente dal GDPR:

• Base giuridica (art. 6): su cosa si fonda il trattamento? Nei progetti aziendali si valuta spesso il legittimo interesse, che però richiede un bilanciamento documentato con i diritti delle persone interessate e non è una formula valida per tutto.
• Finalità e minimizzazione (art. 5): raccogliete solo i campi che servono davvero allo scopo dichiarato. Se vi serve sapere quante recensioni negative ha un prodotto, probabilmente non vi servono i nomi di chi le ha scritte.
• Informativa (art. 14): quando i dati non vengono raccolti presso l'interessato, il GDPR prevede comunque obblighi di informazione, con alcune eccezioni da valutare caso per caso.
• Conservazione e sicurezza: per quanto tempo tenete i dati, dove, chi vi accede.

Il Garante per la protezione dei dati personali ha pubblicato nel 2024 una nota informativa dedicata al web scraping, rivolta soprattutto ai gestori di siti che vogliono difendersi dalla raccolta massiva di dati personali, ma utile anche a chi lo scraping lo fa.

Una regola prudente: se un obiettivo si può raggiungere senza dati personali, progettate il sistema per non raccoglierli affatto, invece di raccoglierli e filtrarli dopo.

3. Le condizioni d'uso del sito

Molti siti hanno termini di servizio che vietano o limitano l'estrazione automatica dei contenuti. Il loro peso dipende da diversi fattori, per esempio se l'utente li ha accettati (con una registrazione o un login) e da come sono formulati. Due indicazioni pratiche:

• Leggeteli prima, non dopo. Se il sito vieta esplicitamente lo scraping, è un elemento da valutare seriamente insieme a chi segue gli aspetti legali.
• Attenzione alle aree riservate: estrarre dati da sezioni accessibili solo dopo login, con un account che ha accettato condizioni contrarie, è una situazione molto diversa dal leggere pagine pubbliche.

4. Banche dati: il diritto sui generis

La Direttiva 96/9/CE sulla tutela giuridica delle banche dati, recepita in Italia nella legge sul diritto d'autore (L. 633/1941), prevede oltre al diritto d'autore un diritto sui generis a favore di chi ha fatto un investimento rilevante per costituire, verificare o presentare una banca dati.

In sintesi, questo diritto consente al costitutore di vietare:

• l'estrazione o il reimpiego della totalità o di una parte sostanziale del contenuto;
• l'estrazione ripetuta e sistematica di parti non sostanziali, quando questo contrasta con il normale sfruttamento della banca dati o arreca un pregiudizio ingiustificato al costitutore.

Il secondo punto è rilevante per lo scraping: anche prelevare poco alla volta, se fatto in modo sistematico fino a ricostruire una parte importante dell'archivio, può ricadere nel divieto.

Va considerata anche la Direttiva (UE) 2019/790, che disciplina il text and data mining: tra le altre cose prevede che i titolari dei diritti possano riservarsi l'uso dei contenuti con strumenti leggibili da una macchina. Se il sito esprime questa riserva, è un'informazione da tenere in conto.

5. robots.txt: non è una legge, ma è un segnale

Il file robots.txt (oggi descritto nello standard RFC 9309) indica quali percorsi del sito il gestore non vuole che vengano visitati dai programmi automatici. Non è di per sé una norma di legge, ma ignorarlo significa ignorare una volontà espressa chiaramente dal gestore, e questo pesa nella valutazione complessiva del progetto.

In pratica: leggete il robots.txt del sito, rispettate i percorsi esclusi e le eventuali indicazioni sul ritmo delle richieste. Se i dati che vi servono stanno in una sezione esclusa, è il momento di chiedersi se esiste un'altra strada.

6. Carico sul server e rate limit

Uno scraper scritto male può mandare in difficoltà un sito, soprattutto se piccolo, e finire bloccato. Le buone pratiche tecniche sono semplici:

• limitare la frequenza delle richieste, con pause tra una pagina e l'altra e poche connessioni in parallelo;
• rispettare i segnali del server: se arriva un errore HTTP 429 (troppe richieste) o un'intestazione Retry-After, rallentare o fermarsi;
• lavorare negli orari di minor traffico quando possibile;
• scaricare solo ciò che è cambiato, usando cache e richieste condizionali invece di riscaricare tutto ogni volta;
• identificarsi in modo onesto e non aggirare le misure di protezione del sito, come captcha o blocchi di accesso.

7. L'alternativa da valutare per prima: le API ufficiali

Prima di scrivere uno scraper conviene sempre verificare se la fonte offre un canale ufficiale:

• API pubbliche o a pagamento, con condizioni d'uso chiare;
• feed (RSS, XML, CSV) o file di esportazione;
• open data pubblicati dalle pubbliche amministrazioni;
• accordi diretti con il gestore, per esempio con un fornitore che può mandarvi il listino in un formato strutturato.

Un'API ufficiale è quasi sempre più stabile di uno scraper, che si rompe ogni volta che il sito cambia grafica, e chiarisce in partenza cosa si può fare con i dati. Lo scraping ha senso quando un canale ufficiale non esiste o non copre quello che serve.

Checklist prima di avviare un progetto

1. Obiettivo: quale decisione o processo deve alimentare il dato? Scrivetelo in una frase.
2. Campi: elencate i campi necessari ed eliminate quelli superflui, in particolare quelli personali.
3. Fonti: per ogni sito, esiste un'API, un feed o un open data alternativo?
4. Condizioni d'uso: le avete lette? Contengono divieti o limiti sull'estrazione automatica?
5. robots.txt e riserve TDM: i percorsi che vi servono sono consentiti?
6. Banca dati: state prelevando una parte sostanziale di un archivio costruito da altri, anche a piccoli pezzi?
7. Dati personali: se ci sono, base giuridica, informativa, conservazione e sicurezza sono documentate?
8. Frequenza e carico: ogni quanto serve aggiornare? Avete previsto pause, limiti e gestione degli errori 429?
9. Uso finale: i dati restano interni o verranno ripubblicati? Il reimpiego verso terzi richiede una valutazione più attenta.
10. Manutenzione: chi si accorge se il sito cambia struttura e lo scraper smette di funzionare?

Se a qualcuna di queste domande non sapete rispondere, è meglio fermarsi e chiarire prima di scrivere codice.

Per approfondire

Se state valutando un progetto di raccolta dati, potete vedere come impostiamo fonti, frequenze e limiti tecnici nella pagina del nostro servizio di web scraping. Quando la fonte mette a disposizione un canale ufficiale, la strada più solida resta l'integrazione tramite sviluppo e integrazione API.