Introduzione

Per anni molte organizzazioni hanno affrontato tecnologia e compliance con una frase rassicurante: "Il sistema non è nostro. È del fornitore."
Lo abbiamo visto nel GDPR. Quando emergeva un problema sui dati personali, non era raro sentire aziende sostenere che la responsabilità dovesse ricadere sul gestionale, sul cloud provider, sulla software house, sul SaaS o sul CRM. Il contratto con il fornitore diventava lo schermo dietro cui ripararsi.
Non era una giustificazione accettabile, ma adesso siamo andati oltre. 

L'AI Act manda un messaggio diverso e quello schermo non regge più definitivamente. Il concetto di responsabilità assume nuovi significati.
L'art. 27 del Regolamento europeo sull'intelligenza artificiale introduce la valutazione d'impatto sui diritti fondamentali, la la FRIA (Fundamental Rights Impact Assessment) per sistemi di IA ad alto rischio.

E non guarda soltanto a chi sviluppa il sistema. Guarda anche a chi lo usa. È un passaggio che sposta il focus dal codice alla decisione organizzativa. E cambia le regole del gioco per chiunque utilizzi AI nei propri processi. L'AI Act distingue con precisione. Il provider realizza o immette sul mercato il sistema. Il deployer è il soggetto che lo utilizza nel proprio contesto operativo: l'azienda, il laboratorio, il Comune, l'ente pubblico, il datore di lavoro, la struttura sanitaria che inserisce quel sistema nei propri processi decisionali. Ed è il deployer che, in non poche ipotesi deve svolgere la valutazione prevista dall'art. 27.

La norma richiede qualcosa che i professionisti della privacy riconosceranno immediatamente: descrivere i processi in cui il sistema verrà impiegato, individuare i soggetti coinvolti, valutare i rischi, prevedere la supervisione umana, definire misure di governance e meccanismi di reclamo accessibili.
Ma c'è una differenza sostanziale rispetto alla logica GDPR. Il Regolamento sulla protezione dei dati guardava principalmente ai dati personali. Qui il legislatore guarda ai diritti fondamentali. La domanda non è più soltanto: "quali dati tratta il sistema?" Diventa: "quali effetti produce sulle persone?"

Un algoritmo utilizzato per selezionare candidati, valutare dipendenti, attribuire priorità di servizio, gestire prestazioni pubbliche o influenzare decisioni amministrative può incidere su lavoro, accesso ai servizi, dignità, non discriminazione, libertà individuali. Effetti reali, su persone reali, prodotti da un sistema che l'organizzazione ha scelto di adottare. Ed è qui che cade la vecchia difesa e ll contratto con il fornitore non è una esimente

Dire "l'algoritmo è del fornitore" oppure “E’ quello del sistema” non esonera chi lo utilizza dal comprendere come quel sistema si inserisce nei propri processi e quali conseguenze produce. È un principio che i DPO conoscono bene: anche nel GDPR il ricorso a fornitori esterni non elimina le responsabilità del titolare. Se un trattamento produce effetti, il problema non si esaurisce nel contratto. L'AI Act segue la stessa traiettoria — e la estende.

C'è poi un passaggio dell'art. 27 destinato ad avere impatto pratico significativo: la FRIA può integrarsi con la DPIA prevista dall'art. 35 GDPR. Non si tratta di una sovrapposizione formale. È un segnale normativo preciso: privacy, governance dei dati e governance dell'intelligenza artificiale convergono. Chi li gestisce in silos separati accumula esposizione su più fronti contemporaneamente.

Conclusione

L'IA non è una questione tecnica da delegare agli sviluppatori o ai reparti IT. Diventa una questione organizzativa nel momento in cui l'azienda decide di utilizzarla.

Il rischio non nasce nel codice. Nasce nella decisione di adottarlo. E quella decisione appartiene all'organizzazione, non al fornitore.
A quel punto il problema non è più di chi abbia scritto l'algoritmo. Il problema è chi lo usa, lo governa, lo gestisce.

La domanda da porsi è se chi lo governa sa cosa sta governando. Il legislatore europeo, tra GDPR, AI Act e NIS2, insieme a quello italiano con l’art. 2086 c.c., stanno indicando una direzione sempre più precisa: non basta essere conformi, bisogna essere governati. Le norme non chiedono più solo adempimenti. Chiedono architetture decisionali.

Chiedono, in altri termini, esattamente ciò che una governance integrata come Cybermetrica® è stata progettata per costruire