IA e privacy nei servizi affidati: perché la stazione appaltante deve valutare l'operatore economico prima dell'aggiudicazione?
Quando l'oggetto dell'affidamento comporta il trattamento di dati personali - gestione di servizi sociali, sanitari, educativi, tributari, help desk, servizi documentali, recupero crediti, gestione del personale, videosorveglianza, servizi informatici, consulenza in generale - la stazione appaltante non si dovrebbe limitare ad acquistare una prestazione: designa, di regola (tranne in alcuni casi), un responsabile del trattamento ai sensi dell'art. 28 del Regolamento (UE) 2016/679. E la designazione non è un atto libero: deve ricadere su un soggetto che «presenti garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate».
Se l'operatore economico intende erogare il servizio ricorrendo, in tutto o in parte, a sistemi di intelligenza artificiale, quella valutazione non può essere rinviata alla fase esecutiva. Va compiuta prima, nel momento in cui la stazione appaltante definisce la lex specialis e seleziona il proprio fornitore.
Il punto non è vietare l'intelligenza artificiale nei servizi pubblici affidati all'esterno. È evitare che l'amministrazione la scopra quando è già parte del trattamento e non è più in condizione di governarla.
Conoscere realmente il proprio fornitore
La valutazione del fornitore non può fondarsi su dichiarazioni generiche di conformità. Se il servizio verrà erogato con il contributo di sistemi di IA, cambiano l'architettura del trattamento, la catena dei soggetti coinvolti e il profilo di rischio. Cambiano, in particolare:
la catena dei sub-responsabili, poiché il modello è spesso fornito da un terzo, talvolta in cloud, talvolta extra-UE;
i flussi di dati, con possibili trasferimenti verso Paesi terzi e conseguente necessità di verificare gli artt. 44 e seguenti del GDPR;
la questione del riutilizzo dei dati per addestramento, fine-tuning o miglioramento del servizio, incompatibile con il ruolo di responsabile che tratta i dati solo su istruzione del titolare;
la conservazione dei prompt e degli output, spesso regolata da policy del fornitore del modello e non dal contratto di servizio;
il grado di intervento umano effettivo sulle attività che incidono sulle persone.
Un'amministrazione che scopra in esecuzione che i dati dei cittadini vengono processati da un servizio generativo di terze parti, con conservazione dei prompt presso un provider estero, si trova davanti a un trattamento non previsto, non informato, non disciplinato e privo di base contrattuale adeguata.
Il rimedio tardivo è sempre più oneroso della verifica preventiva: rinegoziazione, sospensione parziale, aggiornamento dell'informativa, eventuale notifica di violazione, con riflessi sulla continuità del servizio.
Vi è poi un profilo di capacità tecnica sostanziale. Chi promette in offerta tempi di lavorazione o volumi sostenibili soltanto grazie all'automazione deve dichiararlo. Diversamente, la valutazione comparativa si svolge su basi disomogenee: l'offerta che sottace l'IA viene valutata come se il risultato derivasse da un apporto organizzativo e professionale che, in realtà, non è quello effettivamente impiegato. È un problema di attendibilità dell'offerta, di trasparenza e non soltanto di privacy.
Trasparenza amministrativa e accountability
L'amministrazione che affida un servizio con trattamento di dati personali risponde verso una pluralità di soggetti: gli interessati, ai quali deve fornire un'informativa esatta ai sensi degli artt. 13 e 14 del GDPR; l'autorità di controllo, dinanzi alla quale deve dimostrare l'accountability ex art. 5, par. 2 GDPR; gli altri concorrenti, rispetto ai quali deve garantire parità di trattamento; il giudice amministrativo, in caso di contenzioso.
L'informativa deve indicare le categorie di destinatari, gli eventuali trasferimenti e l'esistenza di processi decisionali automatizzati. Se il servizio incorpora sistemi di IA e l'amministrazione non lo sa, l'informativa è oggettivamente incompleta. Il deficit informativo non è del fornitore: è del titolare del trattamento.
Sul piano della trasparenza amministrativa, l'accesso civico e le esigenze di conoscibilità dell'azione pubblica non tollerano che una componente strutturale dell'erogazione del servizio resti opaca.
Valutare ex ante il fornitore e le misure di sicurezza adottate
È il punto centrale. La verifica preventiva non serve soltanto a dimostrare di avere valutato il fornitore: serve a valutare le misure di sicurezza che il fornitore intende concretamente applicare. E la sicurezza di un trattamento che coinvolge sistemi di IA presenta rischi ulteriori rispetto a quelli tradizionalmente considerati nei capitolati. In particolare:
esfiltrazione tramite input
persistenza non governata di prompt, output, cache e log, con tempi di conservazione definiti unilateralmente dal provider;
prompt injection e manipolazione degli input;
inesattezza degli output, rilevante non solo in termini di qualità ma sotto il principio di esattezza dell'art. 5, par. 1, lett. d, GDPR quando l'output confluisce in atti che riguardano persone;
profilazione non dichiarata e rischio di decisioni sostanzialmente automatizzate ai sensi dell'art. 22 GDPR, anche in assenza di una formale qualificazione come tali;
bias e (potenziale) discriminazione, con impatto diretto sui diritti degli interessati e riflessi sull'art. 30 del Codice;
difficoltà di esercizio dei diritti: rettifica, cancellazione e limitazione diventano problematiche se i dati sono confluiti in indici, cache o processi di addestramento;
opacità della catena di fornitura, con sub-responsabili a più livelli e responsabilità tecniche difficilmente ricostruibili in caso di incidente;
lock-in e continuità: dipendenza da un modello o da un provider la cui interruzione o modifica unilaterale compromette la prestazione.
Cosa richiedere in concreto nella documentazione di gara
descrizione delle funzioni per le quali l'IA sarà impiegata, delle fasi del servizio interessate e delle categorie di dati coinvolte;
qualificazione del sistema rispetto all'AI Act, con indicazione se ricada nell'Allegato III, e individuazione dei ruoli di fornitore e deployer;
identificazione del fornitore del modello, dell'architettura di erogazione e dell'ubicazione dei trattamenti;
divieto espresso di utilizzo dei dati dell'amministrazione per addestramento, fine-tuning o finalità proprie del fornitore, salvo diversa e specifica istruzione scritta;
disciplina della conservazione di prompt, output e log, con tempi definiti contrattualmente e non rimessi alle policy del provider;
misure di sicurezza specifiche: segregazione degli ambienti, cifratura, controllo degli accessi, minimizzazione e pseudonimizzazione degli input, filtri di data loss prevention;
descrizione della sorveglianza umana: chi valida, su quali output, con quali competenze e con quale tracciabilità della validazione;
impegno a fornire la documentazione necessaria alla DPIA/FRIA del titolare e, ove applicabile, alla valutazione d'impatto sui diritti fondamentali ex art. 27 AI Act;
divieto di utilizzo di dati sensibili della stazione appaltante ove non previsto;
elenco completo dei sub-responsabili, autorizzazione preventiva alle variazioni e catena contrattuale conforme all'art. 28, par. 4, GDPR;
gestione degli incidenti con tempistiche di notifica al titolare compatibili con l'art. 33 GDPR.
L'affidamento di un servizio che comporta il trattamento di dati personali non è un atto neutrale rispetto alla tecnologia impiegata dall'aggiudicatario.
Chiedere prima quali sistemi di IA l'operatore intenda utilizzare non risponde a una logica di sospetto, ma alla struttura stessa degli obblighi che gravano sul titolare del trattamento e, ormai, sul deployer di sistemi di IA.
Hai bisogno di aiuto? Scrivici! Saremo lieti di fornirTi ulteriori dettagli
Verrai reindirizzat* alla nostra pagina "Contattaci"
Rimani in contatto con noi! IscriviTi alla nostra Newsletter.
Immagine di copertina
Copyright: Unsplash · Alesia Kazantceva
Testo elaborato con il supporto parziale di sistemi di IA
