Il tema della responsabilità (civile, amministrativa, penale) applicata alla protezione dei dati spesso si concentra sulle figure del titolare del trattamento dei dati e del responsabile del trattamento dei dati. Il titolare, essendo l’archetipo di ogni sistema privacy, risulta ovviamente anche il principale accentratore delle responsabilità. Il responsabile, invece, è un portatore di responsabilità variabile, la cui entità dipende fondamentalmente dalla qualità e quantità dei dati affidatigli dal titolare, oltre che dalle caratteristiche dell’atto o contratto di nomina. E’ fuori dubbio, tuttavia, che le responsabilità in capo a quest’ultimo, siano estremamente elevate ad ogni livello quando il titolare vada ad affidargli la totalità o buona parte dei dati trattati. E’ il caso, ad esempio, del responsabile in quanto provider di una piattaforma cloud o di un servizio software su piattaforma cloud che funge da ERP aziendale. Si potrà a lungo discutere sulla possibilità o meno del titolare del trattamento di spogliarsi della propria responsabilità attraverso la delega al responsabile, fatti salvi gli obblighi di sorveglianza sul suo operato, ma non è il tema che in questa sede voglio affrontare. 

Vorrei invece parlare di una figura ormai essenziale nell’universo del trattamento dei dati di oggi la quale, tuttavia, non viene menzionata come portatrice di responsabilità nel Regolamento UE 2016/679 (GDPR). Si può dire che il GDPR più volte giri attorno a questa figura senza mai renderla soggetto del discorso. Mi riferisco allo sviluppatore, o software house, o come lo vogliamo chiamare: il soggetto che per conto di terzi realizza i prodotti o le tecnologie che andranno poi a trattare i dati in un contesto a sé estraneo. Naturalmente, non parlerò delle aziende che dispongono al proprio interno di reparti di sviluppo ad uso dell’operatività della stessa organizzazione (in tal caso, essendo il soggetto giuridico unico, lo sviluppatore coinciderà presumibilmente con il titolare o il responsabile del trattamento). Parlerò in generale di programmatore o sviluppatore, estendendo invece il discorso, nel contesto odierno, anche a chi realizza, produce o fornisce prodotti che raccolgono e condividono dati degli individui che li utilizzano (Internet of Things o IoT) o prodotti che in ogni modo implementano la propria capacità ed autonomia acquisendo informazioni dai loro utilizzatori (intelligenza artificiale).

L’approfondimento sull’eventuale responsabilità dello sviluppatore deve necessariamente partire dall’art 25 del GDPR la cui rubrica recita “Protezione dei dati fin dalla progettazione e protezione per impostazione predefinita”. Da una prima superficiale lettura il riferimento sembrerebbe fuori luogo in quanto la stessa norma citata, nell’individuare l’obbligo di proteggere i dati fin dalla progettazione riferisce: “…il titolare del trattamento mette in atto misure tecniche ed organizzative …” ecc. Il titolare, quindi, è il soggetto su cui ricade l’obbligo. Altrettanto dicasi per la protezione per impostazione predefinita (privacy by default). Va da sé che se è il responsabile del trattamento ad utilizzare lo strumento tecnologico, ricadrà su di lui la responsabilità di rispettare le norme relative alla privacy by design e by default, e sul titolare del trattamento che lo ha incaricato la responsabilità di esercitare la sorveglianza utilizzando gli strumenti di legge e contrattuali a sua disposizione. Nessuna menzione alle responsabilità di chi progetta in qualità di soggetto terzo distinto rispetto a titolare e responsabile. 

Eppure, come può il titolare o responsabile del trattamento, che ha affidato ad un terzo specialista lo sviluppo dello strumento informatico con cui andrà a trattare i dati personali, rispettare quell’obbligo di legge dal momento che non è esso stesso, in prima persona a provvedere materialmente all’attività (e probabilmente, non dispone delle necessarie abilità)? Non certo operando successivamente, diciamo, in sequenza rispetto allo sviluppatore, e questo per due ordini di ragioni. La prima, di natura legale, è che il GDPR prevede espressamente che le attività di protezione siano impostate contestualmente alla progettazione (rendendo così illecito un eventuale intervento riparatorio successivo, fosse anche perfettamente efficace). La seconda, di natura pratica, è che mettere mano ad un prodotto già realizzato significa smontarlo per poi rimontarlo, con buona pace dell’efficienza ed economicità dell’operazione. La risposta unica, scontata e ovvia è che il titolare / responsabile deve adempiere al suo obbligo attraverso lo sviluppatore stesso. Come?  Avendo cura di inserire tale obbligo nel contratto o altro atto giuridico con cui lo incarica ad eseguire la commessa. La responsabilità dello sviluppatore ha pertanto un fondamento essenzialmente contrattuale, e dunque esplica la sua operatività su un piano prettamente civilistico, nel rapporto tra titolare (o responsabile) committente e sviluppatore fornitore. 

Questo primo scenario tuttavia, non può essere generalizzato. Lo schema funziona a tre condizioni:  che la committenza sia estremamente consapevole ed attenta alle tematiche della privacy, che formuli correttamente una clausola di responsabilità ed infine che abbia la forza commerciale per imporla. Direi che è un caso piuttosto raro. Il più delle volte questa sensibilità non esiste, oppure, molto più semplicemente, il software è realizzato da un soggetto contrattualmente forte che impone per la concessione della relativa licenza clausole contrattuali dallo stesso precostituite. E questo non solo, evidentemente, nel caso in cui il software sia un prodotto standard realizzato per essere venduto ad un numero indeterminato di compratori, ma anche, spesso, quando il committente richieda la realizzazione di un prodotto dedicato. Nel qual caso, la trattativa commerciale  presumibilmente si concentrerà sugli aspetti tecnici e sul prezzo, lasciando la tematica delle clausole contrattuali (rigorosamente predisposte dallo sviluppatore) ad una distratta e frettolosa lettura. 

E’ importante però valutare la questione da un punto di vista più generale. Esiste un articolo del codice civile italiano, il 1490, in rubrica “Garanzie per i vizi della cosa venduta”, che recita “Il venditore è tenuto a garantire che la cosa venduta sia immune da vizi che la rendano inidonea all’uso a cui è destinata…” e così via. Ovvio no? Chi vende uno spazzolino da denti deve garantire che sia in grado di pulire i denti. Chi vende un’automobile deve garantire che sia omologata, per poter circolare nella pubblica via. E chi vende un software? Non dovrebbe a sua volta garantire che chi lo utilizza non incorra, per ciò stesso, in una violazione di legge? Va da sé che un prodotto astrattamente idoneo a rispettare la legge può sempre essere usato in modo difforme, come accade quando un’automobile omologata viene guidata ad una velocità non consentita, o come quando un software programmato per rispettare i dati personali venga in qualche modo forzato verso una violazione della norma. Come anche è chiaro che, attraverso un diverso accordo legale, è comunque consentito acquistare un prodotto non idoneo all’uso a cui normalmente sarebbe destinato. Per esempio, potrei decidere di acquistare per finalità di collezionismo un’antica bottiglia di vino, pur sapendo che il contenuto non può essere consumato. Potrei acquistare consapevolmente una motocicletta non funzionante (ottenendo, presumo, un consistente sconto) per ripararla con le mie mani, o per utilizzarne le componenti che andrò a ricavarne come pezzi di ricambio. Potrei accettare di acquistare un software anche se so che il relativo utilizzo sicuramente incorrerà in violazione di legge? Difficile ipotizzare un esempio concreto in tal senso, ma ammettendo l’idea che qualcuno ne abbia interesse, allora sì, si potrebbe anche dire che sia possibile acquistare legalmente un programma che non è stato progettato nel rispetto della legge (purché ovviamente, non sia stato progettato allo scopo specifico di violare la legge) e che risulta legalmente inutilizzabile finché non vi si metta mano. E’ una strada, astrattamente ipotizzabile, piena di “se” e di “ma”, percorribile, mi sento di dire, a condizione che l’acquirente sia un soggetto economico (non certo il consumatore finale) e che abbia piena (e non soltanto formale) contezza di che cosa stia acquistando. In altre parole, non è una questione che si risolva con una clausola a carattere 7 infilata tra le righe del contratto di licenza. 

Dunque, lo sviluppatore ha quasi sempre una piena responsabilità di natura civilistica verso l’acquirente del prodotto, che lo obbliga a valutare l’impatto del prodotto sui diritti e le libertà degli individui e predisporre le necessarie misure di protezione per impostazione predefinita. Una responsabilità che potrebbe ipoteticamente portare il titolare del trattamento, citato in giudizio dall’interessato, a chiamare in causa lo sviluppatore come terzo responsabile dei danni patrimoniali derivanti (supponiamo) da un data breach. 

Ma come si concretizzano, nella pratica questi obblighi? Vi è un primo distinguo fondamentale da fare tra il prodotto su misura ed il prodotto standard. Perché ogni ragionamento deve partire dalla valutazione “dello stato dell’arte, dei costi di attuazione, della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento” e pertanto va calato nel mondo dell’utilizzatore. Che, se nel caso di un prodotto su misura, è un mondo analizzabile dettagliatamente, attraverso un serrato confronto tra committente e sviluppatore, nel caso del prodotto standard, può essere prefigurato soltanto a grandi linee. Il livello di diligenza richiesto allo sviluppatore, dunque, è lo stesso, ma declinato in modo diverso in ragione della prevedibilità degli utilizzi. Lo sviluppatore dovrà, facendosi chiaramente affiancare da un esperto di normativa sulla protezione dei dati (che potrà essere il privacy officer aziendale o un consulente esterno) compiere una serie di operazioni che andranno ad interessare competenze legali, di risk management, di software development e di sicurezza delle informazioni. 

Dovranno essere individuati e descritti il contesto in cui il software opererà e gli scopi per il quale viene realizzato, nonché le finalità di trattamento compatibili con il progetto. Dovranno essere individuati i rischi inerenti le persone fisiche quanto ai dati, le minacce per le loro libertà e per i loro diritti; gli stessi rischi dovranno essere mappati e classificati per gravità e frequenza, al netto delle misure di protezione da implementare. Questa operazione, sussistendone i presupposti, dovrà essere eseguita nella forma di Valutazione di Impatto Privacy (DPIA) ai sensi dell’articolo 35 del GDPR e, in alcuni casi, genererà l’obbligo di procedere ad una consultazione preventiva. Dovranno essere studiate le misure tecniche da introdurre nel software per eliminare o ricondurre ad un livello accettabile i rischi di maggior rilevanza; dovranno essere valutate anche misure di carattere organizzativo a protezione dei dati, e le stesse dovranno essere integrate (quando possibile e coerente) nel flusso procedimentale del prodotto stesso. Dovrà essere valutato il rischio residuale e, soltanto se questo è accettabile, il prodotto finalmente potrà essere rilasciato. 

Idealmente, il software dovrà essere accompagnato da una serie di documenti a comprova della conformità alle normative sulla protezione dei dati. Con una duplice finalità: da un lato garantire la tranquillità del cliente che, acquistando il prodotto, si trova nella condizione di rispettare la norma e di poterlo agevolmente dimostrare (non dimentichiamo che ricade sempre su di esso la responsabilità verso le autorità di vigilanza e verso i soggetti interessati). Dall’altro, tuttavia, questa documentazione giocherà a favore dello sviluppatore, poiché, quanto più dettagliate saranno le istruzioni al cliente, tanto più sarà circoscritta la responsabilità del programmatore in caso di uso difforme del prodotto.

Le straordinarie possibilità e prospettive che lo sviluppo tecnologico sta generando in questi ultimi anni comportano anche pericolose insidie per i diritti e le libertà delle persone. Di conseguenza gli operatori del software design si vanno evolvendo, e devono evolversi, da strutture di specialisti estremi concentrati sulla tecnica, ad organizzazioni capaci di intercettare ed interpretare, in modo interdisciplinare, la complessità del reale.