Né il GDPR né l’AI Act conoscono la categoria «progetto pilota». Perché l’etichetta interna non sposta il momento in cui gli obblighi si attivano — e quale variabile lo sposta davvero.
Ivano Pecis | DPO/RPD — Privacy Specialist UNI CEI EN 17740:2024, CIPP/E, CDPSE | I&P Partners, Milano
| In breve Né il GDPR né l’AI Act riconoscono la categoria «progetto pilota». Gli obblighi si agganciano al trattamento di dati personali e alla messa in servizio del sistema, non alla qualifica interna del progetto. Una sperimentazione che tratta dati di persone reali attiva registro, base giuridica e valutazione d’impatto come qualsiasi altro trattamento. |
Nel portfolio applicativo di quasi ogni organizzazione che ha adottato l’intelligenza artificiale esiste una voce che nessuno rilegge: il progetto pilota avviato due o tre anni fa e mai chiuso formalmente. Non è stato promosso a sistema. Non è stato dismesso. Continua a girare.
Sul piano interno quel sistema gode di uno statuto informale preciso: è «solo una sperimentazione». Da questa qualifica discende una serie di conseguenze pratiche che nessuno ha mai deciso e che nessuno rivendica — non entra nel registro dei trattamenti, non passa dal DPO, non riceve una valutazione d’impatto, non ha una data di fine. È lo stato in cui si trova oggi la maggior parte dei sistemi di IA presenti nelle organizzazioni italiane. E non è uno stato previsto dalla norma.
In sintesi
- La qualifica interna di «pilota» non è una categoria giuridica: non sospende né differisce alcun obbligo.
- Il momento rilevante per il GDPR è l’inizio del trattamento di dati personali, non la promozione del progetto a sistema di produzione.
- L’AI Act, per i sistemi ad alto rischio, disciplina espressamente le prove in condizioni reali (art. 60) con un regime dedicato: la sperimentazione è regolata, non esente.
- Tre variabili decidono il caso concreto: natura dei dati, destinazione dell’output, esistenza di un termine dichiarato.
- Il rischio maggiore non è il pilota breve e circoscritto. È il pilota che nessuno ha mai dichiarato concluso.
Il GDPR prevede un regime speciale per i progetti pilota?
No. Il Regolamento (UE) 2016/679 — GDPR costruisce il proprio perimetro applicativo sulla nozione di trattamento di dati personali, non sulla maturità o sulla qualifica organizzativa del progetto che lo genera. Se un sistema in fase di test raccoglie, elabora o conserva dati riferibili a persone fisiche identificate o identificabili, quel trattamento esiste, ha un titolare e richiede una base giuridica.
Il GDPR conosce una fattispecie adiacente — il trattamento per finalità di ricerca scientifica, con le garanzie dell’art. 89 — ma è un regime a presupposti stringenti, non una copertura generale per la sperimentazione interna. Un pilota condotto per valutare se adottare un fornitore non è ricerca scientifica: è un’attività istruttoria a fini organizzativi.
Il punto in cui questo si traduce in esposizione concreta è il registro. L’art. 30 impone di censire i trattamenti effettuati. Un sistema in test che elabora dati di dipendenti, clienti o cittadini è un trattamento effettuato. La sua assenza dal registro non è una svista formale: è la prova documentale che l’organizzazione non sapeva di trattare quei dati.
Quando un progetto pilota diventa un trattamento a tutti gli effetti?
Lo è dal primo dato reale che entra nel sistema. La domanda utile, però, non è quando scattano gli obblighi — la risposta è sempre «subito» — ma quali variabili determinano l’intensità del presidio richiesto. Sono tre, e vanno decise prima dell’avvio, non dopo.
1. Natura dei dati in input
Un pilota alimentato con dati sintetici o effettivamente anonimi resta fuori dal perimetro del GDPR. Un pilota alimentato con dati pseudonimizzati vi rientra pienamente. Questa è la sola variabile che può escludere l’applicazione della norma, ed è anche quella su cui le organizzazioni si autoingannano con maggiore frequenza: un dataset di produzione con i nomi sostituiti da identificativi resta un dataset di dati personali.
2. Destinazione dell’output
Se l’esito prodotto dal sistema in test viene comunque letto da qualcuno che decide — un selezionatore che scorre un ranking di candidati, un analista che vede un punteggio accanto a una pratica — il sistema incide su persone anche se formalmente «non è in produzione». La presenza di un umano nel processo non neutralizza l’incidenza: la attenua solo se quell’umano dispone di informazione, tempo e legittimazione per discostarsi dall’output. In fase pilota queste tre condizioni sono, tipicamente, meno presenti che a regime, non di più: nessuno ha ancora scritto la procedura di override.
3. Esistenza di un termine dichiarato
È la variabile discriminante, e la meno presidiata. Un pilota con data di fine, criteri di valutazione definiti e destinatario della decisione finale è un progetto governato. Un pilota senza termine non è una fase: è uno stato permanente sottratto al controllo. La differenza tra i due non sta nella tecnologia impiegata né nel volume dei dati — sta in una riga di documentazione che qualcuno ha scritto o non ha scritto all’avvio.
Serve la valutazione d’impatto per una sperimentazione?
L’art. 35 GDPR collega l’obbligo di valutazione d’impatto al rischio elevato per i diritti e le libertà delle persone fisiche, e ne colloca l’adempimento prima del trattamento. Non prima della messa in produzione: prima del trattamento. Se il pilota tratta dati personali con le caratteristiche che attivano la soglia — decisione automatizzata, monitoraggio sistematico, uso innovativo di tecnologia, soggetti in posizione di vulnerabilità — la DPIA va condotta all’avvio della sperimentazione.
L’obiezione ovvia è che in fase pilota mancano le informazioni per compilarla. È vera solo in parte, e va guardata con attenzione: se mancano gli elementi per valutare l’impatto, mancano anche gli elementi per giustificare l’esposizione di persone reali a quel sistema. Una DPIA di fase pilota è legittimamente più snella di quella definitiva, purché espliciti il proprio perimetro provvisorio e fissi il momento del riesame. Ciò che non regge è la sequenza inversa: prima si sperimenta su persone, poi si valuta se si poteva.
Cosa prevede l’AI Act per le prove in condizioni reali?
Qui la lettura corrente è più imprecisa di quanto si creda. Il Regolamento (UE) 2024/1689 — AI Act non ignora la sperimentazione: la disciplina. L’art. 60 regola espressamente le prove dei sistemi di IA ad alto rischio in condizioni reali al di fuori degli spazi di sperimentazione normativa, e l’art. 61 dedica una disposizione autonoma al consenso informato dei soggetti che vi partecipano. L’art. 9, nel disegnare il sistema di gestione dei rischi, prevede che le procedure di prova possano comprendere prove in condizioni reali secondo l’art. 60, e colloca comunque le prove prima dell’immissione sul mercato o della messa in servizio. La vigilanza sulle prove in condizioni reali è a sua volta attribuita alle autorità di vigilanza del mercato dall’art. 76.
La conseguenza è l’opposto di quella che l’etichetta «pilota» suggerisce internamente. Per un sistema ad alto rischio, testare in condizioni reali non è la zona in cui gli obblighi non si applicano ancora: è una fattispecie con presupposti, documentazione e supervisione propri. Un’organizzazione che sperimenta un sistema di selezione del personale su candidature vere senza aver verificato la propria posizione rispetto a questo regime non si trova in un’area grigia. Si trova fuori.
L’obiezione: così la governance blocca la sperimentazione
È l’obiezione più solida contro questa tesi, e merita di essere presa nella sua versione forte. Se ogni proof of concept richiede DPIA, voce a registro, base giuridica documentata e informativa dedicata, il costo istruttorio supera il valore conoscitivo del test. L’effetto pratico non è più governance: è che si sperimenta di meno, o che si sperimenta di nascosto — l’esito peggiore dei due.
La replica non è che gli oneri vadano applicati integralmente in ogni caso. È che la proporzionalità opera sulle misure, non sull’esistenza del presidio. Una sperimentazione a basso impatto può legittimamente avere una valutazione sintetica, un’informativa essenziale e un perimetro dichiarato ristretto. Ciò che non ammette graduazione è la tracciabilità della scelta: chi ha autorizzato l’avvio, su quali dati, per quanto tempo, con quale esito atteso. Quattro informazioni. Nessuna delle quali richiede un progetto di adeguamento.
Il punto debole di questa lettura va detto: dove il pilota utilizza esclusivamente dati sintetici e produce output che non raggiungono alcun processo decisionale, l’impianto qui descritto è largamente sovradimensionato. Regge comunque, perché quella condizione — verificata, non dichiarata — è molto meno frequente di quanto le organizzazioni ritengano, e perché è proprio la verifica di quella condizione a costituire il presidio minimo.
Chi chiude un progetto pilota, e con quale documentazione?
La chiusura è il passaggio che manca quasi sempre. Un pilota si conclude in uno di tre modi: promozione a sistema, interruzione, proroga motivata. Tutti e tre richiedono un atto — e nessuno dei tre coincide con «il progetto si è fermato da solo».
La documentazione minima di chiusura è breve. L’esito della sperimentazione rispetto ai criteri fissati all’avvio. La decisione conseguente e chi l’ha assunta. La sorte dei dati utilizzati, con la base giuridica dell’eventuale conservazione residua o l’evidenza della cancellazione. La revoca degli accessi tecnici e delle integrazioni attivate per il test. L’aggiornamento del registro: iscrizione del nuovo trattamento se il sistema prosegue, chiusura della voce se si interrompe.
Chi ha già affrontato la dismissione di un sistema di IA riconosce lo schema: il trattamento non finisce quando l’uso si interrompe. Nel caso del pilota il problema si presenta prima, e in forma più insidiosa, perché il sistema non è mai stato censito — non c’è nulla da chiudere, nei registri dell’organizzazione, perché non risulta che sia mai stato aperto.
Cosa fare lunedì mattina
L’attività che produce il maggior ritorno immediato è un inventario, non un adeguamento: farsi consegnare dalle funzioni IT e di business l’elenco dei progetti di intelligenza artificiale avviati e non formalmente conclusi, e per ciascuno rispondere a quattro domande — quali dati riceve, dove finisce il suo output, chi ne ha autorizzato l’avvio, quando doveva finire. I casi in cui la quarta domanda non ha risposta sono quelli da cui partire.
Un pilota senza data di fine non è una sperimentazione. È un sistema in produzione che nessuno ha mai autorizzato.
Ivano Pecis
DPO/RPD — Advisor in Governance, Privacy & Compliance
I&P Partners S.r.l. — Milano | ivano.pecis@partnerprivacy.it
© I&P Partners S.r.l. — Riproduzione consentita con citazione della fonte
