Guida all’AI Act europeo: come orientarsi tra divieti, rischi e conformità

Il Regolamento europeo sull’Intelligenza Artificiale, noto come AI Act, rappresenta il primo quadro normativo organico dell’Unione europea pensato per disciplinare lo sviluppo e l’impiego delle tecnologie basate sull’IA. L’obiettivo non è frenare l’innovazione tecnologica, ma indirizzarla verso standard di trasparenza, sicurezza e rispetto dei diritti fondamentali. Per le aziende e le organizzazioni che utilizzano o sviluppano software intelligenti, comprendere questa normativa non è quindi soltanto un esercizio teorico: significa capire quali regole si applicano ai sistemi utilizzati, quali responsabilità ricadono sull’organizzazione e quali misure adottare per operare sul mercato europeo in modo conforme.

Per orientarsi nell’AI Act è utile evitare di partire direttamente da una checklist di adempimenti. La normativa deve essere letta lungo due dimensioni che si incrociano: da una parte il livello di rischio del sistema, dall’altra il ruolo ricoperto dall’organizzazione nella filiera dell’IA. Lo stesso sistema può infatti generare obblighi molto diversi per chi lo sviluppa e lo commercializza rispetto all’azienda che si limita a utilizzarlo.

La sequenza logica è quindi questa: prima occorre capire che cosa fa il sistema e per quale finalità viene utilizzato; poi bisogna stabilire se l’organizzazione opera come fornitore o come deployer; infine si può determinare a quale categoria normativa appartiene il sistema e quali obblighi ne derivano.

Livelli di rischio presenti nell’AI Act

Il fulcro dell’AI Act si basa su un approccio proporzionale, che modula gli obblighi legali in funzione del rischio che un determinato sistema o utilizzo dell’intelligenza artificiale può generare per la sicurezza, la salute e i diritti fondamentali delle persone.

In termini divulgativi, per orientarsi nel Regolamento è utile distinguere quattro livelli principali:

• Al vertice si trovano le pratiche a rischio inaccettabile, che il regolamento vieta. Vi rientrano, a determinate condizioni, sistemi che utilizzano tecniche manipolative o sfruttano vulnerabilità delle persone provocando o potendo provocare un danno significativo, alcune forme di social scoring e determinati utilizzi della biometria. Particolarmente limitato è anche l’impiego dell’identificazione biometrica remota in tempo reale in spazi accessibili al pubblico per finalità di contrasto, ammesso soltanto nelle specifiche eccezioni previste dalla normativa.
• Subito sotto figurano i sistemi ad alto rischio, che rappresentano il vero banco di prova per la conformità aziendale. Possono rientrare in questa categoria, quando ricorrono le condizioni previste dal regolamento, applicazioni utilizzate nella selezione e gestione del personale, nella valutazione dell’affidabilità creditizia delle persone, nelle infrastrutture critiche, in determinati prodotti regolamentati come alcuni dispositivi medici e in specifiche attività legate all’amministrazione della giustizia. Per questi sistemi sono previsti requisiti particolarmente rigorosi relativi, tra gli altri aspetti, alla gestione dei rischi, ai dati, alla documentazione tecnica, alla registrazione delle attività, alla trasparenza, alla supervisione umana, all’accuratezza, alla robustezza e alla cybersicurezza. Gli obblighi concretamente applicabili dipendono però anche dal ruolo ricoperto dall’organizzazione.
• Un livello diverso riguarda i sistemi soggetti principalmente a obblighi di trasparenza. In determinate circostanze l’utente deve, per esempio, poter comprendere che sta interagendo con un sistema di IA; specifici obblighi riguardano inoltre contenuti generati o manipolati artificialmente e particolari sistemi biometrici o di riconoscimento delle emozioni.
• Restano infine le applicazioni che non ricadono nelle categorie maggiormente regolamentate e che vengono comunemente indicate come sistemi a rischio minimo o nullo. Possono rientrare in quest’area, a seconda delle caratteristiche concrete del sistema, applicazioni come filtri anti-spam o alcune funzioni di IA incorporate nei videogiochi. In questi casi l’AI Act non introduce lo stesso livello di adempimenti previsto per i sistemi ad alto rischio, pur restando applicabili eventuali altre normative pertinenti.

Questa classificazione orientativa risponde però soltanto alla prima domanda: quanto è regolamentato il sistema? Per sapere cosa deve fare concretamente un’azienda occorre rispondere alla seconda: quale ruolo svolge rispetto a quel sistema?

Fornitore o utilizzatore: identificare il proprio perimetro di responsabilità

Prima di pianificare qualsiasi adeguamento, un’organizzazione deve chiarire la propria posizione all’interno della filiera tecnologica. L’AI Act distingue diverse figure, ma per molte aziende la prima distinzione da compiere è quella tra fornitore (provider) e deployer, cioè il soggetto che utilizza il sistema sotto la propria autorità.

Il fornitore (provider) è il soggetto che sviluppa un sistema di intelligenza artificiale, o lo fa sviluppare, e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio. Non è quindi necessario aver scritto internamente ogni riga di codice per essere considerati provider.

Per un’azienda essere provider significa assumersi la responsabilità principale della conformità del sistema prima della sua commercializzazione o messa in servizio. Nel caso dei sistemi ad alto rischio questo comporta, tra le altre cose, predisporre un sistema di gestione dei rischi e della qualità, assicurare il rispetto dei requisiti applicabili ai dati, redigere e conservare la documentazione tecnica, predisporre meccanismi di registrazione e supervisione umana, effettuare la procedura di valutazione della conformità, redigere la dichiarazione UE di conformità e apporre la marcatura CE quando richiesta.

L’utilizzatore (deployer) è invece qualsiasi persona fisica o giuridica che utilizza un sistema di IA sotto la propria autorità nell’ambito della propria attività, escluso l’utilizzo per finalità personali non professionali. Un’azienda che acquista una soluzione di IA da un fornitore esterno per selezionare candidati, supportare il servizio clienti o assistere determinate decisioni aziendali opera normalmente come deployer.

Essere deployer, tuttavia, non significa essere privi di responsabilità. Per i sistemi ad alto rischio il deployer deve adottare misure tecniche e organizzative idonee a utilizzare il sistema conformemente alle istruzioni ricevute, affidare la supervisione umana a persone dotate di competenza, formazione e autorità adeguate e, nella misura in cui esercita il controllo sui dati di input, garantirne la pertinenza e la sufficiente rappresentatività rispetto alla finalità prevista. Deve inoltre monitorare il funzionamento del sistema secondo le istruzioni per l’uso e intervenire nei casi previsti dal Regolamento quando emergono rischi o incidenti. Quando i log generati dal sistema sono sotto il suo controllo, deve conservarli secondo le condizioni previste dal regolamento. Specifici obblighi possono scattare anche quando il sistema viene impiegato sul luogo di lavoro.

La differenza può essere sintetizzata così: il provider deve dimostrare che il sistema è stato progettato e immesso sul mercato in modo conforme; il deployer deve dimostrare di utilizzarlo in modo conforme e controllato.

Il confine, però, non è sempre immutabile. Un’azienda che inizialmente acquista un sistema di terze parti può, in alcune circostanze, assumere a sua volta gli obblighi del provider. Questo può accadere, per esempio, quando appone il proprio nome o marchio su un sistema ad alto rischio, quando vi apporta una modifica sostanziale oppure quando ne cambia la finalità prevista in modo tale da trasformare un sistema precedentemente non classificato come ad alto rischio in un sistema ad alto rischio.

È proprio questo passaggio a rendere insufficiente una classificazione basata sulla semplice domanda «abbiamo sviluppato noi il software?». Per stabilire le responsabilità occorre analizzare come il sistema è stato acquisito, modificato, integrato, presentato e concretamente utilizzato dall’organizzazione.

Come impostare la valutazione d’impatto nella propria organizzazione

Affrontare l’implementazione dell’AI Act richiede quindi un percorso graduale che parte dalla mappatura interna degli strumenti di IA già in uso o in fase di adozione. Il censimento non dovrebbe limitarsi al nome del software, ma indicare almeno la sua finalità, il processo aziendale nel quale viene utilizzato, le persone potenzialmente coinvolte nelle sue decisioni, il fornitore e il livello di autonomia con cui opera.

Per ogni sistema censito, l’organizzazione dovrebbe quindi porsi tre domande consecutive: che cosa fa questo sistema? Qual è il nostro ruolo rispetto al sistema? In quale categoria normativa rientra questo specifico utilizzo?

La prima verifica serve a individuare eventuali utilizzi vietati o soggetti a particolari condizioni. La seconda permette di capire se l’azienda opera come provider, deployer o ricopre un’altra posizione nella catena del valore. Soltanto a questo punto ha senso procedere alla classificazione del rischio e costruire la relativa lista degli adempimenti.

Se l’azienda utilizza un’applicazione commerciale che non rientra tra quelle ad alto rischio, il carico di conformità previsto dall’AI Act può essere relativamente contenuto, anche se possono restare obblighi di trasparenza o requisiti derivanti da altre normative, come il GDPR.

Se invece il sistema viene utilizzato in un ambito potenzialmente ad alto rischio, come determinate attività di selezione del personale, la verifica deve diventare più approfondita. Il deployer dovrà innanzitutto accertarsi di utilizzare il sistema secondo la finalità e le istruzioni definite dal provider, individuare chi esercita la supervisione umana, verificare, quando sono sotto il suo controllo, la pertinenza e la sufficiente rappresentatività dei dati di input, stabilire come controllarne gli output e definire procedure per gestire anomalie, rischi e incidenti.

La documentazione fornita dal provider diventa quindi un elemento essenziale della valutazione: non basta sapere che uno strumento utilizza l’intelligenza artificiale, ma occorre comprendere per quale finalità è stato progettato, quali sono i suoi limiti, quali rischi sono stati individuati e quali misure di controllo deve applicare chi lo utilizza.

Anche il concetto di valutazione d’impatto deve essere utilizzato con precisione. L’AI Act non impone indistintamente a qualsiasi azienda una valutazione d’impatto sui diritti fondamentali per ogni sistema di IA. Questo specifico adempimento riguarda le categorie di deployer e i sistemi ad alto rischio individuati dall’articolo 27. Quando vengono trattati dati personali può inoltre essere necessario valutare separatamente l’obbligo di effettuare una valutazione d’impatto sulla protezione dei dati prevista dal GDPR. Nei casi in cui alcuni obblighi della valutazione sui diritti fondamentali siano già soddisfatti attraverso la valutazione d’impatto sulla protezione dei dati, il Regolamento consente di richiamarne o includerne le parti pertinenti.

La conformità all’AI Act non nasce quindi da una checklist identica per tutte le organizzazioni. Il percorso corretto consiste nel mappare i sistemi, identificare il proprio ruolo, verificare la finalità d’uso, classificare il rischio e soltanto dopo individuare gli obblighi applicabili.

È questo incrocio tra ruolo, finalità e livello di rischio a determinare il vero perimetro di responsabilità di un’azienda. Due organizzazioni possono utilizzare la stessa tecnologia ma trovarsi di fronte a obblighi completamente diversi: una perché si limita a impiegare il prodotto secondo le istruzioni del fornitore, l’altra perché lo modifica, lo integra in un proprio servizio o ne cambia la destinazione d’uso.

Per questo il primo esercizio di conformità non dovrebbe essere chiedersi «quali documenti richiede l’AI Act?», ma piuttosto «quali sistemi di IA utilizziamo, cosa fanno, che ruolo abbiamo rispetto a ciascuno di essi e quali persone possono essere coinvolte dalle loro decisioni?». Solo dopo aver risposto a queste domande è possibile trasformare il regolamento in un piano operativo concreto.