Metodologia

Che cos'è

Si tratta di un'aggregazione indipendente e non ufficiale di dati pubblici di report di trasparenza, senza alcuna affiliazione con piattaforme, aziende o governi. Riunisce due corpi di informazioni in un unico schema interrogabile:

• Report di trasparenza DSA dell'UE
  Statistiche periodiche di moderazione dei contenuti che i fornitori pubblicano ai sensi della Legge sui servizi digitali dell'UE (DSA) — i report di trasparenza ricorrenti richiesti dagli articoli 15, 24 e 42 del DSA (gli obblighi di comunicazione per i servizi intermediari, le piattaforme online e le piattaforme di dimensioni molto grandi, rispettivamente), non il distinto database di trasparenza del DSA in tempo reale delle singole motivazioni. I dichiaranti utilizzano un modello UE condiviso e scaglionato: ogni fornitore compila soltanto le sezioni di comunicazione che il suo livello richiede (questo set di dati indicizza internamente tali sezioni come t3–t11). Copre le piattaforme online e i motori di ricerca di dimensioni molto grandi (VLOP / VLOSE) — quelli che la Commissione europea ha formalmente designato per la loro portata nell'UE — che effettuano comunicazioni più frequentemente e in maggior dettaglio, insieme a decine di piattaforme più piccole. Consulta il pannello Report DSA per i conteggi in tempo reale e il periodo coperto.
• Richieste governative di rimozione di Google
  I conteggi pubblicati da Google delle richieste governative di rimozione di contenuti, per paese, prodotto, motivo e periodo di comunicazione — il report di trasparenza volontario e di lunga data di Google stesso, non una presentazione ai sensi del DSA. Esploralo nel pannello Rimozioni di Google.

Il luogo in cui ciascuna piattaforma pubblica il suo report sottostante è catalogato nella pagina Posizioni dei report, con collegamenti a copie archiviate dei file di origine.

Da dove provengono i dati

Ogni cifra proviene dalla piattaforma o dall'azienda che l'ha pubblicata — sono i loro numeri dichiarati, riprodotti senza alterare i valori comunicati, non stime prodotte da questo progetto. Il contributo qui è l'aggregazione e strutturazione: raccogliere i report pubblicati singolarmente, estrarne le tabelle e normalizzarle in un unico schema così da poterle confrontare e interrogare. I valori dichiarati in sé non vengono mai modificati; le trasformazioni sono strutturali — estrazione, marcatura delle righe dei totali aggregati, normalizzazione delle etichette tra le lingue e scarto delle righe che non possono essere analizzate — e sono descritte di seguito.

Come un report diventa interrogabile

Le tabelle di ciascun report di origine vengono estratte e caricate in un database che l'API apre in sola lettura (difesa in profondità) e a cui accede solo attraverso un'interfaccia in grado di leggere ma mai di scrivere, organizzato come uno schema a stella: una tabella di cifre per ciascuna tabella di report DSA (indicizzata internamente come t3–t11), circondata da tabelle di ricerca condivise (servizi, categorie, sezioni, indicatori, ambiti, superfici, periodi di comunicazione). Le etichette ripetute vengono memorizzate una sola volta e referenziate tramite un numero, così lo stesso nome di categoria o di piattaforma risiede in un unico luogo. Sfoglia le tabelle risultanti e ogni campo interrogabile nella pagina Schema.

Le nove tabelle di report si decodificano così: t3 ordini degli Stati membri · t4 notifiche (incl. segnalatori attendibili) · t5 / t6 azioni di propria iniziativa (contenuti illegali / condizioni del servizio) · t7 ricorsi e recidiva · t8 uso di strumenti automatizzati · t9 risorse umane · t10 destinatari attivi medi mensili · t11 descrizioni qualitative.

Quando un report non si adatta al modello

La maggior parte delle piattaforme consegna la cartella di lavoro fissa di 11 sezioni, e il caricatore colloca ciascun foglio in base al numero di sezione presente nel suo nome. Alcune presentano una variante di formato: lo stesso contenuto del modello sottostante, ma con i fogli rinominati o rinumerati. Questi vengono mappati tramite una tabella esplicita, per piattaforma, che collega ciascun foglio alla sua sezione canonica, così le cifre finiscono comunque nella tabella di report corretta: LINE condensa il modello in cinque fogli non numerati (mappati alle sezioni 1, 3, 4, 5 e 11), mentre Discord omette le sezioni di iniziativa propria sui contenuti illegali, delle risorse umane e dei destinatari attivi, e rinumera il resto — quindi i suoi fogli vengono identificati per nome (la sua “Own Initiative TC”, per esempio, è la tabella di iniziativa propria sulle condizioni del servizio, la sezione 6, non la sezione 5). Un documento che non è affatto il modello armonizzato non viene forzato in esso, perché mapparlo inventerebbe una struttura che la fonte non possiede: il report del forum di heise è una breve sintesi in formato libero ai sensi dell'articolo 15 con categorie di testo libero in tedesco, e WordPress.com pubblica un report diverso (richieste DMCA, governative e IRU). Questi vengono conservati come file di origine archiviati anziché caricati in t3–t11.

Come si evita il doppio conteggio

Il modello del DSA colloca una riga di totale aggregato proprio accanto alle righe di dettaglio che somma (per esempio una categoria di totale generale “All the entries” accanto ai conteggi per categoria, un ambito “Total number” accanto agli esiti confermati/ribaltati, o una superficie “All” che somma le righe per superficie come Core e Ads). Un SUM ingenuo su una colonna del genere conta le parti e il loro stesso totale, gonfiando la cifra. Il caricatore marca ogni riga aggregata con un indicatore is_total e la espone come dimensione filtrabile, così una query può scegliere deliberatamente un unico livello di dettaglio — solo i totali, o solo il dettaglio — e non sommare mai un totale insieme ai suoi componenti. Le cifre principali del pannello utilizzano i totali dichiarati; i suoi grafici di dettaglio utilizzano le righe dei componenti. Quando una cifra reca ancora una riserva, l'API restituisce una nota di warnings che il pannello mostra insieme al risultato.

Lettura tra le diverse lingue

Le piattaforme che non sono VLOP possono presentare il modello armonizzato in qualsiasi lingua ufficiale dell'UE, quindi la stessa riga del modello può arrivare come testo diverso (Decisions upheld / Décisions confirmées / Bestätigte Entscheidungen). Ogni riga conserva la sua etichetta nella lingua originale per la visualizzazione, ma le viene anche impressa un'etichetta standard neutra rispetto alla lingua — una chiave canonica — abbinata tramite una mappa di traduzione (una “tabella di corrispondenza”) che allinea report con la stessa struttura a un riferimento in inglese e scarta tutto ciò che è ambiguo. Le query possono raggruppare o filtrare in base alla chiave canonica per confrontare elementi equivalenti tra le lingue, mentre il testo originale continua a essere mostrato — anche se la copertura non è ancora uniforme in tutte le lingue (vedi Limitazioni note).

Come si interroga

Non esiste un'interfaccia SQL. Una query è una richiesta strutturata: nomina una tabella, un filtro booleano di condizioni campo/operazione/valore e, facoltativamente, raggruppamento, aggregati, ordinamento e limiti. Il server valida ogni campo e ogni operazione rispetto al registro fisso di quella tabella e li compila in un'unica ricerca nel database verificata in anticipo (un SELECT parametrizzato), dove ciò che inserisci viene sempre trattato come dato e mai eseguito come comando. Le query sono inoltre delimitate — una dimensione del risultato limitata, limiti di dimensione e di complessità della richiesta e un limite di frequenza per chiave — così una singola richiesta non può esaurire il servizio. Le query “composte” tra tabelle uniscono due o più tabelle su dimensioni condivise attraverso lo stesso confine validato. La casella “Chiedi” in linguaggio naturale, dove è abilitata, invia la tua domanda digitata (insieme allo schema del set di dati) a un LLM di terze parti (Claude, di Anthropic) affinché rediga una query strutturata, che viene poi validata come qualsiasi altra prima di essere eseguita — quella chiamata all'LLM è l'unica volta in cui il servizio invia di propria iniziativa ciò che inserisci a terzi. L'unica altra via in uscita è facoltativa e la indirizzi tu: una callback_url facoltativa che alleghi a una query e che consegna il tuo stesso risultato a un URL che scegli tu. Provalo nel pannello Report DSA, oppure leggi il riferimento dell'API e la nostra nota sulla Privacy.

Riproducibilità e citazione

Il database è un'istantanea statica e di sola lettura. Ogni istantanea reca una versione del set di dati immutabile — un'impronta del suo contenuto, quindi cambia ogni volta che cambiano i dati — inviata come intestazione ETag e X-Dataset-Version, e ogni riga di dati espone il report_id della presentazione che la origina. Una cifra è fissata da tre cose insieme — la versione del set di dati, la query esatta e il o i report_id da cui proviene — quindi cita tutte e tre e le righe potranno essere recuperate di nuovo (la versione e il report_id da soli identificano una presentazione di origine, non una cifra particolare). I risultati vengono restituiti in un ordine completamente deterministico ogni volta che ordini o pagini, così un'estrazione salvata è riproducibile byte per byte. La data di creazione dell'istantanea e il periodo coperto compaiono nella riga «Cita come» di ciascun pannello e nelle intestazioni di ogni esportazione, e il report_id di una riga identifica la sua presentazione di origine (piattaforma, periodo e livello); per le piattaforme non VLOP, dove tale presentazione è pubblicata è elencato per piattaforma nel catalogo Posizioni dei report.

Attribuzione: attribuisci la cifra alla piattaforma che l'ha dichiarata; cita questo sito solo come strumento di accesso.

Esempio: YouTube, EU DSA transparency report (H2 2025), accessed via the Transparency Report API — dataset version 7f3c1a2b9d04, report_id 42, retrieved 2026-06-26. La versione esatta del set di dati e il periodo coperto dell'istantanea in tempo reale compaiono nella riga “Cite as” dei pannelli Report DSA e Rimozioni di Google.

Limitazioni note

• Istantanea, non dati in tempo reale
  Le cifre riflettono i report disponibili quando è stata costruita l'istantanea; le correzioni successive o i report appena presentati compaiono solo in un'istantanea successiva (con una nuova versione del set di dati).
• La qualità delle fonti varia
  Le piattaforme presentano i loro report con rigore e formattazione differenti. Le righe spazzatura interpretate male (celle di intestazione, spazi vuoti, valori sparsi trapelati da alcune estrazioni) vengono scartate durante il caricamento anziché indovinate — così come le righe del modello che la tabella di corrispondenza tra le lingue non può mappare in modo inequivocabile. I conteggi esatti delle righe scartate e la copertura della tabella di corrispondenza non sono ancora pubblicati, quindi la completezza complessiva non è quantificata.
• Alcune etichette restano non normalizzate
  Le estrazioni in greco presentano uno spostamento di colonne nei dati di origine, quindi la maggior parte delle etichette greche di indicatore/ambito viene lasciata corretta ma non mappata anziché rischiare una mappatura errata; le etichette di categoria non sono ancora messe in corrispondenza tra le lingue.
• Servizio dimostrativo
  Questo è un progetto di portfolio/dimostrazione. È fedele alle sue fonti, ma non è un registro ufficiale: conferma sempre con il report pubblicato dalla piattaforma stessa (collegato da Posizioni dei report) per qualsiasi questione di rilievo.

Fonti e codice

Costruito interamente a partire da informazioni pubbliche. L'intera pipeline — estrazione, normalizzazione, la tabella di corrispondenza e il livello di query — è open source su github.com/krMaynard/transparency-report-api. Inizia a esplorare: Report DSA · Rimozioni di Google · Schema.