Il Regolamento UE 2024/1689 — l’AI Act — costruisce gran parte dei suoi obblighi attorno a due categorie centrali: i sistemi AI ad alto rischio e i modelli di IA per finalità generali (GPAI). Per un SaaS che integra le API di OpenAI, Anthropic o Google, per una web agency che sviluppa soluzioni AI su misura, per un’azienda che usa strumenti AI in HR, credito o assicurazioni, capire dove ci si colloca non è un esercizio teorico: significa sapere quali adempimenti scattano, chi li deve eseguire e quali sanzioni si rischiano. Questa guida ricostruisce l’architettura completa: cos’è un sistema ad alto rischio, cosa sono i GPAI, quali sono i ruoli (provider, deployer, importer, distributor) e che cosa deve fare ciascuno.

1. Il quadro generale: la piramide del rischio e i due assi dell’AI Act

L’AI Act regola l’intelligenza artificiale lungo due assi paralleli che vanno tenuti distinti: i sistemi di IA e i modelli di IA.

Un sistema di IA è il prodotto finale che interagisce con l’utente o con l’ambiente: ChatGPT, un software di screening dei CV, un motore di credit scoring. Un modello di IA è invece una componente sottostante, addestrata su grandi quantità di dati, che diventa parte di un sistema solo quando viene integrata con altri elementi software e hardware. GPT è il modello, ChatGPT il sistema. Microsoft Copilot, le chat dei SaaS che chiamano API di Anthropic, gli assistenti AI delle web agency sono tutti sistemi costruiti sopra modelli GPAI.

Su questi due assi, il Regolamento costruisce una classificazione per livelli di rischio. Per i sistemi, la piramide va dalle pratiche vietate (art. 5) ai sistemi ad alto rischio, fino ai sistemi a rischio limitato o minimo. Per i modelli, l’AI Act introduce un insieme separato che si colloca a monte dei sistemi: i GPAI standard e i GPAI con rischio sistemico. La logica è che modelli e sistemi vengano valutati separatamente, e che gli adempimenti dei modelli si stratifichino su quelli dei sistemi in cui poi vengono integrati.

Da qui derivano tre domande operative che ogni azienda deve porsi: il mio sistema rientra tra quelli ad alto rischio? Sto usando o integrando un GPAI? Quale ruolo sto giocando — sviluppo, integro, distribuisco, utilizzo?

2. I sistemi AI ad alto rischio: come riconoscerli

I sistemi AI ad alto rischio sono la categoria più impegnativa dell’AI Act. Comportano adempimenti stringenti per tutto il ciclo di vita del sistema e generano costi di compliance significativi. Il legislatore europeo ha scelto un elenco tassativo, articolato in due sottocategorie.

2.1 Sistemi che sono prodotti o componenti di sicurezza di prodotti regolati

La prima sottocategoria, prevista dall’art. 6, par. 1, Reg. UE 2024/1689, riguarda i sistemi di IA che costituiscono un prodotto, o una componente di sicurezza di un prodotto, già disciplinato dalla normativa europea elencata nell’Allegato I del Regolamento. Si tratta di settori molto specifici e fortemente regolati: macchine, giocattoli, ascensori, dispositivi medici, dispositivi medico-diagnostici in vitro, veicoli, aeronautica, attrezzature a pressione, apparecchi che bruciano carburanti gassosi.

Perché un sistema rientri in questa categoria devono ricorrere due condizioni cumulative: il sistema deve essere un prodotto o una componente di sicurezza di un prodotto regolato dall’Allegato I, e quel prodotto deve essere soggetto a valutazione di conformità da parte di terzi prima dell’immissione sul mercato.

Per chi opera in questi settori, il vero tema è il raccordo tra normative. Il Considerando 51 chiarisce che la qualificazione come “alto rischio” ai sensi dell’AI Act non coincide necessariamente con la classificazione come alto rischio prevista dalle normative di settore (per esempio il Reg. UE 2017/745 sui dispositivi medici). Servirà quindi un’integrazione tra processi di compliance già esistenti e nuovi requisiti AI Act, evitando duplicazioni ma anche zone d’ombra.

2.2 Sistemi indipendenti: l’Allegato III

La seconda sottocategoria, definita “indipendente” perché non legata a prodotti regolati, è elencata in modo tassativo nell’Allegato III del Regolamento. Sono otto aree:

• biometria (identificazione biometrica remota, categorizzazione biometrica basata su attributi sensibili, riconoscimento delle emozioni);
• infrastrutture critiche (sistemi usati come componenti di sicurezza per traffico stradale, fornitura di acqua, gas, riscaldamento, elettricità, infrastrutture digitali critiche);
• istruzione e formazione professionale (sistemi per ammissione, valutazione dei risultati, orientamento, sorveglianza durante le prove);
• occupazione e gestione dei lavoratori (sistemi per selezione, valutazione delle prestazioni, decisioni su promozioni e cessazioni, assegnazione di compiti);
• accesso a servizi essenziali (valutazione dell’ammissibilità a prestazioni pubbliche, credit scoring, valutazione dei rischi nelle assicurazioni vita e sanitarie, smistamento delle chiamate di emergenza);
• attività di contrasto (valutazione del rischio di reato, poligrafi, profilazione in indagini);
• migrazione, asilo e controllo frontiere (valutazione del rischio, esame di domande di asilo e visto);
• amministrazione della giustizia e processi democratici (assistenza giudiziaria nell’interpretazione di fatti e diritto, sistemi che influenzano elezioni o referendum).

Per SaaS, web agency e aziende digitali questa lista è il primo punto di verifica. Un software HR che filtra candidature è alto rischio. Un sistema di credit scoring è alto rischio. Un tool di valutazione studenti è alto rischio. Anche se il sistema integra un GPAI di terzi tramite API, la qualificazione si fa sul sistema finale, non sul modello sottostante.

2.3 La deroga: quando un sistema dell’Allegato III non è alto rischio

L’art. 6, par. 3, Reg. UE 2024/1689 prevede una deroga: anche se un sistema rientra in una delle aree dell’Allegato III, può non essere classificato come alto rischio se “non presenta un rischio significativo di danno per la salute, la sicurezza o i diritti fondamentali” e non influenza materialmente il risultato del processo decisionale.

La deroga si applica solo se ricorre almeno una di queste quattro condizioni:

• il sistema esegue un compito procedurale limitato (per esempio trasforma dati non strutturati in strutturati, classifica documenti, rileva duplicati);
• il sistema è destinato a migliorare il risultato di un’attività umana già completata (per esempio rifinisce il tono di un testo già redatto);
• il sistema rileva schemi decisionali o deviazioni da schemi precedenti senza sostituire la valutazione umana;
• il sistema esegue un compito preparatorio per una valutazione (gestione documentale, indicizzazione, traduzione).

La deroga non si applica mai a sistemi che effettuano profilazione di persone fisiche. Il fornitore che intende avvalersene deve documentare la valutazione ex ante, prima di immettere il sistema sul mercato, e tenerla a disposizione delle autorità nazionali. Resta inoltre l’obbligo di registrazione nella banca dati UE prevista dall’art. 49, par. 2, del Regolamento.

Va sottolineato che si tratta di un’eccezione, da applicare in modo restrittivo. Il Considerando 53 parla di applicazione “in via eccezionale”. Per i sistemi dell’Allegato III opera una vera e propria presunzione di alto rischio, che il fornitore deve superare con una valutazione motivata.

3. I GPAI Models: cosa sono e quali obblighi generano

I GPAI Models sono i modelli di IA per finalità generali, disciplinati dal Capo V (artt. 51-56) del Regolamento. L’art. 3, n. 63, li definisce come modelli addestrati con grandi quantità di dati tramite autosupervisione su larga scala, caratterizzati da generalità significativa, capaci di svolgere con competenza un’ampia gamma di compiti distinti. GPT, Claude, Gemini, Llama sono GPAI Models. I modelli generativi sono indicati dallo stesso legislatore come esempio tipico.

3.1 GPAI standard e GPAI con rischio sistemico

Il Capo V distingue due insiemi:

• GPAI Models a finalità generali, con obblighi di documentazione tecnica e copyright;
• GPAI Models con rischio sistemico, con obblighi ulteriori di valutazione del rischio, sicurezza, notifica di incidenti gravi e cybersecurity.

Il rischio sistemico è definito dall’art. 3, n. 65, come il rischio specifico dei modelli di portata o impatto tale sul mercato UE da causare effetti negativi propagabili lungo la supply chain su salute pubblica, sicurezza, diritti fondamentali o società nel complesso.

L’art. 51 stabilisce i criteri di classificazione. Un modello si presume con capacità di impatto elevato se la potenza di calcolo usata per l’addestramento è pari o superiore a 10^25 FLOP (operazioni in virgola mobile). Soglia che oggi cattura solo i frontier model dei grandi laboratori. Il fornitore che integra questa soglia deve notificarlo alla Commissione entro due settimane (art. 52, par. 1). In alternativa, la Commissione può designare ex officio un modello come a rischio sistemico, anche su segnalazione del gruppo di esperti scientifici, valutando i criteri dell’Allegato XIII (numero di parametri, qualità del dataset, modalità input/output, impatto sul mercato interno, numero di utenti finali registrati).

Il fornitore può opporsi alla classificazione con una relazione motivata contestualmente alla notifica, oppure richiedere una nuova valutazione decorsi sei mesi (art. 52, par. 2 e par. 5).

3.2 Obblighi dei fornitori di GPAI standard

L’art. 53 individua quattro obblighi per i fornitori di GPAI standard:

• redigere e mantenere aggiornata la documentazione tecnica del modello, con il contenuto minimo previsto dall’Allegato XI, da fornire su richiesta all’Ufficio per l’AI e alle autorità nazionali;
• elaborare e mettere a disposizione dei fornitori a valle (cioè dei SaaS e delle aziende che integreranno il modello nei propri sistemi) una documentazione che consenta una buona comprensione delle capacità e dei limiti del modello, secondo l’Allegato XII, con il limite del segreto commerciale;
• attuare policy per la conformità al diritto d’autore UE, anche tramite strumenti automatizzati;
• elaborare e pubblicare una sintesi sufficientemente dettagliata dei contenuti usati per l’addestramento, secondo un modello che sarà fornito dall’Ufficio per l’AI.

I primi due obblighi documentali non si applicano ai fornitori di GPAI rilasciati con licenza libera e open source, salvo che il modello sia a rischio sistemico (art. 53, par. 2).

3.3 Obblighi aggiuntivi per i GPAI con rischio sistemico

I fornitori di GPAI con rischio sistemico, oltre agli obblighi dei GPAI standard, devono (art. 55):

• sottoporsi a valutazioni standardizzate del modello, anche tramite adversarial testing, per identificare e attenuare il rischio sistemico lungo tutto il ciclo di vita;
• attuare politiche di gestione del rischio sistemico con processi di governance e monitoraggio post-immissione;
• tracciare, documentare e notificare alle autorità competenti gli incidenti gravi e le misure correttive adottate;
• garantire un livello adeguato di cybersecurity per il modello e la sua infrastruttura fisica.

L’Ufficio per l’AI è l’autorità centralizzata di monitoraggio. I codici di buone pratiche previsti dall’art. 56 saranno strumento di presunzione di conformità fino alla pubblicazione di standard armonizzati. Le sanzioni sono significative: fino a 15 milioni di euro o, se l’autore è un’impresa, fino al 3% del fatturato mondiale annuo (art. 99, par. 4).

4. Provider, deployer, importer, distributor: il ruolo è tutto

Per un SaaS che integra GPT, per una web agency che sviluppa AI per i propri clienti, per un’azienda che adotta uno strumento AI di terzi, la domanda decisiva è una sola: quale ruolo sto giocando rispetto al sistema? L’AI Act distingue cinque figure, e a ciascuna corrispondono obblighi diversi.

4.1 Le cinque figure dell’AI Act

L’art. 3 del Regolamento definisce:

• fornitore (provider): chi sviluppa un sistema di IA o un GPAI, o lo fa sviluppare, e lo immette sul mercato o in servizio con il proprio nome o marchio, a titolo oneroso o gratuito;
• rappresentante autorizzato: persona fisica o giuridica nell’UE che, su mandato scritto del fornitore, ne adempie obblighi e procedure;
• importatore: persona stabilita nell’UE che immette sul mercato un sistema di IA recante nome o marchio di un soggetto stabilito in un paese terzo;
• distributore: persona della catena di approvvigionamento, diversa da fornitore e importatore, che mette a disposizione un sistema di IA sul mercato dell’Unione;
• deployer: chi utilizza un sistema di IA sotto la propria autorità, salvo l’uso personale non professionale.

La distinzione fornitore/deployer è la più critica per le aziende digitali. Chi sviluppa un’app legaltech che usa Claude via API per generare bozze contrattuali è di norma fornitore del sistema legaltech, mentre Anthropic è fornitore del modello GPAI sottostante. Chi adotta in azienda uno strumento di screening dei CV sviluppato da un vendor è deployer di quel sistema. Lo stesso soggetto può assumere ruoli diversi rispetto a sistemi diversi.

4.2 Cosa deve fare il fornitore di un sistema ad alto rischio

Il fornitore è il soggetto più gravato. Per i sistemi ad alto rischio deve garantire, prima dell’immissione sul mercato, la conformità a tutti i requisiti degli artt. 8-15 del Regolamento. In sintesi, deve:

• istituire un sistema di gestione dei rischi documentato e mantenuto per l’intero ciclo di vita (art. 9), che identifichi, analizzi e mitighi i rischi noti e ragionevolmente prevedibili per salute, sicurezza, diritti fondamentali, con attenzione ai minori e ai gruppi vulnerabili;
• attuare pratiche di governance e gestione dei dati (art. 10), inclusi controlli su rilevanza, rappresentatività, qualità, distorsioni dei dataset di addestramento, convalida e prova;
• redigere e mantenere aggiornata la documentazione tecnica secondo l’Allegato IV (art. 11), in forma semplificata per PMI e startup;
• implementare la registrazione automatica degli eventi (log) per garantire tracciabilità (art. 12);
• predisporre istruzioni d’uso chiare, complete e accessibili per i deployer (art. 13), che descrivano caratteristiche, capacità, limiti, misure di sorveglianza umana, requisiti hardware, manutenzione;
• progettare il sistema in modo che sia efficacemente supervisionabile da persone fisiche (art. 14);
• garantire accuratezza, robustezza e cybersecurity del sistema (art. 15), con misure contro data poisoning, model poisoning, adversarial examples, model evasion e attacchi alla riservatezza;
• istituire un sistema di gestione della qualità (art. 17);
• conservare per dieci anni documentazione tecnica, documentazione del sistema qualità, dichiarazione di conformità UE e log (artt. 18-19);
• sottoporre il sistema a valutazione di conformità (art. 43), elaborare la dichiarazione di conformità UE (art. 47), apporre la marcatura CE (art. 48), registrarlo nella banca dati UE (art. 49);
• adottare misure correttive se il sistema non è conforme e informare distributori, deployer, rappresentanti autorizzati e importatori (art. 20);
• garantire la conformità ai requisiti di accessibilità previsti dalle direttive UE 2016/2102 e 2019/882.

I fornitori stabiliti in paesi terzi devono nominare un rappresentante autorizzato nell’UE prima dell’immissione sul mercato.

4.3 Il fornitore “derivato”: quando il deployer diventa fornitore

Una regola che molte aziende sottovalutano. L’art. 25 del Regolamento prevede che distributore, importatore, deployer o altro terzo diventano fornitori a tutti gli effetti, con i relativi obblighi dell’art. 16, in tre casi:

• se appongono il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato (salvo diversa pattuizione contrattuale);
• se apportano una modifica sostanziale a un sistema ad alto rischio già immesso sul mercato in modo che resti ad alto rischio;
• se modificano la finalità prevista di un sistema (anche di un sistema per finalità generali non classificato come alto rischio) in modo da farlo diventare ad alto rischio.

Per un SaaS o una web agency, la portata pratica è enorme. Integrare un GPAI di terzi in un proprio prodotto, riconfigurarlo per un caso d’uso ad alto rischio, fare white labeling di soluzioni AI: tutte queste operazioni possono trasformare il soggetto in fornitore. Con tutto ciò che ne consegue: gestione del rischio, documentazione tecnica, marcatura CE, valutazione di conformità, conservazione decennale dei documenti. La diligenza contrattuale a monte — sul rapporto con il provider del modello o del sistema integrato — diventa essenziale per non assumersi inavvertitamente la posizione di fornitore.

4.4 Obblighi di importatori e distributori

L’importatore (art. 23) deve verificare, prima dell’immissione sul mercato, che il fornitore abbia eseguito la valutazione di conformità, redatto la documentazione tecnica, apposto la marcatura CE, predisposto dichiarazione di conformità e istruzioni d’uso, nominato un rappresentante autorizzato. Deve inoltre apporre i propri dati di contatto sul sistema o sui documenti di accompagnamento, conservare per dieci anni la documentazione di conformità, cooperare con le autorità e segnalare al fornitore eventuali rischi.

Il distributore (art. 24) verifica marcatura CE, dichiarazione di conformità, istruzioni d’uso, e che fornitore e importatore abbiano adempiuto ai propri obblighi. Non mette a disposizione il sistema se non conforme. Garantisce condizioni di stoccaggio e trasporto adeguate, fornisce informazioni alle autorità competenti e coopera con esse.

4.5 Cosa deve fare il deployer di un sistema ad alto rischio

Il deployer è la figura che più frequentemente coincide con le aziende clienti dello Studio: chi adotta in azienda strumenti AI sviluppati da terzi. Gli obblighi (art. 26) sono articolati. In sintesi, il deployer deve:

• usare il sistema conformemente alle istruzioni d’uso del fornitore e adottare misure tecniche e organizzative idonee;
• affidare la sorveglianza umana a persone fisiche con competenza, formazione e autorità adeguate;
• monitorare il funzionamento del sistema e informare il fornitore di anomalie o rischi;
• conservare i log generati automaticamente, sotto il proprio controllo, per almeno sei mesi;
• in caso di incidente grave, informare immediatamente fornitore, importatore, distributore e autorità di vigilanza;
• se il sistema, usato conformemente alle istruzioni, presenta un rischio, sospenderne l’uso e informare fornitore e autorità;
• prima di mettere in servizio un sistema ad alto rischio sul luogo di lavoro, informare rappresentanti dei lavoratori e lavoratori interessati;
• usare le informazioni dell’art. 13 per adempiere all’obbligo di valutazione d’impatto sulla protezione dei dati ex art. 35 GDPR;
• accertare che il sistema sia registrato nella banca dati UE;
• cooperare con le autorità competenti.

Per i deployer che usano sistemi di identificazione biometrica remota nelle attività di contrasto sono previste regole ulteriori, con autorizzazione giudiziaria o amministrativa.

4.6 Un adempimento specifico del deployer: la FRIA

Tra gli obblighi del deployer di sistemi ad alto rischio merita una menzione specifica la Valutazione d’Impatto sui Diritti Fondamentali, o FRIA (Fundamental Rights Impact Assessment), prevista dall’art. 27 del Regolamento.

Non è un adempimento generalizzato. La FRIA grava solo su alcuni deployer e solo per alcuni sistemi ad alto rischio. Devono effettuarla i deployer che sono organismi di diritto pubblico o enti privati che forniscono servizi pubblici, e i deployer di sistemi destinati al credit scoring e alla valutazione dei rischi nelle assicurazioni vita e sanitarie (Allegato III, n. 5, lett. b e c).

La FRIA è una valutazione ex ante, da condurre prima del primo uso del sistema, che deve comprendere: descrizione dei processi del deployer in cui il sistema sarà usato; periodo di utilizzo e frequenza; categorie di persone fisiche e gruppi verosimilmente interessati; rischi specifici di danno, tenendo conto delle informazioni del fornitore ex art. 13; descrizione delle misure di sorveglianza umana; misure da adottare in caso di concretizzazione dei rischi, incluse governance interna e meccanismi di reclamo.

Per usi successivi analoghi, il deployer può basarsi su FRIA precedenti, aggiornandole se necessario. L’Ufficio per l’AI metterà a disposizione un modello di questionario, anche tramite applicativo online, per agevolare l’adempimento.

La FRIA si applica dal 2 agosto 2026, ventiquattro mesi dopo l’entrata in vigore del Regolamento. Per i deployer interessati è uno degli adempimenti più complessi dell’AI Act, anche per la sovrapposizione parziale con la DPIA del GDPR, di cui parliamo in modo dedicato nella nostra guida alla FRIA.

5. Casi pratici: come orientarsi nello scenario reale

Tre situazioni ricorrenti per chi lavora con AI nel digitale.

SaaS che integra GPT per uno strumento di supporto alle vendite. Il SaaS è fornitore del proprio sistema; OpenAI è fornitore del GPAI sottostante. Se lo strumento si limita a generare email commerciali e proposte, di norma non è ad alto rischio: l’azienda dovrà comunque rispettare gli obblighi di trasparenza sui sistemi che interagiscono con persone fisiche (art. 50), garantire l’AI literacy del personale (art. 4) e gestire correttamente i dati nei prompt sotto il GDPR. Se invece lo stesso SaaS evolve verso uno strumento di scoring del valore dei lead basato su tratti personali, può scivolare nell’alto rischio. La modifica della finalità prevista è uno dei trigger che attivano il regime fornitore.

Web agency che sviluppa un sistema di screening dei CV per un cliente nel settore HR. Il sistema rientra nell’Allegato III, punto 4: occupazione e gestione dei lavoratori. È alto rischio. La web agency che lo sviluppa è fornitore. Il cliente che lo adotta è deployer. La filiera contrattuale deve riflettere chiaramente questa distribuzione di ruoli, prevedere la documentazione tecnica, le istruzioni d’uso ex art. 13, le misure di sorveglianza umana e la cooperazione necessaria al deployer per adempiere ai propri obblighi.

Banca che adotta un sistema di credit scoring fornito da un vendor. Il vendor è fornitore. La banca è deployer di un sistema ad alto rischio (Allegato III, punto 5, lett. b). Oltre agli obblighi generali del deployer, la banca deve condurre la FRIA ex art. 27. L’integrazione tra FRIA, DPIA e modelli di gestione del rischio già adottati in ambito bancario sarà uno dei nodi pratici più complessi.

Conclusione in sintesi