Le nuove Linee guida 03/2026 dell’EDPB chiariscono come il GDPR si applica alla raccolta automatizzata di dati dal web per addestrare o perfezionare sistemi di intelligenza artificiale. Il punto di partenza è semplice, ma spesso sottovalutato: il fatto che un’informazione sia disponibile online non significa che possa essere utilizzata senza limiti per sviluppare un modello AI.

I sistemi di intelligenza artificiale generativa hanno bisogno di grandi quantità di dati. Testi, immagini, registrazioni, discussioni online e altri contenuti possono essere raccolti automaticamente attraverso tecniche di web scraping, cioè mediante software che estraggono e memorizzano informazioni disponibili su siti, social network, forum, blog, registri pubblici e altre risorse online.

Il problema nasce quando tra queste informazioni sono presenti dati personali.

È proprio su questo terreno che interviene l’European Data Protection Board (EDPB), che nel luglio 2026 ha adottato le Guidelines 03/2026 on web scraping in the context of generative AI, attualmente sottoposte a consultazione pubblica fino al 30 ottobre 2026. Le Linee guida riguardano le attività svolte da soggetti privati, sia quando raccolgono direttamente i dati dal web sia quando affidano lo scraping a terzi o riutilizzano dataset già raccolti da altre organizzazioni.

Il messaggio per le imprese è importante: “pubblicamente accessibile” e “liberamente utilizzabile” non sono la stessa cosa.

Cos’è il web scraping e perché interessa il GDPR

L’EDPB definisce il web scraping come una tecnica automatizzata utilizzata per estrarre e conservare informazioni provenienti da servizi web pubblicamente disponibili.

Lo scraping può essere molto selettivo, ad esempio limitato a determinate pagine o argomenti, oppure estremamente ampio, attraverso crawler che seguono automaticamente i collegamenti e possono arrivare a esplorare una parte molto estesa del web.

Ed è proprio la scala del trattamento a creare uno dei problemi principali: chi raccoglie milioni di contenuti può non sapere con precisione quali dati personali abbia acquisito, a quali persone appartengano e quali categorie di informazioni siano finite nel dataset.

Se tra i dati raccolti compaiono nomi, fotografie, contatti o altre informazioni riferibili, anche indirettamente, a persone identificabili, il GDPR entra in gioco. Questo vale anche quando il dataset contiene contemporaneamente informazioni personali e non personali: per la componente relativa a persone identificabili continuano ad applicarsi le regole sulla protezione dei dati.

Un dato pubblicato online resta un dato personale

Questo è probabilmente il punto più importante delle nuove Linee guida.

Una fotografia pubblicata su un sito, un commento scritto in un forum o le informazioni contenute in un profilo pubblico non cessano di essere dati personali semplicemente perché sono accessibili da Internet. Lo stesso problema può presentarsi anche fuori dal training dei modelli: strumenti di lead generation e agenti AI possono utilizzare tecniche di web scraping per raccogliere e arricchire automaticamente informazioni sui potenziali clienti, con ulteriori conseguenze sul piano privacy.

L’EDPB affronta espressamente anche un equivoco piuttosto frequente: il fatto che una persona abbia reso disponibili online propri dati non equivale al consenso al loro scraping per una finalità ulteriore, come l’addestramento di un modello di intelligenza artificiale. Persino l’assenza di un file robots.txt che impedisca ai crawler di accedere a un sito, precisa l’EDPB, non costituisce consenso ai sensi del GDPR.

Significa che un’impresa non può basare la propria analisi su un ragionamento del tipo:

“Era pubblico, quindi potevamo prenderlo.”

Occorre invece stabilire perché quei dati vengono raccolti, quali dati sono realmente necessari, su quale base giuridica vengono trattati e quali garanzie vengono adottate.

Il legittimo interesse può essere utilizzato, ma non è un lasciapassare

Nelle attività di web scraping effettuate da soggetti privati per lo sviluppo di AI generativa, l’EDPB osserva che la base giuridica più frequentemente utilizzata è il legittimo interesse previsto dall’art. 6, par. 1, lett. f) del GDPR. Questo, però, non significa che il legittimo interesse possa essere dichiarato genericamente e considerato sufficiente.

Occorre superare tre verifiche cumulative: deve esistere un interesse legittimo reale e concretamente individuato; il trattamento dei dati deve essere necessario per perseguirlo; infine deve essere effettuato il bilanciamento tra l’interesse dell’organizzazione e i diritti e le libertà delle persone coinvolte.

L’interesse perseguito deve quindi essere lecito, chiaramente formulato, concreto e attuale, non semplicemente ipotetico. L’EDPB richiama, ad esempio, finalità come lo sviluppo di un assistente conversazionale, la rilevazione delle frodi o il miglioramento della capacità di individuare minacce informatiche.

Per un’impresa questo significa che formule generiche come “sviluppare soluzioni innovative basate sull’AI” difficilmente rappresentano, da sole, una buona analisi. Occorre descrivere quale sistema si sta sviluppando, quale obiettivo si intende raggiungere e perché proprio quei dati personali sono necessari per farlo.

La domanda da farsi è: servono davvero tutti quei dati?

Il secondo passaggio è particolarmente interessante. Non basta dimostrare che i dati siano utili al progetto. Occorre valutare se esista un modo altrettanto efficace ma meno invasivo per raggiungere l’obiettivo.

L’EDPB osserva, ad esempio, che potrebbe essere necessario restringere i criteri di raccolta invece di effettuare lo scraping indiscriminato di ampie parti di Internet oppure utilizzare, quando possibile, dati sintetici o dati pseudonimizzati.

È una traduzione molto concreta del principio GDPR di minimizzazione dei dati, infatti la domanda corretta non è quindi soltanto “questi dati possono esserci utili?”, ma piuttosto:

“Siamo in grado di dimostrare che è necessario raccoglierli per raggiungere questo specifico risultato?”

Le aspettative delle persone contano

Uno degli elementi da considerare nel bilanciamento è rappresentato dalle ragionevoli aspettative dell’interessato. Anche qui l’EDPB evita automatismi. Una persona può essere consapevole del fatto che un contenuto pubblicato online possa essere letto o raccolto da terzi. Questo, tuttavia, non significa che debba ragionevolmente aspettarsi qualsiasi trattamento, da qualsiasi soggetto, per qualsiasi finalità.

Devono essere considerati, tra gli altri elementi, il tipo di sito sul quale l’informazione è stata pubblicata, il livello di accessibilità del contenuto, le eventuali restrizioni tecniche contro lo scraping e le caratteristiche degli interessati.

Un articolo pubblicato liberamente su un blog, ad esempio, ha un carattere diverso da un post inserito all’interno di un social network con accesso limitato e, nel merito, l’EDPB attribuisce espressamente importanza anche alle misure con cui un sito manifesta la propria opposizione allo scraping, come robots.txt, ai.txt, sistemi di autenticazione o CAPTCHA.

Minimizzazione: lo scraping non dovrebbe partire “alla cieca”

Le Linee guida dedicano molta attenzione a ciò che dovrebbe avvenire prima ancora che il crawler venga avviato. L’EDPB non afferma che il principio di minimizzazione impedisca di utilizzare dataset molto grandi per addestrare sistemi AI. Afferma invece qualcosa di diverso: un grande dataset non giustifica la raccolta di dati personali inutili rispetto alla finalità perseguita. Prima della raccolta, l’organizzazione dovrebbe quindi definire criteri precisi, mappare le informazioni necessarie, utilizzare filtri e valutare l’esclusione di fonti particolarmente problematiche.

L’EDPB indica espressamente, tra gli esempi, siti prevalentemente utilizzati da minori, fonti che possono contenere informazioni finanziarie o di geolocalizzazione e siti che manifestano chiaramente la volontà di impedire lo scraping. Durante e dopo la raccolta possono inoltre essere utilizzati filtri per intercettare determinati identificativi, nonché tecniche di anonimizzazione, pseudonimizzazione o sostituzione con dati sintetici.

Attenzione ai dati particolari

La raccolta indiscriminata del web presenta un rischio evidente: il crawler potrebbe acquisire informazioni sulla salute, opinioni politiche, origine razziale o etnica, orientamento sessuale o altre categorie particolari di dati personali ai sensi dell’art. 9 GDPR. Per una raccolta intenzionale di queste categorie di dati non basta una base giuridica dell’art. 6: deve sussistere anche una delle condizioni previste dall’art. 9, par. 2, del GDPR.

Più delicato è il caso nel quale questi dati vengano raccolti in maniera incidentale e residuale, nonostante le misure adottate per evitarlo. L’EDPB richiama in proposito la giurisprudenza della Corte di giustizia nel caso GC and Others, ma precisa che non si tratta di una deroga generale. L’organizzazione deve effettuare una valutazione caso per caso e adottare misure concrete prima della raccolta, dopo la raccolta e durante lo sviluppo del modello. Tra queste vi sono filtri preventivi, eliminazione dei dati particolari individuati nel dataset, protezioni contro la loro estrazione dal modello e controlli sugli output generati.

La trasparenza resta necessaria, anche quando non è possibile contattare tutti

Lo scraping su larga scala presenta un problema evidente: come informare centinaia di migliaia, o milioni, di persone che non hanno mai avuto rapporti con l’organizzazione? L’art. 14, par. 5, lett. b) del GDPR può, in determinate circostanze, consentire di non fornire individualmente l’informativa quando ciò risulti impossibile o richieda uno sforzo sproporzionato. Ma l’EDPB chiarisce che questa eccezione non dovrebbe essere utilizzata automaticamente.

Occorre confrontare lo sforzo richiesto all’organizzazione con le conseguenze che la mancata informazione può determinare per le persone, considerando anche il numero degli interessati, l’età dei dati e le garanzie adottate. Quando l’informativa individuale risulta effettivamente impossibile o sproporzionata, il titolare deve comunque adottare misure adeguate e rendere pubblicamente disponibili le informazioni previste dall’art. 14.

Secondo l’EDPB, sarebbe opportuno fornire indicazioni precise sulle fonti utilizzate e sulle caratteristiche del crawler; ove possibile, anche domini o URL interessati e il periodo in cui la raccolta è stata effettuata.

Al contrario, se il dataset è circoscritto, recente, riguarda soggetti identificabili ed esistono strumenti concretamente utilizzabili per contattarli, l’informativa individuale può essere richiesta. È proprio il contrasto tra questi due scenari che l’EDPB utilizza nei propri esempi.

Comprare un dataset non elimina il problema

Un altro passaggio particolarmente rilevante per le aziende riguarda i dataset acquistati o acquisiti da terzi. Un’impresa potrebbe infatti non effettuare direttamente alcuno scraping e ricevere i dati da un data provider o da un soggetto che li ha raccolti precedentemente. Questo non rende automaticamente legittimo il riutilizzo.

Secondo l’EDPB, quando chi ha effettuato lo scraping e lo sviluppatore AI perseguono finalità proprie, sono in linea di principio responsabili dei rispettivi trattamenti. Lo sviluppatore deve quindi valutare autonomamente il trattamento che intende effettuare con il dataset acquisito. Se invece il soggetto che effettua lo scraping agisce semplicemente sulla base delle istruzioni dello sviluppatore, la qualificazione dei ruoli può essere diversa e va analizzata concretamente.

Per chi acquista dataset destinati all’AI, quindi, la due diligence sul fornitore e sulla provenienza dei dati diventa parte della governance privacy. Non dovrebbe interessare soltanto quale volume di dati viene acquistato, ma anche da quali fonti proviene, come è stato costruito il dataset, quali criteri di esclusione sono stati adottati e come vengono gestiti i diritti degli interessati.

Anche l’accuratezza entra nella progettazione dell’AI

C’è un ulteriore aspetto spesso trascurato.

Lo scraping può raccogliere informazioni vecchie, errate o provenienti da fonti poco affidabili. L’EDPB raccomanda quindi, per quanto possibile, di utilizzare fonti affidabili, registrare quando il dato è stato raccolto e validarlo prima dell’utilizzo nel training. Il principio di accuratezza non riguarda soltanto il dataset. Quando il modello è destinato a produrre output che costituiscono dati personali, secondo l’EDPB deve essere considerato anche il rischio che il sistema generi informazioni inesatte riferite alle persone.

Si tratta di un punto significativo: la data protection non termina quando il dataset entra nel modello, ma accompagna anche il modo in cui il modello utilizza e può riprodurre quelle informazioni.

Cosa dovrebbe fare concretamente un’azienda

Per un’impresa che sviluppa, addestra o effettua il fine-tuning di sistemi di AI generativa utilizzando informazioni provenienti dal web, le Linee guida suggeriscono di trasformare lo scraping in un processo governato e documentato, non in una semplice operazione tecnica. Questo approccio è coerente con un principio più generale: la governance privacy e AI deve entrare nel processo di sviluppo e non essere aggiunta quando il prodotto è già terminato. Per le software house abbiamo approfondito questo modello operativo in una specifica checklist dedicata alla governance di GDPR e AI Act.

Prima di avviare o continuare il progetto, suggeriamo quindi almeno queste verifiche:

  1. Definire esattamente la finalità per cui i dati vengono raccolti e documentare il rapporto tra dataset e funzione del modello.
  2. Mappare le fonti e le categorie di dati, distinguendo ciò che viene raccolto direttamente da ciò che proviene da dataset acquistati o forniti da terzi.
  3. Individuare la base giuridica prima della raccolta o del riutilizzo e, se si utilizza il legittimo interesse, documentare interesse, necessità e bilanciamento.
  4. Applicare la minimizzazione prima dello scraping, limitando fonti, periodi, categorie di dati e siti da cui la raccolta può avvenire e valutando alternative meno invasive.
  5. Proteggere categorie particolari, minori e persone vulnerabili, utilizzando filtri preventivi e procedure per eliminare rapidamente eventuali dati raccolti incidentalmente.
  6. Definire la trasparenza verso gli interessati, verificando quando sia necessaria l’informativa individuale e quando possa essere utilizzata l’eccezione dello sforzo sproporzionato, accompagnandola comunque con informazioni pubblicamente accessibili.
  7. Gestire i diritti e l’opposizione allo scraping, anche attraverso meccanismi di opt-out quando appropriati, nonché procedure per cancellazione, anonimizzazione e pseudonimizzazione.
  8. Controllare anche ciò che accade dopo il training, verificando accuratezza, memorizzazione e possibile rigurgito dei dati, sicurezza del modello e capacità degli output di rivelare informazioni personali. Quando caratteristiche, dimensioni o rischi del trattamento lo richiedono, deve inoltre essere valutata la necessità di effettuare una DPIA.

L’obiettivo non è quindi impedire alle aziende di utilizzare grandi quantità di dati per sviluppare sistemi di AI ma essere in grado di spiegare — e documentare — perché determinati dati sono stati raccolti, perché erano necessari e quali misure sono state adottate per ridurre l’impatto sulle persone.

Privacy compliant non significa automaticamente “scraping consentito”

Va infine tenuto distinto un ultimo profilo: le Guidelines 03/2026 riguardano la protezione dei dati personali. Superare correttamente l’analisi GDPR non significa, da solo, avere risolto ogni questione giuridica relativa allo scraping. Possono infatti restare rilevanti altri profili, tra cui quelli relativi al diritto d’autore e alle condizioni di utilizzo delle fonti. Lo stesso EDPB, in uno dei propri esempi, considera separatamente la presenza di contenuti protetti e l’eventuale opposizione dei titolari dei diritti al text and data mining.

Per questo motivo la valutazione dovrebbe essere inserita in una governance complessiva del progetto AI, nella quale aspetti tecnici, privacy, AI Act, proprietà intellettuale, contratti e sicurezza non vengano affrontati separatamente.

Web scraping e AI: il punto per le aziende

Le nuove Linee guida dell’EDPB rendono più difficile sostenere che la provenienza pubblica dei dati sia sufficiente a giustificarne l’utilizzo. La domanda non è più soltanto “possiamo tecnicamente raccogliere questi dati?” ma la domanda diventa: “possiamo dimostrare perché li raccogliamo, perché ci servono, da dove arrivano e come proteggiamo le persone alle quali si riferiscono?”

È una differenza sostanziale.

E riguarda non soltanto i grandi sviluppatori di modelli general purpose, ma anche software house, startup e imprese che effettuano fine-tuning, costruiscono dataset verticali, acquistano basi dati o commissionano la raccolta delle informazioni a fornitori esterni.

Come FinData consigliamo quindi di inserire la verifica dei dataset e delle fonti all’interno della valutazione di conformità del sistema AI prima della messa in produzione, quando modificare criteri di raccolta, architettura e processi è ancora concretamente possibile.

FinData supporta le organizzazioni nella valutazione dei sistemi di intelligenza artificiale, nella governance dei dati, nella conformità GDPR e nell’adeguamento all’AI Act. Se la tua azienda sviluppa o utilizza sistemi AI e vuoi verificare provenienza dei dataset, basi giuridiche, DPIA e misure di governance, contatta il nostro team per una valutazione del progetto.