intelligenza artificiale

AI ACT, come definire ruoli e responsabilità per evitare sanzioni: la guida per imprese e PA



Indirizzo copiato

Il Regolamento Europeo sull’Intelligenza Artificiale (AI Act) impone obblighi variabili a fornitori e deployer di sistemi IA, determinati dal loro ruolo nella catena di fornitura. Le responsabilità si estendono alla compliance, gestione dei rischi e trasparenza, con un focus particolare sui sistemi ad alto rischio

Pubblicato il 4 nov 2024

Alessandro Gui

Partner di Intellera Consulting

Pablo Ivankovich

Senior Aassociate di Intellera Consulting

Sara Mancini

Director di Intellera Consulting

Federico Pozzi

Senior Associate di Intellera Consulting

Alberto Venditti

Associate di Intellera Consulting



intelligenza artificiale pmi startup (1)

Il Regolamento Europeo sull’Intelligenza Artificiale (AI Act) pone una serie di obblighi alle imprese e alle pubbliche amministrazioni operanti su territorio europeo, che nell’ottica del legislatore permettono di garantire un utilizzo responsabile dei sistemi di IA, tutelando così i diritti fondamentali dei cittadini. Non tutti, però, saranno soggetti agli stessi obblighi, che variano in base al ruolo dell’organizzazione della catena di fornitura del singolo sistema IA.

In particolare, l’AI Act distingue principalmente tra fornitori e deployer, ossia tra chi sviluppa il sistema IA e lo immette sul mercato o in servizio sotto la propria responsabilità, e chi lo utilizza. L’AI Act prevede poi degli obblighi specifici per i fornitori di modelli IA che il Regolamento definisce come modelli di IA per finalità generali (general-purpose), definizione che viene estesa anche ai grandi sistemi di IA generativa. Infine, alcuni obblighi specifici sono previsti per altri ruoli nella catena di fornitura, come gli importatori e i distributori di sistemi IA.

Ciò detto, le definizioni (seppur precise nel Regolamento) sono molto più labili nella concreta applicazione. Questo è vero in particolar modo per il confine che distingue i fornitori dai deployer di sistemi di IA, che spesso è difficile da individuare o distinguere. Molte organizzazioni si possono configurare sia come fornitori sia come deployer a seconda del caso specifico considerato.

Al fine di evitare possibili sanzioni e garantire la conformità normativa, è necessario definire ruoli e responsabilità sia all’interno che all’esterno delle organizzazioni che sviluppano e usano sistemi IA. Così facendo, esse possono operare in un ecosistema consapevole degli obblighi vigenti, dei rischi legati a tale tecnologia e delle azioni necessarie per mitigare gli stessi.

Quando un provider è soggetto agli obblighi dell’AI Act

Sui fornitori di sistemi IA ricadono la maggior parte degli obblighi previsti dall’AI Act, e quindi dei relativi costi di compliance. Nell’ottica del legislatore, ciò è necessario poiché questi operatori economici sono responsabili dello sviluppo dei sistemi IA, considerato come la fase più sensibile nel ciclo di vita dell’IA e in cui è possibile istituire misure di mitigazione per la maggior parte dei rischi insiti in un sistema.

Il Regolamento promuove una definizione dettagliata su chi può essere un provider soggetto agli obblighi di compliance dell’AI Act, che è necessario conoscere per comprendere quando la normativa può incidere sui processi e sulla struttura organizzativa.

Innanzitutto, bisogna definire chi è un provider. La prima condizione fondamentale per caratterizzare un fornitore, secondo l’AI Act, è che questo deve sviluppare o far sviluppare un sistema IA. Tale definizione, però, potrebbe non garantire copertura estensiva a tutte le differenti fasi dello sviluppo di un sistema di IA, articolato secondo le sue componenti (e.g., il modello, il dataset utilizzato, il processo di training, tra le altre). Quindi due organizzazioni che sviluppano componenti distinte di uno stesso sistema potrebbero entrambe configurarsi come fornitori del sistema. La seconda condizione fondamentale aiuta a restringere il campo, poiché prevede che il fornitore debba immettere sul mercato o immettere in servizio lo stesso sistema. Se quindi uno stesso sistema IA è sviluppato da più organizzazioni, la definizione di provider ricadrà solo su chi effettivamente lo vende. L’AI Act poi specifica che questo deve avvenire “con il proprio nome o marchio”, determinando i criteri per qualificare il fornitore del sistema IA.

Questo aspetto è particolarmente interessante, perché impatta le organizzazioni nelle relative procedure di procurement. Infatti, per assicurare chiarezza in termini di ruoli e responsabilità, gli accordi di un’organizzazione con la propria catena di fornitura di sistemi IA devono includere delle cautele in questo senso, specificando chi si configura come provider e definendo le responsabilità dei relativi obblighi di compliance per i provider, dove previsto. Questo è particolarmente rilevante in casi ibridi di co-sviluppo del sistema, dove i ruoli non sono nettamente demarcati. Il tema del marchio può supportare la distinzione in questo senso, ma anche qui possono crearsi delle ambiguità, come nel caso in cui uno stesso sistema abbia il marchio di più organizzazioni.

Le persone fisiche o giuridiche, le autorità pubbliche, agenzie o altri organismi che soddisfano queste condizioni si configurano quindi come provider. Non tutti i provider di sistemi IA sono però soggetti agli obblighi del regolamento. Gli obblighi dei fornitori si distinguono a seconda del livello di rischio del sistema IA per cui l’organizzazione si qualifica come fornitore. In particolare, gli obblighi che comportano i maggiori oneri di compliance sono quelli relativi ai sistemi considerati dall’AI Act ad alto rischio. Tra questi rientrano la piena conformità ai requisiti del Regolamento in termini di risk management, data governance, cybersecurity, documentazione, ecc., relativa verifica ed elaborazione di una dichiarazione di conformità, la predisposizione di un sistema di gestione della qualità, la conservazione di documentazione tecnica e dei log relativi ai sistemi di IA, conformità a requisiti di accessibilità e l’applicazione marcatura CE sul sistema di IA ad alto rischio.

Il Regolamento poi distingue per i sistemi IA proibiti, per cui il fornitore ha l’obbligo di non immetterli in servizio o sul mercato, e sistemi IA con obblighi di trasparenza, per cui il fornitore ha la responsabilità di condividere alcune informazioni con i deployer.

In realtà il Regolamento prevede alcune eccezioni: ad esempio se il sistema IA è utilizzato a scopi militari, di difesa o sicurezza nazionale non rientra nel perimetro dell’AI Act, così come se il sistema viene utilizzato a titolo personale.

Gli obblighi dei fornitori di sistemi IA ad alto rischio sono dunque significativi e quindi la definizione di una strategia di compliance dovrebbe essere opportunamente organizzata a livello aziendale, visti gli impatti sia ai livelli gerarchici (verticalmente) che a livello operativo e funzionale (orizzontalmente).

Quali obblighi per i deployer di sistemi IA

Identificati gli obblighi vigenti per i fornitori di sistemi IA, è poi opportuno comprendere quali siano invece le responsabilità dei deployer.

Questi, secondo l’AI Act, svolgono un ruolo fondamentale nel garantire la tutela dei diritti fondamentali dei cittadini dell’UE, riconoscendo e mitigando i rischi che possono essere generati dall’utilizzo dei sistemi IA. A tal proposito, i deployer integrano gli obblighi dei fornitori e riescono ad individuare potenziali rischi non previsti nella fase di sviluppo, in virtù di una conoscenza più puntuale del contesto di utilizzo e dei soggetti che potrebbero essere interessati.

Nell’esperienza di Intellera, tale capacità assume maggiore rilievo in settori come la previdenza sociale o Energy & Utilities, nei quali gli effetti dannosi dei sistemi IA in uso potrebbero pregiudicare gravemente i soggetti interessati. Al fine di garantire un uso sicuro e responsabile di tali sistemi, dunque, Intellera propone la definizione chiara e precisa delle responsabilità all’interno della struttura organizzativa ed al suo esterno, coinvolgendo attivamente i fornitori delle soluzioni IA che saranno utilizzate per verificare la corretta e completa ricezione di tutte le informazioni relative al sistema, in particolar modo se lo stesso è ad alto rischio. Un approccio simile consente di conoscere tutti i rischi legati ai sistemi IA – riguardo lo sviluppo ed il loro utilizzo – comprendere chiaramente in capo a chi sono le responsabilità e relativi obblighi di conformità e adottare misure di prevenzione e mitigazione dei rischi in maniera tempestiva ed uniforme rispetto all’AI Act.

Dunque, tutte le persone – fisiche o giuridiche –, le autorità pubbliche, agenzie o altri organismi, che utilizzano un sistema di IA sotto la propria autorità (a meno che il sistema è utilizzato per un’attività personale non professionale), ricadono nella definizione di deployer. Il Regolamento viene inoltre applicato a quei deployer che sono stabiliti o situati in un paese terzo, a patto che l’output prodotto dal sistema IA venga impiegato in uno dei paesi parte dell’UE. Come anticipato per i fornitori, anche ai deployer è vietato l’utilizzo di sistemi proibiti, mentre per i sistemi a rischio basso vi è la condivisione di obblighi di trasparenza insieme ai fornitori. I sistemi ad alto rischio, invece, determinano l’obbligatorietà per i deployer di svolgere attività di informazione e monitoraggio continuo, così come condurre valutazioni dell’impatto rispetto ai diritti fondamentali dei soggetti interessati dal loro uso.

Maggiori dettagli sugli obblighi specifici dei deployer possono essere trovati nell’approfondimento apposito già disponibile su Agenda Digitale.

Quando un deployer si qualifica come fornitore di sistemi IA

L’AI Act specifica i casi in cui i deployer di sistemi IA possano qualificarsi anche come fornitori. In particolare, il Regolamento prevede le seguenti casistiche specifiche:

  • Il deployer appone il proprio nome o marchio su un sistema IA ad alto rischio già immesso sul mercato o messo in servizio, fatti salvi accordi contrattuali che prevedono una diversa ripartizione degli obblighi. Un esempio di questa casistica può essere rappresentato dai sistemi IA per le diagnosi mediche, i quali rientrano nella categoria di sistemi ad alto rischio poiché impattano direttamente la salute degli individui. Se questi sistemi, già immessi sul mercato, vengono utilizzati da terzi senza apporre il proprio marchio, lo sviluppatore si qualifica come fornitore, mentre i terzi risulteranno essere deployer. Se, al contrario, i terzi forniscono a loro volta servizi di tipo sanitario e decidono di offrire una soluzione di questo tipo ai propri clienti apponendo il loro marchio sul tool, essi non si qualificano come deployer, bensì saranno soggetti agli obblighi previsti dal Regolamento per i fornitori.
  • Il deployer apporta una modifica sostanziale a un sistema IA ad alto rischio già immesso sul mercato o messo in servizio. Un esempio concreto di tale scenario può verificarsi nel settore automobilistico, per quanto riguarda i sistemi di guida automatica dei veicoli. Tali sistemi, già ampiamente disponibili sul mercato, sono da considerare ad alto rischio per l’impatto che potrebbero avere sulla salute dei loro utenti. Dunque, se uno sviluppatore di sistemi che possono essere integrati nei tool di guida automatica aggiungesse funzionalità ulteriori, potrebbe modificare in maniera sostanziale il sistema. Così facendo, lo sviluppatore (deployer) andrà ad essere configurato come fornitore, dovendo sottostare agli obblighi previsti dall’AI Act.
  • Il deployer modifica la finalità prevista di un sistema di IA, compresi i sistemi IA general purpose non classificati come sistemi ad alto rischio e già immessi sul mercato o messi in servizio. In questo caso, tali sistemi sono considerati ad alto rischio. A titolo esemplificativo, casi simili possono verificarsi in contesti ampi e variegati. Infatti, la modifica di tool di IA a finalità generale (chatbot, generazione di contenuto, ecc.) per, ad esempio, prendere decisioni in termini di accesso a servizi di prima necessità o di diagnosi clinica, ne cambia radicalmente le finalità, rendendoli sistemi IA ad alto rischio. In questo caso, il soggetto che apporta tali modifiche ha l’obbligo di rispettare le predisposizioni per i fornitori indicate nel Regolamento.

Ebbene, in questi casi specifici, il deployer dovrebbe essere considerato un fornitore di un sistema IA ad alto rischio e, pertanto, assumere tutti gli obblighi previsti.

Quali obblighi per gli Enti Pubblici

Nonostante la possibilità per le pubbliche amministrazioni di agire come fornitori ai sensi della legge, esse rientreranno nella maggior parte dei casi nella categoria dei distributori/deployer. A questo proposito, oltre agli obblighi già elencati per i deployer, alcune specificità che vale la pena considerare per gli Enti Pubblici includono:

  • Trattenersi dall’utilizzo di un sistema di IA ad alto rischio che non sia già registrato nella banca dati dell’UE: le autorità pubbliche hanno il dovere di registrare l’uso di sistemi di IA ad alto rischio nella banca dati dell’UE. Questo obbligo è facoltativo per tutti gli altri utilizzatori.
  • Effettuare una valutazione d’impatto sui diritti fondamentali: le autorità pubbliche sono tenute a effettuare una valutazione d’impatto sui diritti fondamentali prima di installare qualsiasi sistema di IA ad alto rischio. I risultati della valutazione devono essere condivisi con l’autorità di sorveglianza competente.
  • Invio di informazioni specifiche a un database regionale di sistemi di IA ad alto rischio: questo integra le informazioni già fornite dal fornitore del sistema, includendo i dettagli di contatto, una sintesi dei risultati della valutazione d’impatto sui diritti fondamentali e una sintesi della valutazione d’impatto sulla protezione dei dati.

Questi obblighi dovranno probabilmente essere coniugati con le Linee Guida che AgID promulgherà come dettagliato nella Strategia Italiana per l’Intelligenza Artificiale 2024-2026.

GPAI model provider e quali obblighi

Prima di immettere sul mercato un modello di IA per finalità generali, i fornitori degli stessi devono rispettare specifici obblighi introdotti dall’AI Act, qui delineati:

  • Redigere e aggiornare tutta la documentazione tecnica relativa al modello di IA, come richiesto dai requisiti introdotti nel Regolamento.
  • Elaborare, aggiornare e mettere a disposizione tutte le informazioni per altri fornitori che chiedono di integrare il modello di IA per finalità generali all’interno dei propri sistemi.
  • Assicurare la tutela del diritto d’autore.
  • Redigere e mettere a disposizione del pubblico sintesi dettagliate dei contenuti usati per addestrare il modello.

Questi obblighi, in realtà, non si applicano ai fornitori di modelli di IA rilasciati con licenza libera e open source che garantiscano l’accesso, l’uso, la modifica e la distribuzione del modello e i cui parametri sono resi pubblici. In questa casistica, dunque, rientrano sistemi come GPT-Neo e GPT-J, Stable Diffusion, DALL-E Mini e CLIP (OpenAI).

EU Stories - La coesione innova l'Italia

Tutti
Social
Iniziative
Video
Analisi
Iniziative
Al via il progetto COINS
Eventi
Un nuovo sguardo sulla politica di coesione dell'UE
Iniziative
Parte la campagna di comunicazione COINS
Interviste
Marco De Giorgi (PCM): “Come comunicare le politiche di coesione”
Analisi
La politica di coesione europea: motore della transizione digitale in Italia
Politiche UE
Il dibattito sul futuro della Politica di Coesione
Mobilità Sostenibile
L’impatto dei fondi di coesione sul territorio: un’esperienza di monitoraggio civico
Iniziative
Digital transformation, l’Emilia-Romagna rilancia sulle comunità tematiche
Politiche ue
Fondi Coesione 2021-27: la “capacitazione amministrativa” aiuta a spenderli bene
Finanziamenti
Da BEI e Banca Sella 200 milioni di euro per sostenere l’innovazione di PMI e Mid-cap italiane
Analisi
Politiche di coesione Ue, il bilancio: cosa ci dice la relazione 2024
Politiche UE
Innovazione locale con i fondi di coesione: progetti di successo in Italia
Iniziative
Al via il progetto COINS
Eventi
Un nuovo sguardo sulla politica di coesione dell'UE
Iniziative
Parte la campagna di comunicazione COINS
Interviste
Marco De Giorgi (PCM): “Come comunicare le politiche di coesione”
Analisi
La politica di coesione europea: motore della transizione digitale in Italia
Politiche UE
Il dibattito sul futuro della Politica di Coesione
Mobilità Sostenibile
L’impatto dei fondi di coesione sul territorio: un’esperienza di monitoraggio civico
Iniziative
Digital transformation, l’Emilia-Romagna rilancia sulle comunità tematiche
Politiche ue
Fondi Coesione 2021-27: la “capacitazione amministrativa” aiuta a spenderli bene
Finanziamenti
Da BEI e Banca Sella 200 milioni di euro per sostenere l’innovazione di PMI e Mid-cap italiane
Analisi
Politiche di coesione Ue, il bilancio: cosa ci dice la relazione 2024
Politiche UE
Innovazione locale con i fondi di coesione: progetti di successo in Italia

Articoli correlati

Articolo 1 di 4