Vai al contenuto

AI Act e modelli GPAI: dal 2 agosto 2026 la governance diventa verificabile

AI Act e modelli GPAI: dal 2 agosto 2026 la governance diventa verificabile

Il 2 agosto 2026 non e una data lontana per chi usa, integra o sviluppa soluzioni basate su intelligenza artificiale generale. Da quella data la Commissione europea iniziera a esercitare i propri poteri di enforcement sugli obblighi dei provider di modelli GPAI, cioe i modelli di AI general-purpose che possono essere integrati in molti sistemi e applicazioni diverse.

Il punto non riguarda solo i grandi laboratori che addestrano modelli di frontiera. Riguarda anche imprese, pubbliche amministrazioni, software house, system integrator e professionisti che costruiscono servizi, automazioni, chatbot, strumenti di analisi documentale o agenti digitali usando modelli di terzi. Perche quando un modello entra in un processo aziendale, la domanda non e soltanto “funziona?”. La domanda corretta e: chi lo fornisce, con quali informazioni, per quali limiti, con quali rischi, con quali evidenze e con quali responsabilita lungo la catena del valore?

La Commissione europea ha pubblicato linee guida e strumenti di supporto per chiarire l’ambito degli obblighi sui modelli GPAI. Il messaggio e operativo: l’AI Act non chiede solo policy generiche, ma documentazione, tracciabilita, comprensione dei limiti del modello, gestione dei rischi e cooperazione tra chi sviluppa il modello e chi lo integra in sistemi concreti.

Che cosa sono i modelli GPAI

Nel linguaggio dell’AI Act, un modello general-purpose non e semplicemente un software intelligente. E un modello capace di svolgere un’ampia gamma di compiti e di essere integrato in molte applicazioni successive. I grandi modelli linguistici, i modelli multimodali e i modelli generativi usati tramite API, piattaforme cloud o componenti embedded rientrano spesso in questa logica.

Le linee guida della Commissione chiariscono che l’analisi non si ferma al nome commerciale del prodotto. Occorre capire se il modello ha significativa generalita, se puo generare contenuti o supportare compiti diversi, se viene immesso nel mercato dell’Unione e chi ne e il provider. Questa distinzione e importante perche l’AI Act separa il livello del modello dal livello del sistema AI costruito sopra quel modello.

Per un’organizzazione che usa AI, questo significa una cosa molto concreta: non basta censire le applicazioni finali. Bisogna censire anche i modelli sottostanti, i fornitori, le modalita di accesso, le integrazioni e i casi d’uso.

Gli obblighi non restano al provider

L’articolo 53 dell’AI Act prevede obblighi specifici per i provider di modelli GPAI: mantenere documentazione tecnica, mettere a disposizione informazioni ai provider di sistemi AI che integrano il modello, adottare una policy sul rispetto del diritto d’autore e pubblicare una sintesi sufficientemente dettagliata dei contenuti usati per l’addestramento, secondo il template dell’AI Office.

Questi obblighi sono formalmente in capo al provider del modello. Ma producono effetti lungo tutta la filiera. Se una software house integra un modello in un prodotto, ha bisogno di informazioni affidabili sulle capacita e sui limiti del modello per valutare il proprio sistema. Se una PA usa un assistente AI in un processo amministrativo, deve sapere quali dati vengono trattati, quali output sono prodotti e quali controlli restano umani. Se un’impresa usa un modello per supportare decisioni operative, deve poter dimostrare di aver valutato rischi, ruoli e misure.

In pratica, la governance GPAI diventa un tema di procurement, contratti, sicurezza, privacy, qualita, audit e gestione fornitori. Non e una nota a margine per il reparto legale.

Perche il 2 agosto 2026 conta

Gli obblighi per i provider GPAI sono entrati in applicazione il 2 agosto 2025. La Commissione ha pero indicato un primo periodo di collaborazione con i provider, soprattutto con chi aderisce al Code of Practice. Dal 2 agosto 2026, invece, i poteri di enforcement della Commissione diventano operativi, inclusa la possibilita di applicare sanzioni.

Questo passaggio cambia il tono della compliance. La fase del “ci stiamo preparando” deve lasciare spazio a evidenze verificabili: documentazione del modello, informazioni per gli integratori, gestione dei rischi, policy copyright, sintesi dei dati di addestramento e, per i modelli con rischio sistemico, misure ulteriori di valutazione, mitigazione, sicurezza e segnalazione degli incidenti.

Per chi integra modelli di terzi, la data e utile come campanello organizzativo. Anche se l’obbligo diretto ricade sul provider, l’organizzazione che usa AI deve chiedersi se sta ricevendo informazioni sufficienti per adempiere ai propri obblighi e per governare davvero il rischio.

Il ruolo del Code of Practice

Il General-Purpose AI Code of Practice e uno strumento volontario, ma importante, per dimostrare conformita agli obblighi sui modelli GPAI fino alla disponibilita di standard armonizzati. La Commissione lo presenta come supporto pratico per trasparenza, copyright, sicurezza e gestione dei rischi.

Questo non significa che firmare o richiamare un codice basti automaticamente a essere conformi. Significa piuttosto che il codice puo diventare una base comune per trasformare obblighi giuridici in misure operative. Per imprese e PA, il punto non e solo sapere se il fornitore ha aderito al codice. Il punto e capire che cosa quell’adesione produce nei contratti, nella documentazione fornita, nei controlli tecnici e nella gestione degli incidenti.

Quando un fornitore dichiara di usare un modello GPAI conforme o allineato al Code of Practice, conviene chiedere evidenze: quali informazioni sono disponibili sul modello, quali limiti sono dichiarati, quali usi sono esclusi, quali misure di sicurezza sono applicate, come vengono gestiti aggiornamenti, cambi di versione e incidenti.

Una mappa minima per imprese e PA

La prima azione pratica e costruire un inventario dei modelli AI utilizzati. Non deve essere perfetto al primo giorno, ma deve permettere di rispondere ad alcune domande essenziali:

  • quale modello o servizio AI viene usato;
  • chi e il provider e dove si colloca nella filiera;
  • in quali processi o prodotti viene integrato;
  • quali dati entrano nel sistema e quali output vengono generati;
  • se il modello e accessibile via API, piattaforma cloud, componente open source o soluzione proprietaria;
  • quali informazioni tecniche e contrattuali sono disponibili;
  • quali rischi sono stati valutati;
  • chi e responsabile del caso d’uso interno;
  • quali controlli umani, log e procedure di escalation sono previsti.

Questo inventario e la base per distinguere tra uso sperimentale, uso interno a basso impatto, integrazione in un servizio rivolto a clienti o cittadini, oppure uso in ambiti che possono diventare ad alto rischio.

Attenzione a open source e modifiche significative

Le linee guida chiariscono anche il tema open source. Alcune esenzioni possono applicarsi ai modelli rilasciati con licenza libera e aperta quando pesi, architettura e informazioni d’uso sono disponibili. Ma l’esenzione non vale per i modelli GPAI con rischio sistemico.

Inoltre, chi modifica significativamente un modello non puo limitarsi a dire “lo abbiamo solo adattato”. Fine-tuning, integrazioni profonde, messa a disposizione con un proprio marchio o cambiamenti sostanziali possono modificare il ruolo dell’operatore nella catena. Per questo serve una valutazione tecnica e contrattuale prima di portare un modello modificato in produzione.

Il tema e particolarmente rilevante per software house e integratori: usare componenti open source puo essere una scelta legittima e utile, ma richiede controllo su licenze, documentazione, sicurezza, versioni, dataset, limiti d’uso e responsabilita.

Checklist operativa

Prima di estendere l’uso di modelli GPAI, consiglio di verificare almeno questi punti:

  • esiste un inventario aggiornato dei modelli AI usati dall’organizzazione?
  • sono distinti modello, sistema AI, applicazione finale e caso d’uso?
  • il contratto con il fornitore prevede informazioni sufficienti su capacita, limiti, sicurezza e aggiornamenti?
  • e chiaro se i dati aziendali o personali vengono usati per training, fine-tuning, logging o miglioramento del servizio?
  • sono documentati controlli umani, responsabilita interne e criteri di escalation?
  • sono valutati rischi di copyright, sicurezza, privacy, bias, affidabilita e dipendenza dal fornitore?
  • gli aggiornamenti del modello vengono tracciati e rivalutati?
  • procurement, IT, legale, privacy, sicurezza e business lavorano sullo stesso quadro?

La risposta a queste domande non serve solo per “essere a posto”. Serve per decidere con lucidita dove l’AI puo creare valore e dove invece occorre prima rafforzare dati, contratti, controlli e responsabilita.

Conclusione

L’AI Act sta spostando la discussione dai principi generali alle evidenze. Nel caso dei modelli GPAI, questo significa documentazione, informazioni lungo la filiera, copyright policy, sintesi dei dati di addestramento, valutazione dei rischi e governance dei fornitori.

Chi usa modelli di terzi non deve attendere di essere obbligato direttamente dal legislatore per organizzarsi. Deve sapere quali modelli usa, dove sono integrati, quali dati trattano, quali limiti hanno e chi risponde delle decisioni operative.

Se stai introducendo AI generativa, agenti digitali o modelli integrati nei processi aziendali, posso aiutarti a costruire un inventario dei modelli, valutare rischi e contratti, e impostare una governance proporzionata. Seguimi o contattami per trasformare l’AI Act da adempimento a metodo di lavoro.

Fonti

Tag:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *