Affrontare l’AI Act scaricando un modello standard o spuntando le caselle di una checklist generica rischia di produrre molta documentazione e poca conformità reale. Il Regolamento europeo sull’Intelligenza Artificiale non disciplina infatti l’IA in astratto: gli obblighi cambiano in funzione di come un sistema viene utilizzato, quale ruolo ricopre l’organizzazione e quali effetti può produrre sulle persone.
Per questo, prima ancora di chiedersi quali documenti predisporre, un’azienda dovrebbe capire dove si trova l’intelligenza artificiale nei propri processi e chi ne governa realmente l’utilizzo.
Una checklist diventa utile soltanto dopo questo passaggio. Applicarla prima significa rischiare di controllare molto bene sistemi poco rilevanti e, contemporaneamente, lasciare fuori proprio gli utilizzi che espongono l’organizzazione ai rischi maggiori.
Le domande da porsi sono cinque.
Il primo problema non è classificare i sistemi, ma sapere che esistono.
In molte organizzazioni l’utilizzo dell’intelligenza artificiale si sviluppa più velocemente dei processi con cui l’IT, il legal o il risk management riescono a censirlo. Un reparto marketing può utilizzare strumenti generativi per produrre contenuti, le risorse umane possono sperimentare applicazioni per analizzare candidature, gli sviluppatori possono integrare API esterne e singoli dipendenti possono utilizzare account personali di servizi di IA per sintetizzare documenti o analizzare informazioni.
È il fenomeno comunemente definito Shadow AI, ma limitare il censimento agli strumenti utilizzati senza autorizzazione sarebbe comunque insufficiente.
L’intelligenza artificiale può essere presente anche all’interno di software aziendali già approvati: CRM, piattaforme HR, strumenti di cybersecurity, applicazioni di produttività o servizi cloud possono introdurre progressivamente funzionalità basate su IA senza che l’organizzazione le percepisca come un nuovo sistema da valutare.
Il censimento dovrebbe quindi partire non tanto dal nome della tecnologia, quanto dal caso d’uso.
Per ogni applicazione occorre sapere almeno:
La differenza è sostanziale. Utilizzare lo stesso modello generativo per correggere lo stile di una newsletter e utilizzarlo per valutare automaticamente una candidatura non rappresentano lo stesso caso d’uso, anche se la tecnologia sottostante fosse identica.
La prima domanda dovrebbe quindi produrre una mappa dei sistemi e dei casi d’uso dell’IA presenti nell’organizzazione. Senza questa fotografia iniziale, qualsiasi percorso di conformità parte da informazioni incomplete.
Una volta individuati i sistemi, la seconda domanda riguarda la posizione dell’azienda nella filiera.
L’AI Act distingue diverse figure, tra cui fornitore (provider) e deployer, e a ciascuna associa responsabilità differenti.
Un’azienda che acquista un servizio di IA già presente sul mercato e lo utilizza secondo la finalità prevista dal produttore opera normalmente come deployer. Chi invece sviluppa un sistema, o lo fa sviluppare e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio, può assumere il ruolo di provider.
La distinzione, però, non può essere risolta semplicemente chiedendosi «abbiamo scritto noi il codice?».
In determinate circostanze anche un soggetto che parte da una tecnologia sviluppata da altri può assumere gli obblighi del provider. Per i sistemi ad alto rischio, l’AI Act disciplina, tra gli altri, i casi in cui un soggetto appone il proprio nome o marchio su un sistema già immesso sul mercato o messo in servizio, apporta una modifica sostanziale oppure modifica la finalità prevista di un sistema non classificato ad alto rischio in modo tale da farlo diventare ad alto rischio.
Questo aspetto diventa particolarmente importante nei progetti aziendali basati su tecnologie di terze parti.
Acquistare un chatbot e utilizzarlo così come viene fornito è una situazione. Integrare modelli esterni all’interno di un proprio prodotto, modificarne il funzionamento, costruire un sistema attorno a essi o cambiarne la destinazione d’uso può aprire scenari differenti, da valutare caso per caso.
Per ogni caso d’uso l’organizzazione deve quindi chiedersi:
stiamo semplicemente utilizzando questo sistema oppure ciò che abbiamo fatto attorno alla tecnologia modifica anche le nostre responsabilità?
Il risultato di questa seconda analisi dovrebbe essere una mappa dei ruoli regolamentari. Soltanto dopo averla costruita è possibile capire quali obblighi competono al fornitore della tecnologia e quali restano in capo all’azienda che la utilizza.
A questo punto diventa possibile affrontare il tema del rischio.
L’AI Act adotta un approccio basato sul rischio, ma classificare un sistema non significa attribuire automaticamente un’etichetta alla tecnologia utilizzata. Occorre guardare soprattutto alla finalità prevista e al contesto concreto di utilizzo.
La domanda più utile, prima ancora di chiedersi se un’applicazione sia formalmente ad alto rischio, è quindi: che cosa succede se questo sistema sbaglia?
Un errore nella generazione della bozza di un post aziendale può essere facilmente individuato e corretto prima della pubblicazione. Un errore in un sistema utilizzato per valutare candidati, supportare decisioni relative ai lavoratori o determinare l’accesso di una persona a un servizio essenziale può avere conseguenze molto diverse.
È proprio questa relazione tra tecnologia, finalità e persone coinvolte che deve guidare l’analisi.
L’AI Act individua specifiche categorie di sistemi ad alto rischio, tra cui determinati utilizzi nell’occupazione e nella gestione dei lavoratori, nell’istruzione, nell’accesso ad alcuni servizi essenziali e in altri ambiti sensibili. La classificazione richiede tuttavia di verificare le condizioni previste dal regolamento e non dovrebbe essere dedotta semplicemente dal settore nel quale viene utilizzato un software.
Per questo un inventario realmente utile dovrebbe registrare, oltre alla tecnologia utilizzata, almeno tre elementi: la decisione che il sistema supporta, le persone sulle quali quella decisione può produrre effetti e il grado di autonomia attribuito all’output dell’IA.
C’è infatti una differenza significativa tra un sistema che fornisce un suggerimento successivamente valutato da un professionista e uno il cui risultato viene recepito automaticamente all’interno di un processo.
Questa terza domanda dovrebbe quindi produrre una mappa degli impatti e dei rischi, che permetta all’organizzazione di concentrare controlli e risorse dove le conseguenze potenziali sono maggiori.
Una volta identificati sistemi, ruoli e rischi, emerge il problema centrale della governance: chi è responsabile di cosa?
In molte organizzazioni, la responsabilità sull’intelligenza artificiale è distribuita implicitamente tra più funzioni. L’IT governa la tecnologia, il legal verifica gli aspetti normativi, il privacy officer presidia i dati personali, la cybersecurity valuta i rischi tecnici e il business utilizza concretamente il sistema.
Questa distribuzione non è necessariamente un problema. Lo diventa quando nessuno possiede una responsabilità chiaramente definita sul caso d’uso nel suo complesso.
Per ogni sistema rilevante dovrebbe essere possibile sapere chi ne autorizza l’adozione, chi ne verifica il funzionamento, chi controlla gli output, chi gestisce un eventuale incidente e chi può decidere di sospenderne l’utilizzo.
La supervisione umana, in particolare per i sistemi ad alto rischio, non dovrebbe essere interpretata come la semplice presenza di una persona alla fine del processo.
Per i sistemi ad alto rischio, l’AI Act prevede che la supervisione sia effettiva e proporzionata al rischio, al livello di autonomia e al contesto d’uso del sistema. Le persone incaricate devono essere messe nelle condizioni di comprenderne capacità e limiti, interpretarne correttamente gli output, evitare un affidamento automatico sui risultati e, quando necessario, ignorare, sostituire o modificare l’output oppure intervenire sul funzionamento del sistema o interromperlo.
È qui che emerge uno dei problemi più concreti dell’adozione aziendale dell’IA: avere una persona formalmente responsabile non serve se quella persona non possiede competenze, informazioni o autorità per intervenire realmente.
La domanda diventa quindi: se domani il sistema produce un risultato evidentemente sbagliato o potenzialmente dannoso, sappiamo chi deve accorgersene, chi deve intervenire e chi ha il potere di fermarlo?
Se la risposta non è immediata, il problema è prima di tutto organizzativo.
La conformità all’AI Act non può esaurirsi con l’approvazione iniziale di uno strumento.
I sistemi cambiano, i fornitori aggiornano i modelli, vengono introdotte nuove funzionalità, cambiano i dati utilizzati e, soprattutto, cambiano i modi in cui i dipendenti impiegano gli strumenti.
Un sistema approvato oggi per una determinata finalità potrebbe essere utilizzato tra sei mesi in un processo completamente diverso.
Per questo l’ultima domanda riguarda la capacità dell’organizzazione di governare l’intelligenza artificiale nel tempo.
Rientra qui anche l’AI literacy prevista dall’articolo 4 del regolamento. Provider e deployer devono adottare misure per sostenere lo sviluppo dell’alfabetizzazione in materia di IA del personale e delle altre persone che operano sui sistemi per loro conto, considerando competenze, esperienza, formazione, contesto di utilizzo e persone sulle quali i sistemi vengono impiegati. La disciplina vigente chiarisce inoltre che ciò non comporta l’obbligo di garantire uno specifico livello individuale di competenza a ogni persona.
Questo significa che non esiste un corso di AI literacy valido allo stesso modo per tutti.
Un dipendente che utilizza occasionalmente un assistente generativo deve conoscere, ad esempio, i rischi legati alle allucinazioni, ai dati riservati e all’affidabilità degli output. Un responsabile HR che utilizza sistemi di IA all’interno di processi che riguardano i lavoratori necessita di competenze differenti. Chi sviluppa o integra sistemi deve possedere conoscenze ancora più approfondite sui limiti tecnici, sui dati e sui meccanismi di controllo.
Ma la formazione rappresenta soltanto una parte del problema: governare l’IA nel tempo significa anche stabilire quando un sistema deve essere riesaminato, cosa accade quando il provider modifica il prodotto, quali incidenti devono essere segnalati internamente, come vengono gestiti nuovi casi d’uso e chi verifica periodicamente che uno strumento venga ancora utilizzato per la finalità per cui era stato approvato.
Significa, in altre parole, passare da un progetto di adeguamento a un processo permanente di governo dell’IA.
Soltanto dopo aver risposto a queste cinque domande una checklist diventa realmente utile.
A quel punto l’organizzazione dispone di una mappa dei sistemi, sa quale ruolo ricopre rispetto a ciascuno di essi, conosce gli impatti potenziali, ha assegnato le responsabilità interne e ha definito un processo per controllare l’uso dell’IA nel tempo.
È su questa base che possono essere costruiti gli adempimenti: documentazione, procedure di approvazione, formazione, supervisione umana, controlli sui fornitori, gestione degli incidenti e verifiche periodiche.
Il punto non è quindi evitare le checklist. È evitare di utilizzarle prima di sapere a che cosa devono essere applicate.
Un’azienda può avere policy impeccabili sull’intelligenza artificiale e continuare a non sapere che il reparto commerciale sta caricando documenti riservati su un servizio esterno. Può avere un comitato AI e non aver stabilito chi possa interrompere un sistema quando produce risultati inattendibili. Può aver classificato correttamente un software e non essersi accorta che il modo in cui viene utilizzato è cambiato.
La conformità nasce prima della documentazione. Nasce quando l’organizzazione è in grado di rispondere con chiarezza a cinque domande: dove utilizziamo l’IA, che ruolo abbiamo, su chi può incidere, chi ne mantiene il controllo e come continueremo a governarla quando tecnologia e utilizzi cambieranno.
Solo allora la checklist smette di essere un esercizio burocratico e diventa uno strumento di governo.
Articoli correlati
L’integrazione dell’intelligenza artificiale nei processi produttivi genera spesso il timore di una progressiva sostituzione dell’essere umano. Tuttavia, i dati delineano uno scenario diverso: circa un
Sempre più spesso, durante le riunioni strategiche o di aggiornamento aziendale, emergono sigle come LLM, RAG o prompt. Non si tratta più di un linguaggio
Aprire ChatGPT per farsi aiutare a scrivere una mail complessa, riassumere un lungo report o correggere una porzione di codice è diventata un’abitudine quotidiana per
Il rischio di estinzione da intelligenza artificiale è tornato al centro del discorso pubblico. Questa volta con una firma precisa: il 9 settembre un ricercatore
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
Sapere quando interrompere un’iniziativa di intelligenza artificiale è uno dei test più severi per la governance aziendale. Nella narrazione dominante sull’innovazione tecnologica, l’abbandono di un’iniziativa
