Il Digital Services Act ha introdotto strumenti importanti per aprire le grandi piattaforme digitali allo scrutinio pubblico: accesso ai dati per i ricercatori autorizzati, valutazione dei rischi sistemici, misure di mitigazione e audit indipendenti. Ma questi strumenti non producono automaticamente osservabilità.
Per trasformare dati e report in capacità pubblica di conoscenza serve una grammatica comune: protocolli di osservazione, indicatori condivisi e baseline indipendenti. Senza questo livello intermedio, l’Europa rischia di moltiplicare documenti, procedure e audit senza riuscire davvero a capire come le piattaforme organizzino attenzione e visibilità, e in quali condizioni questa organizzazione generi o amplifichi rischi sistemici.
Indice degli argomenti
Il DSA entra nella fase della prova
Nell’autunno 2025 per il Digital Services Act è iniziata una fase delicata. Con l’entrata in vigore del delegated act sull’Articolo 40, dal 29 ottobre 2025 i ricercatori autorizzati possono presentare richieste di accesso ai dati delle Very Large Online Platforms e dei Very Large Online Search Engines attraverso il Data Access Portal e i Digital Services Coordinator nazionali. Per la prima volta, l’accesso ai dati delle piattaforme non dipende soltanto da accordi bilaterali, dalla disponibilità delle imprese o da collaborazioni opache. Esiste un quadro giuridico europeo.
Quasi nello stesso periodo, il primo ciclo di risk assessment e audit del DSA ha iniziato a mostrare i limiti dell’altro pilastro della regolazione: l’autovalutazione dei rischi da parte delle piattaforme, accompagnata da misure di mitigazione e verifiche indipendenti. Il DSA chiede alle piattaforme di guardare ai propri effetti sistemici: diritti fondamentali, processi democratici, salute pubblica, sicurezza, protezione dei minori, violenza di genere, disinformazione e altri ambiti sensibili. È un salto rilevante rispetto a una regolazione centrata solo sulla rimozione di contenuti illegali o sulla trasparenza formale – un passaggio già discusso in un precedente intervento su come il problema della disinformazione si sia spostato dal piano dei contenuti falsi a quello dell’ecosistema informativo.
Il problema è che né l’accesso ai dati né il risk assessment, presi separatamente, bastano a produrre una capacità pubblica di osservazione. Aprono due porte, ma non costruiscono ancora la stanza in cui dati, report, audit e ricerca indipendente diventano conoscenza cumulativa, confrontabile e verificabile.
Il punto non è che il DSA sia debole. Al contrario: è proprio grazie agli strumenti avanzati introdotti dal DSA che oggi diventa visibile ciò che ancora manca.
Due strumenti osservativi, ma nessuna grammatica comune
Nel dibattito pubblico il DSA viene spesso presentato come una norma sulla moderazione dei contenuti o sulla responsabilità delle piattaforme. È una lettura parziale. Uno degli aspetti più innovativi del regolamento è il tentativo di rendere osservabili i rischi sistemici degli ambienti digitali. Non solo regole su cosa le piattaforme devono fare, ma strumenti per capire cosa sta accadendo.
Questa architettura poggia su due meccanismi distinti.
Il primo è esterno: l’Articolo 40 consente a ricercatori qualificati di richiedere dati alle grandi piattaforme per studiare i rischi sistemici e valutare l’efficacia delle misure di mitigazione. La richiesta nasce fuori dalla piattaforma, passa attraverso il Digital Services Coordinator competente e dovrebbe produrre conoscenza indipendente.
Il secondo è interno: gli Articoli 34 e 35 impongono alle piattaforme di identificare e valutare i propri rischi sistemici e di adottare misure ragionevoli, proporzionate ed efficaci per mitigarli. L’Articolo 37 prevede audit indipendenti sul rispetto di questi obblighi. Qui il movimento è diverso: la piattaforma valuta i propri rischi, documenta le proprie misure e si sottopone a verifica.
In teoria, i due strumenti dovrebbero compensarsi. L’accesso dei ricercatori dovrebbe aprire dall’esterno ciò che l’autovalutazione tende a lasciare opaco. Il risk assessment dovrebbe offrire continuità interna dove la ricerca indipendente procede per progetti, domande specifiche e finestre temporali limitate. L’audit dovrebbe impedire che l’autovalutazione diventi autoreferenziale.
Questa complementarità, però, funziona solo se esiste una grammatica comune. Se ogni piattaforma definisce in modo diverso i propri rischi, ogni auditor valuta con criteri diversi e ogni progetto di ricerca ottiene dataset costruiti in modo diverso, i risultati non si sommano. Restano episodi separati.
Il problema quindi non è soltanto avere più dati. È sapere come renderli confrontabili.
Perché l’accesso ai dati non basta
Aprire un canale di accesso ai dati è indispensabile. Ma l’accesso non produce automaticamente conoscenza.
Il primo limite è informativo. Il ricercatore deve specificare quali dati chiede, per quale finalità, con quale metodo e per studiare quale rischio sistemico. Ma spesso non sa quali dati esistano davvero nella piattaforma, con quale granularità, con quale struttura, per quali periodi, con quali metadati e con quali limiti di qualità. Il delegated act prevede data catalogues, ma questi cataloghi sono redatti dalle piattaforme stesse. Se una piattaforma sostiene che un certo dato non esiste, non è disponibile nella forma richiesta o sarebbe sproporzionato da fornire, ricercatore e Digital Services Coordinator si trovano davanti a una forte asimmetria informativa.
Il secondo limite è istituzionale. L’accesso passa attraverso il DSC del Paese di stabilimento della piattaforma. Questo è comprensibile dal punto di vista giuridico, ma produce una conseguenza pratica: richieste altamente tecniche devono essere valutate da autorità con capacità, culture amministrative e priorità diverse. Nel caso italiano il ruolo è affidato ad AGCom, ma la questione è generale. Anche un coordinatore competente deve valutare richieste complesse senza poter sempre verificare autonomamente l’intero universo dei dati disponibili presso la piattaforma.
Il terzo limite è temporale. Molti rischi sistemici emergono in finestre brevi: campagne elettorali, crisi internazionali, panico finanziario, emergenze sanitarie, attacchi coordinati contro persone o gruppi, dinamiche improvvise di radicalizzazione o amplificazione narrativa. Il percorso di richiesta, valutazione, possibile obiezione, mediazione ed eventuale adattamento della domanda può richiedere mesi. È un tempo compatibile con molti progetti accademici, ma non sempre con fenomeni che nascono, maturano e si dissolvono in giorni o settimane.
Il quarto limite è finalistico. L’accesso è subordinato allo studio dei rischi sistemici previsti dall’Articolo 34. Il vincolo è comprensibile: evita richieste arbitrarie, tutela dati personali e segreti commerciali, impedisce forme di fishing expedition. Ma può lasciare ai margini la ricerca esplorativa su rischi non ancora codificati o su meccanismi emergenti che non rientrano facilmente nelle categorie disponibili. È un limite importante quando l’oggetto regolato evolve più rapidamente del linguaggio normativo che lo descrive.
Questi non sono semplici difetti di implementazione. Sono conseguenze del modello: accesso puntuale, mediato, finalisticamente vincolato e dipendente da informazioni preliminari fornite in larga parte dal soggetto osservato. Una buona implementazione può attenuarli. Non può eliminarli.
Perché autovalutazione e audit non bastano
Il secondo errore sarebbe affidarsi troppo al pilastro interno: risk assessment, mitigazione e audit. Anche qui lo strumento è utile. Anche qui, da solo, non produce conoscenza pubblica replicabile.
Il problema più evidente è il conflitto di interesse strutturale. Le piattaforme devono valutare i rischi sistemici dei propri servizi, ma sono anche gli attori che progettano quei servizi, ne traggono profitto e controllano le infrastrutture informative necessarie a misurarne gli effetti. Definiscono categorie, scelgono indicatori, stabiliscono soglie, selezionano esempi, documentano procedure e valutano misure di mitigazione. L’auditor è formalmente indipendente, ma viene scelto e pagato dalla piattaforma.
Questo non significa che le piattaforme mentano sistematicamente, né che gli auditor lavorino male. Il problema è più strutturale: chi è osservato produce gran parte delle condizioni dell’osservazione. In assenza di standard esterni condivisi, l’auditor può verificare se esiste un processo, se è documentato, se è coerente con le policy interne e se è stato applicato secondo determinate procedure. Molto più difficile è stabilire se gli indicatori siano quelli giusti, se le soglie siano adeguate, se le misure siano proporzionate al rischio reale, o se una piattaforma stia sottostimando un fenomeno perché lo osserva con la metrica sbagliata.
È qui che il primo ciclo di audit del DSA diventa istruttivo. Le analisi disponibili hanno segnalato la difficoltà degli audit a entrare nel merito sostanziale dei rischi sistemici, soprattutto quando si tratta di sistemi di raccomandazione, amplificazione algoritmica, effetti indiretti e dinamiche di lungo periodo. Il nodo non è chiedere agli auditor di essere più severi in astratto. È fornire loro una materia osservabile rispetto alla quale giudicare: benchmark esterni, indicatori comuni, protocolli di confronto, serie temporali e baseline indipendenti.
C’è poi un problema di confidenzialità asimmetrica. Parti rilevanti dei risk assessment e degli audit possono restare non pubbliche per ragioni legate alla sicurezza, alla protezione dei dati personali o ai segreti commerciali. Anche questo è comprensibile. Ma il risultato è che le piattaforme mantengono un forte controllo sulla narrazione pubblica del rischio: che cosa viene reso visibile, con quale livello di dettaglio, in quale formato e con quali omissioni giustificate.
Il modello self-assessment più audit privato può produrre accountability procedurale: può mostrare che una procedura esiste ed è stata seguita. Ma non basta a stabilire se quella procedura misuri il rischio giusto, con indicatori adeguati, né se le misure adottate siano davvero efficaci. Può migliorare le pratiche interne delle piattaforme, ma non costruisce da solo una conoscenza pubblica, cumulativa e confrontabile dell’ecosistema digitale.
La grammatica mancante: protocolli, indicatori, baseline
A questo punto bisogna rendere concreto ciò che spesso resta astratto. Dire che servono protocolli comuni, indicatori condivisi e baseline indipendenti non significa invocare una formula tecnica vaga. Significa chiedere una grammatica minima dell’osservazione.
Un protocollo comune stabilisce come osservare un rischio. Dice che cosa campionare, per quanto tempo, con quale granularità, distinguendo tra contenuti pubblicati, contenuti visti, contenuti raccomandati, contenuti cercati attivamente, contenuti sponsorizzati e contenuti rimossi o declassati. Senza un protocollo, due studi sullo stesso fenomeno possono raccogliere dati diversi, in finestre diverse, con definizioni diverse, producendo risultati non confrontabili.
Un indicatore condiviso stabilisce che cosa misurare. Per esempio: esposizione, reach, impression, frequenza di esposizione, posizione nel feed, quota di traffico generata da raccomandazioni, velocità di diffusione, attraversamento tra comunità, modularità della rete di esposizione, efficacia delle misure di mitigazione, tempo medio di rimozione o downranking. Senza indicatori condivisi, una piattaforma può dire di aver ridotto un rischio mentre un’altra usa una metrica diversa per descrivere un fenomeno simile.
Una baseline indipendente stabilisce rispetto a cosa interpretare una misura. Se una piattaforma dichiara che una misura ha ridotto la diffusione di un certo contenuto del 30 per cento, la domanda è: rispetto a cosa? Rispetto al mese precedente? A un gruppo di controllo? A un feed cronologico? A contenuti simili non trattati? A un’altra piattaforma nello stesso periodo? A una serie storica indipendente? Senza baseline, il numero può essere formalmente corretto e sostanzialmente poco informativo.
Esempi pratici
Prendiamo un rischio elettorale: l’amplificazione di contenuti polarizzanti o fuorvianti durante una campagna. Una piattaforma può dichiarare di aver applicato policy di integrità elettorale, ridotto la visibilità di contenuti borderline, aumentato il fact-checking e migliorato i sistemi di detection. È una risposta procedurale. Per renderla osservabile servirebbe altro: un protocollo di campionamento dei feed in periodo pre-elettorale, con distinzione tra contenuti seguiti, cercati, sponsorizzati e raccomandati; indicatori come quota di contenuti politici raccomandati, rapporto tra visibilità organica e visibilità algoritmica, velocità di diffusione dei contenuti smentiti, esposizione differenziale tra gruppi linguistici o territoriali; baseline come feed cronologici, dati storici di campagne precedenti, confronti tra piattaforme nello stesso periodo o account di audit controllati da ricercatori o autorità.
Lo stesso ragionamento vale per altri rischi sistemici. Nel caso della protezione dei minori, non basta sapere quanti contenuti siano stati rimossi: bisogna osservare traiettorie raccomandative, tempi di esposizione, efficacia dei filtri per età, ricomparsa di contenuti semanticamente simili dopo una rimozione o un downranking. Nel caso della disinformazione sanitaria, non basta contare post falsi: bisogna misurare claim, varianti linguistiche, reach, persistenza dopo il fact-checking, riesposizione degli stessi utenti e distanza tra esposizione al contenuto problematico ed esposizione alla correzione.
Questi esempi mostrano perché chiedere più dati è necessario ma incompleto. Il punto è sapere che cosa quei dati permettono di osservare.
Lo strato che trasforma i dati in conoscenza
In altri settori regolati, questo passaggio è evidente. Nella vigilanza bancaria, gli stress test non consistono nel chiedere a ogni banca di raccontare liberamente quanto sia solida. Esistono scenari macroeconomici comuni, metriche di capitale comparabili, esercizi simultanei e risultati leggibili in modo almeno parzialmente standardizzato. Nella farmacovigilanza, la raccolta degli eventi avversi non dipende solo da report volontari disomogenei: esistono protocolli di segnalazione, database condivisi, criteri causali e procedure di aggiornamento. Nel monitoraggio ambientale, gli indicatori non sono inventati caso per caso: metodi di campionamento, serie temporali e standard di misurazione rendono confrontabili territori, periodi e fonti diverse.
In nessuno di questi casi il regolatore si limita a chiedere dati ai regolati. Tra il dato grezzo e la decisione pubblica esiste uno strato intermedio: protocolli, indicatori, metodi, scenari, formati, criteri di replicabilità. È questo strato che trasforma l’accesso in conoscenza istituzionale.
Nello spazio delle piattaforme digitali questo livello è ancora incompleto. Esistono procedure di accesso, template di audit, proposte metodologiche per l’audit dei sistemi di raccomandazione, studi sul sampling, metriche interne delle piattaforme e primi tentativi di sistematizzazione. Ma non esiste ancora una infrastruttura comune che renda questi elementi cumulativi, confrontabili e verificabili.
Senza questo strato, i dati ottenuti attraverso l’Articolo 40 rischiano di non aggregarsi tra piattaforme diverse. Le serie temporali rischiano di non essere confrontabili. Gli studi indipendenti rischiano di restare isolati. I risk assessment ex Articolo 34 rischiano di non avere benchmark esterni. Gli audit rischiano di verificare procedure senza poter valutare pienamente l’efficacia sostanziale delle misure.
La domanda, allora, non è solo quali dati possano ottenere i ricercatori. È anche: chi definisce gli indicatori comuni? Chi stabilisce le metriche minime? Chi costruisce baseline indipendenti? Chi garantisce che le misure siano confrontabili nel tempo e tra piattaforme? Chi verifica che i data catalogues delle piattaforme rappresentino davvero l’universo dei dati rilevanti?
Il Board non basta a riempire questo spazio
A questo punto l’obiezione è naturale: uno strato di coordinamento esiste già. Il DSA prevede l’European Board of Digital Services, composto dai Digital Services Coordinator nazionali, con la Commissione nel ruolo di presidente senza diritto di voto. La Commissione e il Board possono contribuire all’analisi dei rischi sistemici, all’armonizzazione delle pratiche e alla circolazione di informazioni tra autorità.
Ma il Board è un organo di coordinamento tra regolatori. Non è, nella configurazione attuale, una infrastruttura tecnica di osservazione. Non definisce in modo sistematico protocolli standardizzati di campionamento, indicatori comuni, baseline indipendenti o serie storiche comparabili. Non dispone di una capacità autonoma di raccolta e verifica dei dati paragonabile a quella che, in altri settori, permette di trasformare obblighi di reporting in conoscenza regolatoria.
Il confronto con la vigilanza bancaria chiarisce la differenza. L’European Banking Authority non si limita a coordinare autorità nazionali: definisce metodologie, scenari di stress test, standard tecnici e formati comuni. Quando uno stress test viene condotto su un perimetro armonizzato di banche europee, gli istituti non scelgono liberamente lo scenario macroeconomico rispetto a cui valutarsi. Esiste uno scenario comune, definito esternamente, che rende confrontabili i risultati.
Nello spazio del DSA non esiste ancora un equivalente funzionale. Il Board è una cornice necessaria, ma non costruisce da solo la grammatica tecnica condivisa rispetto a cui i risk assessment dovrebbero essere valutati, i dataset richiesti dovrebbero essere strutturati e gli audit dovrebbero misurare l’adeguatezza delle misure.
Senza quella grammatica, anche un coordinamento perfetto tra autorità nazionali rischia di armonizzare letture parallele di documenti opachi, più che produrre osservazione indipendente.
Piattaforme come sistemi adattivi
C’è poi una differenza qualitativa rispetto ad altri settori regolati. Le piattaforme digitali sono sistemi adattivi.
Una banca può cambiare strategia, un farmaco può mostrare effetti inattesi, un ecosistema ambientale può evolvere. Ma una piattaforma modifica continuamente il proprio ambiente osservato: aggiorna i ranking, conduce test A/B su frazioni dell’utenza, adatta gli algoritmi di raccomandazione ai comportamenti degli utenti, riscrive le policy di moderazione, ridisegna le interfacce, ricalibra gli incentivi per creator e inserzionisti.
Questo significa che l’oggetto da misurare non è stabile. Non basta fotografarlo una volta. Inoltre, appena un indicatore diventa rilevante per la regolazione, può diventare esso stesso oggetto di ottimizzazione. È il problema noto come legge di Goodhart: quando un indicatore diventa un obiettivo, gli attori regolati imparano a migliorare l’indicatore, non necessariamente il fenomeno che l’indicatore doveva misurare. Se una piattaforma sa che sarà valutata su un certo indicatore, può migliorare quell’indicatore senza necessariamente ridurre il rischio sottostante.
Per questo l’osservazione episodica non basta. Servono serie storiche, campionamenti ricorrenti, confronti tra piattaforme, capacità di rilevare cambiamenti di regime e strumenti per aggiornare gli indicatori quando diventano obsoleti o manipolabili. L’osservabilità delle piattaforme non può essere pensata come un singolo accesso a un dataset. Deve assomigliare di più a un’infrastruttura continua di monitoraggio.
Questo non significa costruire un ministero della verità, né attribuire a un’autorità pubblica il compito di stabilire quali contenuti siano corretti. Il problema è diverso: misurare condizioni di visibilità, amplificazione, esposizione, segregazione, coordinazione e mitigazione. Non decidere che cosa i cittadini debbano pensare, ma capire come gli ambienti digitali distribuiscano attenzione, credibilità e opportunità di influenza.
Strumenti non sono capacità
Il DSA non ha sbagliato a costruire strumenti. Ha però lasciato implicita una premessa decisiva: che accesso ai dati, risk assessment, audit e coordinamento tra autorità potessero trasformarsi quasi automaticamente in osservabilità.
Ma una capacità pubblica di osservazione non nasce dalla somma di procedure. Nasce quando esistono metodi comuni per produrre, confrontare e verificare evidenza.
Questo livello non richiede necessariamente, almeno come primo passo, un nuovo grande ente. Richiede però funzioni stabili: definire formati minimi di dati, costruire indicatori di riferimento, verificare a campione i cataloghi dichiarati dalle piattaforme, mantenere serie storiche e tracciabilità delle metodologie usate negli studi precedenti. Non sostituirebbe la ricerca indipendente; la renderebbe cumulativa. Non replicherebbe la conoscenza interna delle piattaforme; la renderebbe verificabile.
Finché questo strato non verrà costruito esplicitamente, ogni nuovo ciclo del DSA produrrà report, audit, dossier e procedure. Non necessariamente conoscenza.
E in un sistema che si modifica più rapidamente di quanto venga osservato, la differenza tra produrre documenti e produrre conoscenza non è cosmetica. È la differenza tra governare le piattaforme e inseguirle, un ritardo che, come ho argomentato altrove, nei mercati digitali può consolidarsi prima che gli strumenti regolatori riescano anche solo a riconoscerlo.
