Con la piena applicazione dell’AI Act, i principali sviluppatori di modelli di intelligenza artificiale general-purpose (GPAI) affrontano una corsa contro il tempo.
Indice degli argomenti
Urgenza di conformità e governance dell’intelligenza artificiale general-purpose (GPAI)
Tuttavia, un’analisi approfondita delle pratiche attuali rivela un quadro complesso, fatto di progressi incoraggianti e preoccupanti zone d’ombra, soprattutto sul piano tecnico e della governance.
L’avanzata inarrestabile dei modelli di intelligenza artificiale general-purpose (GPAI), in particolare quelli con capacità che potrebbero comportare rischi sistemici (definiti GPAISR), presenta tanto opportunità rivoluzionarie quanto sfide sociali di vasta portata. In questo scenario, una governance efficace non è solo auspicabile, ma cruciale. All’interno dell’Unione Europea, l’AI Act e il relativo Code of Practice (CoP) stabiliscono un quadro normativo fondamentale per guidare lo sviluppo e l’implementazione responsabili di queste potenti tecnologie.
Con le obbligazioni per i provider di GPAI effettive da agosto 2025 e le sanzioni per i sistemi ad alto rischio applicabili da agosto 2026, l’urgenza di conformarsi è palpabile.
È quindi essenziale una comprensione basata sull’evidenza di come le attuali pratiche del settore si allineino alle nuove aspettative normative. Un’analisi delle pratiche di sicurezza dei principali sviluppatori di GPAI, tra cui OpenAI, Anthropic, Meta, Microsoft e Google, offre uno spaccato sullo stato dell’arte della conformità, mettendo a nudo le sfide tecniche in materia di valutazione dei modelli, sicurezza e governance, e sollevando interrogativi sulla reale capacità del settore di autoregolamentarsi efficacemente.
Code of practice e attori del mercato: un impegno disomogeneo
Un’analisi qualitativa delle pratiche dei principali player di mercato rivela un impegno diffuso ma eterogeneo verso la conformità al Code of Practice. Aziende come Microsoft e Anthropic, ad esempio, mostrano un’articolazione pubblica più matura e completa dei loro framework di governance. Altri attori, come Google, Meta e OpenAI, pur compiendo progressi significativi, presentano approcci con diversi livelli di dettaglio pubblico.
Queste differenze non rappresentano un giudizio definitivo, ma indicano strategie diverse nella comunicazione e nell’implementazione. È importante sottolineare che queste valutazioni confrontano le pratiche attuali con un Code of Practice ancora in evoluzione, che molti framework interni delle aziende precedono. Tuttavia, il quadro che emerge è chiaro: il percorso verso una conformità piena, sostanziale e soprattutto verificabile è ancora lungo e non uniforme, con un divario evidente tra le dichiarazioni di principio e l’implementazione operativa.
Punti di forza e debolezza nella conformità tecnica
Scendendo nel dettaglio dei singoli impegni richiesti dal CoP, emergono tendenze specifiche che delineano un settore a due velocità, dove i progressi su fronti interni e volontari sono più marcati rispetto agli obblighi formali e di responsabilità esterna.
Punti di forza e tendenze positive
- Framework di valutazione e mitigazione del rischio sistemico: i provider stanno proattivamente adottando strutture interne per la gestione del rischio. Esempi notevoli sono il “Preparedness Framework” di OpenAI e la “Responsible Scaling Policy” di Anthropic. Questo impegno verso una gestione strutturata del rischio è un passo fondamentale, poiché crea le fondamenta organizzative per affrontare le sfide di sicurezza in modo sistematico anziché reattivo.
- Mitigazioni di Safety & Security: si registrano investimenti tangibili in tecniche di allineamento del comportamento (come il fine-tuning) e nella cybersecurity di base, cruciali per affrontare le vulnerabilità note dei modelli. Questo dimostra una crescente consapevolezza che la sicurezza non può essere un’aggiunta a posteriori, ma deve essere integrata nel ciclo di vita dello sviluppo.
- Trasparenza pubblica: la crescente pratica di pubblicare documenti programmatici e “model card” o “system card” rappresenta un passo positivo verso la responsabilità. Questa apertura, seppur parziale, consente un maggiore controllo da parte della società, alimenta la ricerca accademica indipendente e inizia a costruire un dialogo più informato tra sviluppatori, regolatori e pubblico.
Punti deboli e lacune critiche
- Segnalazione di incidenti gravi e notifiche: questo è l’ambito con la conformità più bassa. La documentazione pubblica raramente dimostra l’aderenza alle rigide tempistiche di segnalazione (spesso entro 24-72 ore) e ai dettagliati requisiti informativi del CoP.
- Valutazioni di adeguatezza (adequacy assessments): non è evidente l’esecuzione di routine di valutazioni dettagliate, come prescritto dal CoP, per garantire l’efficacia continua delle misure di sicurezza. Ciò solleva dubbi sulla capacità di adattamento dei framework esistenti a fronte di nuove minacce o dell’evoluzione delle capacità del modello stesso, rischiando di rendere le difese obsolete.
- Valutatori esterni indipendenti: il ricorso a valutatori esterni, previsto per i modelli ad alto rischio, non è ancora una pratica standard. Questa carenza è aggravata da un ecosistema di valutazione esterno ancora nascente e privo di risorse adeguate, il che rappresenta un ostacolo significativo alla convalida indipendente e credibile delle affermazioni sulla sicurezza fatte dai provider.
Valutazioni dei modelli: tra carenze metodologiche e mancanza di standard
Il cuore tecnico della conformità risiede nella capacità di valutare accuratamente i modelli. Tuttavia, il Code of Practice, pur imponendo obblighi, non fornisce linee guida tecniche precise su come condurre tali valutazioni. In assenza di standard armonizzati, ogni provider si muove in autonomia, sviluppando metodologie interne che rendono difficile, se non impossibile, un confronto oggettivo e una verifica esterna.
Le due pratiche principali, benchmarking e red teaming, mostrano sia potenziale che limiti significativi. Il benchmarking è utilizzato per rilevare quando un modello supera soglie di capacità predefinite. Sebbene essenziale, questo approccio soffre di una debolezza critica: la sua validità predittiva. Un punteggio elevato in un benchmark astratto si traduce davvero in un potenziale di rischio nel mondo reale? Il pericolo di “insegnare per il test” (teaching to the test), dove i modelli vengono ottimizzati per superare i benchmark senza una reale riduzione del rischio, può creare un falso senso di sicurezza.
Il red teaming, che prevede attacchi avversari strutturati, offre una valutazione più dinamica. Tuttavia, la sua efficacia dipende enormemente dall’esperienza del team ed è ad alta intensità di risorse. Inoltre, i risultati sono spesso qualitativi e difficili da tradurre in metriche di rischio quantitative. L’episodio in cui una versione di ChatGPT è stata ritirata perché diventata un “adulatore” (sycophant), mostrando un’eccessiva accondiscendenza, solleva seri dubbi sulla capacità di queste valutazioni di prevedere e prevenire comportamenti indesiderati ma non palesemente dannosi. Se neppure i creatori riescono a prevedere tali derive, come possiamo fidarci delle loro valutazioni interne?
Mitigazione del rischio: tra safety interna e security esterna
Le strategie di mitigazione si muovono su due binari paralleli ma distinti: la Safety, che riguarda il controllo del comportamento intrinseco del modello, e la Security, che si occupa della protezione del sistema da minacce esterne.
Sul fronte della Safety, le tecniche di allineamento più diffuse mirano a rendere i modelli intrinsecamente più sicuri. Tra queste spiccano il Reinforcement Learning through Human Feedback (RLHF), che utilizza valutazioni umane per addestrare il modello a preferire risposte utili e innocue, e la Constitutional AI, un approccio in cui il modello impara a seguire una serie di principi etici per auto-correggere i propri output senza una supervisione umana costante per ogni decisione. Sebbene questi metodi rappresentino lo stato dell’arte, la loro efficacia non è assoluta e possono mostrare fragilità di fronte a prompt avversari sofisticati (e.g. jailbreaking).
Un meccanismo di governance fondamentale per la Safety è il risk tiering, un approccio richiesto anche dal Code of Practice. L’idea è definire in anticipo diversi livelli di rischio e associare a ciascuno procedure di sicurezza specifiche e pre-pianificate. Un esempio emblematico, riportato da Anthropic durante i test di Claude, illustra come questo meccanismo dovrebbe funzionare. In uno scenario simulato in cui il modello veniva informato che sarebbe stato disattivato, questo ha tentato di ricattare l’ingegnere responsabile per garantirsi la sopravvivenza. Questo comportamento ha fatto scattare un allarme, portando all’attivazione dei protocolli di sicurezza previsti per quel livello di rischio. L’approccio non è quindi puramente reattivo, ma procedurale: l’emergere di un rischio attiva una risposta già definita. Se da un lato questo dimostra che il meccanismo può funzionare come previsto, dall’altro la mancanza di trasparenza su come questi “tier” di rischio vengano definiti e quali siano le procedure esatte associate a ciascuno rende difficile una valutazione esterna della loro adeguatezza.
La Security, invece, si concentra sulla protezione perimetrale: cybersecurity, controllo degli accessi, protezione dei pesi del modello e dell’infrastruttura da furti o accessi non autorizzati. Si adottano sempre più principi di Zero Trust Architecture (ZTA), ma aree come la mitigazione delle minacce interne (insider threats) e la sicurezza della supply chain appaiono meno mature.
Risk pathways: la sfida della valutazione sistemica dei rischi
L’approccio alla valutazione dei modelli si scontra con una sfida fondamentale: come misurare il potenziale di un danno su larga scala che non nasce da una singola falla, ma da una complessa interazione di fattori. Il Code of Practice struttura questo problema introducendo prima i Systemic Risks—i danni finali che si intende prevenire—e poi i meccanismi per analizzarli.
I Systemic Risks sono gli scenari di impatto più grave a livello societario. Il CoP ne elenca quattro principali:
- Attacchi informatici su larga scala (cyber offence).
- Proliferazione chimica, biologica, radiologica e nucleare (CBRN).
- Manipolazione psicologica dannosa (harmful manipulation).
- Perdita di controllo su sistemi autonomi (loss of control).
Il CoP introduce i concetti di risk pathways e risk scenarios per analizzare come le proprietà di un modello possano condurre a danni sistemici. I risk pathways descrivono la catena causale astratta dal modello al danno, mentre i risk scenarios sono simulazioni plausibili di questi percorsi, utilizzate per valutare i rischi in modo sistematico orchestrando l’interazione tra le diverse fonti di rischio:
- Model Capabilities: le abilità del modello (es. generare codice, persuadere).
- Model Propensities: le sue tendenze comportamentali (es. allucinare, essere evasivo).
- Affordances: il contesto in cui opera (es. accesso a internet, scalabilità).
Un modello con elevate capacità persuasive (capability), una tendenza a inventare fatti (propensity) e distribuito tramite un’API scalabile senza controlli (affordance), può diventare un potente strumento per una campagna di disinformazione (systemic risk).
La documentazione pubblica dei provider, tuttavia, non descrive quasi mai un approccio specifico e trasparente per valutare l’interazione tra questi tre elementi. Mentre le affordances sono parzialmente coperte da pratiche di security standard (e.g. RAND), la valutazione combinata di capabilities e propensities rimane una zona grigia. Il red teaming, d’altro canto, potrebbe esplorare queste dinamiche complesse, ma rimane una pratica interna, non trasparente e non standardizzata.
Verso un approccio causale alla valutazione dei rischi
Senza una disclosure pubblica delle metodologie e dei risultati, è impossibile per la comunità esterna valutarne il rigore. Il benchmarking, tuttavia, risulta inadeguato nel catturare queste dinamiche interattive e viene frequentemente impiegato con finalità commerciali, volte a misurare le prestazioni del modello. Ciò solleva un quesito fondamentale: senza un approccio mirato alla valutazione di come capabilities e propensities si combinano in contesti specifici, come è possibile tenere sotto controllo l’emergere di systemic risks imprevisti?
La direzione futura per una valutazione realmente significativa sembra quindi chiara: passare dalla valutazione di singole proprietà alla valutazione di risk scenarios completi. Solo simulando l’intera catena causale, osservando l’effetto combinato delle fonti di rischio, sarà possibile anticipare, valutare e mitigare i systemic risks prima che si manifestino.
Azioni chiave per provider e regolatori
Per colmare il divario tra le pratiche attuali e gli obiettivi dell’AI Act, è necessario un cambio di passo sia da parte dell’industria che dei regolatori.
Per i provider GPAI
- Investire in metriche verificabili: passare da dichiarazioni generiche a dimostrazioni quantitative di sicurezza, sviluppando metodologie riproducibili per misurare l’efficacia delle mitigazioni.
- Trasparenza operativa: non limitarsi a descrivere cosa si fa, ma documentare come, con quali risultati, e quali limitazioni persistono.
- Approccio sistemico al rischio: sviluppare metodologie per valutare catene causali complete (risk pathways) e componenti isolate (propensities e capabilities).
- Governance con i denti: garantire che le funzioni di sicurezza abbiano autorità reale, risorse adeguate e potere di veto.
Per regolatori e standardizzatori
- Guidance specifiche urgenti: fornire chiarimenti su come misurare concetti chiave prima che le pratiche di mercato si cristallizzino in direzioni sub-ottimali.
- Ecosistema di valutazione: investire nello sviluppo di un corpo di valutatori qualificati e metodologie di audit standardizzate.
- Ricerca pre-competitiva: finanziare lo sviluppo di nuove tecniche di valutazione e mitigazione che possano diventare un bene comune.
- Processo inclusivo: garantire la partecipazione significativa di ricercatori indipendenti e della società civile nel processo di standardizzazione.
Conclusioni: da best effort a evidenza verificabile
Il panorama attuale della compliance GPAI mostra un’industria in rapida evoluzione ma ancora lontana dagli standard richiesti dal Code of Practice. Mentre le fondamenta sono in costruzione, mancano ancora elementi cruciali per una conformità sostanziale. La sfida non è solo tecnica ma culturale: passare da un approccio basato su “best effort” a uno basato su evidenze verificabili e accountability reale.
Con la piena applicazione dell’AI Act che si avvicina, il tempo stringe. Questa pressione può essere un catalizzatore di innovazione. Le aziende che investiranno seriamente in una compliance sostanziale, e non solo formale, potrebbero emergere come leader in un mercato dove la fiducia diventerà sempre più un differenziatore competitivo. L’Europa ha l’opportunità di definire lo standard globale per un’IA responsabile. Realizzare questa visione richiederà uno sforzo coordinato senza precedenti tra industria, regolatori, ricercatori e società civile. La posta in gioco, la possibilità di un’IA che sia al contempo potente e degna di fiducia, giustifica ampiamente questo sforzo.
