DPIA come genere, non come modulo

Il template EDPB è arrivato pubblicamente la settimana scorsa. L’ho aperto la prima volta sul treno tra Pescara e Roma, un PDF di una quarantina di pagine che mi sembrava di conoscere prima ancora di leggerlo, con quella particolare attenzione distratta che si riserva ai documenti di cui sai già tutto. La DPIA la frequento da anni, ne ho aiutate a scrivere decine, mi ero abituato a considerarla un oggetto stabile: un modulo, una checklist, un artefatto di compliance da consegnare al DPO e da archiviare. Aprendo il nuovo template avevo in mano una cosa familiare e leggermente alterata, come quando torni in un appartamento in cui hai vissuto da ragazzo e qualcuno ha spostato i mobili senza dirtelo. Qualcosa mi irritava e non riuscivo a dire cosa.

È stato solo qualche giorno dopo, leggendolo con calma sulla scrivania, che ho capito cosa mi stava infastidendo. Il template non era una versione più dettagliata del precedente. Era un’altra cosa. Non un formulario migliorato, non una griglia più fine: il documento che avevo in mano pretendeva qualcosa di diverso da chi lo compila, e in modo più sottile pretendeva qualcosa di diverso anche da chi lo legge. La DPIA stava smettendo di essere un modulo e stava diventando, per riprendere un termine che ho passato gli anni dell’università a rimuginare, un genere.

Cosa è arrivato, e cosa no

Vale la pena di precisare subito cosa è arrivato e cosa non è arrivato, perché la sfumatura fa differenza per tutto il resto del ragionamento. L’EDPB ha adottato il template in versione 1.0 per procedura scritta il 10 marzo, lo ha reso pubblico in aprile insieme a un explainer document che accompagna ciascuna sezione, e lo ha aperto a consultazione pubblica fino al 9 giugno. L’uso del template non è obbligatorio: i titolari possono continuare a usare le metodologie DPIA che preferiscono. Dopo la consultazione, e con le modifiche eventualmente introdotte, tutte le autorità nazionali di protezione dei dati avvieranno i passi per adottarlo come proprio standard o come meta-template a cui i modelli nazionali dovranno uniformarsi. Nulla è ancora chiuso, insomma, ma tutto sta prendendo forma; e la forma che sta prendendo è esattamente il cuore di ciò che voglio discutere qui.

So di dover argomentare contro l’intuizione comune. La gran parte delle persone che lavora con la DPIA la considera una scocciatura burocratica, un onere da smaltire, un pezzo di carta che il consulente legale compila e il cliente archivia. In Italia, dove la compliance ha a lungo mantenuto un profilo difensivo, la DPIA è spesso stata scritta per non essere letta, e letta per non essere discussa. La domanda «cosa ti serve davvero in una DPIA fatta bene» riceve in genere risposte pratiche: che sia completa, che copra i casi d’uso, che non contraddica altra documentazione, che sopravviva a un controllo dell’autorità. Sono risposte oneste. Sono anche, a mio avviso, risposte sbagliate, o meglio: sono le risposte che si darebbero se la DPIA fosse davvero un modulo. Ed è precisamente quello che, fino a qualche settimana fa, la DPIA era ancora, almeno in larga parte della pratica italiana. Un documento senza autore, nel senso più debole della parola: qualcuno lo firmava, certo, ma nessuno se ne prendeva la responsabilità in senso editoriale.

Un template non è un modulo

Ma qui arriviamo al punto. Un template non è un modulo. Un template, nel momento in cui viene proposto da un’autorità come l’EDPB con l’ambizione esplicita di diventare lo standard comune europeo, smette di essere uno strumento di compilazione e diventa qualcosa di più strano e più potente: la codificazione di una forma. E una forma non si compila. Una forma si scrive, e si scrive avendo ben presente di essere letti dentro attese specifiche, con un lessico, una struttura narrativa, un ritmo retorico che non sono intercambiabili con altri. Questo, in poche parole, è un genere.

Per capire perché il passaggio sia importante, serve fare un passo indietro e guardare il percorso con cui la DPIA è arrivata dove è arrivata. Esiste formalmente dal 2018, prevista dall’articolo 35 del GDPR come valutazione obbligatoria nei casi di trattamento ad alto rischio. Nei primi anni è stata gestita come poteva essere gestita: ciascuna organizzazione, ciascuno studio legale, ciascun DPO ha prodotto la sua versione, con una variabilità che chi ha lavorato cross-settore conosce bene. Alcune DPIA erano documenti di cinque pagine che sembravano un verbale di riunione; altre erano tomi di cento pagine che sembravano tesi di dottorato. Alcune erano compilate con matrici di rischio numeriche ereditate da framework di sicurezza, altre con prosa giuridica fitta di rimandi normativi, altre ancora con approcci ibridi che mescolavano le due culture senza riuscire a farle convivere del tutto. La Commissione aveva suggerito alcuni schemi, il Working Party 29 prima e l’EDPB poi avevano pubblicato linee guida, alcune autorità nazionali avevano messo a disposizione modelli più strutturati, ma il panorama restava frammentato. La DPIA stava in quello stato di cosa giovane in cui le forme non sono ancora decantate, in cui ciascuno prova la sua strada e poche di queste strade si incontrano. Le autorità di controllo europee si erano lamentate ripetutamente di questa eterogeneità, che rendeva difficile costruire una giurisprudenza implicita condivisa, quella giurisprudenza non scritta che in ogni settore maturo si costruisce leggendo centinaia di documenti prodotti secondo una forma riconoscibile.

Quando una forma prende corpo

Il template EDPB apre la chiusura di questa fase. Non con l’autorità formale di un regolamento vincolante, che non è, ma con qualcosa di simile all’autorità che una grammatica normativa esercita su una lingua viva: indica, orienta, crea un centro di gravità. Da ora in poi, chi scrive una DPIA in Europa sa che esiste una forma proposta a livello sovranazionale, e sa che quando il processo di consultazione si chiuderà e le autorità nazionali avranno fatto i loro passi di adozione, ogni deviazione da quella forma andrà giustificata. Questo è esattamente, nella storia delle lingue e dei generi letterari, il movimento con cui una forma prende corpo. Prima di Dante il volgare fiorentino era uno dei tanti volgari italiani; dopo Dante ogni uso del volgare fiorentino si misurava su di lui, anche quando se ne voleva allontanare. L’accostamento a Dante è sproporzionato rispetto a un template burocratico, e lo so. Lo lascio comunque perché la meccanica è la stessa, anche se le altezze sono ovviamente incomparabili. Quando un’autorità propone una forma e tutte le autorità sottostanti annunciano che la adotteranno, quella forma smette di essere una possibilità tra le tante e diventa lo sfondo su cui tutte le altre si ritagliano.

Architesto e autoinquisizione

Gli studiosi di letteratura chiamano questo fenomeno la stabilizzazione di un architesto, termine che devo a Genette ma che girava già in Bachtin sotto il nome di generi del discorso secondari. L’architesto non è un’opera singola: è l’insieme delle attese formali che un lettore porta con sé quando apre un certo tipo di documento. Quando apro un giallo so che ci sarà un delitto da risolvere, quando apro un articolo scientifico so che ci sarà una sezione metodologica, quando apro un sonetto conto le righe prima ancora di leggerle. Un architesto stabilizzato produce attese stabilizzate. E produce, inevitabilmente, una forma di scrittura che sa di essere letta dentro quelle attese. Hans Robert Jauss, a partire dal 1970, chiamava orizzonte d’attesa questa postura del lettore che incontra un testo dentro una cornice di genere già nota. Ogni testo, per Jauss, si legge sempre due volte: una contro la cornice che il lettore porta con sé, una rimodellando quella cornice in base a ciò che il testo effettivamente dice. Una DPIA scritta dentro il template EDPB, quando sarà diventato lo standard di riferimento, verrà letta così: l’auditor o l’ispettore saprà già cosa cercare, saprà in quale sezione aspettarsi cosa, saprà riconoscere immediatamente quando il testo si discosta dalla forma attesa, e in base a quella deviazione si costruirà un giudizio.

C’è un secondo filone teorico che vorrei richiamare, perché illumina il punto in una direzione diversa. Carlo Ginzburg, nei suoi lavori sui processi inquisitoriali friulani del Cinquecento e del Seicento, ha mostrato come i verbali di quei processi fossero un vero genere documentale, con convenzioni retoriche precise, un rapporto codificato tra interrogante e interrogato, una gestione particolare della voce tra discorso diretto e discorso indiretto, una struttura narrativa che traduceva la voce dell’imputato nella cornice processuale dell’inquisitore. Ginzburg leggeva quei verbali come testi, non come pure trascrizioni, e in quella lettura trovava le tracce di una soggettività popolare altrimenti invisibile. Al di là del confronto storico, c’è un’analogia strutturale che mi colpisce da quando rifletto sulla DPIA. La DPIA è, nella sua architettura profonda, un documento auto-inquisitoriale: il titolare del trattamento interroga sé stesso sul proprio operato, ricostruisce le ragioni delle proprie scelte, argomenta di fronte a un lettore assente ma minaccioso (l’autorità) perché quelle scelte sono adeguate. È una forma di discorso che espone la propria razionalità per esserne giudicata. Il fatto che ora abbia un template destinato a diventare genere codificato significa, tra le altre cose, che questa autoinquisizione sta per avere una grammatica. E le grammatiche, come sanno tutti quelli che le hanno studiate sul serio, non sono strumenti neutri: modellano quello che può essere detto, e indirettamente quello che può essere pensato.

La finestra del canone

Chi scrive una DPIA nei prossimi mesi si trova in una condizione particolare, che è diversa sia da quella del pioniere sia da quella del compilatore dentro un genere maturo. Il template è sul tavolo ma non è ancora standard, la consultazione è aperta, le autorità nazionali stanno preparando i propri passi di recepimento. Chi scrive una DPIA in questa finestra sta scrivendo dentro una forma in corso di stabilizzazione, il che significa due cose. La prima è che non può più comportarsi come un pioniere: il template è disponibile, le sue sezioni sono chiare, il suo metodo è pubblico, ignorarlo sarebbe un gesto deliberato e andrebbe motivato. La seconda, meno ovvia, è che ha un’opportunità che chi scriverà fra due anni non avrà più: quella di contribuire, con la propria pratica, a definire cosa significherà «scrivere bene» dentro questo genere. Ogni DPIA prodotta adesso che si confronta seriamente con il template, che lo usa come struttura, che ne segnala i limiti, contribuisce alla formazione del canone. Nei generi stabilizzati il canone esiste già; nei generi in formazione il canone si fa scrivendolo. Per chi fa il nostro mestiere, vale la pena di esserci proprio in questa finestra.

Dal formulario alla prosa

Mi si potrebbe obiettare che sto romanticizzando una cosa che è soltanto un formulario più lungo. L’obiezione è seria e merita di essere presa sul serio. Se la DPIA fosse soltanto un formulario più lungo, allora la sua evoluzione sarebbe irrilevante al di fuori del perimetro stretto della compliance: un’altra griglia da riempire, un altro tipo di PDF da archiviare, un altro costo marginale per chi tratta dati. Ma c’è un dettaglio del nuovo template che, una volta notato, smonta questa lettura. Il template non chiede più soltanto di elencare. Chiede di argomentare. Chiede, in particolare, di motivare la proporzionalità delle scelte, di ricostruire il ragionamento che porta da una valutazione del rischio a una misura di mitigazione, di mostrare perché un certo bilanciamento tra utilità e rischio residuo è accettabile. Chiede, insomma, una cosa che un formulario non può chiedere: chiede prosa.

La comparsa della prosa in un documento di compliance è il sintomo più chiaro del passaggio a genere. Un modulo non ha bisogno di prosa, perché il suo valore informativo è interamente contenuto nella griglia. Un genere, invece, vive nella prosa, perché è nella prosa che si esprimono le connessioni tra i fatti, le gerarchie di importanza, le giustificazioni, le sfumature. Quando il template EDPB chiede di scrivere perché la base giuridica scelta è adeguata al contesto del trattamento, sta chiedendo un piccolo saggio. Il contenuto di quel saggio avrà dei vincoli formali, ma resta un saggio. E chi scrive un saggio, anche un saggio di trecento parole in una casella di un PDF, scrive diversamente da chi compila una casella di un foglio Excel. La prosa costringe a scegliere un punto di vista, a decidere cosa mettere prima e cosa dopo, a mostrare quali informazioni siano accessorie e quali centrali. La griglia, per sua natura, appiattisce queste gerarchie. Il passaggio dalla griglia alla prosa non è un passaggio di pura forma; è un passaggio di epistemologia locale, di cosa un certo testo può raccontare e cosa non può raccontare.

I molti lettori di una DPIA

Un aspetto sottovalutato, e che vorrei portare alla luce, riguarda chi legge una DPIA. Nella pratica corrente si pensa quasi sempre a un lettore solo, anzi a un lettore ipotetico e poco caratterizzato: l’ispettore di un’autorità di controllo, figura un po’ astratta, con cui in realtà la gran parte delle DPIA non si confronterà mai. Ma un documento di genere ha sempre più lettori reali di quanti ne dichiari, e la DPIA non fa eccezione. La legge il committente pubblico che valuta il fornitore. La legge il compliance officer che fa due diligence in un’acquisizione. La legge l’avvocato che prepara la difesa in un contenzioso. La legge, se ben scritta e se resa accessibile, l’interessato che vuole capire come vengono trattati i suoi dati. La legge, in un contesto sempre più frequente, il fornitore di tecnologia a monte che deve verificare se il proprio ruolo di responsabile del trattamento è stato correttamente perimetrato. Ciascuno di questi lettori porta con sé un orizzonte d’attesa diverso, e il fatto che il template EDPB stia stabilizzando la forma aiuta tutti loro allo stesso tempo: un lettore disciplinato sa dove cercare, sa riconoscere quello che cerca, sa distinguere il testo ben fatto da quello abborracciato. Un modulo è in fondo opaco a qualsiasi lettore esterno al suo compilatore. Un genere, invece, ha il pregio democratizzante di essere leggibile da chiunque ne conosca le convenzioni.

DPIA-as-code

Torno per un momento all’esperienza di Oltrematica degli ultimi mesi, perché è stata proprio la quotidianità con certi progetti a farmi capire cosa stesse cambiando. Abbiamo in corso lavori su piattaforme sanitarie per la Regione Abruzzo, su sistemi di people analytics in ambito ospedaliero, su applicativi per la pubblica amministrazione locale, su piattaforme di formazione online con certificazioni ECM, su sistemi di gestione della sosta per municipalizzate. In tutti questi casi abbiamo, o avremo, una DPIA. Fino a un anno fa l’approccio tipico era: fissiamo una call con il DPO del cliente, raccogliamo le informazioni, produciamo un draft, lo rivediamo insieme, lo mettiamo a repository. Il documento era sostanzialmente chiuso alla fine del processo. Si aggiornava al cambiare del trattamento, con un ciclo di revisione annuale o biennale. Era, chiaramente, un modulo. La cosa interessante è che anche internamente al team tecnico trattavamo la DPIA come un modulo: la consideravamo qualcosa che il DPO produceva per noi, non con noi, e che ci riguardava solo se un auditor ci chiedeva di confermare uno dei suoi contenuti.

Quando ho letto il nuovo template, la prima cosa che ho fatto è stata scrivere un memo interno su cosa sarebbe cambiato operativamente. La seconda cosa, meno immediata, è stata buttare giù una proposta che ho chiamato per brevità DPIA-as-code: portare la DPIA dentro il flusso di versionamento dei progetti, integrarla con Jira e Confluence, renderla un artefatto che vive nello stesso ecosistema in cui vive il codice. Non è un’idea rivoluzionaria. Altri ci stavano già pensando, in particolare in ambienti dove la compliance si è storicamente intrecciata con l’ingegneria del software, penso ad alcuni team security nel mondo cloud-native statunitense. Ma il motivo per cui è diventata una proposta sensata proprio ora, e non due anni fa, è esattamente quello di cui sto scrivendo: solo quando un documento sta diventando un genere, e non più un modulo, ha senso versionarlo come versioneresti un capitolo di un libro. Un modulo lo aggiorni con un nuovo modulo; un capitolo lo revisioni con tracciabilità genetica, con attenzione alle varianti, con un archivio delle decisioni che ti permette di tornare sui tuoi passi e capire perché, un anno fa, avevi scelto una certa formulazione piuttosto che un’altra.

I progetti su cui questa trasformazione si sta rivelando più interessante sono quelli in cui il profilo di rischio evolve insieme al prodotto. Una piattaforma di people analytics come quella che sviluppiamo in partnership con Umana Analytics ha un ciclo in cui ogni nuova feature tocca potenzialmente dati sensibili, e ogni modifica ai modelli predittivi ridefinisce i contorni del trattamento. Una DPIA-modulo qui invecchia molto in fretta: la scrivi, la archivi, la rileggi a un anno di distanza e scopri che il suo paragrafo centrale non descrive più fedelmente cosa il prodotto sta facendo. Una DPIA-genere versionata, invece, segue il prodotto. Ogni pull request che tocca il perimetro del trattamento apre una corrispondente discussione sul paragrafo pertinente, che può restare invariato oppure essere aggiornato con un diff che spiega cosa è cambiato e perché. La piattaforma sanitaria per la Regione Abruzzo su cui lavoriamo da anni, con il suo flusso di dati verso un’anagrafica regionale e verso i sistemi nazionali di rilevazione, è un caso ancora più chiaro, perché ogni cambio normativo a monte impone una rilettura del trattamento, e senza una DPIA versionata quella rilettura rischia di perdere il filo delle motivazioni originali. Con una DPIA versionata, invece, puoi partire dal presente e risalire, decisione per decisione, fino al punto in cui il trattamento è stato definito, leggendo insieme al testo le discussioni che lo hanno accompagnato. Un caso ancora diverso è la piattaforma di formazione online che gestiamo per enti che erogano ECM, dove la DPIA deve rendere conto di un trattamento relativamente stabile ma di un pubblico di utenti molto vasto e di una filiera di sub-responsabili articolata. Qui il valore di una DPIA versionata è soprattutto nel mantenere allineata la catena di responsabilità man mano che i fornitori cambiano, e ogni aggiornamento di un fornitore diventa un commit sulla sezione pertinente, con una coerenza che un modulo archiviato una volta all’anno non può avere.

Filologia d’autore, e il git log

Qui diventa importante chiedersi cosa voglia dire, davvero, versionare un genere. La critica letteraria ha una tradizione consolidata su questo: quella che in Italia chiamiamo filologia d’autore, o critica delle varianti, associata per il Novecento ai nomi di Contini e di Isella, e che in Francia ha preso il nome di critique génétique, con figure come Bellemin-Noël e Pierre-Marc de Biasi. Studia come un testo è cresciuto nel tempo, quali varianti sono state adottate e scartate, quali pressioni esterne hanno modificato la forma, quali riscritture sono state indotte da revisori, committenti, autocensure. Il git log di una DPIA versionata è, banalmente, un avant-texte in tempo reale. Mostra quando una misura di mitigazione è stata rafforzata, chi l’ha proposta, in risposta a quale segnalazione, con quali alternative considerate e scartate. Produce, come effetto collaterale, un livello di tracciabilità che nessuna DPIA-modulo ha mai avuto, perché il modulo nasconde la sua storia nella sua versione finale, mentre il genere la esibisce. E la esibisce non per narcisismo archivistico, ma perché in un genere maturo la storia delle scelte è parte dell’argomentazione corrente. Un auditor che sa leggere un git log riesce a capire, senza chiedere conferma a nessuno, se una certa misura è stata implementata in risposta a un’analisi del rischio reale o invece ritagliata a posteriori per giustificare una scelta già presa. La genealogia di un testo è un controllo di qualità molto più efficace di qualsiasi firma in calce.

Lavorare dentro questo quadro cambia, in modo che nella mia esperienza si rivela progressivo, alcune dimensioni operative. La prima riguarda la separazione tra la fonte e la resa. Una DPIA-modulo vive nel suo file PDF finale, con tutti i problemi di disallineamento che questo comporta: modifichi la DPIA e poi scopri che la scheda del trattamento in un altro documento dice una cosa diversa, oppure che l’abstract per la direzione è rimasto fermo alla versione di sei mesi prima. Una DPIA-genere vive in una sorgente strutturata, nel nostro caso Confluence con alcune pagine chiave marcate per la pipeline di export, da cui si generano le rese destinate ai diversi lettori. La stessa sorgente produce la DPIA completa per il DPO, un abstract esecutivo per la direzione, una scheda tecnica di mitigazioni per il team di sviluppo, eventualmente anche una versione sintetica per gli interessati qualora il titolare scelga di renderla accessibile. I contenuti sono gli stessi, la forma si adatta. Questo richiede, alla fonte, una disciplina di scrittura più rigorosa di quanto la DPIA-modulo pretendesse, perché ogni paragrafo deve essere pensato per sopravvivere a usi multipli. In cambio, riduce drasticamente la cosa che in compliance fa più danno di qualsiasi altra, cioè la proliferazione di versioni non allineate dello stesso trattamento in documenti diversi.

La seconda dimensione riguarda il collegamento con il ticketing di progetto. In ogni nostro lavoro, un’epic o una storia di Jira che tocca un nuovo trattamento di dati personali, o ne modifica uno esistente, apre una richiesta formale di aggiornamento della DPIA corrispondente. Non necessariamente un aggiornamento pieno; anche una verifica di non-impatto è sufficiente, purché sia registrata. Il collegamento rende esplicito quello che nel mondo DPIA-modulo era implicito, e quindi dimenticato: ogni scelta di prodotto è una scelta di compliance, ogni feature che tocca dati è una potenziale modifica al trattamento documentato. Legare il ticket al paragrafo di DPIA significa, in pratica, imporre che il prodotto e il suo atto di scrittura procedano allineati. Il git log diventa una storia genetica del trattamento; la cronologia di Jira diventa la cronologia delle sue motivazioni. Per un team abituato a pensare la compliance come un’attività satellitare rispetto allo sviluppo è un cambio di postura non banale, e va accompagnato. Nei primi mesi abbiamo avuto resistenze da sviluppatori che vedevano l’aggancio Jira-Confluence come burocrazia aggiuntiva; dopo sei mesi, la maggior parte lo considera un aiuto, perché riduce le riunioni di allineamento e rende visibile il contributo tecnico alla costruzione della compliance.

Il DPO come editor

La dimensione più delicata riguarda i ruoli. In un modello DPIA-modulo il DPO è tipicamente l’autore principale o il revisore finale, e il team tecnico è un fornitore di informazioni. In un modello DPIA-genere, questa geometria si ribalta parzialmente. Il DPO resta responsabile della conformità, ma diventa più propriamente un editor: stabilisce standard, rivede contributi, garantisce coerenza tra sezioni, richiede riscritture. Chi scrive il primo draft di molte sezioni è chi conosce la materia, cioè il product owner, l’architetto, lo sviluppatore che ha disegnato il data model, il DBA che ha impostato la politica di retention. Il documento finale resta firmato dal DPO e dal titolare, ma il tessuto del testo è tessuto da più mani. È una cosa che chi ha lavorato in redazione riconosce immediatamente, e che chi ha lavorato solo in compliance trova disorientante. Eppure mi sembra, dopo sei mesi di esperimenti, la configurazione più sana.

So che sto introducendo una tensione. Un DPO che diventa editor rischia di perdere in autorità formale quello che guadagna in qualità del prodotto. Nella tradizione italiana, dove la figura del DPO è spesso giuridica e spesso esterna all’organizzazione, la proposta di un DPO-editor può suonare come un indebolimento. Credo invece che sia un rafforzamento, per una ragione sottile ma importante. L’autorità di un editor non è l’autorità di chi produce il testo da solo; è l’autorità di chi decide cosa passa e cosa no. Un DPO che scrive tutto da solo può produrre una DPIA formalmente inattaccabile ma distante dalla realtà operativa del trattamento. Un DPO che edita ciò che il team scrive resta nella posizione finale di dire no, ma lo fa su materiale che ha la presa dei fatti. Il risultato è, nella mia esperienza, più difficile da attaccare e più facile da difendere in caso di ispezione.

Leggibilità non è semplicità

Qui arriviamo alla seconda obiezione seria che voglio affrontare, che è stata sollevata in diversi confronti interni negli ultimi mesi. Si potrebbe dire: questo riconoscimento della DPIA come genere non è un progresso, è una sofisticazione inutile, una barocchizzazione della compliance che aggiunge oneri senza aggiungere valore. L’Europa, si dirà, già soffre di inflazione normativa; trasformare la DPIA in un prodotto letterario, per quanto tecnico-letterario, significa aggravare un problema senza risolverlo. Capisco l’obiezione, ma credo sia sbagliata per una ragione specifica. I generi non complicano i testi; li rendono leggibili. L’alternativa a un genere stabilizzato non è un testo più semplice, è un testo più difficile da leggere, perché manca la griglia che permette al lettore di orientarsi. Quando uno stesso documento arriva sul tavolo di un’autorità di controllo in dieci forme diverse, scritte da dieci autori che hanno deciso ciascuno la propria struttura, il lavoro di lettura diventa lentissimo e sconta un margine di errore alto. Quando il genere è stabilizzato, l’autorità può leggere cento DPIA con lo stesso sforzo con cui un critico esperto legge cento romanzi, cioè riconoscendo rapidamente dove cercare cosa, e accorgendosi altrettanto rapidamente delle deviazioni significative.

Leggibilità, in questo senso, non è sinonimo di semplicità. Un sonetto è più difficile di un post su un social, ma è immensamente più leggibile per chi conosce il genere, perché sa dove cercare la volta argomentativa, il concetto centrale, la chiusura. Allo stesso modo, una DPIA ben scritta nel nuovo formato sarà più esigente nel dettaglio ma più rapida da leggere per un auditor che conosce il template. E sarà, soprattutto, comparabile con altre DPIA scritte nella stessa forma. La comparabilità è il beneficio invisibile dei generi stabilizzati, e sarà, a mio parere, il guadagno più importante degli anni che vengono per le autorità di protezione dei dati. Fino a oggi ogni ispezione partiva dal leggere un documento come se fosse il primo della sua specie, ricostruendone la forma insieme ai contenuti. Quando il nuovo template sarà lo standard, il confronto tra cento DPIA di cento titolari diversi diventerà un’operazione praticabile, perché la forma sarà condivisa e le differenze saranno informative.

C’è un corollario di questa comparabilità che riguarda in modo specifico chi lavora con il committente pubblico, e che voglio sviluppare perché è la parte del nostro portafoglio che sta cambiando più in fretta. Nelle procedure di affidamento e nei capitolati tecnici, la DPIA (o la documentazione di impatto equivalente) è stata spesso richiesta come allegato generico, senza troppe specifiche sul come. L’amministrazione verificava che il documento esistesse, lasciando alla sostanza una revisione di solito tardiva, spesso in fase di esecuzione contrattuale. Con un genere stabilizzato, le stazioni appaltanti avranno la possibilità di fare una cosa diversa e, dal punto di vista di chi compete, molto più esigente: valutare la qualità del documento come criterio di selezione. Una DPIA scritta dentro il template EDPB potrà essere punteggiata in modo consistente, confrontata con quelle dei concorrenti, usata come indicatore del livello di maturità di compliance dell’offerente. Per un fornitore che ha investito nella scrittura come pratica, questo sarà un vantaggio netto, perché trasforma un allegato rituale in uno strumento di differenziazione. Per un fornitore che ha sempre trattato la DPIA come un onere amministrativo da delegare all’ultimo momento, sarà un rischio crescente, perché la distanza tra un documento ben scritto e uno abborracciato diventerà evidente a chiunque legga il template. Nei nostri ambiti specifici, dalla sanità regionale agli enti camerali ai comuni, credo che nei prossimi due anni vedremo esattamente questo tipo di selezione comparsa nei criteri di aggiudicazione: un segnale che il genere è entrato nella contrattualistica pubblica non più come casella di spunta ma come oggetto di lettura vera.

Il sospetto degli LLM

C’è una terza obiezione che va affrontata, anche se richiede una digressione, e che mi è stata formulata da persone molto vicine alla nostra realtà tecnica. Se la DPIA sta diventando un documento di prosa argomentata, si dice, allora è esattamente il tipo di testo che un modello linguistico di grandi dimensioni può produrre bene, e in pochi minuti. Perché preoccuparsi di tutto questo discorso sulla scrittura, sulla filologia d’autore, sui ruoli editoriali, quando basta un buon prompt e un paio di iterazioni per avere una DPIA formalmente impeccabile? È una domanda legittima e me la sono posta anch’io, avendo lavorato con intensità in questi mesi sugli strumenti AI-native di sviluppo. La risposta breve è che questa obiezione confonde due cose diverse, e la confusione è pericolosa. Un LLM può produrre, effettivamente, un testo che sembra una DPIA e che nella gran parte dei casi supererà una verifica formale superficiale. Ma una DPIA non è solo il suo testo finale; è la traccia documentale di un processo di decisione. Le sue sezioni non sono uno sfoggio retorico autonomo, sono la restituzione di conversazioni reali avvenute tra persone reali su trattamenti reali. Un LLM può aiutarmi a scrivere meglio quelle restituzioni, a dare ritmo al testo, a suggerire formulazioni più efficaci, e lo fa. Non può sostituire le conversazioni che stanno a monte del testo, perché quelle conversazioni sono esattamente ciò di cui la DPIA deve rendere conto. Una DPIA prodotta da LLM senza quelle conversazioni a monte è un simulacro, e la differenza con il genuino si vede presto, soprattutto quando arriva il momento di difenderla davanti a qualcuno che fa domande precise. Il genere, qui, protegge chi lo pratica onestamente e smaschera chi lo finge, perché la profondità di una DPIA ben scritta è inseparabile dalla profondità della riflessione che l’ha prodotta. Questo, tra parentesi, è un punto che la cultura dell’AI-native development sta imparando in ogni dominio in cui si spinge: gli strumenti automatici sono eccellenti amplificatori di pensiero, ma non sostitutivi di pensiero. Ed è proprio nei generi maturi che la differenza tra le due cose si vede meglio.

Un ecosistema di generi tecnico-normativi

C’è un punto correlato che merita un cenno, anche se meriterebbe un pezzo a parte. La DPIA-genere, proprio perché vive nello stesso ecosistema del prodotto, si presta a integrazioni che la DPIA-modulo non poteva avere. Penso in particolare al nesso con l’SBOM, il software bill of materials, che sta diventando un requisito sempre più formalizzato in ambito Cyber Resilience Act. Le due documentazioni, SBOM e DPIA, hanno storie separate e logiche diverse, ma parlano della stessa piattaforma. Quando entrambe vivono versionate e interrogabili, diventa possibile cose come: identificare quali componenti software sono coinvolti nel trattamento dei dati sensibili descritto nella sezione X della DPIA, o segnalare quando un aggiornamento di dipendenza introduce un componente che cambia il profilo di rischio documentato. Uno sviluppatore che aggiorna una libreria di logging, per dirne una, può ricevere automaticamente un alert che gli dice: «questa libreria è referenziata nella DPIA del progetto Y, paragrafo 4.2, verifica se la nuova versione modifica il comportamento descritto». Sono scenari che, in un’ottica di prodotto integrato, restano fantascientifici; in un’ottica di compliance integrata diventano, se non facili, almeno pensabili. E il motivo per cui diventano pensabili è, ancora una volta, che la DPIA sta diventando un testo governato da convenzioni note, navigabile come si naviga un testo, e non una griglia opaca al mondo esterno.

Il nesso tra SBOM e DPIA, peraltro, è il punto in cui mi accorgo che il discorso che sto facendo ha implicazioni più ampie della DPIA stessa. Se la DPIA si sta trasformando in genere, è ragionevole chiedersi se altri artefatti della compliance europea stiano subendo la stessa trasformazione, e in che direzione. Mi sembra evidente, per fare un esempio, che anche il fascicolo tecnico dell’AI Act sia in traiettoria verso un’identità di genere, con le sue sezioni canoniche, il suo ritmo argomentativo, la sua pretesa di leggibilità da parte di un’autorità di mercato. Lo stesso vale, a un livello diverso, per la documentazione di vulnerabilità e per le policy di disclosure che il Cyber Resilience Act sta stabilizzando nel corso dell’anno, con le obbligazioni di reporting che entreranno in vigore a settembre 2026 e le obbligazioni sostanziali piene da dicembre 2027. Stiamo assistendo, in Europa, a una decennale operazione di generazione di generi tecnico-normativi, che avrà conseguenze ancora in buona parte inesplorate sul lavoro di chi produce software. Dieci anni fa la compliance software era una costellazione di moduli. Fra dieci anni sarà, con ogni probabilità, una biblioteca di generi, ciascuno con i suoi canoni, i suoi esemplari di riferimento, la sua critica consolidata, la sua scuola di autori.

Questa prospettiva, che può sembrare astratta, ha un risvolto commerciale concreto di cui credo si parli ancora troppo poco. Un’impresa che ha imparato a scrivere dentro generi normativi maturi ha un vantaggio competitivo sostanziale rispetto a un’impresa che ogni volta deve imparare daccapo. E imparare a scrivere dentro un genere non è una cosa che si fa in un corso di una settimana: richiede pratica, correzione, esposizione a buoni e cattivi esemplari, critica tra pari, esperienza progressiva di quale formulazione tiene e quale no. L’Europa sta costruendo, con tempi e modi non sempre coordinati, un ecosistema di generi tecnico-normativi che premierà le organizzazioni capaci di fare di questa scrittura una competenza stabile. Per chi fa il nostro mestiere, il software per la pubblica amministrazione e per la sanità, questo significa che il prossimo quinquennio non sarà vinto da chi scrive codice più elegante ma da chi scrive documenti di compliance migliori, intendendo per migliori non più dettagliati ma più leggibili, più argomentati, più capaci di sostenere un confronto con lettori competenti. È un cambio di paradigma che attraversa trasversalmente le nostre organizzazioni e ridefinisce quali competenze siano scarse e quali no.

Torno allora alla DPIA, con un’osservazione che spero non suoni troppo astratta. Il fatto che un modulo si stia trasformando in genere è una di quelle cose che, una volta avvenuta, cambia retrospettivamente il modo in cui leggiamo la storia precedente. Le DPIA scritte negli anni tra il 2018 e il 2025 erano già in qualche misura genere, perché esistevano attese di lettura, perché circolavano esemplari considerati buoni o cattivi, perché le autorità cominciavano a costruire una giurisprudenza implicita di cosa volesse dire una DPIA fatta bene. Era un genere in formazione, fluido, con confini incerti. Il template EDPB, una volta chiusa la consultazione e avviati i passi di adozione nazionali, fisserà quei confini, cristallizzerà quel genere, e nel farlo renderà retroattivamente visibile una traiettoria che prima era ambigua. Da quel momento in poi, la DPIA avrà un prima e un dopo, e la differenza tra i due non sarà una questione di dettaglio ma di natura. La finestra in cui scriviamo adesso è esattamente il momento in cui questo passaggio si compie: non è più prima, non è ancora del tutto dopo, è la soglia.

Cosa fare domani mattina

Mi rendo conto che tutto questo discorso può suonare, a un ingegnere pragmatico, come un’astrazione filosofica inutile. A cosa mi serve, nel lavoro concreto di domani, sapere che la DPIA sta diventando un genere? La risposta pratica l’ho già distribuita nei paragrafi precedenti, ma vale la pena ricomporla in una forma più vicina a ciò che un team deve fare quando apre il prossimo progetto. Bisogna smettere di trattare la DPIA come un documento di chiusura, prodotto a valle della progettazione, e cominciare a trattarla come un documento di accompagnamento, che nasce con il progetto e cresce con lui. Bisogna accettare che le persone che contribuiscono alla DPIA non sono più soltanto il legale e il DPO, ma anche chi costruisce il prodotto, e questo richiede un investimento, piccolo ma costante, nella loro capacità di scrivere testi argomentati. Bisogna introdurre nei processi di sviluppo i collegamenti, tecnici e organizzativi, tra i ticket di progetto e i paragrafi di DPIA, in modo che la scrittura non resti un’attività parallela ma diventi parte del lavoro corrente. Bisogna ripensare il ruolo del DPO come editor più che come redattore unico, con tutto quello che questo comporta in termini di relazione con il resto del team. Nessuno di questi cambi è drammatico preso singolarmente. Messi insieme ridisegnano il modo in cui la compliance dati si fa, e fanno emergere la differenza tra organizzazioni che hanno capito il passaggio e organizzazioni che continueranno a produrre moduli in un mondo che legge generi.

C’è poi una cosa che voglio segnalare a chi, come noi, sta operando proprio in questa finestra di formazione del genere. La consultazione pubblica aperta dall’EDPB non è un adempimento formale che riguarda solo gli addetti ai lavori della protezione dei dati: è il momento in cui il template viene ancora modellato, ed è quindi il momento in cui una voce informata può lasciare un segno. Un fornitore di software per la PA italiana che manda un contributo ragionato, riferito all’esperienza concreta di scrivere DPIA per enti pubblici, partecipa alla definizione del genere più di quanto immagini. Non è un gesto simbolico: la consultazione è lo strumento attraverso cui le autorità europee raccolgono i casi limite, le difficoltà operative, le incompatibilità con prassi consolidate, e riformulano le sezioni in risposta. Nei prossimi due mesi, da qui al 9 giugno, c’è un tempo utile a contribuire. Dopo sarà tardi nel senso specifico che le forme del canone saranno state scelte. Vale la pena di spenderci una giornata.

Un’ora di riscrittura

Vorrei chiudere con un’immagine che mi è venuta in mente qualche settimana fa, rileggendo per l’ennesima volta un paragrafo sulle misure di mitigazione in una DPIA di un progetto sanitario. Il paragrafo era formalmente corretto, copriva i punti richiesti, citava le norme giuste. Ma era scritto male, con quella particolare opacità che hanno i testi tecnici non curati, in cui la sintassi è sostanzialmente un parcheggio di clausole. L’ho riletto pensando: se un auditor legge questo passaggio in fretta, cosa porta a casa? La risposta era: quasi niente, perché il testo non è fatto per essere letto in fretta, anzi non è fatto per essere letto affatto. È fatto per essere presente. È archeologia di compliance prima ancora di essere archiviato. Ho passato un’ora a riscriverlo, senza aggiungere contenuti, soltanto mettendo in ordine il ritmo. Alla fine il paragrafo era lungo il 30% in meno e, soprattutto, diceva le stesse cose con una chiarezza che prima non aveva. La differenza era editoriale, non tecnica. Ma era esattamente la differenza che separa un modulo da un genere.

Quell’ora di lavoro, a pensarci bene, è la cifra esatta del cambiamento che sto cercando di descrivere. In un mondo DPIA-modulo, un’ora di riscrittura su un paragrafo che è formalmente corretto è tempo sprecato: il documento è compliant, chiudere il ticket, passare al prossimo. In un mondo DPIA-genere, quell’ora è l’unica parte davvero produttiva della giornata, perché è l’unica che migliora la qualità del testo come testo. La trasformazione che stiamo descrivendo, insomma, cambia anche la definizione di tempo ben speso. Cambia cosa un team è autorizzato a considerare lavoro. E cambia, di conseguenza, come il lavoro va pianificato. Una sprint planning che riserva due ore a settimana alla scrittura e revisione collaborativa della DPIA non è un’eccentricità di un team che ama perdere tempo in letteratura tecnica; è un team che ha capito in quale regime documentale sta cominciando a operare. Un team che continua a trattare la DPIA come un artefatto da produrre in un pomeriggio alla fine del progetto sta, letteralmente, vivendo in un regime che sta smettendo di esistere.

Questo piccolo episodio si collega, nella mia testa, a un filo che sto tirando da mesi su cose apparentemente diverse: il software che non invecchia bene, il prodotto che smette di essere una categoria stabile, l’internet che è stata recintata più che degenerata. In tutti questi casi la questione di fondo è la stessa, e riguarda la scrittura. Quando un artefatto tecnico smette di essere autosufficiente e diventa parte di un ecosistema di testi che ne documentano l’esistenza, le proprietà del testo contano quanto e più delle proprietà dell’artefatto. Il software moderno, dicevo in Cruft, non patina, non invecchia perché non è mai abbastanza finito per invecchiare. La DPIA, in una piega speculare, non può più essere abbastanza finita per essere archiviata: vive finché vive il trattamento che documenta, e ogni sua versione è una fotografia in movimento, non un monumento. La compliance sta diventando, senza che quasi nessuno se ne accorga, una pratica di scrittura continua, non di archiviazione finale. E come ogni pratica di scrittura continua, premia chi la prende sul serio come scrittura, non chi la finge come modulistica.

È una direzione che domanderà di più a chi scrive, ma che restituirà anche di più, nel lungo periodo, in termini di qualità delle decisioni prese, di difendibilità delle scelte fatte, di trasmissibilità del sapere accumulato. Tradurla in pratica, nei nostri flussi di lavoro, è il lavoro che ci aspetta per i prossimi mesi. Non è un lavoro urgente nel senso delle deadline; è un lavoro urgente nel senso che più si tarda, più il debito di scrittura si accumula. E un debito di scrittura, in un genere in via di stabilizzazione, è difficile da ripagare quando il momento del giudizio arriva. Chi sta scrivendo adesso le sue prime DPIA nel nuovo template sta anche, senza saperlo del tutto, partecipando alla formazione di un canone. Nei prossimi due o tre anni si deciderà, attraverso la somma delle pratiche concrete di migliaia di organizzazioni europee, quali tratti del genere si consolideranno come normali e quali resteranno marginali. Vale la pena esserci, per una volta, non come spettatori ma come autori.

L'autore

Andrea MargiovanniCompliance EU

Lavoro a fianco di team che disegnano sistemi sotto AI Act, CRA, NIS2, GDPR. La regola non è una checklist: è un vincolo architetturale, e va portato a bordo prima del design, non dopo.

Vai al percorso →