Il Data Processing Agreement (comunemente detto “DPA”) è quell’“accordo sulla privacy”, tipicamente accessorio ad un contratto principale, che sancisce un vincolo tra due parti contrattuali, laddove il servizio svolto comporti il trattamento di dati personali da una parte per conto dell’altra.
Indice degli argomenti
Data processing agreement: perché non coincide sempre con la nomina ex art. 28
Comunemente, i non addetti ai lavori all’interno di una organizzazione identificano con il termine DPA quell’atto che in italiano, prima dell’avvento del Reg. UE n. 2016/679 (“GDPR”), veniva comunemente definito “nomina a responsabile del trattamento”, ora disciplinato dall’art. 28 del GDPR.
Interpretazione questa, sia ben chiaro, non errata ma non completamente esatta in quanto il contenuto del Data Processing Agreement potrebbe essere più esteso, a seconda del caso concreto.
È giusto dirlo. Questo argomento non è una novità dell’ultima ora ma, adesso più che mai, è importante che le organizzazioni capiscano che dietro un Data Processing Agreement non sempre si cela – sempre e comunque – un semplice atto di nomina a responsabile del trattamento.
Sicuramente la “sana e vecchia” formazione sui temi privacy effettuata nei confronti del personale gioca a favore delle organizzazioni poiché, in fin dei conti, impone all’azienda di fermarsi allo STOP, di controllare e analizzare i contratti in essere, capire se vi sia un trattamento di dati personali, capire quali siano i ruoli privacy intercorrenti tra le parti, per poi procedere verso la strada scelta.
E questo è un bene per chi gestisce o deve gestire tali adempimenti (alle volte affidati all’ufficio legale, altre al Procurement, all’ufficio acquisti o alla funzione amministrativa) in quanto parte fondamentale dell’iter di approvazione di un contratto.
La formazione crea consapevolezza, la consapevolezza crea sensibilizzazione, la sensibilizzazione innesta processi, i processi formano presidi, i presidi portano alla compliance.
Gli accordi privacy: quando serve un data processing agreement e quando no
Partiamo dal presupposto che esistono vari tipi di accordi contrattuali con cui le parti regolamentano le attività di trattamento dei dati personali sottese al contratto.
Clausola, allegato o accordo separato: come cambia la gestione
Tali accordi relativi al trattamento dei dati personali possono assumere varie forme: a seconda dei casi possono vestire la forma di clausola contrattuale, di allegato oppure di contratto ad hoc, separato rispetto al contratto principale e ad esso connessi.
A prescindere dalla forma, tuttavia, bisogna anche premettere che DPA è un termine non codificato: non si tratta di un negozio tipico ed il termine, che, come visto, è normalmente associato alla nomina a responsabile ex art. 28 del GDPR, è alle volte utilizzato anche per regolamentare altre tipologie di rapporti privacy tra le parti, soprattutto nel mondo anglosassone.
Per entrare nel merito delle tipologie di accordi relativi al trattamento, per classificarle occorre in primis comprendere le attività svolte e definire i rispettivi ruoli privacy assunti dalle organizzazioni coinvolte: ad esempio si potrebbe applicare l’art. 28 del GDPR (Data processor) laddove un fornitore opera in nome e per conto del committente oppure l’art. 26 del GDPR (Joint Controller) nei casi in cui le aziende decidono congiuntamente le finalità e i mezzi del trattamento.
Art. 28, art. 26 e titolari autonomi: criteri pratici di scelta
Nel primo caso, tipicamente, si userebbe il termine (già visto) DPA, mentre nell’ultimo caso, nella tradizione italiana, si parlerebbe normalmente di “accordo di contitolarità” anche detto in inglese “joint-controllership agreement”. Nel caso in cui le parti, invece, prevedano uno scambio di dati personali ciascuno in qualità di titolare autonomo del trattamento, ulteriore al semplice scambio di contatti e riferimenti interni alle organizzazioni per l’esecuzione del contratto, la tradizione anglosassone utilizza spesso il termine “data sharing agreement”.
Data processing agreement e coerenza al rischio: cosa deve chiarire il contratto
Sicuramente l’approccio che si consiglia nella regolamentazione delle attività di trattamento è sempre di coerenza al rischio ed alla complessità delle attività da svolgere. Il contratto principale deve sempre definire con grande chiarezza tutti gli aspetti inerenti al servizio, alle intenzioni delle parti, ed alla determinazione di finalità e mezzi del trattamento.
La regolamentazione vera e propria dei contenuti obbligatori e necessari può essere inserita direttamente in clausole contrattuali laddove questi siano particolarmente semplici, mentre si potrebbero prevedere, ove necessario, specifici allegati o separati accordi relativi alla protezione dei dati personali laddove questi richiedano maggiore dettaglio.
Il ruolo dei presidi interni nella gestione dei contratti privacy
Riuscire a sensibilizzare sufficientemente il personale interno all’organizzazione al punto di “porsi la domanda” se sia necessario o meno nominare il fornitore come responsabile del trattamento ai sensi dell’art. 28 del GDPR era un traguardo e dovrebbe essere oggi il minimo essenziale.
Ciò, in altri termini, significa riuscire a porre un presidio all’interno della propria organizzazione di verifica e controllo non solo delle attività dal punto di vista della protezione dei dati personali ma anche della sistemazione dei necessari passaggi formali (come si dice: “avere le carte a posto”), per evitare di incorre in sanzione da parte dell’Autorità Garante per la protezione dei dati personali in caso di accertamento o verifiche ispettive.
Uno obiettivo successivo, a onor del vero piuttosto complesso da raggiungere, è la capacità dei presidi interni non legali di comprendere i presupposti della contitolarità. In tal senso, sicuramente una corretta e continuativa formazione privacy può porre le basi affinché la gestione di queste casistiche risulti più agevole.
Ad ogni modo la definizione dei ruoli privacy tra le parti nel contratto non deve però far “abbassare la guardia” su servizi aggiuntivi o attività insite proprio nell’oggetto del contratto in quanto gli stessi potrebbe far emergere ulteriori aspetti privacy.
Contratti con ruoli privacy mutevoli: il caso dei servizi basati su AI
A parte questa questione di “organizzazione contrattuale” che potrebbe sembrare semplice, potrebbero sorgere altre complessità in relazione, soprattutto, ad alcune innovazioni tecnologiche. Ed infatti non appare neanche più una novità che i contratti prevedano fasi di attività del servizio erogato in cui le regole sul trattamento dei dati personali cambiano o si “mischiano” in varie situazioni.
Il caso, ad avviso degli scriventi, più “gettonato” allo stato attuale (ma non per questo l’unico presente), è quello che riguarda la fornitura di prodotti tecnologici basati su AI (Artificial Intelligence).
Infatti, l’effettiva efficacia e efficienza di questi sistemi di AI passa necessariamente dall’addestramento dei modelli: anche se non vi è una relazione lineare e direttamente proporzionale, il principio generale è che più dati sono usati per addestrare l’algoritmo, più il modello può essere performante.
Ed è proprio qui, in questi passaggi, che i contratti devono essere ben analizzati e revisionati da esperti della materia in quanto la base dell’addestramento dei modelli sono i dati. Pensare che in una fornitura di un prodotto tecnologico vi sia soltanto un rapporto committente/fornitore potrebbe essere un’analisi parziale, soprattutto sul piano privacy.
Come mai?
Addestramento dei modelli: quando il data processing agreement diventa una trattativa
Capita sempre più spesso che fornitori tecnologici, nell’erogazione del servizio che offrono, inquadrino il proprio ruolo privacy in modo diverso a seconda delle fasi del servizio svolto. È opportuno sempre comprendere a pieno tali ruoli e, ove possibile, limitarli.
Una delle casistiche più tipiche in questi tempi riguarda tutti quei servizi che includono o hanno ad oggetto funzionalità di intelligenza artificiale. Tali servizi, come è noto, per essere erogati necessitano di addestramento dei propri modelli di AI: finché tali dati sono (lecitamente) acquisiti altrove, la questione è marginale per il committente che acquista il servizio.
I problemi, tuttavia, emergono nel momento in cui il fornitore del servizio richiede o pretende di addestrare i propri modelli di AI con i dati personali che gli vengono forniti dal committente. In sostanza, oltre ad incassare il corrispettivo del servizio, il fornitore acquisisce anche i dati necessari per l’addestramento del modello. In questi casi, la terminologia utilizzata è spesso vaga, e spesso fa riferimento a generiche attività di “miglioramento del servizio”.
Doppio cappello del fornitore: responsabile per il servizio, titolare per il training
Ed è qui che un’attenta e dettagliata analisi contrattuale può essere di grande aiuto. Infatti, l’approccio tipico per i fornitori, in questi casi, è di inquadrarsi come responsabili del trattamento per l’effettiva erogazione del servizio contrattuale, e come titolari autonomi nello svolgimento delle attività di addestramento del proprio modello di AI per rendere sempre più performante il proprio prodotto tecnologico.
Il tentativo dei fornitori di inserire queste finalità proprie di addestramento dei modelli di AI deve fare i conti con i problemi che ciò potrebbe comportare per l’organizzazione che conferisce i dati, che tipicamente ricoprirà il ruolo di titolare e che sicuramente si assume la maggior parte dei rischi di compliance.
Quattro opzioni contrattuali sul data processing agreement per il training AI
In questi casi, l’organizzazione committente potrebbe perseguire diverse strade:
- potrebbe richiedere al fornitore di eliminare del tutto l’attività di addestramento dal contratto, cristallizzando il fatto che non avviene alcun addestramento sui dati trattati per conto del committente;
- potrebbe accogliere in modo parziale l’attività di addestramento dei dati da parte del fornitore ma imporre a quest’ultimo che l’allenamento dei dati avvenga – in modalità segregata – solo ed esclusivamente per il modello AI in dotazione al committente, senza possibilità che tali dati possano essere utilizzati per allenare altri modelli che il fornitore potrebbe vendere ad altri clienti: infatti in questo caso il ruolo del fornitore rimarrebbe di responsabile del trattamento
- il committente potrebbe avere invece la necessità di avere un modello di AI performante e, quindi, decidere di consentire l’addestramento sui propri dati ma solo in modalità anonima e aggregata. In questo caso il fornitore potrebbe anche accettare questa soluzione ma, nel caso in cui lo stesso non abbia un processo consolidato di anonimizzazione dei dati al suo interno, è realistico che ciò potrebbe avere un impatto sul corrispettivo del servizio
- il committente, infine, potrebbe decidere di avere un modello AI sempre performante, di consentire al fornitore di addestrare il modello AI e, solo per tale attività, identificarsi come Titolare del trattamento. Questo approccio, ovviamente, comporta diverse conseguenze sul piano della conformità alla normativa sulla protezione dei dati personali da parte del committente, tra cui, in primi, la verifica della base giuridica per il trasferimento dei dati ad un terzo titolare (il fornitore).
Accorgersi per tempo, come è stato detto, e prima della firma del contratto di tutte le attività insite nel servizio, permette di avere una visione generale di tutti gli impatti privacy derivanti del trattamento con la conseguenza di poter negoziare il tutto, eventualmente effettuare le attività di compliance necessarie, o eventualmente rivolgersi altrove sul mercato.
Errori da evitare: domande operative prima della firma del data processing agreement
Veniamo ad alcune riflessioni per non commettere errori in questi casi.
Sicuramente, per l’esame di tali contratti, l’organizzazione potrebbe affidarsi a specialisti della materia in grado di mettere il committente e il fornitore nelle condizioni di poter valutare tutti gli aspetti privacy. Infatti, può essere lo stesso fornitore del prodotto tecnologico ad avere la necessità di analizzare, già prima di negoziare il contratto, tutte le diverse soluzioni che si potrebbero prospettare al cliente, dimostrando altresì un elevato grado di accountability e responsabilizzazioni su tali tematiche.
Le domande da porsi, pertanto, sono davvero tante, ad esempio:
• sono stati definiti i ruoli privacy, a seconda delle diverse attività erogate?
• nel caso in cui il committente decida di consentire al fornitore di addestrare il modello AI, nella sua veste di Titolare del trattamento, ha valutato come quest’ultimo possa rilasciare l’informativa privacy ai soggetti interessati? Si ricorda che è compito del Titolare del trattamento porre in essere gli adempimenti previsti dalla normativa applicabile;
• sempre in tale caso, qual è la corretta base giuridica per il trasferimento dei dati?
• nel contratto tra committente e fornitore è reso in modo chiaro e trasparente quali siano i dati personali oggetto di addestramento?
• il fornitore ha valutato l’esigenza di redigere una DPIA relativa all’addestramento dei dati per finalità di miglioramento del modello di AI realizzato? Ed il committente deve fare lo stesso in relazione al trasferimento dei dati?
• È stato verificato che il servizio messo in commercio non rientri tra le pratiche vietate dall’art. 5 del Reg. (UE) 2024/1689 oppure non rientri nei sistemi ad alto rischio di cui all’art. 6? In ottica di accountability, il fornitore ha redatto un documento interno in cui attesta la valutazione circa il sistema?
Perché negoziare prima tutela dati, responsabilità e compliance
In conclusione, la negoziazione contrattuale e le prestazioni previste possono celare diverse insidie che, se non opportunamente gestite, possono determinare profili di rischio e, dunque, di responsabilità. È sempre bene ricordare che in gioco ci sono dati personali di persone fisiche che devono sempre essere protetti.
