Trasferimento di banche dati in operazioni societarie, richieste dell’Autorità con termini ristretti, trattamenti senza precedenti, sistemi di IA che decidono su persone. Quattro situazioni diverse con lo stesso problema: la qualificazione precede l’applicazione, e la qualificazione è una scelta di cui qualcuno risponde.
Ivano Pecis | DPO/RPD — Advisor in Governance, Privacy & Compliance | I&P Partners S.r.l., Milano
Risposta diretta
Una casistica è complessa non quando la norma è oscura, ma quando la situazione deve essere qualificata prima che una norma possa esserle applicata. Nei trasferimenti di banche dati, nelle richieste istruttorie a termine breve, nei trattamenti privi di precedenti e nelle decisioni automatizzate su persone il parametro giuridico esiste già: manca la premessa di fatto. Quella premessa la sceglie l’organizzazione, e ne risponde.
In sintesi
- Il modello standard funziona sulle situazioni già qualificate. Le casistiche complesse sono quelle in cui la qualificazione è essa stessa la decisione da prendere.
- In un’operazione societaria la variabile che decide non è il consenso: è se l’operazione produce successione universale nei rapporti giuridici o trasferimento di singoli beni.
- In una richiesta dell’Autorità il rischio principale non è il ritardo. È una risposta corretta nei fatti e ambigua nella qualificazione del ruolo.
- Non raccogliere l’attributo protetto non impedisce a un sistema di IA di discriminare: impedisce di accorgersene. Questo è uno snodo aperto, non un dettaglio metodologico.
- Dove la norma impone un obbligo procedurale senza fissare la soglia sostanziale — supervisione “effettiva”, accuratezza “adeguata”, rischio “accettabile” — la soglia la fissa chi decide. È lì che l’etica diventa giuridicamente rilevante, per via dell’accountability.
Che cosa rende complessa una casistica, se la norma è uguale per tutti?
La distinzione utile non passa tra norme chiare e norme oscure. Passa tra situazioni già qualificate e situazioni da qualificare. Un trattamento di curriculum in fase di selezione è qualificato: titolare, finalità, base giuridica e termini di conservazione hanno una collocazione consolidata, e il modello standard la restituisce senza attrito. Il valore aggiunto di un’analisi dedicata, lì, è vicino a zero.
Il modello si rompe quando la premessa di fatto non è data. Chi è il titolare di una banca dati che sta passando da una società a un’altra mentre l’operazione è in corso? Un’organizzazione che riceve una richiesta istruttoria a quindici giorni sta rispondendo come titolare, come responsabile o come contitolare, e su quale perimetro? Un sistema di raccomandazione clinica che non decide ma orienta produce un effetto “similmente significativo” ai sensi dell’art. 22 del Regolamento (UE) 2016/679? In tutti e tre i casi la norma applicabile non è controversa. È controverso il fatto a cui applicarla.
Qui la formula “dipende dal caso concreto” è corretta e inutile, se non si dice da che cosa dipende. Le pagine che seguono provano a dirlo, per quattro famiglie di casi che ricorrono nel lavoro di mandato.
Chi è il titolare quando una banca dati passa in un’operazione societaria?
La variabile che decide è civilistica, non privacy: se l’operazione produce successione universale nei rapporti giuridici o trasferimento di singoli beni. Nella fusione, l’art. 2504-bis del codice civile fa proseguire la società incorporante in tutti i rapporti anteriori; nel trasferimento d’azienda l’art. 2558 c.c. regola la successione nei contratti relativi all’esercizio dell’azienda ceduta. Dove il complesso passa come tale, la posizione di titolare segue il complesso. Dove invece si cede un singolo asset — un database clienti staccato dal ramo che lo generava — il trasferimento è una comunicazione di dati a un terzo, e ha bisogno di reggersi da sola.
Il punto meno presidiato viene dopo, e vale in entrambi gli scenari. La titolarità può passare senza che passi la finalità. Una base clienti raccolta da un operatore locale per la gestione del rapporto contrattuale, acquisita da un gruppo che opera per campagne di cross-selling su tutte le società controllate, non è lo stesso trattamento con un titolare diverso: è un trattamento ulteriore, che richiede il test di compatibilità dell’art. 6, par. 4 GDPR e, se la finalità è nuova, l’informazione preventiva agli interessati. La data dell’atto notarile non è la data in cui il trattamento diventa lecito nel nuovo contesto.
Tradotto in sequenza operativa — chi firma cosa, e in che ordine:
- Il titolare uscente cristallizza il perimetro alla data di efficacia: quali banche dati, quali finalità dichiarate, quali basi giuridiche, quali termini di conservazione già maturati. Non è un allegato del contratto: è il presupposto della difendibilità di entrambe le parti.
- Il titolare entrante congela la banca dati in sola lettura fino al completamento della qualificazione. Nessuna integrazione con il CRM di gruppo, nessuna profilazione, nessun arricchimento prima di quel momento.
- Il test di compatibilità si documenta come decisione datata, con l’esito e la firma di chi lo ha autorizzato — non come parere allegato al closing.
- L’aggiornamento dei registri e delle informative ha un termine interno definito, non “appena possibile”.
Questa impostazione ha un costo, e va detto: rallenta l’integrazione post-closing di settimane, in una fase in cui la pressione va nella direzione opposta. Regge comunque, perché il costo alternativo — scoprire in sede ispettiva che l’acquirente ha profilato per due anni una base clienti su una finalità mai comunicata — non è recuperabile a posteriori.
Come si risponde a una richiesta dell’Autorità con termini ristretti?
L’errore diffuso è trattarla come un problema di reperimento documentale: si raccoglie quello che c’è, si allega, si invia entro il termine. Il rischio maggiore non è però il ritardo. È una risposta corretta nei fatti e ambigua nella qualificazione: se l’organizzazione non dichiara in che veste sta rispondendo e su quale perimetro, quella qualificazione la compie l’Autorità, e lo farà sulla base di ciò che le è stato scritto.
La prima risposta definisce il perimetro dell’intero procedimento. Da lì in avanti, ogni correzione di rotta è una ritrattazione. Tre accorgimenti che cambiano la posizione difensiva a parità di fatti:
- Separare la ricostruzione fattuale dalla qualificazione giuridica. La prima è verificabile e datata: cosa è accaduto, quando, su quali sistemi, con quali evidenze. La seconda è argomentabile e va argomentata, non lasciata implicita nei documenti allegati.
- Dichiarare il ruolo in modo esplicito e circoscritto. “Titolare per il trattamento X, responsabile per il trattamento Y ai sensi del contratto del [data]” è una posizione. L’invio di documenti senza nota di accompagnamento non lo è.
- Se il termine non consente una ricostruzione attendibile, la proroga si chiede indicando che cosa si sta ricostruendo e perché richiede più tempo. Una richiesta generica di proroga vale meno del silenzio.
C’è una tensione reale che va gestita, non nascosta: l’art. 83, par. 2 GDPR include tra i criteri di commisurazione il grado di cooperazione con l’autorità di controllo, mentre l’art. 31 impone un obbligo generale di cooperazione. Cooperare però non significa qualificare a proprio sfavore fatti non ancora accertati. La linea passa qui: piena trasparenza su ciò che è accaduto, posizione argomentata su ciò che quei fatti significano giuridicamente. Confondere i due piani è il modo più rapido per trasformare un’istruttoria circoscritta in un procedimento largo.
Che cosa si fa con un trattamento privo di precedenti?
Quando non esiste un precedente, la tentazione è cercare l’analogia più vicina e applicarla. Spesso è la mossa sbagliata: l’analogia importa nel caso nuovo le assunzioni del caso vecchio, che sono proprio le assunzioni da verificare.
L’assenza di precedenti è, di per sé, un indicatore rilevante: l’uso innovativo di una tecnologia è uno dei criteri con cui il Gruppo di lavoro Articolo 29 — e poi l’EDPB — individua i trattamenti a rischio elevato. In presenza di altri indicatori, la valutazione d’impatto dell’art. 35 GDPR non è un’opzione. E se il rischio residuo resta elevato dopo le misure, l’art. 36 prevede la consultazione preventiva del Garante per la protezione dei dati personali: strumento strutturalmente sottoutilizzato, letto come ammissione di debolezza quando è invece la sola via per ottenere una posizione opponibile prima dell’avvio.
Nel caso senza precedenti la DPIA cambia funzione. Non verifica una conformità rispetto a un modello noto: costruisce il precedente. Il che sposta il peso su un elemento che nelle DPIA ordinarie resta implicito: perché il rischio residuo è stato ritenuto accettabile, da chi, con quale potere di autorizzarlo. Una valutazione che descrive i rischi e non registra chi ha deciso di correrli è un documento tecnico, non un atto di governo.
Quando un sistema di IA decide su una persona, chi risponde della decisione?
Nella quasi totalità dei casi l’organizzazione che impiega il sistema è contemporaneamente deployer ai sensi del Regolamento (UE) 2024/1689 — AI Act — e titolare del trattamento ai sensi del GDPR. Due discipline, due autorità di supervisione, un solo soggetto responsabile. L’art. 26 dell’AI Act attribuisce al deployer obblighi propri — tra cui l’uso conforme alle istruzioni del fornitore, la supervisione umana e l’adeguatezza dei dati di input sotto il proprio controllo — che non dipendono dalla diligenza del fornitore.
La responsabilità della decisione non si trasferisce con il contratto di fornitura. Con il contratto si sposta il rischio economico, che è un’altra cosa: davanti all’interessato e davanti all’autorità risponde chi ha deciso di usare quel sistema su quelle persone.
La conseguenza operativa è poco praticata. La documentazione tecnica del fornitore è un input della valutazione del deployer, non un suo sostituto. Un fornitore che non consegna elementi sufficienti a completare la valutazione d’impatto e a dimostrare l’effettività della supervisione non è un fornitore con una documentazione incompleta: è un fornitore che non può essere usato per quel trattamento. La qualificazione del fornitore, in ambito IA, precede la trattativa economica e talvolta la chiude.
Come si verifica che un sistema di IA non produca effetti discriminatori?
Qui c’è una zona grigia reale, e vale la pena nominarla invece di aggirarla. Per misurare un impatto differenziale su un gruppo protetto occorre conoscere l’appartenenza a quel gruppo. Ma origine etnica, convinzioni religiose, stato di salute e orientamento sessuale sono categorie particolari ai sensi dell’art. 9 GDPR: il loro trattamento è vietato salvo eccezioni tipizzate, e “verificare che il mio modello non discrimini” non figura tra quelle eccezioni in modo autonomo ed evidente. L’organizzazione che vuole controllare i propri sistemi si trova a dover trattare esattamente i dati che non dovrebbe trattare.
L’AI Act interviene su questo punto per i sistemi ad alto rischio, consentendo il trattamento di categorie particolari nella misura strettamente necessaria a rilevare e correggere le distorsioni, con garanzie specifiche. La disposizione risolve però una parte del problema, non tutto: copre un perimetro definito di sistemi, e non trasferisce automaticamente la propria logica ai sistemi che restano fuori dall’alto rischio o alle verifiche condotte da soggetti diversi dal deployer.
La posizione che sostengo è questa: l’affermazione “non raccogliamo dati sensibili, quindi il sistema non può discriminare” è un non sequitur. La discriminazione algoritmica opera per proxy — codice di avviamento postale, continuità contributiva, distanza dal luogo di lavoro, tipo di scuola — e nessuno di questi è un dato particolare. Non raccogliere l’attributo protetto non impedisce di discriminare: impedisce di accorgersene.
Le strade praticabili esistono e vanno scelte, non subite: test su proxy dichiarati e documentati; misurazione aggregata su campioni con base giuridica costruita per la sola finalità di verifica e conservazione separata; audit affidato a terzo su un perimetro limitato. Ciascuna ha limiti noti. La scelta tra esse, e la motivazione della scelta, sono materia di governance: sono precisamente il tipo di decisione che nessun modello standard restituisce.
Quali scelte devono restare in capo a un essere umano?
L’art. 14 dell’AI Act impone che i sistemi ad alto rischio siano progettati per consentire una sorveglianza umana effettiva, da parte di persone dotate di competenza, autorità e mezzi adeguati; l’art. 22, par. 3 GDPR riconosce all’interessato il diritto di ottenere l’intervento umano rispetto alle decisioni interamente automatizzate. Nessuna delle due disposizioni dice a quali condizioni quella supervisione sia effettiva. La soglia la fissa l’organizzazione.
Nel lavoro di mandato la verifica più informativa è anche la più semplice: quante volte il supervisore si è discostato dall’output del sistema, su quale volume, con quale motivazione registrata. Un tasso di scostamento pari a zero su migliaia di casi è un dato che l’organizzazione deve poter spiegare.
Questa lettura ha un punto debole, e va riconosciuto: uno scostamento nullo può significare che il sistema funziona bene, non che il supervisore è passivo. Regge comunque, perché l’onere non è dell’autorità: è dell’organizzazione che deve dimostrare che il supervisore avrebbe potuto discostarsi — e che non lo ha fatto per una ragione documentabile, non perché non ne aveva il tempo, i dati o il potere.
Tre condizioni rendono la supervisione qualcosa di più di un campo “approvato da”:
- Accesso ai fattori che hanno prodotto l’output, non al solo output. Chi vede un punteggio e non le variabili che lo determinano non supervisiona: ratifica.
- Potere formale di discostarsi senza autorizzazione superiore. Se lo scostamento richiede l’avallo di un dirigente, la supervisione è collocata altrove rispetto a dove il processo la dichiara.
- Tempo compatibile con il volume. Duecento pratiche al giorno e una supervisione “caso per caso” sono un’affermazione che non regge il primo controllo aritmetico.
Un’osservazione che l’analisi teorica non produce: la scelta che deve restare umana non è sempre la decisione finale. Spesso la discrezionalità vera sta a monte — nella definizione dei criteri di esclusione, nella scelta delle variabili ammesse, nella soglia oltre la quale una pratica esce dal flusso automatico. Presidiare l’output lasciando quei parametri alla configurazione del fornitore significa collocare il controllo umano nel punto in cui incide meno.
L’obiezione: «l’etica non è una categoria giuridica»
L’obiezione più solida a tutto questo è di metodo, e viene da giuristi competenti: l’etica non è una fonte, non è azionabile, non è opponibile. Il parametro rilevante è la norma; dove la norma tace, il privato è libero. Le lacune saranno chiuse dalle norme tecniche armonizzate, dalle linee guida dell’EDPB e dalla prassi applicativa. Chiedere “scelte etiche” prima di allora significa introdurre un obbligo senza perimetro e senza sanzione, cioè un obbligo che non esiste.
L’obiezione ha ragione sulla fonte e torto sull’effetto. Quando una disposizione impone un obbligo procedurale senza fissare la soglia sostanziale — sorveglianza “effettiva”, accuratezza “adeguata”, rischio residuo “accettabile” — la soglia non resta vuota: la riempie chi decide, e la riempie comunque, anche implicitamente. Il principio di responsabilizzazione dell’art. 5, par. 2 GDPR trasforma quel riempimento in un atto giuridicamente rilevante, perché va motivato e dimostrato. Ciò che chiamiamo etica, qui, non è un supplemento morale: è il nome del criterio che l’organizzazione deve fornire dove il legislatore non lo ha fornito.
E la conformità a una norma tecnica non risolve la questione: attribuisce una presunzione di conformità rispetto ai requisiti dell’AI Act, non immunità rispetto alla disciplina antidiscriminatoria, al diritto del lavoro o al GDPR. Uno standard fissa un pavimento comune. Non risponde alla domanda se quel sistema, su quelle persone, in quel contesto, si potesse usare.
Il test operativo
Tre domande che, in una verifica, arrivano quasi sempre prima delle altre. Se la risposta esiste in forma documentata, l’organizzazione ha governance. Se esiste solo nella memoria di chi ha deciso, ha un archivio.
- Sulla qualificazione: chi ha stabilito che questa situazione rientra in quella categoria, sulla base di quali elementi, e in quale data rispetto all’avvio del trattamento?
- Sulla soglia: dove la norma richiede un’adeguatezza senza definirla, quale livello è stato adottato e con quale motivazione è stato ritenuto sufficiente?
- Sul controllo umano: nel punto del processo in cui la discrezionalità incide davvero, esiste una persona con accesso, potere e tempo per discostarsi — e ne esiste traccia?
In I&P Partners il presidio delle casistiche che non trovano risposta in un modello standard — operazioni societarie con trasferimento di banche dati, richieste dell’Autorità a termine breve, trattamenti privi di precedenti — e delle questioni etiche connesse all’impiego dell’intelligenza artificiale è affidato a una funzione dedicata (Tosolini), che opera anche in qualità di DPO su mandato. Il perimetro è quello delle valutazioni che precedono la norma e che la norma da sola non chiude.
Dott.ssa Martina Tosolini
DPO/RPD — Advisor in Governance, Privacy & Compliance
I&P Partners S.r.l. — Udine | martina.tosolini@partnerprivacy.it
© I&P Partners S.r.l. — Riproduzione consentita con citazione della fonte
